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, 9 Apr 2015 21:30:00 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	Frans Klaver <fransklaver@...il.com>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-mtd@...ts.infradead.org
Subject: Re: [PATCH 01/60] mtd: core: tone down suggestion that dev.parent
 should be set

On Wed, Mar 11, 2015 at 09:03:46AM +0100, Frans Klaver wrote:
> On Tue, Mar 10, 2015 at 6:39 PM, Brian Norris
> <computersforpeace@...il.com> wrote:
> > On Tue, Mar 10, 2015 at 08:47:46AM +0100, Frans Klaver wrote:
> >> On Tue, Mar 10, 2015 at 12:14 AM, Brian Norris
> >> <computersforpeace@...il.com> wrote:
> >> > On Tue, Mar 03, 2015 at 10:39:45PM +0100, Frans Klaver wrote:
> >> >> add_mtd_device() has a comment suggesting that the caller should have
> >> >> set dev.parent. This is required to have the device show up in sysfs,
> >> >
> >> > What do you mean "have the device show up in sysfs"? AFAICT, this only
> >> > has bearing on whether the *parent* device shows up as a sysfs symlink
> >> > within the MTD device directory. i.e.:
> >> >
> >> >    /sys/class/mtd/mtd*/device
> >> >
> >> > For instance, this sort of symlink:
> >> >
> >> >    /sys/class/mtd/mtd0/device -> ../../../f03e2800.nand
> >> >
> >> > It might be good to clarify this in the commit message, since you make
> >> > the problem sound worse than (I think) it is.
> >>
> >> I do? That was definitely not my intention. I'll look into it.
> >
> > Maybe it's just my bias when reading, since some people have complained
> > loudly about this, seemingly without understanding that the problem
> > really isn't that significant.
> >
> > So my question was really just to confirm my own understanding, that
> > this only affects the 'device' symlink.
> 
> Ah right. I'll double check and reword where necessary. I already had
> the feeling that this wasn't very significant, as there weren't any
> real issues related to this using these drivers.

OK, I just made some small edits to the language to clarify that this
patch is only fixing the 'parent device symlink' rather than the 'device
is missing in sysfs'. I also tweaked the language on all the other
patches to reflect this.

> > BTW, it'd be nice if you don't respam with another 60 patches, if you're
> > only changing a few of them. I can probably take most of them as-is,
> > after you confirm there are no more compile failures.
> 
> Sure thing, I thought as much.

I ran the other 59 patches through a pretty wide range of compile tests
and saw no issues, so I've pushed patches 1-29 and 31-60 to l2-mtd.git,
with small tweaks to the commit descriptions. If you get a chance to
rework patch 30, feel free.

Thanks for the patches!

Brian
--
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