From: Boaz Harrosh <bharrosh@panasas.com>
To: Jim Rees <rees@umich.edu>
Cc: <linux-nfs@vger.kernel.org>, peter honeyman <honey@citi.umich.edu>
Subject: Re: Block layout status
Date: Mon, 3 Oct 2011 11:20:23 +0200 [thread overview]
Message-ID: <4E897E57.2000309@panasas.com> (raw)
In-Reply-To: <20110929165253.GC3724@umich.edu>
On 09/29/2011 07:52 PM, Jim Rees wrote:
> Since the call doesn't seem to be happening, here's my status.
>
> On 16 Sep I sent these bug fixes to Trond for 3.1:
>
> Jim Rees (2):
> pnfsblock: fix size of upcall message
> pnfsblock: fix return code confusion
> Peng Tao (3):
> pnfsblock: fix NULL pointer dereference
> pnfsblock: fix writeback deadlock
> pnfsblock: add missing rpc_put_mount and path_put
>
> These are the ones I think are important enough, and low enough risk to
> anyone else, that they should be considered for 3.1 even though it's late in
> the release cycle. They have not shown up upstream. Trond?
>
> On 22 Sep I sent these to Trond for 3.2. I believe these are all in Benny's
> tree now (sorry about that, Benny):
>
> Jim Rees (2):
> pnfsblock: fix return code confusion
> pnfsblock: fix size of upcall message
> Peng Tao (8):
> SUNRPC/NFS: make rpc pipe upcall generic
> pnfsblock: add missing rpc_put_mount and path_put
> pnfs: make _set_lo_fail generic
> - pnfsblock: init pg_bsize properly
> pnfs: recoalesce when ld write pagelist fails
> pnfs: recoalesce when ld read pagelist fails
> pnfsblock: fix NULL pointer dereference
> pnfsblock: fix writeback deadlock
Hi Jim I think this "writeback deadlock" should be sent for
current 3.1 since surly it renders pnfsblock unusable. If you
feel it has not been tested enough consider submitting it with
CC: stable@. Because it should hit 3.1.x eventually. No?
(While at it maybe some of the other clear FIXs above as well
these that make it unusable)
Thanks
Boaz
>
> This includes all the bug fixes for 3.1 plus some others that are less
> important or higher risk. Notice that "init pg_bsize properly" is wrong and
> should not be used. Benny, you may want to remove this from your tree, or I
> can send a revert patch.
>
> Missing from these is one more, "nfs4: serialize layoutcommit" that's
> important but I somehow missed it.
>
> The recent automount changes really screwed us up but I just built a kernel
> from Linus's latest, which includes the patches from Trond, and it passes
> all tests so I think we're still ok for 3.1.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-10-03 9:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 16:52 Block layout status Jim Rees
2011-10-02 7:15 ` Benny Halevy
2011-10-03 9:20 ` Boaz Harrosh [this message]
2011-10-03 12:43 ` Jim Rees
2011-10-06 12:52 ` Benny Halevy
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=4E897E57.2000309@panasas.com \
--to=bharrosh@panasas.com \
--cc=honey@citi.umich.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=rees@umich.edu \
/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.