From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: asmadeus@codewreck.org, Li Zhong <floridsleeves@gmail.com>
Cc: netdev@vger.kernel.org, v9fs-developer@lists.sourceforge.net,
pabeni@redhat.com, kuba@kernel.org, edumazet@google.com,
davem@davemloft.net, lucho@ionkov.net, ericvh@gmail.com
Subject: Re: [PATCH net-next v1] net/9p/trans_fd: check the return value of parse_opts
Date: Thu, 22 Sep 2022 11:38:20 +0200 [thread overview]
Message-ID: <2328558.MEb0jBPE05@silver> (raw)
In-Reply-To: <CAMEuxRo-QctyufOmAxZdoNrPE57KFd0MLa-kQftmhpHQfkWkJQ@mail.gmail.com>
On Donnerstag, 22. September 2022 00:12:38 CEST Li Zhong wrote:
> On Wed, Sep 21, 2022 at 2:23 PM <asmadeus@codewreck.org> wrote:
> > Li Zhong wrote on Wed, Sep 21, 2022 at 02:09:21PM -0700:
> > > parse_opts() could fail when there is error parsing mount options into
> > > p9_fd_opts structure due to allocation failure. In that case opts will
> > > contain invalid data.
> >
> > In practice opts->rfd/wfd is set to ~0 before the failure modes so they
> > will contain exactly what we want them to contain: something that'll
> > fail the check below.
> >
> > It is however cleared like this so I'll queue this patch in 9p tree when
> > I have a moment, but I'll clarify the commit message to say this is
> > NO-OP : please feel free to send a v2 if you want to put your own words
> > in there; otherwise it'll be something like below:
> > ----
> > net/9p: clarify trans_fd parse_opt failure handling
> >
> > This parse_opts will set invalid opts.rfd/wfd in case of failure which
> > we already check, but it is not clear for readers that parse_opts error
> > are handled in p9_fd_create: clarify this by explicitly checking the
> > return value.
> > ----
>
> Thanks for the patient reply! I agree that the check on
> opts.rfd/wft against ~0 will prevent error even if it fails
> memory allocation. But currently the error log is
> 'insufficient options', which is kind of misleading and the
> error code returned is -ENOPROTOOPT instead of -ENOMEM, which
> I guess would be better if we distinguish between them.
Avoiding those confusions for users makes sense to me, but then please also
mention that in the commit log, because it is also useful to know the actual
motivation of a patch.
Best regards,
Christian Schoenebeck
prev parent reply other threads:[~2022-09-22 9:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 21:09 [PATCH net-next v1] net/9p/trans_fd: check the return value of parse_opts Li Zhong
2022-09-21 21:23 ` asmadeus
2022-09-21 22:12 ` Li Zhong
2022-09-22 9:38 ` Christian Schoenebeck [this message]
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=2328558.MEb0jBPE05@silver \
--to=linux_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=ericvh@gmail.com \
--cc=floridsleeves@gmail.com \
--cc=kuba@kernel.org \
--cc=lucho@ionkov.net \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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).