From: "J.Bruce Fields" <bfields@fieldses.org>
To: NeilBrown <neilb@suse.de>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
Gao feng <gaofeng@cn.fujitsu.com>,
Containers <containers@lists.linux-foundation.org>,
linux-fsdevel@vger.kernel.org,
Aditya Kali <adityakali@google.com>,
Oleg Nesterov <oleg@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Eric Dumazet <edumazet@google.com>,
NFS <linux-nfs@vger.kernel.org>
Subject: Re: [REVIEW][PATCH 1/3] vfs: In d_path don't call d_dname on a mount point
Date: Mon, 2 Dec 2013 11:23:40 -0500 [thread overview]
Message-ID: <20131202162340.GH1960@fieldses.org> (raw)
In-Reply-To: <20131202164359.4f4f2c94@notabene.brown>
On Mon, Dec 02, 2013 at 04:43:59PM +1100, NeilBrown wrote:
> On Sat, 30 Nov 2013 17:02:26 +0000 Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
>
> > BTW, what happens if svc_export_request() ends up with pathname filling
> > almost all space left, so that qword_add(bpp, blen, pth) right after the
> > call of d_path() in there overwrites the beginning of d_path() output?
> > Neil? And while we are at it, handling of overflow in there looks also
> > looks fishy...
>
> In this case the returned *blen will be negative so cache_request() in
> net/sunrpc/cache.h will return -EAGAIN.
> cache_read() would then go into a tight loop, trying again and again to
> create the request, but it will never fit in the buffer.
>
> I guess maybe an EINVAL might help there, plus code to skip over impossible
> requests.
> Maybe the following. We'd need to double check that no ->cache_request
> function can fail in a way that is worth retrying, but I doubt they would.
>
> Any thoughts Bruce?
Yes, the cache_request failures are all similarly fatal overflows.
Uh, not sure if I remember how the data structures here work: so
userspace is now going to get an -EINVAL on read, and may just end up
retrying the read?
Or do we hit the "need to release rq" case in cache_read and just
discard the request?
--b.
>
> Thanks,
> NeilBrown
>
>
> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> index a72de074172d..a065f827e2a3 100644
> --- a/net/sunrpc/cache.c
> +++ b/net/sunrpc/cache.c
> @@ -748,7 +748,7 @@ static int cache_request(struct cache_detail *detail,
>
> detail->cache_request(detail, crq->item, &bp, &len);
> if (len < 0)
> - return -EAGAIN;
> + return -EINVAL;
> return PAGE_SIZE - len;
> }
>
> @@ -788,6 +788,11 @@ static ssize_t cache_read(struct file *filp, char __user *buf, size_t count,
>
> if (rq->len == 0) {
> err = cache_request(cd, rq);
> + if (err == -EINVAL) {
> + spin_lock(&queue_lock);
> + list_move(&rp->q.list, &rq->q.list);
> + spin_unlock(&queue_lock);
> + }
> if (err < 0)
> goto out;
> rq->len = err;
WARNING: multiple messages have this Message-ID (diff)
From: "J.Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
Cc: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>,
Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>,
Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
NFS <linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [REVIEW][PATCH 1/3] vfs: In d_path don't call d_dname on a mount point
Date: Mon, 2 Dec 2013 11:23:40 -0500 [thread overview]
Message-ID: <20131202162340.GH1960@fieldses.org> (raw)
In-Reply-To: <20131202164359.4f4f2c94-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
On Mon, Dec 02, 2013 at 04:43:59PM +1100, NeilBrown wrote:
> On Sat, 30 Nov 2013 17:02:26 +0000 Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org> wrote:
>
>
> > BTW, what happens if svc_export_request() ends up with pathname filling
> > almost all space left, so that qword_add(bpp, blen, pth) right after the
> > call of d_path() in there overwrites the beginning of d_path() output?
> > Neil? And while we are at it, handling of overflow in there looks also
> > looks fishy...
>
> In this case the returned *blen will be negative so cache_request() in
> net/sunrpc/cache.h will return -EAGAIN.
> cache_read() would then go into a tight loop, trying again and again to
> create the request, but it will never fit in the buffer.
>
> I guess maybe an EINVAL might help there, plus code to skip over impossible
> requests.
> Maybe the following. We'd need to double check that no ->cache_request
> function can fail in a way that is worth retrying, but I doubt they would.
>
> Any thoughts Bruce?
Yes, the cache_request failures are all similarly fatal overflows.
Uh, not sure if I remember how the data structures here work: so
userspace is now going to get an -EINVAL on read, and may just end up
retrying the read?
Or do we hit the "need to release rq" case in cache_read and just
discard the request?
--b.
>
> Thanks,
> NeilBrown
>
>
> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> index a72de074172d..a065f827e2a3 100644
> --- a/net/sunrpc/cache.c
> +++ b/net/sunrpc/cache.c
> @@ -748,7 +748,7 @@ static int cache_request(struct cache_detail *detail,
>
> detail->cache_request(detail, crq->item, &bp, &len);
> if (len < 0)
> - return -EAGAIN;
> + return -EINVAL;
> return PAGE_SIZE - len;
> }
>
> @@ -788,6 +788,11 @@ static ssize_t cache_read(struct file *filp, char __user *buf, size_t count,
>
> if (rq->len == 0) {
> err = cache_request(cd, rq);
> + if (err == -EINVAL) {
> + spin_lock(&queue_lock);
> + list_move(&rp->q.list, &rq->q.list);
> + spin_unlock(&queue_lock);
> + }
> if (err < 0)
> goto out;
> rq->len = err;
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-12-02 16:24 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-15 16:41 Regression wrt mounting /proc in user namespace in 3.13 Daniel P. Berrange
[not found] ` <20131115164123.GN28794-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-16 16:48 ` Serge E. Hallyn
[not found] ` <20131116164840.GA4441-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-11-17 3:06 ` Serge E. Hallyn
[not found] ` <20131117030653.GA7670-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-11-18 3:19 ` Serge E. Hallyn
[not found] ` <20131118031932.GA17621-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-11-18 4:52 ` Gao feng
[not found] ` <52899D09.5080202-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-11-18 14:08 ` Serge E. Hallyn
[not found] ` <20131118140830.GA22075-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-11-18 18:01 ` Serge E. Hallyn
[not found] ` <20131118180134.GA24156-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-11-19 1:51 ` Eric W. Biederman
[not found] ` <87k3g5gnuv.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-19 3:47 ` Serge E. Hallyn
2013-11-26 18:10 ` Serge E. Hallyn
[not found] ` <20131126181043.GA25492-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-11-27 0:14 ` [REVIEW][PATCH 0/3] userns fixes for v3.13-rc1 Eric W. Biederman
[not found] ` <87siui1z1g.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-27 0:16 ` [REVIEW][PATCH 1/3] vfs: In d_path don't call d_dname on a mount point Eric W. Biederman
[not found] ` <8738mi1yya.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-27 1:58 ` Serge E. Hallyn
2013-11-30 6:15 ` Al Viro
[not found] ` <20131130061525.GY10323-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2013-11-30 17:02 ` Al Viro
[not found] ` <20131130170226.GZ10323-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2013-11-30 21:51 ` Eric W. Biederman
[not found] ` <87a9glh838.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-30 22:43 ` Al Viro
[not found] ` <20131130224340.GA10323-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2013-12-02 7:29 ` Al Viro
2014-01-17 3:29 ` Eric W. Biederman
2014-01-17 3:29 ` Eric W. Biederman
[not found] ` <874n53gub7.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2014-01-17 8:39 ` Al Viro
[not found] ` <20140117083901.GA10323-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2014-02-07 2:21 ` [PATCH 0/4] d_dname cleanups Eric W. Biederman
[not found] ` <87iosrhdc0.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2014-02-07 2:23 ` [PATCH 1/4] perfmon: Use d_alloc_pseudo like all of the d_dname callers Eric W. Biederman
2014-02-07 2:23 ` [PATCH 2/4] vfs: Simply when d_alloc_dname is called Eric W. Biederman
2014-02-07 2:24 ` [PATCH 3/4] vfs: Move the call of d_op->d_dname from d_path to prepend_path Eric W. Biederman
2014-02-07 2:24 ` [PATCH 4/4] vfs: Call d_dname from dentry_path Eric W. Biederman
2013-12-01 5:09 ` [REVIEW][PATCH 1/3] vfs: In d_path don't call d_dname on a mount point Al Viro
2013-12-01 6:15 ` [REVIEW][PATCH 1/3] vfs: In d_path don't call d_dname on a mountpoint Tetsuo Handa
[not found] ` <20131201050930.GB10323-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2013-12-01 6:15 ` Tetsuo Handa
2013-12-02 5:43 ` [REVIEW][PATCH 1/3] vfs: In d_path don't call d_dname on a mount point NeilBrown
2013-12-02 5:43 ` NeilBrown
2013-12-02 16:23 ` J.Bruce Fields [this message]
2013-12-02 16:23 ` J.Bruce Fields
[not found] ` <20131202164359.4f4f2c94-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2013-12-02 16:23 ` J.Bruce Fields
2013-11-27 1:58 ` Serge E. Hallyn
2013-11-27 0:16 ` [REVIEW][PATCH 2/3] fork: Allow CLONE_PARENT after setns(CLONE_NEWPID) Eric W. Biederman
2013-11-27 0:16 ` Eric W. Biederman
[not found] ` <87vbzezojq.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-27 1:58 ` Serge E. Hallyn
2013-11-27 0:17 ` [REVIEW][PATCH 3/3] vfs: Fix a regression in mounting proc Eric W. Biederman
2013-11-27 16:13 ` Oleg Nesterov
[not found] ` <20131127161300.GA24773-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-27 16:29 ` Serge E. Hallyn
[not found] ` <20131127162928.GB7358-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-11-27 18:09 ` Oleg Nesterov
2013-11-27 16:41 ` Andy Lutomirski
[not found] ` <CALCETrXFnw63=JoEaQxM+Opj+kCXSL=9XppymzGKhLzOnp3WaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-27 18:10 ` Oleg Nesterov
2013-11-27 18:51 ` Eric W. Biederman
[not found] ` <871u21oeyr.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-27 19:47 ` Oleg Nesterov
2013-11-27 19:47 ` Oleg Nesterov
[not found] ` <20131127194722.GA32673-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-27 19:52 ` Eric W. Biederman
2013-11-27 19:52 ` Eric W. Biederman
[not found] ` <87iovdmxl7.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-27 20:01 ` Oleg Nesterov
2013-11-27 20:07 ` Eric W. Biederman
2013-11-27 20:41 ` Andy Lutomirski
[not found] ` <CALCETrUwjK7iLMMJaCvKUbBwEqV58oXY4dWzTGJohYgg4DwjWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-29 14:56 ` Serge E. Hallyn
[not found] ` <87wqjtlic3.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-27 20:41 ` Andy Lutomirski
2013-11-29 19:53 ` Oleg Nesterov
[not found] ` <20131129195327.GA12974-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-12-13 22:07 ` Richard Weinberger
2013-12-13 22:07 ` Richard Weinberger
[not found] ` <87pppmzoin.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-27 0:21 ` Andy Lutomirski
[not found] ` <CALCETrVp78EfzY3Oa-LV1Hm8A4Y35apehcxrxdyrzvTb5sp=pA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-27 0:36 ` Eric W. Biederman
2013-11-27 2:00 ` Serge E. Hallyn
2013-11-27 3:19 ` Gao feng
[not found] ` <529564AA.8050100-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-11-27 5:00 ` Eric W. Biederman
2013-11-27 5:00 ` Eric W. Biederman
2013-11-27 16:13 ` Oleg Nesterov
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=20131202162340.GH1960@fieldses.org \
--to=bfields@fieldses.org \
--cc=adityakali@google.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=edumazet@google.com \
--cc=gaofeng@cn.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=neilb@suse.de \
--cc=oleg@redhat.com \
--cc=serge@hallyn.com \
--cc=torvalds@linux-foundation.org \
--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.