All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Stephen Zhang <starzhangzsd@gmail.com>,
	Dave Chinner <david@fromorbit.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-xfs@vger.kernel.org, Shida Zhang <zhangshida@kylinos.cn>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: Signed-off-by missing for commit in the xfs tree
Date: Wed, 5 Oct 2022 05:13:36 +0200	[thread overview]
Message-ID: <20221005031336.GA3161@1wt.eu> (raw)
In-Reply-To: <YzzzhsZQ4qlDrcFW@magnolia>

On Tue, Oct 04, 2022 at 08:01:26PM -0700, Darrick J. Wong wrote:
> 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@kernel.org>
> To:     djwong@kernel.org
> Cc:     linux-xfs@vger.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@kernel.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@kernel.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?

Or maybe we could have a new option to git-am to always use the first
SOB as the From when there's no other explicit From in the message, so
that we never care about the From used to send the e-mail ? That would
also implicitly perform a requirement that an SOB necessarily exists.

Willy

  reply	other threads:[~2022-10-05  3:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03 20:23 linux-next: Signed-off-by missing for commit in the xfs tree Stephen Rothwell
2022-10-03 22:21 ` Dave Chinner
2022-10-04 11:50   ` Stephen Rothwell
2022-10-04 15:57     ` Darrick J. Wong
2022-10-04 21:04       ` Dave Chinner
2022-10-05  2:52         ` Stephen Zhang
2022-10-05  3:01           ` Darrick J. Wong
2022-10-05  3:13             ` Willy Tarreau [this message]
2022-10-05 16:46         ` Konstantin Ryabitsev
  -- strict thread matches above, loose matches on Subject: below --
2024-11-13 21:13 Stephen Rothwell
2021-06-06 22:26 Stephen Rothwell
2020-07-26 21:57 Stephen Rothwell
2018-06-04 22:03 Stephen Rothwell
2018-06-04 22:17 ` Darrick J. Wong
2017-08-16 21:48 Stephen Rothwell

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=20221005031336.GA3161@1wt.eu \
    --to=w@1wt.eu \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=starzhangzsd@gmail.com \
    --cc=zhangshida@kylinos.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.