BUG: missing get_mtd_device when running cat /dev/mtdblock*

[Jörn Engel]

On Mon, 31 July 2006 17:12:16 +0200, Jörn Engel wrote:
> On Mon, 31 July 2006 10:05:52 -0500, Josh Boyer wrote:
> > On 7/31/06, Jörn Engel <joern at wohnheim.fh-wedel.de> wrote:
> > >While debugging on a 2.6.5 kernel (with fairly recent mtd) I noticed
> > >that mtdblock appears to be bypassing get_mtd_device().
> > 
> > Yes, it bypasses calling that.  But...
> > 
> > >Can anyone verify this on current mtd by adding a simple printk() to
> > >get_mtd_device() and running cat /dev/mtdblock0 > /dev/null or so?
> > >
> > >I am assuming this is not desired behaviour and should get fixed.
> > 
> > It seems mtd_blkdevs.c handles the reference counting itself.  See
> > blktrans_open.  Most certainly this could be changed to call
> > get_mtd_device instead, but I believe all the locking is correct as it
> > stands.
> > 
> > Might want to double check though.
> 
> Well, the gluebi patch does not work with that.  Among other things,
> gluebi introduced two new methods to struct mtd_info:
> 
> +	int (*open) (struct mtd_info *mtd);
> +	int (*close) (struct mtd_info *mtd);

And with those two methods, the refcounting in mtd_blkdevs.c is no
longer correct.  It is plain impossibly to synchronize mtd_blkdevs.c
and mtdcore.c race-free.  You can end up calling open() twice or not
at all, depending on your design.

Jörn

-- 
"Error protection by error detection and correction."
-- from a university class