linux-kernel - Re: linux-next: manual merge of the usb-gadget tree with the vfs tree

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]

Message-ID: <20140918180921.GA7996@ZenIV.linux.org.uk>
Date:	Thu, 18 Sep 2014 19:09:21 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Felipe Balbi <balbi@...com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Robert Baldyga <r.baldyga@...sung.com>
Subject: Re: linux-next: manual merge of the usb-gadget tree with the vfs tree

On Thu, Sep 18, 2014 at 12:12:26PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Sep 17, 2014 at 10:34:00AM -0500, Felipe Balbi wrote:
> > On Wed, Sep 17, 2014 at 04:16:58PM +1000, Stephen Rothwell wrote:
> > > Hi Felipe,
> > > 
> > > Today's linux-next merge of the usb-gadget tree got a conflict in
> > > drivers/usb/gadget/function/f_fs.c between commit 8322215aa91c ("f_fs:
> > 
> > I can't find this commit on linux-usb. In fact, googling for it the only
> > reference I find to that commit is this very thread. I would strong
> > suggest that it be removed from the tree as it, apparently, went in
> > without any review. Sure, it's a simple change, but it needs to be
> > reviewed and needs to be sent to proper maintainers.
> > 
> > Unless I'm missing something, of course, but I could not find any other
> > references to this commit.
> > 
> > Al, was this commit sent to any mailing list ?
> 
> a gentle ping here

<looks at #for-next>

Oh, bugger...  I see what has happened - there's a local queue with a lot
of pending cleanups; this (and several around it) got into the wrong queue
and leaked into #for-next.  My apologies; I can certainly take this stuff
out.  It is an obvious patch, and the only reason why it's there at all
is that it's a part of preliminary cleanups for sorting the
d_add/d_splice_alias/d_materialise_unique/d_instantiate/d_add_unique
mess out.  That almost certainly will be a part of the next cycle, in
the first place, and this particular commit isn't even a prereq - it's just
something that fell out of grep while sorting out the calling conventions
for those guys (what's locked, what is or isn't hashed, etc.)

So I've no problems whatsoever either with ripping it out of -next and moving
it to the local queue until the next cycle, or throwing it your way and waiting
for it to hit the mainline.  Both f_fs and gadgetfs commits should go your
way, right?  Just tell which way you prefer them handled...  Again, I hadn't
planned to push those; there's no reason not to, but they can certainly sit
around for longer.  Sorry about the mess...
--
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/