All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Jeff Layton <jlayton@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel@vger.kernel.org,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Ceph fixes for 5.1-rc7
Date: Sun, 28 Apr 2019 05:38:12 +0100	[thread overview]
Message-ID: <20190428043801.GE2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <b175faae4bb98d3379a8642fe5f4e00587c3a734.camel@kernel.org>

On Fri, Apr 26, 2019 at 01:30:53PM -0400, Jeff Layton wrote:

> > I _probably_ would take allocation out of the loop (e.g. make it
> > __getname(), called unconditionally) and turned it into the
> > d_path.c-style read_seqbegin_or_lock()/need_seqretry()/done_seqretry()
> > loop, so that the first pass would go under rcu_read_lock(), while
> > the second (if needed) would just hold rename_lock exclusive (without
> > bumping the refcount).  But that's a matter of (theoretical) livelock
> > avoidance, not the locking correctness for ->d_name accesses.
> > 
> 
> Yeah, that does sound better. I want to think about this code a bit

FWIW, is there any reason to insist that the pathname is put into the
beginning of the buffer?  I mean, instead of path + pathlen we might
return path + offset, with the pathname going from path + offset to
path + PATH_MAX - 1 inclusive, with path being the thing eventually
freed.

It's easier to build the string backwards, seeing that we are walking
from leaf to root...

  reply	other threads:[~2019-04-28  4:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25 17:47 [GIT PULL] Ceph fixes for 5.1-rc7 Ilya Dryomov
2019-04-25 18:02 ` Linus Torvalds
2019-04-25 18:21   ` Al Viro
2019-04-25 18:24     ` Linus Torvalds
2019-04-25 18:31       ` Al Viro
2019-04-25 18:36       ` Jeff Layton
2019-04-25 18:23   ` Jeff Layton
2019-04-25 20:09     ` Al Viro
2019-04-26 16:25       ` Jeff Layton
2019-04-26 16:36         ` Linus Torvalds
2019-04-26 16:43           ` Linus Torvalds
2019-04-26 17:01           ` Al Viro
2019-04-26 17:08             ` Linus Torvalds
2019-04-26 17:11               ` Al Viro
2019-04-26 20:49             ` Jeff Layton
2019-04-26 21:28               ` Al Viro
2019-04-26 16:50         ` Al Viro
2019-04-26 17:30           ` Jeff Layton
2019-04-28  4:38             ` Al Viro [this message]
2019-04-28 13:27               ` Jeff Layton
2019-04-28 14:48                 ` Al Viro
2019-04-28 15:47                   ` Jeff Layton
2019-04-28 15:52                     ` Al Viro
2019-04-28 16:18                       ` Jeff Layton
2019-04-28 16:40                       ` Al Viro
2019-04-25 18:35 ` 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=20190428043801.GE2217@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.