From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "J. Bruce Fields" <bfields@redhat.com>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 08/14] svcrpc: ignore unknown address type in udp receive
Date: Tue, 21 Aug 2012 17:42:33 -0400 [thread overview]
Message-ID: <20120821214233.GA19185@fieldses.org> (raw)
In-Reply-To: <E2217068-BD91-4428-913A-4CDA910250AE@oracle.com>
On Tue, Aug 21, 2012 at 05:38:26PM -0400, Chuck Lever wrote:
>
> On Aug 21, 2012, at 5:33 PM, J. Bruce Fields wrote:
>
> > On Tue, Aug 21, 2012 at 05:29:16PM -0400, Chuck Lever wrote:
> >>
> >> On Aug 21, 2012, at 5:24 PM, J. Bruce Fields wrote:
> >>
> >>> On Tue, Aug 21, 2012 at 05:02:14PM -0400, Chuck Lever wrote:
> >>>>
> >>>> On Aug 21, 2012, at 4:57 PM, J. Bruce Fields wrote:
> >>>>
> >>>>> From: "J. Bruce Fields" <bfields@redhat.com>
> >>>>>
> >>>>> How would this happen?
> >>>>
> >>>> If an unsupported address family is used in the rqstp.
> >>>
> >>> Right, but that's impossible, isn't it?
> >>
> >> The point is to catch this case when someone adds support for new address families. It won't happen in current code.
> >>
> >>>>> In any case, it appears this would be returned all the way up to the
> >>>>> caller of svc_recv(), and it's obvious that none of them are equipped to
> >>>>> handle it, and not clear what they would want to do with it anyway.
> >>>>> Let's just drop this and return -EAGAIN.
> >>>>
> >>>> EAGAIN is incorrect; the correct error code is EAFNOSUPPORT. If callers are not prepared for this error return, perhaps BUG_ON() would be more appropriate here.
> >>>
> >>> Yeah. Actually on a quick check this is the only caller that even
> >>> checks for this case. So probably the check should go in svc_addr_len.
> >>> Maybe we should be nice and make it a warning.
> >>
> >> I normally find BUG pretty harsh, but in this case it's true a software error, and as you say, should be "impossible": thus it should be a BUG. The code should stop before the zero length is used.
> >
> > Eh, OK, I guess I can live with that.
> >
> > commit 751f877b10f8ce0d12b40d2a102f3b42b26dc08d
> > Author: J. Bruce Fields <bfields@redhat.com>
> > Date: Tue Aug 21 17:22:11 2012 -0400
> >
> > svcrpc: don't bother checking bad svc_addr_len result
> >
> > None of the callers should see an unsupported address family (only one
> > of them even bothers to check for that case), so just check for the
> > buggy case in svc_addr_len and don't bother elsewhere.
> >
> > Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>
> Acked-by: Chuck Lever <chuck.lever@oracle.com>
Ok, thanks.--b.
next prev parent reply other threads:[~2012-08-21 21:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-21 20:57 nfsd & svcrpc patches (mainly cleanup) for 3.7 J. Bruce Fields
2012-08-21 20:57 ` [PATCH 01/14] svcrpc: standardize svc_setup_socket return convention J. Bruce Fields
2012-08-21 20:57 ` [PATCH 02/14] svcrpc: clean up control flow J. Bruce Fields
2012-08-21 20:57 ` [PATCH 03/14] svcrpc: make svc_create_xprt enqueue on clearing XPT_BUSY J. Bruce Fields
2012-08-21 20:57 ` [PATCH 04/14] svcrpc: share some setup of listening sockets J. Bruce Fields
2012-08-21 20:57 ` [PATCH 05/14] nfsd: remove redundant "port" argument J. Bruce Fields
2012-08-21 20:57 ` [PATCH 06/14] nfsd: allow configuring nfsd to listen on 5-digit ports J. Bruce Fields
2012-08-21 21:25 ` J. Bruce Fields
2012-08-21 20:57 ` [PATCH 07/14] svcrpc: minor udp code cleanup J. Bruce Fields
2012-08-21 20:57 ` [PATCH 08/14] svcrpc: ignore unknown address type in udp receive J. Bruce Fields
2012-08-21 21:02 ` Chuck Lever
2012-08-21 21:24 ` J. Bruce Fields
2012-08-21 21:29 ` Chuck Lever
2012-08-21 21:33 ` J. Bruce Fields
2012-08-21 21:38 ` Chuck Lever
2012-08-21 21:42 ` J. Bruce Fields [this message]
2012-08-21 20:57 ` [PATCH 09/14] svcrpc: make xpo_recvfrom return only >=0 J. Bruce Fields
2012-08-21 20:57 ` [PATCH 10/14] svcrpc: remove handling of unknown errors from svc_recv J. Bruce Fields
2012-08-21 20:57 ` [PATCH 11/14] svcrpc: make svc_xprt_received static J. Bruce Fields
2012-08-21 20:57 ` [PATCH 12/14] svcrpc: break up svc_recv J. Bruce Fields
2012-08-21 20:57 ` [PATCH 13/14] svcrpc: split up svc_handle_xprt J. Bruce Fields
2012-08-21 20:57 ` [PATCH 14/14] nfsd: document kernel interfaces for nfsd configuration J. Bruce Fields
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=20120821214233.GA19185@fieldses.org \
--to=bfields@fieldses.org \
--cc=bfields@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
/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).