From: Dominique Martinet <dominique.martinet@cea.fr>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Eric Van Hensbergen <ericvh@gmail.com>,
Ron Minnich <rminnich@sandia.gov>,
Latchesar Ionkov <lucho@ionkov.net>,
<v9fs-developer@lists.sourceforge.net>,
<linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fs/9p: Initialize status in v9fs_file_do_lock.
Date: Fri, 9 Jan 2015 14:07:23 +0100 [thread overview]
Message-ID: <20150109130723.GA3183@u-isr-ctg-01> (raw)
In-Reply-To: <20150109123353.GA24928@node.dhcp.inet.fi>
Kirill A. Shutemov wrote on Fri, Jan 09, 2015 at 02:33:53PM +0200:
> On Fri, Jan 09, 2015 at 12:56:07PM +0100, Dominique Martinet wrote:
> > If p9_client_lock_dotl returns an error, status is possibly never filled
> > but will be used in the following switch.
> > Initializing it to P9_LOCK_ERROR makes sur we will return an error and
> > cleanup (and not hit the default case).
>
> That's what my patch[1] fixes.
>
> http://marc.info/?i=1419858019-116944-1-git-send-email-kirill.shutemov%40linux.intel.com
Actually, it's slightly different and still worth adding (mine if we
apply your's first and your's if we apply mine first - don't think
they'll conflict. I even reworded the (too old!) commit message to fit
with your patch :))
Your patch will not BUG() if status is junk, BUT if status uninitialized
value is 0 and p9_client_lock_dotl then we'll return res=0 (success) and
not unlock before returning. My patch makes sure we'll return -ENOLCK.
Likewise, if we only apply my patch then a rogue server could BUG() a
client, so we want your's anyway.
--
Dominique Martinet,
CEA
next prev parent reply other threads:[~2015-01-09 13:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 11:56 [PATCH] fs/9p: Initialize status in v9fs_file_do_lock Dominique Martinet
2015-01-09 12:33 ` Kirill A. Shutemov
2015-01-09 13:07 ` Dominique Martinet [this message]
2015-01-09 13:20 ` Kirill A. Shutemov
2015-01-09 13:29 ` Dominique Martinet
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=20150109130723.GA3183@u-isr-ctg-01 \
--to=dominique.martinet@cea.fr \
--cc=ericvh@gmail.com \
--cc=kirill@shutemov.name \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=rminnich@sandia.gov \
--cc=v9fs-developer@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).