backport fs/9p: avoid debug OOPS when reading a long symlink

Date: Tue, 21 Aug 2012 00:20:49 -0700
From: Jim Meyering <jim@meyering.net>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
CC: Eric Van Hensbergen <ericvh@gmail.com>, Ron Minnich
<rminnich@sandia.gov>,
        Latchesar Ionkov <lucho@ionkov.net>,
        "v9fs-developer@lists.sourceforge.net"
       	<v9fs-developer@lists.sourceforge.net>
Subject: [V9fs-developer] [PATCHv2] fs/9p: avoid debug OOPS when reading
a long
       	symlink

Reading a symlink longer than the given buffer, a p9_debug use would
try to print the link name (not NUL-terminated) using a %s format.
Use %.*s instead, and replace the strncpy+strnlen with functionally
equivalent strlen+memcpy.

Signed-off-by: Jim Meyering <meyering@redhat.com>
---
V1 provoked a warning due to strlen/buflen type differences (size_t/int)
and the "min" macro's type equality requirement.  This adds a cast to
avoid that warning:

-       retval = min(strlen(st->extension)+1, buflen);
+       retval = min(strlen(st->extension)+1, (size_t)buflen);

 fs/9p/vfs_inode.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
backport [PATCH 1/4] 9P: Fix race in p9_read_work()

Date: Mon, 17 Sep 2012 06:16:28 -0700
From: Simon Derr <simon.derr@bull.net>
To: "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>,
        "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>
CC: "simon.derr@bull.net" <simon.derr@bull.net>
Subject: [V9fs-developer] [PATCH 1/4] 9P: Fix race in p9_read_work()

Race scenario between p9_read_work() and p9_poll_mux()

Data arrive, Rworksched is set, p9_read_work() is called.

thread A                                thread B

                                        p9_read_work()
                                                .
                                        reads data
                                                .
                                        checks if new data ready. No.
                                                .
                                        gets preempted
                                                .
More data arrive, p9_poll_mux() is called.      .
                                                .
                                                .
p9_poll_mux()                                   .
                                                .
if (!test_and_set_bit(Rworksched,               .
                      &m->wsched)) {            .
  schedule_work(&m->rq);                        .
}                                               .
                                                .
-> does not schedule work because               .
   Rworksched is set                            .
                                                .
                                        clear_bit(Rworksched,
&m->wsched);
                                        return;

No work has been scheduled, and yet data are waiting.
Currently p9_read_work() checks if there is data to read,
and if not, it clears Rworksched.

I think it should clear Rworksched first, and then check if there is
data to
read.

Signed-off-by: Simon Derr <simon.derr@bull.net>
backport [PATCH 2/4] 9P: fix test at the end of p9_write_work()

Date: Mon, 17 Sep 2012 06:16:29 -0700
From: Simon Derr <simon.derr@bull.net>
To: "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>,
        "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>
CC: "simon.derr@bull.net" <simon.derr@bull.net>
Subject: [V9fs-developer] [PATCH 2/4] 9P: fix test at the end of
        p9_write_work()

At the end of p9_write_work() we want to test if there is still data to
send.
This means:
- either the current request still has data to send (wsize != 0)
- or there are requests in the unsent queue

Signed-off-by: Simon Derr <simon.derr@bull.net>
backport [PATCH 3/4] 9P: Fix race in p9_write_work()

Date: Mon, 17 Sep 2012 06:16:30 -0700
From: Simon Derr <simon.derr@bull.net>
To: "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>,
        "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>
CC: "simon.derr@bull.net" <simon.derr@bull.net>
Subject: [V9fs-developer] [PATCH 3/4] 9P: Fix race in p9_write_work()

See previous commit about p9_read_work() for details.

This fixes a similar race between p9_write_work() and p9_poll_mux()

Signed-off-by: Simon Derr <simon.derr@bull.net>
backport [PATCH 4/4] 9P: Fix race between p9_write_work() and p9_fd_request()

Date: Mon, 17 Sep 2012 06:16:31 -0700
From: Simon Derr <simon.derr@bull.net>
To: "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>,
        "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>
CC: "simon.derr@bull.net" <simon.derr@bull.net>
Subject: [V9fs-developer] [PATCH 4/4] 9P: Fix race between
p9_write_work() and
        p9_fd_request()

Race scenario:

thread A                                thread B

p9_write_work()                         p9_fd_request()

if (list_empty(&m->unsent_req_list))
  ...

                                        spin_lock(&client->lock);
                                        req->status = REQ_STATUS_UNSENT;
                                        list_add_tail(...,
&m->unsent_req_list);
                                        spin_unlock(&client->lock);
                                        ....
                                        if (n & POLLOUT &&
                                           !test_and_set_bit(Wworksched,
&m->wsc
hed)
                                            schedule_work(&m->wq);
                                        --> not done because Wworksched
is set

  clear_bit(Wworksched, &m->wsched);
  return;

--> nobody will take care of sending the new request.

This is not very likely to happen though, because p9_write_work() being
called
with
an empty unsent_req_list is not frequent.
But this also means that taking the lock earlier will not be costly.

Signed-off-by: Simon Derr <simon.derr@bull.net>
backport 9P : Check errno validity

Date: Fri, 10 Aug 2012 06:52:06 -0700
From: Simon Derr <simon.derr@bull.net>
To: "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>
CC: Simon Derr <simon.derr@bull.net>
Subject: [V9fs-developer] [PATCH] 9P : Check errno validity

Hi,

While working on a modified server I had the Linux clients crash
a few times. This lead me to find this:

Some error codes are directly extracted from the server replies.
A malformed server reply could contain an invalid error code, with a
very large value. If this value is then passed to ERR_PTR() it will
not be properly detected as an error code by IS_ERR() and as a result
the kernel will dereference an invalid pointer.

This patch tries to avoid this.

        Simon

Signed-off-by: Simon Derr <simon.derr@bull.net>

Date: Mon, 3 Sep 2012 14:48:33 -0700
From: Eric Van Hensbergen <ericvh@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
CC: "v9fs-developer@lists.sourceforge.net"
        <v9fs-developer@lists.sourceforge.net>, Simon Derr
        <simon.derr@bull.net>
Subject: Re: [V9fs-developer] [PATCH] 9P : Check errno validity

Agreed, if the primary case really is a malformed server reply, the
right thing might be EIO, but that tends to be fatal, which might be a
bit extreme, maybe EPROTO?

Sorry for being radio silent for the past few weeks, transitioning
jobs has been a bit time intensive.  I'm processing through the patch
queue today, gonna go for EPROTO on this one for now until someone
comes up with something better.

       -eric
backport fs/9p: Don't use O_TRUNC flag in TOPEN and TLOPEN request

Date: Tue, 5 Feb 2013 11:26:28 +0530
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: v9fs-developer@lists.sourceforge.net
Subject: [V9fs-developer] [PATCH] fs/9p: Don't use O_TRUNC flag in TOPEN and TLOPEN request

From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>

We do the truncate via setattr request, hence don't pass the O_TRUNC flag in
open request. Without this patch we end up sending zero sized write request
to server when we try to truncate. Some servers (VirtFS) were not handling that properly.

Reported-by: M. Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
backport locking in fs/9p ->readdir()

Date: Sat, 26 Jan 2013 00:11:36 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Eric Van Hensbergen <ericvh@gmail.com>
CC: linux-fsdevel@vger.kernel.org, v9fs-developer@lists.sourceforge.net
Subject: [V9fs-developer] locking in fs/9p ->readdir()

        ... is really excessive.  First of all, ->readdir() is
serialized by
file->f_path.dentry->d_inode->i_mutex; playing with
file->f_path.dentry->d_lock
is not buying you anything.  Moreover, rdir->mutex is pointless for
exactly
the same reason - you'll never see contention on it.

        While we are at it, there's no point in having rdir->buf a
pointer -
you have it point just past the end of rdir, so it might as well be a
flex
array (and no, it's not a gccism).

        Absolutely untested patch follows:

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
prep for 2.6.38.5-21