summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-11-10Merge remote-tracking branch 'asoc/topic/rockchip' into asoc-nextMark Brown
2017-11-10Merge remote-tracking branch 'asoc/topic/rcar' into asoc-nextMark Brown
2017-11-10Merge remote-tracking branch 'asoc/topic/qcom' into asoc-nextMark Brown
2017-11-10Merge remote-tracking branch 'asoc/topic/pcm512x' into asoc-nextMark Brown
2017-11-10Merge remote-tracking branch 'asoc/topic/intel' into asoc-nextMark Brown
2017-11-10Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown
2017-11-10Merge remote-tracking branch 'asoc/topic/core' into asoc-nextMark Brown
2017-11-10Merge remote-tracking branch 'asoc/topic/component' into asoc-nextMark Brown
2017-11-10Merge remote-tracking branch 'asoc/fix/sunxi' into asoc-linusMark Brown
2017-11-10Merge remote-tracking branch 'asoc/fix/intel' into asoc-linusMark Brown
2017-11-10Merge tag 'asoc-fix-v4.14-rc6' into asoc-linusMark Brown
ASoC: Fixes for v4.14 I've been quite lax in sending these due to conference season but here's a fairly large collection of ASoC updates. The one thing that's not device specific is Takashi's fix for races between delayed work and PCM destruction, otherwise everything is specific to an individual device. # gpg: Signature made Thu 26 Oct 2017 15:11:23 BST # gpg: using RSA key ADE668AA675718B59FE29FEA24D68B725D5487D0 # gpg: issuer "broonie@kernel.org" # gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>" [unknown] # gpg: aka "Mark Brown <broonie@debian.org>" [unknown] # gpg: aka "Mark Brown <broonie@kernel.org>" [unknown] # gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>" [unknown] # gpg: aka "Mark Brown <broonie@linaro.org>" [unknown] # gpg: aka "Mark Brown <Mark.Brown@linaro.org>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 3F25 68AA C269 98F9 E813 A1C5 C3F4 36CA 30F5 D8EB # Subkey fingerprint: ADE6 68AA 6757 18B5 9FE2 9FEA 24D6 8B72 5D54 87D0
2017-11-10spi: imx: Don't require platform data chipselect arrayTrent Piepho
If the array is not present, assume all chip selects are native. This is the standard behavior for SPI masters configured via the device tree and the behavior of this driver as well when it is configured via device tree. This reduces platform data vs DT differences and allows most of the platform data based boards to remove their chip select arrays. CC: Shawn Guo <shawnguo@kernel.org> CC: Sascha Hauer <kernel@pengutronix.de> CC: Fabio Estevam <fabio.estevam@nxp.com> CC: Mark Brown <broonie@kernel.org> Signed-off-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10spi: imx: Fix failure path leak on GPIO request errorTrent Piepho
If the code that requests any chip select GPIOs fails, the cleanup of spi_bitbang_start() by calling spi_bitbang_stop() is not done. Add this to the failure path. Note that spi_bitbang_start() has to be called before requesting GPIOs because the GPIO data in the spi master is populated when the master is registed, and that doesn't happen until spi_bitbang_start() is called. CC: Shawn Guo <shawnguo@kernel.org> CC: Sascha Hauer <kernel@pengutronix.de> CC: Fabio Estevam <fabio.estevam@nxp.com> CC: Mark Brown <broonie@kernel.org> CC: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10spi: imx: GPIO based chip selects should not be requiredTrent Piepho
The driver will fail to load if no gpio chip selects are specified, this patch changes this so that it no longer fails. It's possible to use all native chip selects, in which case there is no reason to have a gpio chip select array. This is what happens if the *optional* device tree property "cs-gpios" is omitted. The spi core already checks for the absence of gpio chip selects in the master and assigns any slaves the gpio_cs value of -ENOENT. Also have the driver respect the standard SPI device tree property "num-cs" to allow setting the number of chip selects without using cs-gpios. CC: Mark Brown <broonie@kernel.org> CC: Shawn Guo <shawnguo@kernel.org> CC: Sascha Hauer <kernel@pengutronix.de> CC: Fabio Estevam <fabio.estevam@nxp.com> CC: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10ASoC: bcm2835: Support left/right justified and DSP modesMatthias Reichl
DSP modes and left/right justified modes can be supported on bcm2835 by configuring the frame sync polarity and frame sync length registers and by adjusting the channel data position registers. Clock and frame sync polarity handling in hw_params has been refactored to make the interaction between logical rising/falling edge frame start and physical configuration (changed by normal/inverted polarity modes) clearer. Modes where the first active data bit is transmitted immediately after frame start (eg DSP mode B with slot 0 active) only work reliable if bcm2835 is configured as frame master. In frame slave mode channel swap (or shift, this isn't quite clear yet) can occur. Currently the driver only warns if an unstable configuration is detected but doensn't prevent using them. Signed-off-by: Matthias Reichl <hias@horus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10ASoC: bcm2835: Enforce full symmetryMatthias Reichl
bcm2835's configuration registers can't be changed when a stream is running, which means asymmetric configurations aren't supported. Channel and rate symmetry are already enforced by constraints but samplebits had been missed. As hw_params doesn't check for symmetry constraints by itself and just returns success if a stream is running this led to situations where asymmetric configurations were seeming to succeed but of course didn't work because the hardware wasn't configured at all. Fix this by adding the missing samplerate symmetry constraint. Signed-off-by: Matthias Reichl <hias@horus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10ASoC: bcm2835: Support additional samplerates up to 384kHzMatthias Reichl
Sample rates are only restricted by the capabilities of the clock driver, so use SNDRV_PCM_RATE_CONTINUOUS instead of SNDRV_PCM_RATE_8000_192000. Tests (eg with pcm5122) have shown that bcm2835 works fine in 384kHz/32bit stereo mode, so change the maximum allowed rate from 192kHz to 384kHz. Signed-off-by: Matthias Reichl <hias@horus.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10ASoC: bcm2835: Add support for TDM modesMatthias Reichl
bcm2835 supports arbitrary positioning of channel data within a frame and thus is capable of supporting TDM modes. Since the driver is limited to 2-channel operations only TDM setups with exactly 2 active slots are supported. Logical TDM slot numbering follows the usual convention: For I2S-like modes, with a 50% duty-cycle frame clock, slots 0, 2, ... are transmitted in the first half of a frame, slots 1, 3, ... are transmitted in the second half. For DSP modes slot numbering is ascending: 0, 1, 2, 3, ... Channel position calculation has been refactored to use TDM info and moved out of hw_params. set_tdm_slot, set_bclk_ratio and hw_params now check more strictly if the configuration is valid. Illegal configurations like odd number of slots in I2S mode, data lengths exceeding slot width or frame sizes larger than the hardware limit of 1024 are rejected. Also hw_params now properly checks for errors from clk_set_rate. Allowed PCM formats are already guarded by stream constraints, thus the formats check in hw_params has been removed and data_length is now retrieved via params_width(). Also standard functions like snd_soc_params_to_bclk are now being used instead of manual calculations to make the code more readable. Special care has been taken to ensure that set_bclk_ratio works as before. The bclk ratio is mapped to a 2-channel TDM config with a slot width of half the ratio. In order to support odd ratios, which can't be expressed via a TDM config, the ratio (frame length) is stored and used by hw_params. Signed-off-by: Matthias Reichl <hias@horus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10ASoC: add mclk-fs support to audio graph cardOlivier Moysan
Add mclk-fs support to audio graph card as it was previously implemented in simple card. Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10ASoC: add mclk-fs to audio graph card bindingOlivier Moysan
Add mclk-fs support to audio graph card as initially supported in simple card. Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10ASoC: rt5514: work around link errorArnd Bergmann
The main rt5514 driver optionally calls into the SPI back-end to load the firmware. This causes a link error when one driver selects rt5514 as built-in and another driver selects rt5514-spi as a loadable module: sound/soc/codecs/rt5514.o: In function `rt5514_dsp_voice_wake_up_put': rt5514.c:(.text+0xac8): undefined reference to `rt5514_spi_burst_write' As a workaround, this adds another silent symbol, to force rt5514-spi to be built-in for that configuration. I'm not overly happy with that solution, but couldn't come up with anything better. Using 'IS_REACHABLE()' would break the case that relies on the loadable module, and all other ideas would result in more complexity. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10ASoC: rt5514: mark PM functions as __maybe_unusedArnd Bergmann
The new functions are only used when CONFIG_PM is enabled, leading to a harmless warning: sound/soc/codecs/rt5514-spi.c:474:12: error: 'rt5514_resume' defined but not used [-Werror=unused-function] sound/soc/codecs/rt5514-spi.c:464:12: error: 'rt5514_suspend' defined but not used [-Werror=unused-function] This marks them as __maybe_unused to make the build silent again. Fixes: 58f1c07d23cd ("ASoC: rt5514: Voice wakeup support.") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-10audit: filter PATH records keyed on filesystem magicRichard Guy Briggs
Tracefs or debugfs were causing hundreds to thousands of PATH records to be associated with the init_module and finit_module SYSCALL records on a few modules when the following rule was in place for startup: -a always,exit -F arch=x86_64 -S init_module -F key=mod-load Provide a method to ignore these large number of PATH records from overwhelming the logs if they are not of interest. Introduce a new filter list "AUDIT_FILTER_FS", with a new field type AUDIT_FSTYPE, which keys off the filesystem 4-octet hexadecimal magic identifier to filter specific filesystem PATH records. An example rule would look like: -a never,filesystem -F fstype=0x74726163 -F key=ignore_tracefs -a never,filesystem -F fstype=0x64626720 -F key=ignore_debugfs Arguably the better way to address this issue is to disable tracefs and debugfs on boot from production systems. See: https://github.com/linux-audit/audit-kernel/issues/16 See: https://github.com/linux-audit/audit-userspace/issues/8 Test case: https://github.com/linux-audit/audit-testsuite/issues/42 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> [PM: fixed the whitespace damage in kernel/auditsc.c] Signed-off-by: Paul Moore <paul@paul-moore.com>
2017-11-10Audit: remove unused audit_log_secctx functionCasey Schaufler
The function audit_log_secctx() is unused in the upstream kernel. All it does is wrap another function that doesn't need wrapping. It claims to give you the SELinux context, but that is not true if you are using a different security module. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: James Morris <james.l.morris@oracle.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2017-11-10audit: Allow auditd to set pid to 0 to end auditingSteve Grubb
The API to end auditing has historically been for auditd to set the pid to 0. This patch restores that functionality. See: https://github.com/linux-audit/audit-kernel/issues/69 Reviewed-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Steve Grubb <sgrubb@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2017-11-10audit: Add new syscalls to the perm=w filterSteve Grubb
The audit subsystem allows selecting audit events based on watches for a particular behavior like writing to a file. A lot of syscalls have been added without updating the list. This patch adds 2 syscalls to the write filters: fallocate and renameat2. Signed-off-by: Steve Grubb <sgrubb@redhat.com> Reviewed-by: Richard Guy Briggs <rgb@redhat.com> [PM: cleaned up some whitespace errors] Signed-off-by: Paul Moore <paul@paul-moore.com>
2017-11-10audit: use audit_set_enabled() in audit_enable()Paul Moore
Use audit_set_enabled() to enable auditing during early boot. This obviously won't emit an audit change record, but it will work anyway and should help prevent in future problems by consolidating the enable/disable code in one function. Reviewed-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2017-11-10audit: convert audit_ever_enabled to a booleanPaul Moore
We were treating it as a boolean, let's make it a boolean to help avoid future mistakes. Reviewed-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2017-11-10audit: don't use simple_strtol() anymorePaul Moore
The simple_strtol() function is deprecated, use kstrtol() instead. Reviewed-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2017-11-10audit: initialize the audit subsystem as early as possiblePaul Moore
We can't initialize the audit subsystem until after the network layer is initialized (core_initcall), but do it soon after. Reviewed-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2017-11-10audit: ensure that 'audit=1' actually enables audit for PID 1Paul Moore
Prior to this patch we enabled audit in audit_init(), which is too late for PID 1 as the standard initcalls are run after the PID 1 task is forked. This means that we never allocate an audit_context (see audit_alloc()) for PID 1 and therefore miss a lot of audit events generated by PID 1. This patch enables audit as early as possible to help ensure that when PID 1 is forked it can allocate an audit_context if required. Reviewed-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2017-11-10MIPS: Fix odd fp register warnings with MIPS64r2James Hogan
Building 32-bit MIPS64r2 kernels produces warnings like the following on certain toolchains (such as GNU assembler 2.24.90, but not GNU assembler 2.28.51) since commit 22b8ba765a72 ("MIPS: Fix MIPS64 FP save/restore on 32-bit kernels"), due to the exposure of fpu_save_16odd from fpu_save_double and fpu_restore_16odd from fpu_restore_double: arch/mips/kernel/r4k_fpu.S:47: Warning: float register should be even, was 1 ... arch/mips/kernel/r4k_fpu.S:59: Warning: float register should be even, was 1 ... This appears to be because .set mips64r2 does not change the FPU ABI to 64-bit when -march=mips64r2 (or e.g. -march=xlp) is provided on the command line on that toolchain, from the default FPU ABI of 32-bit due to the -mabi=32. This makes access to the odd FPU registers invalid. Fix by explicitly changing the FPU ABI with .set fp=64 directives in fpu_save_16odd and fpu_restore_16odd, and moving the undefine of fp up in asmmacro.h so fp doesn't turn into $30. Fixes: 22b8ba765a72 ("MIPS: Fix MIPS64 FP save/restore on 32-bit kernels") Signed-off-by: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 4.0+: 22b8ba765a72: MIPS: Fix MIPS64 FP save/restore on 32-bit kernels Cc: <stable@vger.kernel.org> # 4.0+ Patchwork: https://patchwork.linux-mips.org/patch/17656/
2017-11-10dm cache: lift common migration preparation code to alloc_migration()Mike Snitzer
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm cache: remove usused deferred_cells member from struct cacheJoe Thornber
Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm cache policy smq: allocate cache blocks in orderJoe Thornber
Previously, cache blocks were being allocated in reverse order. Fix this by pulling the block off the head of the free list. Shouldn't have any impact on performance or latency but it is more correct to have the cache blocks allocated/mapped in ascending order. This fix will slightly increase the chances of two adjacent oblocks being in adjacent cblocks. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm cache policy smq: change max background work from 10240 to 4096 blocksJoe Thornber
10240 blocks was too much, lowering this reduces the latency of copying and consumes less memory. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm cache background tracker: limit amount of background work that may be ↵Joe Thornber
issued at once On large systems the cache policy can be over enthusiastic and queue far too much dirty data to be written back. This consumes memory. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm cache policy smq: take origin idle status into account when queuing ↵Joe Thornber
writebacks If the origin device is idle try and writeback more data. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm cache policy smq: handle races with queuing background_workJoe Thornber
The background_tracker holds a set of promotions/demotions that the cache policy wishes the core target to implement. When adding a new operation to the tracker it's possible that an operation on the same block is already present (but in practise this doesn't appear to be happening). Catch these situations and do the appropriate cleanup. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm raid: fix panic when attempting to force a raid to syncHeinz Mauelshagen
Requesting a sync on an active raid device via a table reload (see 'sync' parameter in Documentation/device-mapper/dm-raid.txt) skips the super_load() call that defines the superblock size (rdev->sb_size) -- resulting in an oops if/when super_sync()->memset() is called. Fix by moving the initialization of the superblock start and size out of super_load() to the caller (analyse_superblocks). Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm integrity: allow unaligned bv_offsetMikulas Patocka
When slub_debug is enabled kmalloc returns unaligned memory. XFS uses this unaligned memory for its buffers (if an unaligned buffer crosses a page, XFS frees it and allocates a full page instead - see the function xfs_buf_allocate_memory). dm-integrity checks if bv_offset is aligned on page size and this check fail with slub_debug and XFS. Fix this bug by removing the bv_offset check, leaving only the check for bv_len. Fixes: 7eada909bfd7 ("dm: add integrity target") Cc: stable@vger.kernel.org # v4.12+ Reported-by: Bruno Prémont <bonbons@sysophe.eu> Reviewed-by: Milan Broz <gmazyland@gmail.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm crypt: allow unaligned bv_offsetMikulas Patocka
When slub_debug is enabled kmalloc returns unaligned memory. XFS uses this unaligned memory for its buffers (if an unaligned buffer crosses a page, XFS frees it and allocates a full page instead - see the function xfs_buf_allocate_memory). dm-crypt checks if bv_offset is aligned on page size and these checks fail with slub_debug and XFS. Fix this bug by removing the bv_offset checks. Switch to checking if bv_len is aligned instead of bv_offset (this check should be sufficient to prevent overruns if a bio with too small bv_len is received). Fixes: 8f0009a22517 ("dm crypt: optionally support larger encryption sector size") Cc: stable@vger.kernel.org # v4.12+ Reported-by: Bruno Prémont <bonbons@sysophe.eu> Tested-by: Bruno Prémont <bonbons@sysophe.eu> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Milan Broz <gmazyland@gmail.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm: small cleanup in dm_get_md()Mike Snitzer
Makes dm_get_md() and dm_get_from_kobject() have similar code. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm: fix race between dm_get_from_kobject() and __dm_destroy()Hou Tao
The following BUG_ON was hit when testing repeat creation and removal of DM devices: kernel BUG at drivers/md/dm.c:2919! CPU: 7 PID: 750 Comm: systemd-udevd Not tainted 4.1.44 Call Trace: [<ffffffff81649e8b>] dm_get_from_kobject+0x34/0x3a [<ffffffff81650ef1>] dm_attr_show+0x2b/0x5e [<ffffffff817b46d1>] ? mutex_lock+0x26/0x44 [<ffffffff811df7f5>] sysfs_kf_seq_show+0x83/0xcf [<ffffffff811de257>] kernfs_seq_show+0x23/0x25 [<ffffffff81199118>] seq_read+0x16f/0x325 [<ffffffff811de994>] kernfs_fop_read+0x3a/0x13f [<ffffffff8117b625>] __vfs_read+0x26/0x9d [<ffffffff8130eb59>] ? security_file_permission+0x3c/0x44 [<ffffffff8117bdb8>] ? rw_verify_area+0x83/0xd9 [<ffffffff8117be9d>] vfs_read+0x8f/0xcf [<ffffffff81193e34>] ? __fdget_pos+0x12/0x41 [<ffffffff8117c686>] SyS_read+0x4b/0x76 [<ffffffff817b606e>] system_call_fastpath+0x12/0x71 The bug can be easily triggered, if an extra delay (e.g. 10ms) is added between the test of DMF_FREEING & DMF_DELETING and dm_get() in dm_get_from_kobject(). To fix it, we need to ensure the test of DMF_FREEING & DMF_DELETING and dm_get() are done in an atomic way, so _minor_lock is used. The other callers of dm_get() have also been checked to be OK: some callers invoke dm_get() under _minor_lock, some callers invoke it under _hash_lock, and dm_start_request() invoke it after increasing md->open_count. Cc: stable@vger.kernel.org Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm: allocate struct mapped_device with kvzallocMikulas Patocka
The structure srcu_struct can be very big, its size is proportional to the value CONFIG_NR_CPUS. The Fedora kernel has CONFIG_NR_CPUS 8192, the field io_barrier in the struct mapped_device has 84kB in the debugging kernel and 50kB in the non-debugging kernel. The large size may result in failure of the function kzalloc_node. In order to avoid the allocation failure, we use the function kvzalloc_node, this function falls back to vmalloc if a large contiguous chunk of memory is not available. This patch also moves the field io_barrier to the last position of struct mapped_device - the reason is that on many processor architectures, short memory offsets result in smaller code than long memory offsets - on x86-64 it reduces code size by 320 bytes. Note to stable kernel maintainers - the kernels 4.11 and older don't have the function kvzalloc_node, you can use the function vzalloc_node instead. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm zoned: ignore last smaller runt zoneDamien Le Moal
The SCSI layer allows ZBC drives to have a smaller last runt zone. For such a device, specifying the entire capacity for a dm-zoned target table entry fails because the specified capacity is not aligned on a device zone size indicated in the request queue structure of the device. Fix this problem by ignoring the last runt zone in the entry length when seting up the dm-zoned target (ctr method) and when iterating table entries of the target (iterate_devices method). This allows dm-zoned users to still easily setup a target using the entire device capacity (as mandated by dm-zoned) or the aligned capacity excluding the last runt zone. While at it, replace direct references to the device queue chunk_sectors limit with calls to the accessor blk_queue_zone_sectors(). Reported-by: Peter Desnoyers <pjd@ccs.neu.edu> Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm space map metadata: use ARRAY_SIZEJérémy Lefaure
Using the ARRAY_SIZE macro improves the readability of the code. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p /sizeof(T)) ) Signed-off-by: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm log writes: add support for DAXRoss Zwisler
Now that we have the ability log filesystem writes using a flat buffer, add support for DAX. The motivation for this support is the need for an xfstest that can test the new MAP_SYNC DAX flag. By logging the filesystem activity with dm-log-writes we can show that the MAP_SYNC page faults are writing out their metadata as they happen, instead of requiring an explicit msync/fsync. Unfortunately we can't easily track data that has been written via mmap() now that the dax_flush() abstraction was removed by commit c3ca015fab6d ("dax: remove the pmem_dax_ops->flush abstraction"). Otherwise we could just treat each flush as a big write, and store the data that is being synced to media. It may be worthwhile to add the dax_flush() entry point back, just as a notifier so we can do this logging. Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm log writes: add support for inline data buffersRoss Zwisler
Currently dm-log-writes supports writing filesystem data via BIOs, and writing internal metadata from a flat buffer via write_metadata(). For DAX writes, though, we won't have a BIO, but will instead have an iterator that we'll want to use to fill a flat data buffer. So, create write_inline_data() which allows us to write filesystem data using a flat buffer as a source, and wire it up in log_one_block(). Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2017-11-10dm cache: simplify get_per_bio_data() by removing data_size argumentMike Snitzer
There is only one per_bio_data size now that writethrough-specific data was removed from the per_bio_data structure. Signed-off-by: Mike Snitzer <snitzer@redhat.com>