linux-kernel - Re: linux-next: Signed-off-by missing for commit in the xfs 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: <YzzzhsZQ4qlDrcFW@magnolia>
Date:   Tue, 4 Oct 2022 20:01:26 -0700
From:   "Darrick J. Wong" <djwong@...nel.org>
To:     Stephen Zhang <starzhangzsd@...il.com>
Cc:     Dave Chinner <david@...morbit.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        linux-xfs@...r.kernel.org, Shida Zhang <zhangshida@...inos.cn>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: Signed-off-by missing for commit in the xfs tree

On Wed, Oct 05, 2022 at 10:52:05AM +0800, Stephen Zhang wrote:
> Dave Chinner <david@...morbit.com> 于2022年10月5日周三 05:06写道：
> > As it is, I use the convention of putting an explicit From: tag in
> > the commit message that matches the SOB so tools pulling stuff from
> > mailing lists do the right thing with them (same as any third-party
> > provided patch in a series).
> >
> > > That said... I think we should get in the habit of asking patch authors
> > > to make sure that at least one of the email or name strings match
> > > between the From and SOB tags.  I can see how people who grok even less
> > > about how Chinese names work than I do (read: lawyers) might get fussy
> > > about this kind of thing.
> >
> > As per above, the normal solution is an explicit "From: <foo>" line
> > that matches the SOB.  It's just annoying that our new-fangled tools
> > haven't encoded this long-standing convention to warn us when we
> > pull a patch with a from-tag that doesn't match a sob-tag.
> >
> 
> Sorry, but I'm not sure whether what you mean is adding another "From: " line
> right above the SOB tag like:
> ====
> From: name2 <email address2>
> Date: Mon, 12 Sep 2022 xx:xx:xx +0800
> Subject: [PATCH ] xfs: fix xxx and xxx
> 
> ...
> the commit  message
> ...
> 
> From: name <email address>             //added line
> signed-off-by:  name <email address>
> ...
> ====

I think Dave means something like this patch of mine:
https://lore.kernel.org/linux-xfs/166473478893.1083155.2555785331844801316.stgit@magnolia/T/#u

From:   "Darrick J. Wong" <djwong@...nel.org>
To:     djwong@...nel.org
Cc:     linux-xfs@...r.kernel.org
Date:   Sun, 02 Oct 2022 11:19:48 -0700
Subject: [PATCH 3/4] xfs: set the buffer type after holding the AG[IF] across trans_roll

From: Darrick J. Wong <djwong@...nel.org>

Currently, the only way to lock an allocation group is to hold the AGI
and AGF buffers.  If repair needs to roll the transaction while
repairing some AG metadata, it maintains that lock by holding the two
buffers across the transaction roll and joins them afterwards.

However, repair is not the same as the other parts of XFS that employ
this bhold/bjoin sequence, because it's possible that the AGI or AGF
buffers are not actually dirty before the roll.  In this case, the
buffer log item can detach from the buffer, which means that we have to
re-set the buffer type in the bli after joining the buffer to the new
transaction so that log recovery will know what to do if the fs fails.

Signed-off-by: Darrick J. Wong <djwong@...nel.org>
---

Notice how after the Subject: there is a blank line (which terminates
the headers) followed by a new From: line in the body?  And the
name/email in that second From: line matches the SOB later on?

--D

> 
> Thanks,
> Stephen.