[systemd-devel] cdrom_id opens device with O_EXCL, why?
Hello together, I recently stumbled over cdrom_id opening the device with the O_EXCL flag set, if it is not currently mounted: fd = open(node, O_RDONLY|O_NONBLOCK|(is_mounted(node) ? 0 : O_EXCL)); The effect of this is that automatically mounting a cdrom sometimes results in resource busy, if change uevents of the devices are processed by udevd while the automounter (udisks or something different in my case) is currently trying to mount the device triggered by a previous add or change uevent. I've to questions to this issue. Maybe someone of you can help me: 1. Is there any particular reason why cdrom_id should open the device exclusively (especially since it is not opened exclusively when it is already mounted)? 2. If there is any good reason to keep this behavior: How is the best way for an automounter to deal with this? Retry? Something different? Thx in advance for valuable input. Best regards Marko Hoyer Advanced Driver Information Technology GmbH Software Group II (ADITG/SW2) Robert-Bosch-Str. 200 31139 Hildesheim Germany Tel. +49 5121 49 6948 Fax +49 5121 49 6999 mho...@de.adit-jv.com ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car Multimedia GmbH and DENSO Corporation Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438 Geschaeftsfuehrung: Wilhelm Grabow, Katsuyoshi Maeda ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id opens device with O_EXCL, why?
-Original Message- From: Hoyer, Marko (ADITG/SW2) Sent: Thursday, September 18, 2014 8:22 AM To: systemd-devel@lists.freedesktop.org Subject: cdrom_id opens device with O_EXCL, why? Hello together, I recently stumbled over cdrom_id opening the device with the O_EXCL flag set, if it is not currently mounted: fd = open(node, O_RDONLY|O_NONBLOCK|(is_mounted(node) ? 0 : O_EXCL)); The effect of this is that automatically mounting a cdrom sometimes results in resource busy, if change uevents of the devices are processed by udevd while the automounter (udisks or something different in my case) is currently trying to mount the device triggered by a previous add or change uevent. I've to questions to this issue. Maybe someone of you can help me: 1. Is there any particular reason why cdrom_id should open the device exclusively (especially since it is not opened exclusively when it is already mounted)? 2. If there is any good reason to keep this behavior: How is the best way for an automounter to deal with this? Retry? Something different? Thx in advance for valuable input. There is one additional more general issue with the behavior of cdrom_id. - Insert a cdrom and mount it. - cd into the mounted subtree of the cdrom - do an lazy unmount (umount -l /dev/sr0) From now on, cdrom_id will fail completely due to the following reasons: - the bash which cded into the mounted sub tree creates busy i-nodes - this keeps the kernel from releasing the /dev/sr0 node - the lazy umount appears to the userspace as if nothing is mounted any more (no entry in /proc/self/mountinfo, which is evaluated by cdrom_id) - due to this, cdrom_id tries to open the device exclusively, which fails - after 20 retries, cdrom_id finally fails The kernel itself is able to deal with this issue. Even though we have this busy i-nodes hanging around in the back, it allows mounting the cd drive again at a different position. So the only blocker seems to me is cdrom_id, failing opening the device exclusively. Any comments? Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id opens device with O_EXCL, why?
Hi On Thu, Sep 18, 2014 at 8:22 AM, Hoyer, Marko (ADITG/SW2) mho...@de.adit-jv.com wrote: Hello together, I recently stumbled over cdrom_id opening the device with the O_EXCL flag set, if it is not currently mounted: fd = open(node, O_RDONLY|O_NONBLOCK|(is_mounted(node) ? 0 : O_EXCL)); The effect of this is that automatically mounting a cdrom sometimes results in resource busy, if change uevents of the devices are processed by udevd while the automounter (udisks or something different in my case) is currently trying to mount the device triggered by a previous add or change uevent. I've to questions to this issue. Maybe someone of you can help me: 1. Is there any particular reason why cdrom_id should open the device exclusively (especially since it is not opened exclusively when it is already mounted)? 2. If there is any good reason to keep this behavior: How is the best way for an automounter to deal with this? Retry? Something different? This was introduced in: commit 38a3cde11bc77af49a96245b8a8a0f2b583a344c Author: Kay Sievers kay.siev...@vrfy.org Date: Thu Mar 18 11:14:32 2010 +0100 cdrom_id: open non-mounted optical media with O_EXCL This should prevent confusing drives during CD burning sessions. Based on a patch from Harald Hoyer. According to this commit we use O_EXCL to not confuse burning-sessions that might run in parallel. Admittedly, burning-sessions should usually open the device themselves via O_EXCL, or lock critical sections via scsi, but I guess back in the days we had to work around bugs in other programs (or I may be missing something non-obvious; I'm not that much into scsi..). Regarding what do to: If you deal with cdrom devices and get EBUSY, I'd simply ignore the device. In case of udev, you get a uevent once udev is done, and usually that means the device changed in some way so it's *good* you wait for it to be processed. So your automounter will get a uevent once udev is done and can then try to mount the device. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id opens device with O_EXCL, why?
-Original Message- From: David Herrmann [mailto:dh.herrm...@gmail.com] Sent: Thursday, September 18, 2014 10:31 AM To: Hoyer, Marko (ADITG/SW2) Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] cdrom_id opens device with O_EXCL, why? Hi On Thu, Sep 18, 2014 at 8:22 AM, Hoyer, Marko (ADITG/SW2) mho...@de.adit- jv.com wrote: Hello together, I recently stumbled over cdrom_id opening the device with the O_EXCL flag set, if it is not currently mounted: fd = open(node, O_RDONLY|O_NONBLOCK|(is_mounted(node) ? 0 : O_EXCL)); The effect of this is that automatically mounting a cdrom sometimes results in resource busy, if change uevents of the devices are processed by udevd while the automounter (udisks or something different in my case) is currently trying to mount the device triggered by a previous add or change uevent. I've to questions to this issue. Maybe someone of you can help me: 1. Is there any particular reason why cdrom_id should open the device exclusively (especially since it is not opened exclusively when it is already mounted)? 2. If there is any good reason to keep this behavior: How is the best way for an automounter to deal with this? Retry? Something different? This was introduced in: commit 38a3cde11bc77af49a96245b8a8a0f2b583a344c Author: Kay Sievers kay.siev...@vrfy.org Date: Thu Mar 18 11:14:32 2010 +0100 cdrom_id: open non-mounted optical media with O_EXCL This should prevent confusing drives during CD burning sessions. Based on a patch from Harald Hoyer. According to this commit we use O_EXCL to not confuse burning-sessions that might run in parallel. Admittedly, burning-sessions should usually open the device themselves via O_EXCL, or lock critical sections via scsi, but I guess back in the days we had to work around bugs in other programs (or I may be missing something non-obvious; I'm not that much into scsi..). Regarding what do to: If you deal with cdrom devices and get EBUSY, I'd simply ignore the device. In case of udev, you get a uevent once udev is done, and usually that means the device changed in some way so it's *good* you wait for it to be processed. So your automounter will get a uevent once udev is done and can then try to mount the device. Thanks David Thx for the answer. The automounter is listening to the udev socket so it is actually waiting for the event to be processed completely. But unfortunately, it appears that sequences of change events might come in a short time frame. So the automounter is trying to mount the device triggered by the first one, while udevd is currently processing the second one. That's what's happening actually in my case. Besides that the issue with cdrom_id not working in case of a lazy unmount (described in my second mail) seems to me to be a bit more critical. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id opens device with O_EXCL, why?
Hi On Thu, Sep 18, 2014 at 1:02 PM, Hoyer, Marko (ADITG/SW2) mho...@de.adit-jv.com wrote: Thx for the answer. The automounter is listening to the udev socket so it is actually waiting for the event to be processed completely. But unfortunately, it appears that sequences of change events might come in a short time frame. So the automounter is trying to mount the device triggered by the first one, while udevd is currently processing the second one. That's what's happening actually in my case. Besides that the issue with cdrom_id not working in case of a lazy unmount (described in my second mail) seems to me to be a bit more critical. The automounter could just ignore the udev event on EBUSY. That is, if you get EBUSY, bail out (maybe print a debug message) and just do nothing. If udev was the offending O_EXCL blocker, you can be sure to get a follow-up event. Regarding lazy-unmount: That's just ugly. I have no idea how to work around that, sorry. I'm putting Harald and Kay on CC, as they added O_EXCL to protect against parallel burning-sessions. Maybe they can tell you whether that is still needed today and whether we can drop it. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id opens device with O_EXCL, why?
Hi again On Thu, Sep 18, 2014 at 1:34 PM, David Herrmann dh.herrm...@gmail.com wrote: I'm putting Harald and Kay on CC, as they added O_EXCL to protect against parallel burning-sessions. Maybe they can tell you whether that is still needed today and whether we can drop it. So my conception of O_EXCL was kinda wrong. O_EXCL on block devices fails with EBUSY if, and only if, there's someone else also opening the device with O_EXCL. You can still open it without O_EXCL. Now, the kernel-internal mount helpers always keep O_EXCL for mounted block devices. This way, user-space can open block devices via O_EXCL and be sure no-one can mount it in parallel. For your automounter, this means you should just drop the event on EBUSY. If udev was the offender, you will get a follow-up event. If fsck was the offender, you're screwed anyway as it takes ages to complete (but fsck shouldn't be any problem for the automounter, anyway). if anyone else is the offender, you have no idea what they do, so you should just fail right away. Regarding lazy-unmount: It'd require kernel support to notice such usage in user-space. I don't plan on working on this (and nobody really cares). But if there will be a kernel-interface, we'd gladly accept patches to fix cdrom_id. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id opens device with O_EXCL, why?
-Original Message- From: David Herrmann [mailto:dh.herrm...@gmail.com] Sent: Thursday, September 18, 2014 1:57 PM To: Hoyer, Marko (ADITG/SW2) Cc: systemd-devel@lists.freedesktop.org; Harald Hoyer; Kay Sievers Subject: Re: [systemd-devel] cdrom_id opens device with O_EXCL, why? Hi again On Thu, Sep 18, 2014 at 1:34 PM, David Herrmann dh.herrm...@gmail.com wrote: I'm putting Harald and Kay on CC, as they added O_EXCL to protect against parallel burning-sessions. Maybe they can tell you whether that is still needed today and whether we can drop it. So my conception of O_EXCL was kinda wrong. O_EXCL on block devices fails with EBUSY if, and only if, there's someone else also opening the device with O_EXCL. You can still open it without O_EXCL. Now, the kernel-internal mount helpers always keep O_EXCL for mounted block devices. This way, user-space can open block devices via O_EXCL and be sure no-one can mount it in parallel. Yeah that's true, that's what I found as well. But exactly this parallel try to mount the device while cdrom_id is working is the problem here. I understand that it is needed for some processes to get exclusive access to a device for good reasons (to prevent mounting for instance). I'd like to understand the reason for cdrom_id especially since it gets only exclusive access if no one mounted the device before. For your automounter, this means you should just drop the event on EBUSY. If udev was the offender, you will get a follow-up event. If fsck was the offender, you're screwed anyway as it takes ages to complete (but fsck shouldn't be any problem for the automounter, anyway). if anyone else is the offender, you have no idea what they do, so you should just fail right away. I've to think about just kicking the event. My first guess is that it is a kind of complicated because there is a comparable complex state machine in the background. My way out would be probably implementing a retry mechanism for the mounting. That would cover all you suggested as well, I guess. Regarding lazy-unmount: It'd require kernel support to notice such usage in user-space. I don't plan on working on this (and nobody really cares). But if there will be a kernel-interface, we'd gladly accept patches to fix cdrom_id. I'm not really happy with the lazy umount mechanism as well especially with the completely untransparent behavior in the background. But in my case it seems to be the only way out. The thing is that I cannot guarantee that some applications just keeps i-nodes of a mounted sd-card for instance (just cding into the subtree is enough). But I have to react somehow if the card is removed. There are two options: 1. I'm not unmounting the partition. - In principal, this is somehow ok (not nice), any further IO access leads to IO errors. - Since the mount point is still available, other applications can enter as well (ok, but not nice) - The shit happens when now someone inserts another sd card - I'm not able to mount the partition (with same number) of the new sda card since the device node is still mounted - Applications entering the mount point are getting lots of rubbish when they access i-nodes linked to cached parent nodes (the files in the root dir for instance) So this is really not a good way out here. 2. I'm lazy umounting the partition so that the scope is really only limited to applications that are keeping i-nodes and only to the i-nodes that are kept. - No other application can access the invalid cached i-nodes any more - I can mount a new sd card without any problems even if we have the same partition number - The kept i-nodes are removed automatically when the application decides to release them - Part of the shit remains: - The application keeping the i-node are getting still rubbish in case a new card is inserted. But only this one application. Well the world is not perfect. So back to the initial question. Is there still a valid reason why cdrom_id is acquiring exclusive access? The cd buring case is at least for me not really a problem. If this is the only reason I could simply locally patch it out. But to be honest, I can't really imagine how this mechanism could even help with this use case ... Thanks David Regards, Marko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
