[PATCH v2 1/2] mtd: Stop directly calling master ->_xxx() hooks from mtdpart code

[Boris Brezillon]

Le Tue, 27 Jun 2017 11:46:14 -0700,
Brian Norris <computersforpeace at gmail.com> a écrit :

> On Sun, Jun 25, 2017 at 06:01:12PM +0200, Boris Brezillon wrote:
> > The MTD layer provides several wrappers around mtd->_xxx() hooks. Call
> > these wrappers instead of directly dereferencing the associated ->_xxx()
> > pointer.
> > 
> > This change has been motivated by another rework letting the core
> > handle the case where ->_read/write_oob() are implemented but not  
> > ->_read/write(). In this case, we want mtd_read/write() to fall back to
> > ->_read/write_oob() when ->_read/write() are NULL. The problem is,  
> > mtdpart is directly calling the ->_xxx() instead of using the wrappers,
> > thus leading to a NULL pointer exception.
> > 
> > Even though we only need to do the change for part_read/write(), going
> > through those wrappers for all kind of part -> master operation
> > propagation is a good thing, because other wrappers might become
> > smarter over time, and the duplicated check overhead (parameters will
> > be checked at the partition and master level instead of only at the
> > partition level) should be negligible.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
> > ---
> > Changes since v1:
> > - new patch needed to fix a NULL pointer dereference BUG  
> 
> I think I like this patch on the whole. A few notes below.

Ok, cool. I was afraid someone would complain about the induced
overhead.

> 
> > ---
> >  drivers/mtd/mtdpart.c | 71 ++++++++++++++++++++++-----------------------------
> >  1 file changed, 31 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
> > index ea5e5307f667..11486ec6cab0 100644
> > --- a/drivers/mtd/mtdpart.c
> > +++ b/drivers/mtd/mtdpart.c
> > @@ -68,8 +68,7 @@ static int part_read(struct mtd_info *mtd, loff_t from, size_t len,
> >  	int res;
> >  
> >  	stats = part->master->ecc_stats;
> > -	res = part->master->_read(part->master, from + part->offset, len,
> > -				  retlen, buf);
> > +	res = mtd_read(part->master, from + part->offset, len, retlen, buf);
> >  	if (unlikely(mtd_is_eccerr(res)))
> >  		mtd->ecc_stats.failed +=
> >  			part->master->ecc_stats.failed - stats.failed;  
> 
> The parent-to-child ECC stat handling is different here than it is
> below, in part_read_oob().
> 
> ...
> 
> > @@ -132,7 +130,7 @@ static int part_read_oob(struct mtd_info *mtd, loff_t from,
> >  			return -EINVAL;
> >  	}
> >  
> > -	res = part->master->_read_oob(part->master, from + part->offset, ops);
> > +	res = mtd_read_oob(part->master, from + part->offset, ops);
> >  	if (unlikely(res)) {
> >  		if (mtd_is_bitflip(res))
> >  			mtd->ecc_stats.corrected++;  
> 
> Notice how we only count a single increment here.
> 
> That seems wrong, doesn't it?

Indeed, it does, but this patch does not change the current
behavior ;-).

> But then, do we guarantee that
> ->_read_oob() implementations follow the same stat recording guarantees  
> that ->_read() implementations do (or should)? Might double check that
> before trying to fiddle here any more than you are.

Well, if you want my opinion, all this ecc_stats dance on MTD parts is
already fragile, because, AFAICT, nothing guarantees that someone else
is not reading another partition of the same device while we are
extracting the stats, which means that those numbers might already be
inconsistent when we do the calculation to extract the number of
bitflips and failures related to the partition. So, I'm not sure we
really care about these numbers.

If we want things to be perfectly reliable, we should return the stats
attached to a specific read request and then atomically update the
global stats (see the discussion I had we Sacha a while ago [1]).

Anyway, I'm fine making the logic consistent between part_read() and
part_read_oob() if you like, but that should be done in a separate
patch IMO.

> 
> I'm not sure if that affects your next patch at all. It's not a
> criticism of this patch either, but I just noticed it when reviewing.

Nope, because part_read() will still be used for the standard read path,
and the core will only fall back to ->_read_oob() when doing the read
on the master device.

> 
> [...]
> 
> I was also wondering whether this patch couldn't go a step further, and
> remove conditions like this:
> 
> 	if (parent->_panic_write)
> 		slave->mtd._panic_write = part_panic_write; 
> 
> Since part_panic_write() should call mtd_panic_write() on the parent
> (master), which would do its own -EOPNOTSUPP check. But then I suppose
> that might invert the order of the checks, causing (for example) -EINVAL
> for out-of-bounds panic write instead of -EOPNOTSUPP. So maybe that's
> better left alone.

I considered doing that but was too lazy to check if all helpers were
properly checking the pointer value before dereferencing it :).

> 
> Brian

[1]https://patchwork.ozlabs.org/patch/614493/