aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-07nvme: update the known admin effectsChristoph Hellwig1-2/+2
A Format NVM command can change the capabilities of namespaces, while Sanitize does change the Logical Block Content and must be serialized. Also remove CSUPP bit for Format - it is not a mandatory command, and we don't check for the bit anyway. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: set the queue limits in nvme_update_ns_infoChristoph Hellwig1-25/+21
Only set the queue limits once we have the real block size. This also updates the limits on a rescan if needed. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: remove the 0 lba_shift check in nvme_update_ns_infoChristoph Hellwig1-6/+0
We can no longer reach this code if Identify Namespace failed. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: clean up the check for too large logic block sizesChristoph Hellwig1-8/+5
Use a single statement to set both the capacity and fake block size instead of two. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]>
2020-10-07nvme: freeze the queue over ->lba_shift updatesChristoph Hellwig1-6/+14
Ensure that there can't be any I/O in flight went we change the disk geometry in nvme_update_ns_info, most notable the LBA size by lifting the queue free from nvme_update_disk_info into the caller Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: factor out a nvme_configure_metadata helperChristoph Hellwig1-31/+47
Factor out a helper from nvme_update_ns_info that configures the per-namespaces metadata and PI settings. Also make sure the helpers clear the flags explicitly instead of all of ->features to allow for potentially reusing ->features for future non-metadata flags. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: call nvme_identify_ns as the first thing in nvme_alloc_ns_blockChristoph Hellwig1-8/+7
Check if the namespace actually exists as the very first thing and don't bother with any extra work if not. This should speed up and simplify the sequential scanning for NVMe 1.0 devices. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: lift the check for an unallocated namespace into nvme_identify_nsChristoph Hellwig1-9/+8
Move the check from the two callers into the common helper. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]>
2020-10-07nvme: rename __nvme_revalidate_diskChristoph Hellwig1-5/+4
Rename __nvme_revalidate_disk to nvme_update_ns_info and pass a namespace instead of the gendisk. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: rename _nvme_revalidate_diskChristoph Hellwig1-7/+6
Rename _nvme_revalidate_disk to nvme_validate_ns to better describe what the function does, and pass the struct nvme_ns instead of the gendisk to better match the call chain. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: rename nvme_validate_ns to nvme_validate_or_alloc_nsChristoph Hellwig1-3/+3
Use a slightly more descriptive name to enable reusing nvme_validate_ns in the next patch for a lower level function. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: remove the disk argument to nvme_update_zone_infoChristoph Hellwig3-10/+5
The queue can trivially be derived from the nvme_ns structure. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme: fix initialization of the zone bitmapsChristoph Hellwig3-23/+17
The removal of the ->revalidate_disk method broke the initialization of the zone bitmaps, as nvme_revalidate_disk now never gets called during initialization. Move the zone related code from nvme_revalidate_disk into a new helper in zns.c, and call it from nvme_alloc_ns in addition to nvme_validate_ns to ensure the zone bitmaps are initialized during probe. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07block: optimize blk_queue_zoned_model for !CONFIG_BLK_DEV_ZONEDChristoph Hellwig1-1/+3
Always return BLK_ZONED_NONE if zoned device support is not enabled. This allows various compiler optimizations including the dead code elimination that we so like for avoiding ifdefs. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2020-10-07nvme-loop: don't put ctrl on nvme_init_ctrl errorChaitanya Kulkarni1-2/+2
The function nvme_init_ctrl() gets the ctrl reference & when it fails it does put the ctrl reference in the error unwind code. When creating loop ctrl in nvme_loop_create_ctrl() if nvme_init_ctrl() returns non zero (i.e. error) value it jumps to the "out_put_ctrl" label which calls nvme_put_ctrl(), that will lead to douple ctrl put in error unwind path. Update nvme_loop_create_ctrl() such that this patch removes the "out_put_ctrl" label, add a new "out" label after nvme_put_ctrl() in error unwind path and jump to newly added label when nvme_init_ctrl() call retuns an error. Signed-off-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2020-10-07nvme-core: put ctrl ref when module ref get failChaitanya Kulkarni1-1/+3
When try_module_get() fails in the nvme_dev_open() it returns without releasing the ctrl reference which was taken earlier. Put the ctrl reference which is taken before calling the try_module_get() in the error return code path. Fixes: 52a3974feb1a "nvme-core: get/put ctrl and transport module in nvme_dev_open/release()" Signed-off-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2020-10-07drm/nouveau/mem: guard against NULL pointer access in mem_delKarol Herbst1-0/+2
other drivers seems to do something similar Signed-off-by: Karol Herbst <[email protected]> Cc: dri-devel <[email protected]> Cc: Dave Airlie <[email protected]> Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-07drm/nouveau/device: return error for unknown chipsetsKarol Herbst1-0/+1
Previously the code relied on device->pri to be NULL and to fail probing later. We really should just return an error inside nvkm_device_ctor for unsupported GPUs. Fixes: 24d5ff40a732 ("drm/nouveau/device: rework mmio mapping code to get rid of second map") Signed-off-by: Karol Herbst <[email protected]> Cc: dann frazier <[email protected]> Cc: dri-devel <[email protected]> Cc: Dave Airlie <[email protected]> Cc: [email protected] Reviewed-by: Jeremy Cline <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-07exfat: fix use of uninitialized spinlock on error pathNamjae Jeon4-15/+6
syzbot reported warning message: Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d6/0x29e lib/dump_stack.c:118 register_lock_class+0xf06/0x1520 kernel/locking/lockdep.c:893 __lock_acquire+0xfd/0x2ae0 kernel/locking/lockdep.c:4320 lock_acquire+0x148/0x720 kernel/locking/lockdep.c:5029 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151 spin_lock include/linux/spinlock.h:354 [inline] exfat_cache_inval_inode+0x30/0x280 fs/exfat/cache.c:226 exfat_evict_inode+0x124/0x270 fs/exfat/inode.c:660 evict+0x2bb/0x6d0 fs/inode.c:576 exfat_fill_super+0x1e07/0x27d0 fs/exfat/super.c:681 get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342 vfs_get_tree+0x88/0x270 fs/super.c:1547 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x179d/0x29e0 fs/namespace.c:3192 do_mount fs/namespace.c:3205 [inline] __do_sys_mount fs/namespace.c:3413 [inline] __se_sys_mount+0x126/0x180 fs/namespace.c:3390 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 If exfat_read_root() returns an error, spinlock is used in exfat_evict_inode() without initialization. This patch combines exfat_cache_init_inode() with exfat_inode_init_once() to initialize spinlock by slab constructor. Fixes: c35b6810c495 ("exfat: add exfat cache") Cc: [email protected] # v5.7+ Reported-by: syzbot <[email protected]> Signed-off-by: Namjae Jeon <[email protected]>
2020-10-07exfat: fix pointer error checkingTetsuhiro Kohada1-7/+6
Fix missing result check of exfat_build_inode(). And use PTR_ERR_OR_ZERO instead of PTR_ERR. Signed-off-by: Tetsuhiro Kohada <[email protected]> Signed-off-by: Namjae Jeon <[email protected]>
2020-10-07arm/arm64: xen: Fix to convert percpu address to gfn correctlyMasami Hiramatsu2-1/+4
Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu address conversion. In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted to gfn by virt_to_gfn() macro. However, since the virt_to_gfn(v) assumes the given virtual address is in linear mapped kernel memory area, it can not convert the per-cpu memory if it is allocated on vmalloc area. This depends on CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK. If it is enabled, the first chunk of percpu memory is linear mapped. In the other case, that is allocated from vmalloc area. Moreover, if the first chunk of percpu has run out until allocating xen_vcpu_info, it will be allocated on the 2nd chunk, which is based on kernel memory or vmalloc memory (depends on CONFIG_NEED_PER_CPU_KM). Without this fix and kernel configured to use vmalloc area for the percpu memory, the Dom0 kernel will fail to boot with following errors. [ 0.466172] Xen: initializing cpu0 [ 0.469601] ------------[ cut here ]------------ [ 0.474295] WARNING: CPU: 0 PID: 1 at arch/arm64/xen/../../arm/xen/enlighten.c:153 xen_starting_cpu+0x160/0x180 [ 0.484435] Modules linked in: [ 0.487565] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4+ #4 [ 0.493895] Hardware name: Socionext Developer Box (DT) [ 0.499194] pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) [ 0.504836] pc : xen_starting_cpu+0x160/0x180 [ 0.509263] lr : xen_starting_cpu+0xb0/0x180 [ 0.513599] sp : ffff8000116cbb60 [ 0.516984] x29: ffff8000116cbb60 x28: ffff80000abec000 [ 0.522366] x27: 0000000000000000 x26: 0000000000000000 [ 0.527754] x25: ffff80001156c000 x24: fffffdffbfcdb600 [ 0.533129] x23: 0000000000000000 x22: 0000000000000000 [ 0.538511] x21: ffff8000113a99c8 x20: ffff800010fe4f68 [ 0.543892] x19: ffff8000113a9988 x18: 0000000000000010 [ 0.549274] x17: 0000000094fe0f81 x16: 00000000deadbeef [ 0.554655] x15: ffffffffffffffff x14: 0720072007200720 [ 0.560037] x13: 0720072007200720 x12: 0720072007200720 [ 0.565418] x11: 0720072007200720 x10: 0720072007200720 [ 0.570801] x9 : ffff8000100fbdc0 x8 : ffff800010715208 [ 0.576182] x7 : 0000000000000054 x6 : ffff00001b790f00 [ 0.581564] x5 : ffff800010bbf880 x4 : 0000000000000000 [ 0.586945] x3 : 0000000000000000 x2 : ffff80000abec000 [ 0.592327] x1 : 000000000000002f x0 : 0000800000000000 [ 0.597716] Call trace: [ 0.600232] xen_starting_cpu+0x160/0x180 [ 0.604309] cpuhp_invoke_callback+0xac/0x640 [ 0.608736] cpuhp_issue_call+0xf4/0x150 [ 0.612728] __cpuhp_setup_state_cpuslocked+0x128/0x2c8 [ 0.618030] __cpuhp_setup_state+0x84/0xf8 [ 0.622192] xen_guest_init+0x324/0x364 [ 0.626097] do_one_initcall+0x54/0x250 [ 0.630003] kernel_init_freeable+0x12c/0x2c8 [ 0.634428] kernel_init+0x1c/0x128 [ 0.637988] ret_from_fork+0x10/0x18 [ 0.641635] ---[ end trace d95b5309a33f8b27 ]--- [ 0.646337] ------------[ cut here ]------------ [ 0.651005] kernel BUG at arch/arm64/xen/../../arm/xen/enlighten.c:158! [ 0.657697] Internal error: Oops - BUG: 0 [#1] SMP [ 0.662548] Modules linked in: [ 0.665676] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 5.9.0-rc4+ #4 [ 0.673398] Hardware name: Socionext Developer Box (DT) [ 0.678695] pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) [ 0.684338] pc : xen_starting_cpu+0x178/0x180 [ 0.688765] lr : xen_starting_cpu+0x144/0x180 [ 0.693188] sp : ffff8000116cbb60 [ 0.696573] x29: ffff8000116cbb60 x28: ffff80000abec000 [ 0.701955] x27: 0000000000000000 x26: 0000000000000000 [ 0.707344] x25: ffff80001156c000 x24: fffffdffbfcdb600 [ 0.712718] x23: 0000000000000000 x22: 0000000000000000 [ 0.718107] x21: ffff8000113a99c8 x20: ffff800010fe4f68 [ 0.723481] x19: ffff8000113a9988 x18: 0000000000000010 [ 0.728863] x17: 0000000094fe0f81 x16: 00000000deadbeef [ 0.734245] x15: ffffffffffffffff x14: 0720072007200720 [ 0.739626] x13: 0720072007200720 x12: 0720072007200720 [ 0.745008] x11: 0720072007200720 x10: 0720072007200720 [ 0.750390] x9 : ffff8000100fbdc0 x8 : ffff800010715208 [ 0.755771] x7 : 0000000000000054 x6 : ffff00001b790f00 [ 0.761153] x5 : ffff800010bbf880 x4 : 0000000000000000 [ 0.766534] x3 : 0000000000000000 x2 : 00000000deadbeef [ 0.771916] x1 : 00000000deadbeef x0 : ffffffffffffffea [ 0.777304] Call trace: [ 0.779819] xen_starting_cpu+0x178/0x180 [ 0.783898] cpuhp_invoke_callback+0xac/0x640 [ 0.788325] cpuhp_issue_call+0xf4/0x150 [ 0.792317] __cpuhp_setup_state_cpuslocked+0x128/0x2c8 [ 0.797619] __cpuhp_setup_state+0x84/0xf8 [ 0.801779] xen_guest_init+0x324/0x364 [ 0.805683] do_one_initcall+0x54/0x250 [ 0.809590] kernel_init_freeable+0x12c/0x2c8 [ 0.814016] kernel_init+0x1c/0x128 [ 0.817583] ret_from_fork+0x10/0x18 [ 0.821226] Code: d0006980 f9427c00 cb000300 17ffffea (d4210000) [ 0.827415] ---[ end trace d95b5309a33f8b28 ]--- [ 0.832076] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 0.839815] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Signed-off-by: Masami Hiramatsu <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Link: https://lore.kernel.org/r/160196697165.60224.17470743378683334995.stgit@devnote2 Signed-off-by: Juergen Gross <[email protected]>
2020-10-06riscv: Fixup bootup failure with HARDENED_USERCOPYGuo Ren1-2/+3
6184358da000 ("riscv: Fixup static_obj() fail") attempted to elide a lockdep failure by rearranging our kernel image to place all initdata within [_stext, _end], thus triggering lockdep to treat these as static objects. These objects are released and eventually reallocated, causing check_kernel_text_object() to trigger a BUG(). This backs out the change to make [_stext, _end] all-encompassing, instead just moving initdata. This results in initdata being outside of [__init_begin, __init_end], which means initdata can't be freed. Link: https://lore.kernel.org/linux-riscv/[email protected]/T/#t Signed-off-by: Guo Ren <[email protected]> Reported-by: Aurelien Jarno <[email protected]> Tested-by: Aurelien Jarno <[email protected]> [Palmer: Clean up commit text] Signed-off-by: Palmer Dabbelt <[email protected]>
2020-10-06hwmon: (pmbus/max20730) adjust the vout reading given voltage dividerChu Lin1-0/+18
Problem: We use voltage dividers so that the voltage presented at the voltage sense pins is confusing. We might need to convert these readings to more meaningful readings given the voltage divider. Solution: Read the voltage divider resistance from dts and convert the voltage reading to a more meaningful reading. Testing: max20730 with voltage divider Signed-off-by: Chu Lin <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Return -EINVAL instead of -ENODEV on bad deevicetree data] Signed-off-by: Guenter Roeck <[email protected]>
2020-10-06dt-bindings: hwmon: max20730: adding device tree doc for max20730Chu Lin1-0/+65
max20730 Integrated, Step-Down Switching Regulator with PMBus Signed-off-by: Chu Lin <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-10-06hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controllerRahul Tanwar3-0/+667
PVT controller (MR75203) is used to configure & control Moortec embedded analog IP which contains temprature sensor(TS), voltage monitor(VM) & process detector(PD) modules. Add hardware monitoring driver to support MR75203 PVT controller. Signed-off-by: Rahul Tanwar <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/05b59cd860d2a1aa0a68ab300829efe709645184.1601889876.git.rahul.tanwar@linux.intel.com Signed-off-by: Guenter Roeck <[email protected]>
2020-10-06hwmon: Add DT bindings schema for PVT controllerRahul Tanwar1-0/+71
PVT controller (MR75203) is used to configure & control Moortec embedded analog IP which contains temprature sensor(TS), voltage monitor(VM) & process detector(PD) modules. Add DT bindings schema for PVT controller. Signed-off-by: Rahul Tanwar <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/b540b49ca47d75c5f716f8a4e4eed0664a1116bf.1601889876.git.rahul.tanwar@linux.intel.com Signed-off-by: Guenter Roeck <[email protected]>
2020-10-06block: Consider only dispatched requests for inflight statisticGabriel Krisman Bertazi1-1/+1
According to Documentation/block/stat.rst, inflight should not include I/O requests that are in the queue but not yet dispatched to the device, but blk-mq identifies as inflight any request that has a tag allocated, which, for queues without elevator, happens at request allocation time and before it is queued in the ctx (default case in blk_mq_submit_bio). In addition, current behavior is different for queues with elevator from queues without it, since for the former the driver tag is allocated at dispatch time. A more precise approach would be to only consider requests with state MQ_RQ_IN_FLIGHT. This effectively reverts commit 6131837b1de6 ("blk-mq: count allocated but not started requests in iostats inflight") to consolidate blk-mq behavior with itself (elevator case) and with original documentation, but it differs from the behavior used by the legacy path. This version differs from v1 by using blk_mq_rq_state to access the state attribute. Avoid using blk_mq_request_started, which was suggested, since we don't want to include MQ_RQ_COMPLETE. Signed-off-by: Gabriel Krisman Bertazi <[email protected]> Cc: Omar Sandoval <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06dt-bindings: hwmon: Add the +vs supply to the lm75 bindingsAlban Bedel1-0/+4
Some boards might have a regulator that control the +VS supply, add it to the bindings. Signed-off-by: Alban Bedel <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-10-06dt-bindings: hwmon: Convert lm75 bindings to yamlAlban Bedel2-39/+62
In order to automate the verification of DT nodes convert lm75.txt to lm75.yaml. Signed-off-by: Alban Bedel <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-10-06Merge tag 'arm64-fixes' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Fix a kernel panic in the AES crypto code caused by a BR tail call not matching the target BTI instruction (when branch target identification is enabled)" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: crypto: arm64: Use x16 with indirect branch to bti_c
2020-10-06Merge tag 'platform-drivers-x86-v5.9-3' of ↵Linus Torvalds3-7/+42
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull another x86 platform driver fix from Hans de Goede: "One final pdx86 fix for Tablet Mode reporting regressions (which make the keyboard and touchpad unusable) on various Asus notebooks. These regressions were caused by the asus-nb-wmi and the intel-vbtn drivers both receiving recent patches to start reporting Tablet Mode / to report it on more models. Due to a miscommunication between Andy and me, Andy's earlier pull-req only contained the fix for the intel-vbtn driver and not the fix for the asus-nb-wmi code. This fix has been tested as a downstream patch in Fedora kernels for approx two weeks with no problems being reported" * tag 'platform-drivers-x86-v5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: asus-wmi: Fix SW_TABLET_MODE always reporting 1 on many different models
2020-10-06Merge tag 'drm-fixes-2020-10-06-1' of git://anongit.freedesktop.org/drm/drmLinus Torvalds25-68/+1469
Pull drm fixes from Dave Airlie: "Daniel queued these up last week and I took a long weekend so didn't get them out, but fixing the OOB access on get font seems like something we should land and it's cc'ed stable as well. The other big change is a partial revert for a regression on android on the clcd fbdev driver, and one other docs fix. fbdev: - Re-add FB_ARMCLCD for android - Fix global-out-of-bounds read in fbcon_get_font() core: - Small doc fix" * tag 'drm-fixes-2020-10-06-1' of git://anongit.freedesktop.org/drm/drm: drm: drm_dsc.h: fix a kernel-doc markup Partially revert "video: fbdev: amba-clcd: Retire elder CLCD driver" fbcon: Fix global-out-of-bounds read in fbcon_get_font() Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h
2020-10-06usermodehelper: reset umask to default before executing user processLinus Torvalds1-0/+9
Kernel threads intentionally do CLONE_FS in order to follow any changes that 'init' does to set up the root directory (or cwd). It is admittedly a bit odd, but it avoids the situation where 'init' does some extensive setup to initialize the system environment, and then we execute a usermode helper program, and it uses the original FS setup from boot time that may be very limited and incomplete. [ Both Al Viro and Eric Biederman point out that 'pivot_root()' will follow the root regardless, since it fixes up other users of root (see chroot_fs_refs() for details), but overmounting root and doing a chroot() would not. ] However, Vegard Nossum noticed that the CLONE_FS not only means that we follow the root and current working directories, it also means we share umask with whatever init changed it to. That wasn't intentional. Just reset umask to the original default (0022) before actually starting the usermode helper program. Reported-by: Vegard Nossum <[email protected]> Cc: Al Viro <[email protected]> Acked-by: Eric W. Biederman <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-10-06splice: teach splice pipe reading about empty pipe buffersLinus Torvalds1-0/+20
Tetsuo Handa reports that splice() can return 0 before the real EOF, if the data in the splice source pipe is an empty pipe buffer. That empty pipe buffer case doesn't happen in any normal situation, but you can trigger it by doing a write to a pipe that fails due to a page fault. Tetsuo has a test-case to show the behavior: #define _GNU_SOURCE #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> int main(int argc, char *argv[]) { const int fd = open("/tmp/testfile", O_WRONLY | O_CREAT, 0600); int pipe_fd[2] = { -1, -1 }; pipe(pipe_fd); write(pipe_fd[1], NULL, 4096); /* This splice() should wait unless interrupted. */ return !splice(pipe_fd[0], NULL, fd, NULL, 65536, 0); } which results in write(5, NULL, 4096) = -1 EFAULT (Bad address) splice(4, NULL, 3, NULL, 65536, 0) = 0 and this can confuse splice() users into believing they have hit EOF prematurely. The issue was introduced when the pipe write code started pre-allocating the pipe buffers before copying data from user space. This is modified verion of Tetsuo's original patch. Fixes: a194dfe6e6f6 ("pipe: Rearrange sequence in pipe_write() to preallocate slot") Link:https://lore.kernel.org/linux-fsdevel/[email protected]/ Reported-by: Tetsuo Handa <[email protected]> Acked-by: Tetsuo Handa <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-10-06crypto: arm64: Use x16 with indirect branch to bti_cJeremy Linton1-2/+2
The AES code uses a 'br x7' as part of a function called by a macro. That branch needs a bti_j as a target. This results in a panic as seen below. Using x16 (or x17) with an indirect branch keeps the target bti_c. Bad mode in Synchronous Abort handler detected on CPU1, code 0x34000003 -- BTI CPU: 1 PID: 265 Comm: cryptomgr_test Not tainted 5.8.11-300.fc33.aarch64 #1 pstate: 20400c05 (nzCv daif +PAN -UAO BTYPE=j-) pc : aesbs_encrypt8+0x0/0x5f0 [aes_neon_bs] lr : aesbs_xts_encrypt+0x48/0xe0 [aes_neon_bs] sp : ffff80001052b730 aesbs_encrypt8+0x0/0x5f0 [aes_neon_bs] __xts_crypt+0xb0/0x2dc [aes_neon_bs] xts_encrypt+0x28/0x3c [aes_neon_bs] crypto_skcipher_encrypt+0x50/0x84 simd_skcipher_encrypt+0xc8/0xe0 crypto_skcipher_encrypt+0x50/0x84 test_skcipher_vec_cfg+0x224/0x5f0 test_skcipher+0xbc/0x120 alg_test_skcipher+0xa0/0x1b0 alg_test+0x3dc/0x47c cryptomgr_test+0x38/0x60 Fixes: 0e89640b640d ("crypto: arm64 - Use modern annotations for assembly functions") Cc: <[email protected]> # 5.6.x- Signed-off-by: Jeremy Linton <[email protected]> Suggested-by: Dave P Martin <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-10-06spi: spi-mtk-nor: Add power management supportIkjoon Jang1-22/+76
This patch adds dev_pm_ops to mtk-nor to support suspend/resume, auto suspend delay is set to -1 by default. Accessing registers are only permitted after its clock is enabled to deal with unknown state of operating clk at probe time. Signed-off-by: Ikjoon Jang <[email protected]> Link: https://lore.kernel.org/r/20201006155010.v5.4.I68983b582d949a91866163bab588ff3c2a0d0275@changeid Signed-off-by: Mark Brown <[email protected]>
2020-10-06spi: spi-mtk-nor: support 36bit dma addressingIkjoon Jang1-1/+20
This patch enables 36bit dma address support to spi-mtk-nor. Currently this is enabled only for mt8192-nor. Signed-off-by: Ikjoon Jang <[email protected]> Link: https://lore.kernel.org/r/20201006155010.v5.3.Id1cb208392928afc7ceed4de06924243c7858cd0@changeid Signed-off-by: Mark Brown <[email protected]>
2020-10-06spi: spi-mtk-nor: use dma_alloc_coherent() for bounce bufferIkjoon Jang1-42/+52
Use dma_alloc_coherent() for bounce buffer instead of kmalloc() to make sure the bounce buffer to be allocated within its DMAable range. Signed-off-by: Ikjoon Jang <[email protected]> Link: https://lore.kernel.org/r/20201006155010.v5.2.I06cb65401ab5ad63ea30c4788d26633928d80f38@changeid Signed-off-by: Mark Brown <[email protected]>
2020-10-06dt-bindings: spi: add mt8192-nor compatible stringIkjoon Jang1-0/+1
Add MT8192 spi-nor controller support. Signed-off-by: Ikjoon Jang <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/20201006155010.v5.1.I4cd089ef1fe576535c6b6e4f1778eaab1c4441cf@changeid Signed-off-by: Mark Brown <[email protected]>
2020-10-06scsi: megaraid_sas: Added support for shared host tagset for cpuhotplugKashyap Desai2-13/+55
Fusion adapters can steer completions to individual queues, and we now have support for shared host-wide tags. So we can enable multiqueue support for fusion adapters. Once driver enable shared host-wide tags, cpu hotplug feature is also supported as it was enabled using below patchsets - commit bf0beec0607d ("blk-mq: drain I/O when all CPUs in a hctx are offline") Currently driver has provision to disable host-wide tags using "host_tagset_enable" module parameter. Once we do not have any major performance regression using host-wide tags, we will drop the hand-crafted interrupt affinity settings. Performance is also meeting the expecatation - (used both none and mq-deadline scheduler) 24 Drive SSD on Aero with/without this patch can get 3.1M IOPs 3 VDs consist of 8 SAS SSD on Aero with/without this patch can get 3.1M IOPs. Signed-off-by: Kashyap Desai <[email protected]> Signed-off-by: Hannes Reinecke <[email protected]> Signed-off-by: John Garry <[email protected]> Tested-by: Douglas Gilbert <[email protected]> Acked-by: Martin K. Petersen <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06scsi: scsi_debug: Support host tagsetJohn Garry1-18/+10
When host_max_queue is set (> 0), set the Scsi_Host.host_tagset such that blk-mq will use a hostwide tagset over all SCSI host submission queues. This means that we may expose all submission queues and always use the hwq chosen by blk-mq. And since if sdebug_host_max_queue is set, sdebug_max_queue is fixed to the same value, we can simplify how sdebug_driver_template.can_queue is set. Signed-off-by: John Garry <[email protected]> Tested-by: Douglas Gilbert <[email protected]> Acked-by: Martin K. Petersen <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06scsi: hisi_sas: Switch v3 hw to MQJohn Garry3-70/+56
Now that the block layer provides a shared tag, we can switch the driver to expose all HW queues. Signed-off-by: John Garry <[email protected]> Tested-by: Douglas Gilbert <[email protected]> Acked-by: Martin K. Petersen <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06scsi: core: Show nr_hw_queues in sysfsJohn Garry1-0/+11
So that we don't use a value of 0 for when Scsi_Host.nr_hw_queues is unset, use the tag_set->nr_hw_queues (which holds 1 for this case). Signed-off-by: John Garry <[email protected]> Tested-by: Douglas Gilbert <[email protected]> Acked-by: Martin K. Petersen <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06scsi: Add host and host template flag 'host_tagset'Hannes Reinecke3-1/+11
Add Host and host template flag 'host_tagset' so hostwide tagset can be shared on multiple reply queues after the SCSI device's reply queue is converted to blk-mq hw queue. [jpg: Update comment on .can_queue and add Scsi_Host.host_tagset] Signed-off-by: Hannes Reinecke <[email protected]> Signed-off-by: John Garry <[email protected]> Tested-by: Don Brace<[email protected]> #SCSI resv cmds patches used Tested-by: Douglas Gilbert <[email protected]> Acked-by: Martin K. Petersen <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06block: move blk_mq_sched_try_merge to blk-merge.cChristoph Hellwig3-63/+50
Move blk_mq_sched_try_merge to blk-merge.c, which allows to mark a lot of the merge infrastructure static there. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06block: remove the unused blk_integrity_merge_bio exportChristoph Hellwig3-9/+7
Also move the definition from the public blkdev.h to the private block/blk.h header. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06block: remove the unused blk_integrity_merge_rq exportChristoph Hellwig3-9/+8
Also move the definition from the public blkdev.h to the private block/blk.h header. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06block: move 'q_usage_counter' into front of 'request_queue'Ming Lei1-1/+2
The field of 'q_usage_counter' is always fetched in fast path of every block driver, and move it into front of 'request_queue', so it can be fetched into 1st cacheline of 'request_queue' instance. Signed-off-by: Ming Lei <[email protected]> Tested-by: Veronika Kabatova <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Sagi Grimberg <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Bart Van Assche <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06percpu_ref: reduce memory footprint of percpu_ref in fast pathMing Lei3-62/+123
'struct percpu_ref' is often embedded into one user structure, and the instance is usually referenced in fast path, however actually only 'percpu_count_ptr' is needed in fast path. So move other fields into one new structure of 'percpu_ref_data', and allocate it dynamically via kzalloc(), then memory footprint of 'percpu_ref' in fast path is reduced a lot and becomes suitable to put into hot cacheline of user structure. Signed-off-by: Ming Lei <[email protected]> Tested-by: Veronika Kabatova <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Tejun Heo <[email protected]> Cc: Sagi Grimberg <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Bart Van Assche <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-06Merge tag 'rxrpc-fixes-20201005' of ↵David S. Miller8-290/+66
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== rxrpc: Miscellaneous fixes Here are some miscellaneous rxrpc fixes: (1) Fix the xdr encoding of the contents read from an rxrpc key. (2) Fix a BUG() for a unsupported encoding type. (3) Fix missing _bh lock annotations. (4) Fix acceptance handling for an incoming call where the incoming call is encrypted. (5) The server token keyring isn't network namespaced - it belongs to the server, so there's no need. Namespacing it means that request_key() fails to find it. (6) Fix a leak of the server keyring. ==================== Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.