lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon,  1 Nov 2010 19:44:34 +0100
From:	Tejun Heo <tj@...nel.org>
To:	axboe@...nel.dk, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, kay.sievers@...y.org, jack@...e.cz,
	James.Bottomley@...senPartnership.com
Subject: [PATCHSET RFC] block/SCSI: implement in-kernel disk event handling

This patchset implements in-kernel disk event handling framework and
add support for it to sr and sd.  This is largely to move media
presence polling into kernel as userspace implementation turned out to
be quite problematic over the years.

>From the patch description of the third patch,

 Currently, media presence polling for removeable block devices is done
 from userland.  There are several issues with this.

 * Polling is done by periodically opening the device.  For SCSI
   devices, the command sequence generated by such action involves a
   few different commands including TEST_UNIT_READY.  This behavior,
   while perfectly legal, is different from Windows which only issues
   single command, GET_EVENT_STATUS_NOTIFICATION.  Unfortunately, some
   ATAPI devices lock up after being periodically queried such command
   sequences.

 * There is no reliable and unintrusive way for a userland program to
   tell whether the target device is safe for media presence polling.
   For example, polling for media presence during an on-going burning
   session can make it fail.  The polling program can avoid this by
   opening the device with O_EXCL but then it risks making a valid
   exclusive user of the device fail w/ -EBUSY.

 * Userland polling is unnecessarily heavy and in-kernel implementation
   is lighter and better coordinated (workqueue, timer slack).

This patchset contains the following seven patches.

 0001-block-kill-genhd_media_change_notify.patch
 0002-block-move-register_disk-and-del_gendisk-to-block-ge.patch
 0003-implement-in-kernel-gendisk-events-handling.patch
 0004-cdrom-add-check_events-support.patch
 0005-scsi-replace-sr_test_unit_ready-with-scsi_test_unit_.patch
 0006-sr-implement-sr_check_events.patch
 0007-sd-implement-sd_check_events.patch

0001-0002 are prepreations.  0003 implements the block layer framework
for disk event handling.  0004-0007 add support for it to cdrom and
then sr and sd.

Block drivers just need to implement a new bdev method
->check_events() which supercedes ->media_change() and set
bdev->events[_async] masks according to what the device can do.
Everything else is handled by block layer including event generation,
polling and its configuration.

Tested with dvd drives and an iomega click drive (a removable direct
access ATAPI device Alan gave to me, still operational!).

Kay, as you're the media presence polling expert :-) how does this
look to you?

This patchset is on top of v2.6.37-rc1 + clean-up-bdev-claim-release
patchset and available in the following git tree,

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git disk-events

and contains the following changes.

 block/genhd.c           |  544 +++++++++++++++++++++++++++++++++++++++++++++---
 drivers/cdrom/cdrom.c   |   55 ++++
 drivers/scsi/scsi_lib.c |   13 -
 drivers/scsi/sd.c       |   97 ++++----
 drivers/scsi/sd.h       |    1 
 drivers/scsi/sr.c       |  168 ++++++++------
 drivers/scsi/sr.h       |    3 
 drivers/scsi/sr_ioctl.c |    2 
 fs/block_dev.c          |   41 +++
 fs/partitions/check.c   |   89 -------
 include/linux/blkdev.h  |    4 
 include/linux/cdrom.h   |    6 
 include/linux/fs.h      |    1 
 include/linux/genhd.h   |   20 +
 include/scsi/scsi.h     |    1 
 15 files changed, 774 insertions(+), 271 deletions(-)

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ