From: Xiaotian Feng <dfeng@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Neil Brown <neilb@suse.de>,
Trond Myklebust <Trond.Myklebust@netapp.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] sunrpc: fix peername failed on closed listener
Date: Wed, 06 Jan 2010 17:07:32 +0800 [thread overview]
Message-ID: <4B4452D4.6090708@redhat.com> (raw)
In-Reply-To: <20100105230131.GA22850@fieldses.org>
On 01/06/2010 07:01 AM, J. Bruce Fields wrote:
> On Thu, Dec 31, 2009 at 10:52:36AM +0800, Xiaotian Feng wrote:
>> There're some warnings of "nfsd: peername failed (err 107)!"
>> socket error -107 means Transport endpoint is not connected.
>> This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c],
>> when kernel_getpeername returns -107. This means socket might be CLOSED.
>>
>> And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c]
>>
>> if (test_bit(XPT_LISTENER,&xprt->xpt_flags)) {
>> <snip>
>> newxpt = xprt->xpt_ops->xpo_accept(xprt);
>> <snip>
>>
>> So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE.
>>
>> Let's take a look at commit b0401d72, this commit has moved the close
>> processing after do recvfrom method, but this commit also introduces this
>> warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should
>> close it, not accpet then close.
>
> The logic here seems unnecessarily complicated now, but as a minimal
> fix, this seems fine.
>
> Is the *only* justification for this to silence this warning, or is
> there some more serious problem I'm missing?
If a xprt->xpt_flags has XPT_CLOSE & XPT_LISTENER, kernel will accept it
first,
and svc_xprt_received(xptr) no mater xpo_accept is suceed or failed,
then svc_delete_xprt(xprt).
I'm not sure what will happened between the svc_xprt_received and
svc_delete_xprt, there isn't any
lock to protect it.
>
> --b.
>
>>
>> Signed-off-by: Xiaotian Feng<dfeng@redhat.com>
>> Cc: J. Bruce Fields<bfields@fieldses.org>
>> Cc: Neil Brown<neilb@suse.de>
>> Cc: Trond Myklebust<Trond.Myklebust@netapp.com>
>> Cc: David S. Miller<davem@davemloft.net>
>> ---
>> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
>> index 1c924ee..187f0f4 100644
>> --- a/net/sunrpc/svc_xprt.c
>> +++ b/net/sunrpc/svc_xprt.c
>> @@ -699,7 +699,8 @@ int svc_recv(struct svc_rqst *rqstp, long timeout)
>> spin_unlock_bh(&pool->sp_lock);
>>
>> len = 0;
>> - if (test_bit(XPT_LISTENER,&xprt->xpt_flags)) {
>> + if (test_bit(XPT_LISTENER,&xprt->xpt_flags)&&
>> + !test_bit(XPT_CLOSE,&xprt->xpt_flags)) {
>> struct svc_xprt *newxpt;
>> newxpt = xprt->xpt_ops->xpo_accept(xprt);
>> if (newxpt) {
>
WARNING: multiple messages have this Message-ID (diff)
From: Xiaotian Feng <dfeng-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Neil Brown <neilb-l3A5Bk7waGM@public.gmane.org>,
Trond Myklebust
<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>,
"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: Re: [PATCH] sunrpc: fix peername failed on closed listener
Date: Wed, 06 Jan 2010 17:07:32 +0800 [thread overview]
Message-ID: <4B4452D4.6090708@redhat.com> (raw)
In-Reply-To: <20100105230131.GA22850-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On 01/06/2010 07:01 AM, J. Bruce Fields wrote:
> On Thu, Dec 31, 2009 at 10:52:36AM +0800, Xiaotian Feng wrote:
>> There're some warnings of "nfsd: peername failed (err 107)!"
>> socket error -107 means Transport endpoint is not connected.
>> This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c],
>> when kernel_getpeername returns -107. This means socket might be CLOSED.
>>
>> And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c]
>>
>> if (test_bit(XPT_LISTENER,&xprt->xpt_flags)) {
>> <snip>
>> newxpt = xprt->xpt_ops->xpo_accept(xprt);
>> <snip>
>>
>> So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE.
>>
>> Let's take a look at commit b0401d72, this commit has moved the close
>> processing after do recvfrom method, but this commit also introduces this
>> warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should
>> close it, not accpet then close.
>
> The logic here seems unnecessarily complicated now, but as a minimal
> fix, this seems fine.
>
> Is the *only* justification for this to silence this warning, or is
> there some more serious problem I'm missing?
If a xprt->xpt_flags has XPT_CLOSE & XPT_LISTENER, kernel will accept it
first,
and svc_xprt_received(xptr) no mater xpo_accept is suceed or failed,
then svc_delete_xprt(xprt).
I'm not sure what will happened between the svc_xprt_received and
svc_delete_xprt, there isn't any
lock to protect it.
>
> --b.
>
>>
>> Signed-off-by: Xiaotian Feng<dfeng-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Cc: J. Bruce Fields<bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
>> Cc: Neil Brown<neilb-l3A5Bk7waGM@public.gmane.org>
>> Cc: Trond Myklebust<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
>> Cc: David S. Miller<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>> ---
>> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
>> index 1c924ee..187f0f4 100644
>> --- a/net/sunrpc/svc_xprt.c
>> +++ b/net/sunrpc/svc_xprt.c
>> @@ -699,7 +699,8 @@ int svc_recv(struct svc_rqst *rqstp, long timeout)
>> spin_unlock_bh(&pool->sp_lock);
>>
>> len = 0;
>> - if (test_bit(XPT_LISTENER,&xprt->xpt_flags)) {
>> + if (test_bit(XPT_LISTENER,&xprt->xpt_flags)&&
>> + !test_bit(XPT_CLOSE,&xprt->xpt_flags)) {
>> struct svc_xprt *newxpt;
>> newxpt = xprt->xpt_ops->xpo_accept(xprt);
>> if (newxpt) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-01-06 9:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-31 2:52 [PATCH] sunrpc: fix peername failed on closed listener Xiaotian Feng
2009-12-31 2:52 ` Xiaotian Feng
2010-01-04 7:12 ` Nikola Ciprich
2010-01-04 7:12 ` Nikola Ciprich
2010-01-04 7:12 ` Nikola Ciprich
2010-01-05 23:01 ` J. Bruce Fields
2010-01-06 9:07 ` Xiaotian Feng [this message]
2010-01-06 9:07 ` Xiaotian Feng
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=4B4452D4.6090708@redhat.com \
--to=dfeng@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=netdev@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 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.