From: Greg KH <gregkh@linuxfoundation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [GIT PULL] Driver core fixes for 5.7-rc7 - take 2
Date: Mon, 25 May 2020 09:33:10 +0200 [thread overview]
Message-ID: <20200525073310.GB261205@kroah.com> (raw)
In-Reply-To: <20200524154219.GU33628@sasha-vm>
On Sun, May 24, 2020 at 11:42:19AM -0400, Sasha Levin wrote:
> On Sun, May 24, 2020 at 05:00:18PM +0200, Greg KH wrote:
> > On Sat, May 23, 2020 at 11:14:28AM -0700, Linus Torvalds wrote:
> > > On Sat, May 23, 2020 at 8:29 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > The kobject patch that was originally in here has now been reverted, as
> > > > Guenter reported boot problems with it on some of his systems.
> > >
> > > Hmm. That original patch looks obviously buggy: in kobject_cleanup()
> > > it would end up doing "kobject_put(parent)" regardless of whether it
> > > had actually done __kobject_del() or not.
> > >
> > > That _could_ have been intentional, but considering the commit
> > > message, it clearly wasn't in this case. It might be worth re-trying
> > > to the commit, just with that fixed.
> >
> > Turns out that wasn't the real problem here, the culprit is the
> > lib/test_printf.c code trying to tear down a kobject tree from the
> > parent down to the children (i.e. in the backwards order).
> >
> > > Btw, when you end up reverting a patch that was already the top patch,
> > > you might as well just remove it entirely from that tree instead (ie
> > > "git reset --hard HEAD^" instead of "git revert HEAD").
> > >
> > > Unless somebody else uses your branches and you are afraid that the
> > > non-reverted commit escaped out in the wild that way?
> >
> > I don't like rebasing or changing the HEAD like that on a public branch.
> > As proof, syzbot started sending me a bunch of "this is the failed
> > commit" messages right after your email, based on it's testing of the
> > tree in linux-next.
>
> OTOH, leaving commits like this may result in confusion later on because
> of confusion around the "correct" patch.
>
> Consider this:
>
> 1. Someone writes a patch named "close memory leak when freeing XYZ"
> 2. We revert it a day later with 'Revert "close memory leak when
> freeing XYZ"'
And the sha1 is in the commit, showing which patch was reverted.
> 3. Now, what would the author of the original patch do? That's right -
> re-submit a patch with an identical subject line and patch description,
> but with a subtle change in the code to fix the bug the original patch
> was reverted for.
Sometimes, yes, but sometimes, as in this case, a totally different
patch will be submitted for the problem :)
But, even if it was there, the sha1 in the revert should allow us to
track this properly. I can't remember a time where this has caused
problems in the past, can you?
> So now we end up with two "close memory leak when freeing XYZ" commits
> in our git history that are nearly identical. Recipe for a disaster :)
Time and sha1 should show them being different :)
thanks,
greg k-h
next prev parent reply other threads:[~2020-05-25 7:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-23 13:17 [GIT PULL] Driver core fixes for 5.7-rc7 Greg KH
2020-05-23 14:05 ` Greg KH
2020-05-23 15:29 ` [GIT PULL] Driver core fixes for 5.7-rc7 - take 2 Greg KH
2020-05-23 18:14 ` Linus Torvalds
2020-05-24 15:00 ` Greg KH
2020-05-24 15:38 ` Greg KH
2020-05-24 15:42 ` Sasha Levin
2020-05-25 7:33 ` Greg KH [this message]
2020-05-24 17:05 ` Linus Torvalds
2020-05-24 19:45 ` Sasha Levin
2020-05-24 21:12 ` Sasha Levin
2020-05-24 22:28 ` Linus Torvalds
2020-05-24 22:24 ` Linus Torvalds
2020-05-25 7:40 ` Greg KH
2020-05-23 18:30 ` pr-tracker-bot
2020-05-23 18:30 ` [GIT PULL] Driver core fixes for 5.7-rc7 pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200525073310.GB261205@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).