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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 5 Jun 2008 18:43:10 +0400
From:	Anton Vorontsov <avorontsov@...mvista.com>
To:	Marc Pignat <marc.pignat@...s.ch>
Cc:	Kumar Gala <galak@...nel.crashing.org>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Pierre Ossman <drzeus-mmc@...eus.cx>,
	Jochen Friedrich <jochen@...am.de>,
	Timur Tabi <timur@...escale.com>, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net
Subject: Re: [PATCH 3/3] mmc: change .get_ro() callback semantics

On Tue, Jun 03, 2008 at 12:07:49PM +0200, Marc Pignat wrote:
> Hi all!
> 
> On Friday 23 May 2008, Anton Vorontsov wrote:
> > get_ro() callback must return values >= 0 for its logical state, and
> ...
> >  static void pxamci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> > diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> > index f2e9885..ef3b773 100644
> > --- a/include/linux/mmc/host.h
> > +++ b/include/linux/mmc/host.h
> > @@ -55,6 +55,9 @@ struct mmc_host_ops {
> >  	 * Avoid calling these three functions too often or in a "fast path",
> >  	 * since underlaying controller might implement them in an expensive
> >  	 * and/or slow way.
> > +	 *
> > +	 * .get_ro and .get_cd should return >= 0 for their logical values,
> > +	 * or negative errno value in case of error.
> >  	 */
> 
> I would suggest to use something more strict (bulletproof), something like:
> 
> /*
>  * get_ro will return:
>  *   0 for a read/write card
>  *   1 for a read-only card 

This isn't always practical. For example, host is using u8 register for
the status, so it might safely return u8 & mask, that will always fit
into int. Or very smart/adventurous authors might be aware that, for the
particular host, mask's bit isn't last, and safely do uXX & mask. :-)

The above is weak argument of course, since it is about optimization.

As an counter-evidence, the strict scheme that you described probably
less error prone. But is it? To implement it we'll need something like
WARN_ON(ret > 0 && ret != 1) to catch erroneous users. Take a closer
look though, will it catch uXX & lastbit case? Nope. :-)

We can catch bogus users though... via hack (_assuming_ that there
are no errno values of 1 << (sizeof(int) * 8 - 1)), i.e.
WARN_ON(ret == (1 << (sizeof(int) * 8 - 1)). Though, to do so, we don't
need the strict scheme, this debugging hack will work in the current
scheme too.

-- 
Anton Vorontsov
email: cbouatmailru@...il.com
irc://irc.freenode.net/bd2
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ