[systemd-devel] cdrom_id opens device with O_EXCL, why?

[Hoyer, Marko (ADITG/SW2)]

> -----Original Message-----
> From: David Herrmann [mailto:dh.herrmann at gmail.com]
> Sent: Thursday, September 18, 2014 1:57 PM
> To: Hoyer, Marko (ADITG/SW2)
> Cc: systemd-devel at 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.herrmann at 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 "cd"ing 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