* [PATCH SCSI] sr: check_events() ignore GET_EVENT when TUR says
From: Tejun Heo @ 2011-06-30 13:03 UTC (permalink / raw)
To: James E.J. Bottomley; +Cc: linux-scsi, kay.sievers, maggu2810, linux-hotplug
From: Kay Sievers <kay.sievers@vrfy.org>
Some broken devices indicates that media has changed on every
GET_EVENT_STATUS_NOTIFICATION. This translates into MEDIA_CHANGE
uevent on every open() which lets udev run into a loop.
Verify GET_EVENT result against TUR and if it generates spurious
events for several times in a row, ignore the GET_EVENT events, and
trust only the TUR status.
This is the log of a USB stick with a (broken) fake CDROM drive:
scsi 5:0:0:0: Direct-Access SanDisk U3 Cruzer Micro 8.02 PQ: 0 ANSI: 0 CCS
sd 5:0:0:0: Attached scsi generic sg3 type 0
scsi 5:0:0:1: CD-ROM SanDisk U3 Cruzer Micro 8.02 PQ: 0 ANSI: 0
sd 5:0:0:0: [sdb] Attached SCSI removable disk
sr2: scsi3-mmc drive: 48x/48x tray
sr 5:0:0:1: Attached scsi CD-ROM sr2
sr 5:0:0:1: Attached scsi generic sg4 type 5
sr2: GET_EVENT and TUR disagree continuously, suppress GET_EVENT events
sd 5:0:0:0: [sdb] 31777279 512-byte logical blocks: (16.2 GB/15.1 GiB)
sd 5:0:0:0: [sdb] No Caching mode page present
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sd 5:0:0:0: [sdb] No Caching mode page present
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
-tj: Updated to consider only spurious GET_EVENT events among
different types of disagreement and allow using TUR for kernel
event polling after GET_EVENT is ignored.
Reported-By: Markus Rathgeb maggu2810@googlemail.com
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@kernel.org # >= v2.6.38, fixes udev busy looping w/ certain devices
---
drivers/scsi/sr.c | 46 ++++++++++++++++++++++++++++++++++++++++++----
drivers/scsi/sr.h | 7 +++++++
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 4778e27..5fc97d2 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -221,14 +221,33 @@ static unsigned int sr_check_events(struct cdrom_device_info *cdi,
return 0;
events = sr_get_events(cd->device);
+ cd->get_event_changed |= events & DISK_EVENT_MEDIA_CHANGE;
+
+ /*
+ * If earlier GET_EVENT_STATUS_NOTIFICATION and TUR did not agree
+ * for several times in a row. We rely on TUR only for this likely
+ * broken device, to prevent generating incorrect media changed
+ * events for every open().
+ */
+ if (cd->ignore_get_event) {
+ events &= ~DISK_EVENT_MEDIA_CHANGE;
+ goto do_tur;
+ }
+
/*
* GET_EVENT_STATUS_NOTIFICATION is enough unless MEDIA_CHANGE
* is being cleared. Note that there are devices which hang
* if asked to execute TUR repeatedly.
*/
- if (!(clearing & DISK_EVENT_MEDIA_CHANGE))
- goto skip_tur;
+ if (cd->device->changed) {
+ events |= DISK_EVENT_MEDIA_CHANGE;
+ cd->device->changed = 0;
+ cd->tur_changed = true;
+ }
+ if (!(clearing & DISK_EVENT_MEDIA_CHANGE))
+ return events;
+do_tur:
/* let's see whether the media is there with TUR */
last_present = cd->media_present;
ret = scsi_test_unit_ready(cd->device, SR_TIMEOUT, MAX_RETRIES, &sshdr);
@@ -242,12 +261,31 @@ static unsigned int sr_check_events(struct cdrom_device_info *cdi,
(scsi_sense_valid(&sshdr) && sshdr.asc != 0x3a);
if (last_present != cd->media_present)
- events |= DISK_EVENT_MEDIA_CHANGE;
-skip_tur:
+ cd->device->changed = 1;
+
if (cd->device->changed) {
events |= DISK_EVENT_MEDIA_CHANGE;
cd->device->changed = 0;
+ cd->tur_changed = true;
+ }
+
+ if (cd->ignore_get_event)
+ return events;
+
+ /* check whether GET_EVENT is reporting spurious MEDIA_CHANGE */
+ if (!cd->tur_changed) {
+ if (cd->get_event_changed) {
+ if (cd->tur_mismatch++ > 8) {
+ sdev_printk(KERN_WARNING, cd->device,
+ "GET_EVENT and TUR disagree continuously, suppress GET_EVENT events\n");
+ cd->ignore_get_event = true;
+ }
+ } else {
+ cd->tur_mismatch = 0;
+ }
}
+ cd->tur_changed = false;
+ cd->get_event_changed = false;
return events;
}
diff --git a/drivers/scsi/sr.h b/drivers/scsi/sr.h
index e036f1d..37c8f6b 100644
--- a/drivers/scsi/sr.h
+++ b/drivers/scsi/sr.h
@@ -41,6 +41,13 @@ typedef struct scsi_cd {
unsigned readcd_known:1; /* drive supports READ_CD (0xbe) */
unsigned readcd_cdda:1; /* reading audio data using READ_CD */
unsigned media_present:1; /* media is present */
+
+ /* GET_EVENT spurious event handling, blk layer guarantees exclusion */
+ int tur_mismatch; /* nr of get_event TUR mismatches */
+ bool tur_changed:1; /* changed according to TUR */
+ bool get_event_changed:1; /* changed according to GET_EVENT */
+ bool ignore_get_event:1; /* GET_EVENT is unreliable, use TUR */
+
struct cdrom_device_info cdi;
/* We hold gendisk and scsi_device references on probe and use
* the refs on this kref to decide when to release them */
^ permalink raw reply related
* [PATCH block:for-2.6.31/core] block: flush MEDIA_CHANGE from drivers
From: Tejun Heo @ 2011-06-30 15:48 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-kernel, kay.sievers, linux-hotplug
Currently, only open(2) is defined as the 'clearing' point. It has
two roles - first, it's an acknowledgement from userland indicating
that the event has been received and kernel can clear pending states
and proceed to generate more events. Secondly, it's passed on to
device drivers as a hint indicating that a synchronization point has
been reached and it might want to take a deeper look at the device.
The latter currently is only used by sr which uses two different
mechanisms - GET_EVENT_MEDIA_STATUS_NOTIFICATION and TEST_UNIT_READY
to discover events, where the former is lighter weight and safe to be
used repeatedly but may not provide full coverage. Among other
things, GET_EVENT can't detect media removal while TUR can.
This patch makes close(2) - blkdev_put() - indicate clearing hint for
MEDIA_CHANGE to drivers. disk_check_events() is renamed to
disk_flush_events() and updated to take @mask for events to flush
which is or'd to ev->clearing and will be passed to the driver on the
next ->check_events() invocation.
This change makes sr generate MEDIA_CHANGE when media is ejected from
userland - e.g. with eject(1).
Note: Given the current usage, it seems @clearing hint is needlessly
complex. disk_clear_events() can simply clear all events and the hint
can be boolean @flush.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>
---
Jens, this patch is for 3.1 merge window but generated on top of the
current block:for-linus because it depends on the fixes in that
branch. It would probably be best to pull in for-linus into
for-2.6.32/core before applying this patch.
Thanks.
block/genhd.c | 22 ++++++++++++----------
fs/block_dev.c | 23 ++++++++++++++---------
include/linux/genhd.h | 2 +-
3 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 3608289..6cd3f5b 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1500,30 +1500,32 @@ void disk_unblock_events(struct gendisk *disk)
}
/**
- * disk_check_events - schedule immediate event checking
- * @disk: disk to check events for
+ * disk_flush_events - schedule immediate event checking and flushing
+ * @disk: disk to check and flush events for
+ * @mask: events to flush
*
- * Schedule immediate event checking on @disk if not blocked.
+ * Schedule immediate event checking on @disk if not blocked. Events in
+ * @mask are scheduled to be cleared from the driver. Note that this
+ * doesn't clear the events from @disk->ev.
*
* CONTEXT:
- * Don't care. Safe to call from irq context.
+ * If @mask is non-zero must be called with bdev->bd_mutex held.
*/
-void disk_check_events(struct gendisk *disk)
+void disk_flush_events(struct gendisk *disk, unsigned int mask)
{
struct disk_events *ev = disk->ev;
- unsigned long flags;
if (!ev)
return;
- spin_lock_irqsave(&ev->lock, flags);
+ spin_lock_irq(&ev->lock);
+ ev->clearing |= mask;
if (!ev->block) {
cancel_delayed_work(&ev->dwork);
queue_delayed_work(system_nrt_wq, &ev->dwork, 0);
}
- spin_unlock_irqrestore(&ev->lock, flags);
+ spin_unlock_irq(&ev->lock);
}
-EXPORT_SYMBOL_GPL(disk_check_events);
/**
* disk_clear_events - synchronously check, clear and return pending events
@@ -1713,7 +1715,7 @@ static int disk_events_set_dfl_poll_msecs(const char *val,
mutex_lock(&disk_events_mutex);
list_for_each_entry(ev, &disk_events, node)
- disk_check_events(ev->disk);
+ disk_flush_events(ev->disk, 0);
mutex_unlock(&disk_events_mutex);
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 610e8e0..6ff7f07 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1447,6 +1447,8 @@ static int __blkdev_put(struct block_device *bdev, fmode_t mode, int for_part)
int blkdev_put(struct block_device *bdev, fmode_t mode)
{
+ mutex_lock(&bdev->bd_mutex);
+
if (mode & FMODE_EXCL) {
bool bdev_free;
@@ -1455,7 +1457,6 @@ int blkdev_put(struct block_device *bdev, fmode_t mode)
* are protected with bdev_lock. bd_mutex is to
* synchronize disk_holder unlinking.
*/
- mutex_lock(&bdev->bd_mutex);
spin_lock(&bdev_lock);
WARN_ON_ONCE(--bdev->bd_holders < 0);
@@ -1473,17 +1474,21 @@ int blkdev_put(struct block_device *bdev, fmode_t mode)
* If this was the last claim, remove holder link and
* unblock evpoll if it was a write holder.
*/
- if (bdev_free) {
- if (bdev->bd_write_holder) {
- disk_unblock_events(bdev->bd_disk);
- disk_check_events(bdev->bd_disk);
- bdev->bd_write_holder = false;
- }
+ if (bdev_free && bdev->bd_write_holder) {
+ disk_unblock_events(bdev->bd_disk);
+ bdev->bd_write_holder = false;
}
-
- mutex_unlock(&bdev->bd_mutex);
}
+ /*
+ * Trigger event checking and tell drivers to flush MEDIA_CHANGE
+ * event. This is to ensure detection of media removal commanded
+ * from userland - e.g. eject(1).
+ */
+ disk_flush_events(bdev->bd_disk, DISK_EVENT_MEDIA_CHANGE);
+
+ mutex_unlock(&bdev->bd_mutex);
+
return __blkdev_put(bdev, mode, 0);
}
EXPORT_SYMBOL(blkdev_put);
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 300d758..02fa469 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -420,7 +420,7 @@ static inline int get_disk_ro(struct gendisk *disk)
extern void disk_block_events(struct gendisk *disk);
extern void disk_unblock_events(struct gendisk *disk);
-extern void disk_check_events(struct gendisk *disk);
+extern void disk_flush_events(struct gendisk *disk, unsigned int mask);
extern unsigned int disk_clear_events(struct gendisk *disk, unsigned int mask);
/* drivers/char/random.c */
^ permalink raw reply related
* Re: [PATCH block:for-2.6.31/core] block: flush MEDIA_CHANGE from
From: Jens Axboe @ 2011-07-01 14:18 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-kernel, kay.sievers, linux-hotplug
In-Reply-To: <20110630154822.GR3386@htj.dyndns.org>
On 2011-06-30 17:48, Tejun Heo wrote:
> Currently, only open(2) is defined as the 'clearing' point. It has
> two roles - first, it's an acknowledgement from userland indicating
> that the event has been received and kernel can clear pending states
> and proceed to generate more events. Secondly, it's passed on to
> device drivers as a hint indicating that a synchronization point has
> been reached and it might want to take a deeper look at the device.
>
> The latter currently is only used by sr which uses two different
> mechanisms - GET_EVENT_MEDIA_STATUS_NOTIFICATION and TEST_UNIT_READY
> to discover events, where the former is lighter weight and safe to be
> used repeatedly but may not provide full coverage. Among other
> things, GET_EVENT can't detect media removal while TUR can.
>
> This patch makes close(2) - blkdev_put() - indicate clearing hint for
> MEDIA_CHANGE to drivers. disk_check_events() is renamed to
> disk_flush_events() and updated to take @mask for events to flush
> which is or'd to ev->clearing and will be passed to the driver on the
> next ->check_events() invocation.
>
> This change makes sr generate MEDIA_CHANGE when media is ejected from
> userland - e.g. with eject(1).
>
> Note: Given the current usage, it seems @clearing hint is needlessly
> complex. disk_clear_events() can simply clear all events and the hint
> can be boolean @flush.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Kay Sievers <kay.sievers@vrfy.org>
> ---
> Jens, this patch is for 3.1 merge window but generated on top of the
> current block:for-linus because it depends on the fixes in that
> branch. It would probably be best to pull in for-linus into
> for-2.6.32/core before applying this patch.
Apart from some branch confusing in your email, I did that :-)
Applied, thanks.
--
Jens Axboe
^ permalink raw reply
* USB reloading
From: Sw@g @ 2011-07-02 0:50 UTC (permalink / raw)
To: linux-hotplug
to whom it might concern,
I am running ArchLinux with Gnome Shell for your information, I would
like to know if it would be possible to have a command (running in a
bash script) to reload a specific USB appliance (in that occasion a
Logitech Ultra Vision webcam).
It work well pretty much all the time but as I am not there when certain
user run their necessary application requiring the webcam I would like
to have an automatic relaunch (the same as a manual unplugging/pluggin
of the usb device)
If necessary all of the USB device could be re-loaded but I would prefer
for obvious reasons only that specific USB device to be re-loaded.
Looking forward for your advice,
Regards,
^ permalink raw reply
* udev 171 kernel requirement
From: William Hubbs @ 2011-07-06 19:31 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 398 bytes --]
Hello all,
I am one of the people who assists with maintaining udev on gentoo
linux.
I noticed that the README for udev-171 states that udev 171 requires
kernel 2.6.32. However, on gentoo, we currently have this open bug:
http://bugs.gentoo.org/show_bug.cgi?id=368403.
I figured out that the missing symbols appear in 2.6.34. So, is 2.6.34
the requirement for udev 171?
Thanks much,
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: udev 171 kernel requirement
From: Marco d'Itri @ 2011-07-06 19:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110706193100.GA10779@linux1>
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
On Jul 06, William Hubbs <williamh@gentoo.org> wrote:
> I figured out that the missing symbols appear in 2.6.34. So, is 2.6.34
> the requirement for udev 171?
Looks like this is just a build dependency. I will try hard to make udev
keep supporting 2.6.32 to allow for simpler upgrades (some distributions
actually support upgrading to the next release).
--
ciao,
Marco
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: detection usb camera devices in my own application
From: Alan Stern @ 2011-07-10 14:59 UTC (permalink / raw)
To: linux-hotplug
On Sun, 10 Jul 2011, Sudarshan Jagadale wrote:
> hello alan,
>
> thnaks for your response...:)
>
> I cant use lsusb since its utility and so it would not be available on all
> platforms.
>
> I dont use libusb-1.0, i was using file created by kernel i.e.
> /proc/bus/input/devices.
>
> how to use libusb? is it available on all linux machines/platforms ? can you
> give me more idea about its use and will it give me bus_info and card name
> /device name accuratly?
libusb is available for all Linux systems and also for Mac OS X and
Windows. See www.libusb.org.
> thanks in advance. one more point i have joined group "linux-hotplug" , i
> got welcome message but i am yet not able to send the email to that group? i
> get failure deliver from this group?
Maybe the mailing list doesn't like HTML-formatted email.
Alan Stern
^ permalink raw reply
* Re: detection usb camera devices in my own application
From: Alan Stern @ 2011-07-12 15:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1107101057360.12216-100000@netrider.rowland.org>
On Tue, 12 Jul 2011, Sudarshan Jagadale wrote:
> hello alan,
>
> If i dont want to use any library or usb.h in my hotplug detection and
> removal code then is there other way to do this?
You can copy the code from libusb into your own program, if you're
willing to follow the license requirements.
> I just want following information from system/kernel to my module like,
> idvendor,idproduct, bus_info, system device name?
> Bus info should be like we use in /dev/video0? is there any way to do this?
> in short i would like to make path equivalant to *usb_make_path()? how can i
> achive this ?
You can look through the directories under /sys/bus/usb/devices/.
Ignore directory names that start with "usb" or that contain a ':',
because they don't refer to external devices.
Within each of the remaining directories, the vendor ID is in a file
named idVendor and the product ID is in a file named idProduct. I
don't know what you mean by "bus_info" or "system device name".
Alan Stern
^ permalink raw reply
* Re: detection usb camera devices in my own application
From: Kay Sievers @ 2011-07-12 15:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1107101057360.12216-100000@netrider.rowland.org>
On Tue, Jul 12, 2011 at 17:51, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 12 Jul 2011, Sudarshan Jagadale wrote:
>> If i dont want to use any library or usb.h in my hotplug detection and
>> removal code then is there other way to do this?
>
> You can copy the code from libusb into your own program, if you're
> willing to follow the license requirements.
>
>> I just want following information from system/kernel to my module like,
>> idvendor,idproduct, bus_info, system device name?
>> Bus info should be like we use in /dev/video0? is there any way to do this?
>> in short i would like to make path equivalant to *usb_make_path()? how can i
>> achive this ?
>
> You can look through the directories under /sys/bus/usb/devices/.
> Ignore directory names that start with "usb" or that contain a ':',
> because they don't refer to external devices.
>
> Within each of the remaining directories, the vendor ID is in a file
> named idVendor and the product ID is in a file named idProduct. Â I
> don't know what you mean by "bus_info" or "system device name".
This is a rather old, but still almost valid example of a
full-hotplug-support program handling video devices:
http://article.gmane.org/gmane.linux.hotplug.devel/13925
(I still can see only Alan's mails. Alan, you are the HTML-filter? :))
Kay
^ permalink raw reply
* Re: detection usb camera devices in my own application
From: Alan Stern @ 2011-07-12 20:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1107101057360.12216-100000@netrider.rowland.org>
On Tue, 12 Jul 2011, Kay Sievers wrote:
> This is a rather old, but still almost valid example of a
> full-hotplug-support program handling video devices:
> http://article.gmane.org/gmane.linux.hotplug.devel/13925
Kay, you undoubtedly didn't see the earlier messages from Sudarshan.
They said that he wanted to enumerate these video devices even when the
corresponding video driver wasn't loaded. I'm not sure that this
really makes sense, but that's what he asked.
> (I still can see only Alan's mails. Alan, you are the HTML-filter? :))
Apparently so. :-) I did tell Sudarshan not to send HTML-formatted
messages to the mailing list.
Alan Stern
^ permalink raw reply
* [PATCH] udev-acl: handle "dialout" devices
From: Linus Walleij @ 2011-07-14 12:23 UTC (permalink / raw)
To: linux-hotplug
As a simple user, I'm pretty tired of this, when using a
simple serial console for something:
$ minicom
Device /dev/ttyUSB0 access failed: Permission denied.
The device is indeed readable/writable by the group "dialout":
$ ls -al /dev/ttyUSB0
crw-rw----. 1 root dialout 188, 0 Jul 14 14:11 /dev/ttyUSB0
But that group is not maintained by anyone just installing Linux
for some simple desktop use. Just like we let udev-acl handle
media players, cameras and whatnot, let it handle modems, not to
mention the fact that these "dialouts" are often just some serial
link or irDA link, we don't really know if they are modems after
all.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
| 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--git a/extras/udev-acl/70-udev-acl.rules b/extras/udev-acl/70-udev-acl.rules
index 2dac283..770da3c 100644
--- a/extras/udev-acl/70-udev-acl.rules
+++ b/extras/udev-acl/70-udev-acl.rules
@@ -12,6 +12,9 @@ TEST="/sys/fs/cgroup/systemd", TAG="uaccess", GOTO="acl_end"
# PTP/MTP protocol devices, cameras, portable media players
SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:060101:*", TAG+="udev-acl"
+# USB-to-serial dongles, irDA links and other stuff classified as "dialout"
+GROUP="dialout", TAG+="udev-acl"
+
# digicams with proprietary protocol
ENV{ID_GPHOTO2}="*?", TAG+="udev-acl"
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] udev-acl: handle "dialout" devices
From: Kay Sievers @ 2011-07-14 12:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1310646233-2113-1-git-send-email-linus.walleij@linaro.org>
On Thu, Jul 14, 2011 at 14:23, Linus Walleij <linus.walleij@linaro.org> wrote:
> As a simple user, I'm pretty tired of this, when using a
> simple serial console for something:
> $ minicom
> Device /dev/ttyUSB0 access failed: Permission denied.
> +# USB-to-serial dongles, irDA links and other stuff classified as "dialout"
> +GROUP="dialout", TAG+="udev-acl"
We obviously can't do that for security reasons. Any untrusted user
could call 900 numbers that way. You need to put yourself in the
dialout group or use a privileged helper to wrap your access.
Kay
^ permalink raw reply
* Re: [PATCH] udev-acl: handle "dialout" devices
From: Linus Walleij @ 2011-07-14 16:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1310646233-2113-1-git-send-email-linus.walleij@linaro.org>
On Thu, Jul 14, 2011 at 2:27 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Jul 14, 2011 at 14:23, Linus Walleij <linus.walleij@linaro.org> wrote:
>> As a simple user, I'm pretty tired of this, when using a
>> simple serial console for something:
>> $ minicom
>> Device /dev/ttyUSB0 access failed: Permission denied.
>
>> +# USB-to-serial dongles, irDA links and other stuff classified as "dialout"
>> +GROUP="dialout", TAG+="udev-acl"
>
> We obviously can't do that for security reasons. Any untrusted user
> could call 900 numbers that way. You need to put yourself in the
> dialout group or use a privileged helper to wrap your access.
First I think that is only interesting to administrators of servers
and largescale installations, is that right? It does only create
obstacles for a home desktop user that s/he cannot use a modem
with a default install of the OS.
So if it is an axiom that the default ACL rules are for servers,
I understand this, is that the case?
But there is plain naming problems with this default rule
(which creates the dialout group):
# serial
KERNEL="tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*",
GROUP="dialout"
tty[A-Z]*[0-9] and ircomm[0-9]* has nothing implicit in their
drivers that tells you there is a modem on the other side.
I will cook another patch that illustrates the problem better...
Thanks,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] udev-acl: handle "dialout" devices
From: Marco d'Itri @ 2011-07-14 16:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1310646233-2113-1-git-send-email-linus.walleij@linaro.org>
On Jul 14, Linus Walleij <linus.walleij@linaro.org> wrote:
> First I think that is only interesting to administrators of servers
> and largescale installations, is that right? It does only create
No, it is interesting to owners of any host connected to a modem which
can be compromised to allow execution of arbitrary code.
> obstacles for a home desktop user that s/he cannot use a modem
> with a default install of the OS.
So ask your favourite distribution to add by default to the dialout
group the user created at install time.
> So if it is an axiom that the default ACL rules are for servers,
Is it?
> tty[A-Z]*[0-9] and ircomm[0-9]* has nothing implicit in their
> drivers that tells you there is a modem on the other side.
Serial modems are like this, sometimes you cannot detect them.
--
ciao,
Marco
^ permalink raw reply
* Re: [PATCH] udev-acl: handle "dialout" devices
From: Linus Walleij @ 2011-07-14 17:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1310646233-2113-1-git-send-email-linus.walleij@linaro.org>
On Thu, Jul 14, 2011 at 6:44 PM, Marco d'Itri <md@linux.it> wrote:
> On Jul 14, Linus Walleij <linus.walleij@linaro.org> wrote:
>> First I think that is only interesting to administrators of servers
>> and largescale installations, is that right? It does only create
>
> No, it is interesting to owners of any host connected to a modem which
> can be compromised to allow execution of arbitrary code.
.. just like they should be worried of same black hats connecting
to their iPoD and stealing their soundfiles (which may be recordings
of sensitive meetings), so we should stop using udev-acl for these
too, and mandate that everyone create a GROUP="mediaplayer"
as well?
I'd argue that there are soon more people using their serial port
for most other things than modems than there are people
doing that soon or already now.
But who knows...
I know users of most other operating systems are able to use
their serial ports without administering themselves into a "dialout"
group, but they can of course be wrong.
>> obstacles for a home desktop user that s/he cannot use a modem
>> with a default install of the OS.
>
> So ask your favourite distribution to add by default to the dialout
> group the user created at install time.
Yeah next patch set is about helping distros with that by adding
the necessary ID_EXTERNAL_PORT and ID_MODEM environment
variables so they can easily do that.
>> tty[A-Z]*[0-9] and ircomm[0-9]* has nothing implicit in their
>> drivers that tells you there is a modem on the other side.
>
> Serial modems are like this, sometimes you cannot detect them.
Can you ever do it? According to some sources Windows
sends "ATI0" to external ports to detect modems, but I guess it's
after manually requesting some "Wizard" program to look for
modems...
Thanks,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] rules: split serial links
From: Linus Walleij @ 2011-07-14 17:24 UTC (permalink / raw)
To: linux-hotplug
This splits the large serial links rule into:
- Local serial ports such as tty[A-Z]*[0-9]* and irDA links
- Bluetooth links
- Modem links
It also adds some explanation of why local serial ports and
bluetooth links are put into the "dialout" group.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
rules/rules.d/50-udev-default.rules | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/rules/rules.d/50-udev-default.rules b/rules/rules.d/50-udev-default.rules
index f5b181d..7684ea9 100644
--- a/rules/rules.d/50-udev-default.rules
+++ b/rules/rules.d/50-udev-default.rules
@@ -7,8 +7,16 @@ KERNEL="tty", GROUP="tty", MODE="0666"
KERNEL="tty[0-9]*", GROUP="tty", MODE="0620"
KERNEL="vcs|vcs[0-9]*|vcsa|vcsa[0-9]*", GROUP="tty"
-# serial
-KERNEL="tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"
+# external serial ports - these may or may not be connected to modems,
+# we assume they are connected to modems for security reasons
+KERNEL="tty[A-Z]*[0-9]|ircomm[0-9]*", GROUP="dialout"
+
+# bluetooth TTY links - not always possible to use for dialout but we
+# assume so anyway for security reasons
+KERNEL="rfcomm[0-9]*", GROUP="dialout"
+
+# modems
+KERNEL="pppox[0-9]*|noz[0-9]*", GROUP="dialout"
KERNEL="mwave", GROUP="dialout"
KERNEL="hvc*|hvsi*", GROUP="dialout"
--
1.7.6
^ permalink raw reply related
* [PATCH 2/2] rules: add ID_EXTERNAL_PORT and ID_MODEM
From: Linus Walleij @ 2011-07-14 17:24 UTC (permalink / raw)
To: linux-hotplug
Distributions doing desktop spins or other single-user systems
may be interested in enabling access to the external ports (serial,
USB-to-serial dongle etc) and modems for the logged-in user.
To help with this, mark external serial ports with
ID_EXTERNAL_PORT and modems with ID_MODEM. This way a distributor
can create a 60-desktop-acl.rules (or similarly named) file like
this:
ENV{ID_EXTERNAL_PORT}="*?", TAG+="udev-acl"
ENV{ID_MODEM}="*?", TAG+="udev-acl"
To enable local access to external ports and modems on these
specific distributions.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
rules/rules.d/50-udev-default.rules | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/rules/rules.d/50-udev-default.rules b/rules/rules.d/50-udev-default.rules
index 7684ea9..2ad08e9 100644
--- a/rules/rules.d/50-udev-default.rules
+++ b/rules/rules.d/50-udev-default.rules
@@ -9,16 +9,16 @@ KERNEL="vcs|vcs[0-9]*|vcsa|vcsa[0-9]*", GROUP="tty"
# external serial ports - these may or may not be connected to modems,
# we assume they are connected to modems for security reasons
-KERNEL="tty[A-Z]*[0-9]|ircomm[0-9]*", GROUP="dialout"
+KERNEL="tty[A-Z]*[0-9]|ircomm[0-9]*", GROUP="dialout", ENV{ID_EXTERNAL_PORT}="1"
# bluetooth TTY links - not always possible to use for dialout but we
# assume so anyway for security reasons
-KERNEL="rfcomm[0-9]*", GROUP="dialout"
+KERNEL="rfcomm[0-9]*", GROUP="dialout", ENV{ID_EXTERNAL_PORT}="1"
# modems
-KERNEL="pppox[0-9]*|noz[0-9]*", GROUP="dialout"
-KERNEL="mwave", GROUP="dialout"
-KERNEL="hvc*|hvsi*", GROUP="dialout"
+KERNEL="pppox[0-9]*|noz[0-9]*", GROUP="dialout", ENV{ID_MODEM}="1"
+KERNEL="mwave", GROUP="dialout", ENV{ID_MODEM}="1"
+KERNEL="hvc*|hvsi*", GROUP="dialout", ENV{ID_MODEM}="1"
# virtio serial / console ports
KERNEL="vport*", ATTR{name}="?*", SYMLINK+="virtio-ports/$attr{name}"
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 2/2] rules: add ID_EXTERNAL_PORT and ID_MODEM
From: Kay Sievers @ 2011-07-14 18:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1310664282-6287-1-git-send-email-linus.walleij@linaro.org>
On Thu, Jul 14, 2011 at 19:24, Linus Walleij <linus.walleij@linaro.org> wrote:
> Distributions doing desktop spins or other single-user systems
> may be interested in enabling access to the external ports (serial,
> USB-to-serial dongle etc) and modems for the logged-in user.
Almost all distributions with desktop focus run a system-wide service
like ModemManager on connman, which hook into udev and probes and
classifies modems, and tags them in a more reliable way. The users
usually talk to these services not to the devices directly.
> ENV{ID_EXTERNAL_PORT}="*?", TAG+="udev-acl"
We really don't want to get into the external/internal business ever,
that can not be reliable determined.
Kay
^ permalink raw reply
* Re: [PATCH 2/2] rules: add ID_EXTERNAL_PORT and ID_MODEM
From: Linus Walleij @ 2011-07-14 18:07 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1310664282-6287-1-git-send-email-linus.walleij@linaro.org>
On Thu, Jul 14, 2011 at 8:03 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Jul 14, 2011 at 19:24, Linus Walleij <linus.walleij@linaro.org> wrote:
>> ENV{ID_EXTERNAL_PORT}="*?", TAG+="udev-acl"
>
> We really don't want to get into the external/internal business ever,
> that can not be reliable determined.
I used ID_SERIAL first, but that was taken by serial numbers...
ID_SERIAL_PORT is maybe smarter.
But I'll drop that patch anyway, so nevermind.
Thanks,
Linus Walleij
^ permalink raw reply
* UDEV : ASUS Laptop G73S MultiCard Reader
From: Postmaster @ 2011-07-16 12:00 UTC (permalink / raw)
To: linux-hotplug
my laptop comes with an internal Realtek card reader ( vendor=0x0bda,
product=0x0139 )
It is not recognized by udevd.
The bInterface class is 255, which I think is wrong ( should be 8 for
mass storage device, i think )
Right now the kern does not assign this device to usb-storage.
The realtek driver is nice, but the product id of 0x0138 does not match
this productid 0f 0x0139.
How are the udev hooks supposed to work to rename the bInterface class
from vendor specific to mass storage/realtek driver?
============LSUSB -v =================
Bus 001 Device 004: ID 0bda:0139 Realtek Semiconductor Corp. USB 2.0
multicard reader
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x0139 USB 2.0 multicard reader
bcdDevice 39.60
iManufacturer 1 Generic
iProduct 2 USB2.0-CRW
iSerial 3 20100201396000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 CARD READER
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 6
bInterfaceProtocol 80
iInterface 5 Bulk-In, Bulk-Out, Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0003 1x 3 bytes
bInterval 10
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
[root@Asus gat]#
^ permalink raw reply
* Re: UDEV : ASUS Laptop G73S MultiCard Reader
From: Greg KH @ 2011-07-17 9:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E217D77.7030503@gatworks.com>
On Sat, Jul 16, 2011 at 08:00:55AM -0400, Postmaster wrote:
> my laptop comes with an internal Realtek card reader (
> vendor=0x0bda, product=0x0139 )
>
> It is not recognized by udevd.
>
> The bInterface class is 255, which I think is wrong ( should be 8
> for mass storage device, i think )
If so, that's the device problem, nothing you can do from the kernel, or
from udev, to change that. See the USB spec for details.
> Right now the kern does not assign this device to usb-storage.
> The realtek driver is nice, but the product id of 0x0138 does not
> match this productid 0f 0x0139.
That is because this is a different device, and it says it is a
vendor-specific protocol, which will not work with the usb-storage
driver, sorry.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] rules: split serial links
From: Linus Walleij @ 2011-07-17 9:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1310664275-6257-1-git-send-email-linus.walleij@linaro.org>
On Thu, Jul 14, 2011 at 7:24 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This splits the large serial links rule into:
> - Local serial ports such as tty[A-Z]*[0-9]* and irDA links
> - Bluetooth links
> - Modem links
>
> It also adds some explanation of why local serial ports and
> bluetooth links are put into the "dialout" group.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This one is OK then? Or do you want me to re-send it as a single
[PATCH]?
Thanks,
Linus Walleij
^ permalink raw reply
* Re: UDEV : ASUS Laptop G73S MultiCard Reader
From: Postmaster @ 2011-07-17 15:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E217D77.7030503@gatworks.com>
> That is because this is a different device, and it says it is a
> vendor-specific protocol, which will not work with the usb-storage
> driver, sorry.
I Disagree with most of what u suggest.
Who knows what vendor specific means. And you really wont know until you
try. Which is why there are tables to handle Unusual Devices.
At this time there is a realtek driver in the latest kern code. I would
like to load up this driver when usb-core detects this device.
Right now, I have not found the udev rule for loading up usb-storage.
So where are the udev system specs
BTW: is there a way to disable, and enable the device? Since this usb
device is internal, if I have too many "printk" or DBG messages at
boot-up time, it tends to overflow the rsyslogd daemon.
btw#2 where is this forum? All one sees in the written docs is to email
questions, rather than post questions to a forum.
^ permalink raw reply
* Re: detection usb camera devices in my own application
From: Kay Sievers @ 2011-07-17 17:11 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1107101057360.12216-100000@netrider.rowland.org>
On Tue, Jul 12, 2011 at 22:32, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 12 Jul 2011, Kay Sievers wrote:
>
>> This is a rather old, but still almost valid example of a
>> full-hotplug-support program handling video devices:
>> http://article.gmane.org/gmane.linux.hotplug.devel/13925
>
> Kay, you undoubtedly didn't see the earlier messages from Sudarshan.
> They said that he wanted to enumerate these video devices even when the
> corresponding video driver wasn't loaded. I'm not sure that this
> really makes sense, but that's what he asked.
I see. Yeah, I only see your messages. :)
The example to hook into hotplug events and enumerate existing devices
should still work the same way by subscribing to subsytem:"usb",
devtype:"usb_device" events instead of the "video4linux" ones. All
usual properties of the device can just be retrieved with libudev.
>> (I still can see only Alan's mails. Alan, you are the HTML-filter? :))
>
> Apparently so. :-) I did tell Sudarshan not to send HTML-formatted
> messages to the mailing list.
Right, all html messages are rejected at the receiving smtp server,
they never reach kernel.org.
Kay
^ permalink raw reply
* Re: UDEV : ASUS Laptop G73S MultiCard Reader
From: Greg KH @ 2011-07-17 18:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E217D77.7030503@gatworks.com>
On Sun, Jul 17, 2011 at 11:50:31AM -0400, Postmaster wrote:
>
> >That is because this is a different device, and it says it is a
> >vendor-specific protocol, which will not work with the usb-storage
> >driver, sorry.
>
> I Disagree with most of what u suggest.
I'm sorry to hear that.
> Who knows what vendor specific means. And you really wont know until
> you try. Which is why there are tables to handle Unusual Devices.
If a vendor says it is not a mass-storage device, why do you think they
are lying? And the term, "vendor specific" has a very specific
definition, see the USB specification if you are curious as to what it
is.
> At this time there is a realtek driver in the latest kern code. I
> would like to load up this driver when usb-core detects this device.
>
> Right now, I have not found the udev rule for loading up usb-storage.
There is no such rule, the usb device id causes it to happen through
modprobe of the module alias of the device.
> So where are the udev system specs
This is not something that udev does at all, sorry.
> BTW: is there a way to disable, and enable the device? Since this
> usb device is internal, if I have too many "printk" or DBG messages
> at boot-up time, it tends to overflow the rsyslogd daemon.
>
> btw#2 where is this forum? All one sees in the written docs is to
> email questions, rather than post questions to a forum.
Yes, this is done through email, not a web forum.
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox