On Wed, Jun 19, 2013 at 11:04:04PM +0800, Ming Lei wrote:
> On Wed, Jun 19, 2013 at 10:39 PM, Greg KH <greg@xxxxxxxxx> wrote:
> > On Wed, Jun 19, 2013 at 02:58:39PM +0800, Ming Lei wrote:
> >> On Wed, Jun 19, 2013 at 1:32 PM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> >> > Hi Greg,
> >> >
> >> > Today's linux-next merge of the driver-core tree got a conflict in
> >> > drivers/base/firmware_class.c between commit 875979368eb4 ("firmware
> >> > loader: fix use-after-free by double abort") from the driver-core.current
> >> > tree and commit fe304143b0c3 ("firmware: Avoid deadlock of usermodehelper
> >> > lock at shutdown") from the driver-core tree.
> >> >
> >> > I fixed it up (more may be required - see below) and can carry the fix as
> >> > necessary (no action is required).
> >> >
> >> > --
> >> > Cheers,
> >> > Stephen Rothwell sfr@xxxxxxxxxxxxxxxx
> >> >
> >> > diff --cc drivers/base/firmware_class.c
> >> > index 01e2103,6ede229..0000000
> >> > --- a/drivers/base/firmware_class.c
> >> > +++ b/drivers/base/firmware_class.c
> >> > @@@ -446,22 -452,11 +452,18 @@@ static struct firmware_priv *to_firmwar
> >> > return container_of(dev, struct firmware_priv, dev);
> >> > }
> >> >
> >> > - static void fw_load_abort(struct firmware_priv *fw_priv)
> >> > + static void fw_load_abort(struct firmware_buf *buf)
> >> > {
> >> > - struct firmware_buf *buf = fw_priv->buf;
> >> > -
> >> > + /*
> >> > + * There is a small window in which user can write to 'loading'
> >> > + * between loading done and disappearance of 'loading'
> >> > + */
> >> > + if (test_bit(FW_STATUS_DONE, &buf->status))
> >> > + return;
> >> > +
> >> > + list_del_init(&buf->pending_list);
> >> > set_bit(FW_STATUS_ABORT, &buf->status);
> >> > complete_all(&buf->completion);
> >> > -
> >> > - /* avoid user action after loading abort */
> >> > - fw_priv->buf = NULL;
> >>
> >> Hmm, maybe the most important part in the commit 875979368eb4
> >> ("firmware loader: fix use-after-free by double abort") has been removed, :-)
> >>
> >> In fact, the commit 87597936 is for linus tree only because it is a fix,
> >> so the conflict is caused by merging it with other firmware loader patches
> >> in -next tree.
> >>
> >> Greg, I can figure out one patch for -next easily, but it depends you
> >> push it on 3.10-rc or 3.11-rc.
> >
> > I'll be pushing your patch for 3.10-final to Linus as it fixes a bug,
> > but I will need something to resolve the merge issue properly. Can you
> > provide me that patch/merge?
>
> OK, I can send you one patch, but I am wondering the patch is against
> today's next tree or your driver-core/driver-core-next?
>
> If it is against your driver-core/driver-core-next, would you mind letting
> me know how to generate the patch for the conflict? Sorry for the stupid
> question, because I seldom meet such problem, :-(
Can you merge the two branches together (driver-core-next and
driver-core-linus) and send me the proper merge patch that I should be
applying when doing that? Then I can push that out through the
driver-core-next tree to make linux-next work properly, as well as make
the merge sane for me when I pull in the final 3.10 release.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
