linux-kernel - Re: [PATCH 2/4] chardev: Increment cdev reference count when i

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-prev] [day] [month] [year] [list]

Message-ID: <20141105165418.GD30558@quack.suse.cz>
Date:	Wed, 5 Nov 2014 17:54:18 +0100
From:	Jan Kara <jack@...e.cz>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Jan Kara <jack@...e.cz>, hch@....de, linux-fsdevel@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] chardev: Increment cdev reference count when i_cdev
 references it

On Tue 04-11-14 16:03:03, Al Viro wrote:
> On Tue, Nov 04, 2014 at 04:55:43PM +0100, Jan Kara wrote:
> > > That consequence looks broken, IMO.
> >   Hum, it already behaves for block devices that way (and noone complained
> > - but admittedly block devices tied to strange modules are less common than
> > character devices). Also rmmod isn't that common IMO, but I see your point
> > that it's unintuitive behavior.
> 
> Umm...  Since when?  The last time I looked, bdev module refcounts were
> tied to struct gendisk, not to struct block_device.
  Ah, right you are. So how about clearing i_cdev and dropping reference to
it when inode is not open anymore? Doing first open after a cleanup would
be more expensive but it doesn't seem too much. For block devices first
open of it is also more expensive - although there bd_openers is per block
device while for character devices we would have the openers per device
inode.  I don't think that's a real difference in practice unless you run
some container service. If you think it would help, we could add some
intermediate structure for character devices with similar rules like struct
block_device for block devices (and character device references would be
handled in the same way as we handle gendisk references for block devices).
However I don't think it's really worth the bother...


								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/