All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Miklos Szeredi <mszeredi@redhat.com>
Subject: Re: [git pull] fileattr series from Miklos
Date: Tue, 27 Apr 2021 11:31:19 -0700	[thread overview]
Message-ID: <CAHk-=whNdEKs-LoF9DKYW8k5Eg2rPjqqWf047TxAY3+v4W=iRQ@mail.gmail.com> (raw)
In-Reply-To: <YIdByy4WJcXTN7Wy@zeniv-ca.linux.org.uk>

On Mon, Apr 26, 2021 at 3:42 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>         The branch is straight from Miklos' tree (it's #fileattr_v6 there),
> sat merged into vfs.git #for-next for a while.  Not sure what's the normal
> way to do pull requests in situations like that - do you prefer a reference
> to my tree (as below) or to mszeredi/vfs.git?

This is fine. The only downside here is that there was no signed tag,
which I would have preferred - either from you or from Milkos.

We've had this a couple of times before, and I've started trying to
"document" it with a "Pull X from Y via Z" thing. See for example

   git show 836d7f0572ca 70cd33d34c60

which is a similar kind of thing where Borislav just forwarded Ard's
work (and it has happened in the past a couple of times without those
kinds of notices).

Btw, unrelated to that, this pull request got a conflict with

  64708539cd23 ("btrfs: use btrfs_inode_lock/btrfs_inode_unlock inode
lock helpers")

which I think I sorted out correctly (the "inode_lock()" is now done
by the VFS layer for the fileattr things, and the btrfs use of
"btrfs_inode_lock/btrfs_inode_unlock" ended up being undone). But just
to be safe I'm cc'ing the btrfs people involved. Please double-check
that I didn't screw something up.

(Note: it doesn't show up as a conflict in the merge itself, because
each piece was a straight "take the case from one side or the other",
and in this case "take it from the fileattr" side meant that the
inode_[un]lock -> btrfs_inode_[un]lock conversion for the fileattr
cases just went away).

                 Linus

  reply	other threads:[~2021-04-27 18:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-26 22:42 [git pull] fileattr series from Miklos Al Viro
2021-04-27 18:31 ` Linus Torvalds [this message]
2021-04-28 16:55   ` David Sterba
2021-04-27 18:37 ` 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='CAHk-=whNdEKs-LoF9DKYW8k5Eg2rPjqqWf047TxAY3+v4W=iRQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.