- 30 Nov, 2020 3 commits
-
-
Pankaj Gupta authored
This patch improves readability by using better variable names in flush request coalescing logic. Signed-off-by:
Pankaj Gupta <pankaj.gupta@cloud.ionos.com> Reviewed-by:
Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by:
Song Liu <songliubraving@fb.com>
-
Kevin Vigor authored
In __make_request() a new r10bio is allocated and passed to raid10_read_request(). The read_slot member of the bio is not initialized, and the raid10_read_request() uses it to index an array. This leads to occasional panics. Fix by initializing the field to invalid value and checking for valid value in raid10_read_request(). Cc: stable@vger.kernel.org Signed-off-by:
Kevin Vigor <kvigor@gmail.com> Signed-off-by:
-
Dae R. Jeong authored
Syzkaller reports a warning as belows. WARNING: CPU: 0 PID: 9647 at drivers/md/md.c:7169 ... Call Trace: ... RIP: 0010:md_ioctl+0x4017/0x5980 drivers/md/md.c:7169 RSP: 0018:ffff888096027950 EFLAGS: 00010293 RAX: ffff88809322c380 RBX: 0000000000000932 RCX: ffffffff84e266f2 RDX: 0000000000000000 RSI: ffffffff84e299f7 RDI: 0000000000000007 RBP: ffff888096027bc0 R08: ffff88809322c380 R09: ffffed101341a482 R10: ffff888096027940 R11: ffff88809a0d240f R12: 0000000000000932 R13: ffff8880a2c14100 R14: ffff88809a0d2268 R15: ffff88809a0d2408 __blkdev_driver_ioctl block/ioctl.c:304 [inline] blkdev_ioctl+0xece/0x1c10 block/ioctl.c:606 block_ioctl+0xee/0x130 fs/block_dev.c:1930 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe This is caused by a race between two concurrenct md_ioctl()s closing the array. CPU1 (md_ioctl()) CPU2 (md_ioctl()) ------ ------ set_bit(MD_CLOSING, &mddev->flags); did_set_md_closing = true; WARN_ON_ONCE(test_bit(MD_CLOSING, &mddev->flags)); if(did_set_md_closing) clear_bit(MD_CLOSING, &mddev->flags); Fix the warning by returning immediately if the MD_CLOSING bit is set in &mddev->flags which indicates that the array is being closed. Fixes: 065e519e ("md: MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop") Reported-by: syzbot+1e46a0864c1a6e9bd3d8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by:Dae R. Jeong <dae.r.jeong@kaist.ac.kr> Signed-off-by:
-
- 16 Nov, 2020 37 commits
-
-
Jan Höppner authored
If the Fibre Channel Endpoint-Security status of a path changes, a corresponding path event is received from the CIO layer. Process this event by re-reading the FCES information. As the information is retrieved for all paths on a single CU in one call, the internal status can also be updated for all paths and no processing per path is necessary. Signed-off-by:
Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by:
Stefan Haberland <sth@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Jan Höppner authored
As more path events need to be handled for ECKD the current path verification infrastructure can be reused. Rename all path verifcation code to fit the more broadly based task of path event handling and put the path verification in a new separate function. Signed-off-by:
-
Jan Höppner authored
Add a new sysfs attribute (fc_security) per device and per operational channel path. The information of the current FC Endpoint Security state is received through the CIO layer. The state of the FC Endpoint Security can be either "Unsupported", "Authentication", or "Encryption". For example: $ cat /sys/bus/ccw/devices/0.0.c600/fc_security Encryption If any of the operational paths is in a state different from all others, the device sysfs attribute will display the additional state "Inconsistent". The sysfs attributes per paths are organised in a new directory called "paths_info" with subdirectories for each path. /sys/bus/ccw/devices/0.0.c600/paths_info/ ├── 0.38 │ └── fc_security ├── 0.39 │ └── fc_security ├── 0.3a │ └── fc_security └── 0.3b └── fc_security Signed-off-by: -
Jan Höppner authored
During online processing and setting up a DASD device, the configuration data for operational paths is read and validated two times (dasd_eckd_read_conf()). The first time to provide information that are necessary for the LCU setup. A second time after the LCU setup as a device might report different configuration data then. When the configuration setup for each operational path is being validated, an initial call to dasd_eckd_clear_conf_data() is issued. This call wipes all previously available configuration data and path information for each path. However, the operational path mask is not updated during this process. As a result, the stored operational path mask might no longer correspond to the operational paths mask reported by the CIO layer, as several paths might be gone between the two dasd_eckd_read_conf() calls. This inconsistency leads to more severe issues in later path handling changes. Fix this by removing the channel paths from the operational path mask during the dasd_eckd_clear_conf_data() call. Signed-off-by:
-
Jan Höppner authored
Currently, the configuration data for a path is retrieved during a path verification and used only temporarily. If a path is newly added to the I/O setup after a boot, no configuration data will be stored for this particular path. However, this data is required for later use and should be present for a valid I/O path anyway. Store this data during the path verification so that newly added paths can provide all information necessary. [sth@linux.ibm.com: fix conf_data memleak] Signed-off-by:
-
Jan Höppner authored
For storing retrieved path information both the if and else block in dasd_eckd_read_conf() use the same code. To avoid duplicate code this should be done after the if/else block. To further increase readability, move the code to a new function, dasd_eckd_store_conf_data(). Signed-off-by:
-
Jan Höppner authored
The discipline argument in dasd_generic_probe() isn't used and there is no history how it was used in the past. Remove it. Signed-off-by:
-
Vineeth Vijayan authored
Fibre Channel Endpoint-Security event is received as an sei:nt0 type in the CIO layer. This information needs to be shared with the CCW device drivers using the path_events callback. Co-developed-by:
Sebastian Ott <sebott@linux.ibm.com> Signed-off-by:
Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Acked-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Vineeth Vijayan authored
Add an interface in the CIO layer to retrieve the information about the Endpoint-Security Mode (ESM) of the specified CU. The ESM values are defined as 0-None, 1-Authenticated or 2, 3-Encrypted. [vneethv@linux.ibm.com: cleaned-up and modified description] Signed-off-by:
-
Sebastian Ott authored
Add a new sysfs attribute 'esc' per chpid. This new attribute exports the Endpoint-Security-Capability byte of channel-path description block, which could be 0-None, 1-Authentication, 2 and 3-Encryption. For example: $ cat /sys/devices/css0/chp0.34/esc 0 [vneethv@linux.ibm.com: cleaned-up & modified description] Signed-off-by:
-
Christoph Hellwig authored
Switch the comment to talk about __register_blkdev instead of register_blkdev and document the new probe parameter. Fixes: 3da1a61e7046 ("block: add an optional probe callback to major_names") Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
Now that bdev_map is only used for finding gendisks, we can use a simple xarray instead of the regions tracking structure for it. Signed-off-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Christoph Hellwig authored
Use separate gendisks (which share a tag_set) for the different operating modes instead of redirecting the gendisk lookup using a probe callback. This avoids potential problems with aliased block_device instances and will eventually allow for removing the blk_register_region framework. Signed-off-by:
-
Christoph Hellwig authored
reindent the driver using Lident as the code style was far away from normal Linux code. Signed-off-by:
-
Christoph Hellwig authored
The Atari floppy driver usually autodetects the media when used with the ormal /dev/fd? devices, which also are the only nodes created by udev. But it also supports various aliases that force a given media format. That is currently supported using the blk_register_region framework which finds the floppy gendisk even for a 'mismatched' dev_t. The problem with this (besides the code complexity) is that it creates multiple struct block_device instances for the whole device of a single gendisk, which can lead to interesting issues in code not aware of that fact. To fix this just create a separate gendisk for each of the aliases if they are accessed. Signed-off-by:
-
Christoph Hellwig authored
Use separate gendisks (which share a tag_set) for the native Amgiga vs the MS-DOS mode instead of redirecting the gendisk lookup using a probe callback. This avoids potential problems with aliased block_device instances and will eventually allow for removing the blk_register_region framework. Signed-off-by:
-
Christoph Hellwig authored
The floppy driver usually autodetects the media when used with the normal /dev/fd? devices, which also are the only nodes created by udev. But it also supports various aliases that force a given media format. That is currently supported using the blk_register_region framework which finds the floppy gendisk even for a 'mismatched' dev_t. The problem with this (besides the code complexity) is that it creates multiple struct block_device instances for the whole device of a single gendisk, which can lead to interesting issues in code not aware of that fact. To fix this just create a separate gendisk for each of the aliases if they are accessed. Signed-off-by:
-
Christoph Hellwig authored
ide is the last user of the blk_register_region framework except for the tracking of allocated gendisk. Switch to __register_blkdev, even if that doesn't allow us to trivially find out which command set to probe for. That means we now always request all modules when a user tries to access an unclaimed ide device node, but except for a few potentially loaded modules for a fringe use case of a deprecated and soon to be removed driver that doesn't make a difference. Signed-off-by:
-
Christoph Hellwig authored
Use the simpler mechanism attached to major_name to allocate a md device when a currently unregistered minor is accessed. Signed-off-by:
Song Liu <song@kernel.org> Signed-off-by:
-
Christoph Hellwig authored
Use the simpler mechanism attached to major_name to allocate a brd device when a currently unregistered minor is accessed. Signed-off-by:
-
Christoph Hellwig authored
Use the simpler mechanism attached to major_name to allocate a brd device when a currently unregistered minor is accessed. Signed-off-by:
-
Christoph Hellwig authored
Switch from using blk_register_region to the probe callback passed to __register_blkdev to disable the request_module call for an unclaimed dev_t in the SD majors. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Christoph Hellwig authored
The swim driver (unlike various other floppy drivers) doesn't have magic device nodes for certain modes, and already registers a gendisk for each of the floppies supported by a device. Thus the region registered is a no-op and can be removed. Signed-off-by:
-
Christoph Hellwig authored
There is no need to ever register the fake gendisk used for ide-tape. Signed-off-by:
-
Christoph Hellwig authored
Add a callback to the major_names array that allows a driver to override how to probe for dev_t that doesn't currently have a gendisk registered. This will help separating the lookup of the gendisk by dev_t vs probe action for a not currently registered dev_t. Signed-off-by:
-
Christoph Hellwig authored
Instead of reusing the ranges in bdev_map, add a new helper that is called if no ranges was found. This is a first step to unpeel and eventually remove the complex ranges structure. Signed-off-by:
-
Christoph Hellwig authored
Split the block_class_lock mutex into one each to protect bdev_map and major_names. Signed-off-by:
-
Christoph Hellwig authored
Copy and paste the kobj_map functionality in the block code in preparation for completely rewriting it. Signed-off-by:
-
Christoph Hellwig authored
Merge three hidden gendisk checks into one. Signed-off-by:
-
Christoph Hellwig authored
Just open code it in the few callers. Signed-off-by:
-
Christoph Hellwig authored
Fold set_device_ro into its only remaining caller. Signed-off-by:
-
Christoph Hellwig authored
Use set_disk_ro instead of set_device_ro to match all other block drivers and to ensure all partitions mirror the read-only flag. Signed-off-by:
-
Christoph Hellwig authored
Now that all drivers that want to hook into setting or clearing the read-only flag use the set_read_only method, this code can be removed. Signed-off-by:
-
Christoph Hellwig authored
Implement the ->set_read_only method instead of parsing the actual ioctl command. Signed-off-by:
-
Christoph Hellwig authored
Implement the ->set_read_only method instead of parsing the actual ioctl command. Signed-off-by:
-
Christoph Hellwig authored
Implement the ->set_read_only method instead of parsing the actual ioctl command. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Christoph Hellwig authored
Add a new method to allow for driver-specific processing when setting or clearing the block device read-only state. This allows to replace the cumbersome and error-prone override of the whole ioctl implementation. Signed-off-by:
-
