All of lore.kernel.org
 help / color / mirror / Atom feed
From: Menyhart Zoltan <Zoltan.Menyhart@bull.net>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: "xprt" reference count drops to 0
Date: Fri, 22 Oct 2010 17:00:50 +0200	[thread overview]
Message-ID: <4CC1A722.4060907@bull.net> (raw)
In-Reply-To: <20101021203801.GA12038@fieldses.org>

J. Bruce Fields wrote:
> On Tue, Oct 05, 2010 at 10:22:30AM +0200, Menyhart Zoltan wrote:
>> Due to some race conditions, the reference count can become 0
>> while "xprt" is still on a "pool":
>
> Apologies, your email got buried in my inbox....
>
>>
>> WARNING: at lib/kref.c:43 kref_get+0x23/0x2d()
>>   [] kref_get+0x23/0x2d
>>   [] svc_xprt_get+0x12/0x14 [sunrpc]
>>   [] svc_recv+0x2db/0x78a [sunrpc]
>
> Which kernel exactly did you see this on?  Is it reproduceable?

I saw it on a 2.6.32.
It has not been corrected for the 2.6.36-rc3 yet.
The patch is for  the 2.6.36-rc3.

It is a narrow window, you need a high work load and a bit of luck  to
delay the current CPU just after"svc_xprt_enqueue()" returns.

>> I think we should increase the reference counter before adding "xprt"
>> onto any list.
>
> I don't see the xprt added to any list after the svc_xprt_get() you've
> added below.

"svc_xprt_enqueue()" has got two ways to pass an "xprt":
- via "rqstp->rq_xprt" if a worker is available,
- on the "pool->sp_sockets" list otherwise

         if (!list_empty(&pool->sp_threads)) {
                 rqstp = list_entry(pool->sp_threads.next,  struct svc_rqst,  rq_list);
                 svc_thread_dequeue(pool, rqstp);
                 rqstp->rq_xprt = xprt;
                 svc_xprt_get(xprt);
                 rqstp->rq_reserved = serv->sv_max_mesg;
                 atomic_add(rqstp->rq_reserved, &xprt->xpt_reserved);
                 pool->sp_stats.threads_woken++;
                 wake_up(&rqstp->rq_wait);
         } else {
                 list_add_tail(&xprt->xpt_ready, &pool->sp_sockets);
                 pool->sp_stats.sockets_queued++;
         }

In the 1st case, there is a "svc_xprt_get(xprt)", in the 2nd one, there is not.
Once "svc_xprt_enqueue()" returns, at some places, "svc_xprt_put(xprt)" is
invoked. If we has passed the "else" branch, the "kref" can drop down to 0.

"svc_recv()" includes:

         xprt = svc_xprt_dequeue(pool);
         if (xprt) {
                 rqstp->rq_xprt = xprt;
                 svc_xprt_get(xprt);
                 rqstp->rq_reserved = serv->sv_max_mesg;
                 atomic_add(rqstp->rq_reserved, &xprt->xpt_reserved);
         } else {

i.e. it calls "svc_xprt_get(xprt)" if it has picked up "xprt" from the "pool" list.
Yet it is too late, if the caller of "svc_xprt_enqueue()" has already had the
time to call "svc_xprt_put(xprt)".

I think "svc_xprt_get(xprt)" should be called in "svc_xprt_enqueue()" before
"list_add_tail(&xprt->xpt_ready, &pool->sp_sockets)" to keep the reference
counter valid.
It is much simpler to move the call "svc_xprt_get(xprt)" just before

	if (!list_empty(&pool->sp_threads))

Thanks,

Zoltan




  reply	other threads:[~2010-10-22 15:01 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-01 12:17 Relocate NFS root FS for maintenance Greg
2010-09-01 17:34 ` J. Bruce Fields
2010-09-01 21:52 ` Tom Haynes
2010-09-02  7:32   ` Greg
2010-09-02 16:06     ` J. Bruce Fields
2010-09-07  6:59       ` Greg
2010-09-02  6:56 ` statfs() gives ESTALE error Menyhart Zoltan
2010-09-07 18:32   ` Trond Myklebust
2010-09-08 13:33 ` Re :statfs() " Menyhart Zoltan
2010-09-08 20:25   ` Trond Myklebust
2010-09-09  8:12 ` Menyhart Zoltan
2010-09-20 12:49 ` Locking question around "...PagePrivate()" Menyhart Zoltan
2010-09-20 13:55   ` Trond Myklebust
2010-10-05  8:22 ` "xprt" reference count drops to 0 Menyhart Zoltan
2010-10-21 20:38   ` J. Bruce Fields
2010-10-22 15:00     ` Menyhart Zoltan [this message]
2010-10-22 21:20       ` J. Bruce Fields
2010-10-22 23:01         ` J. Bruce Fields
2010-10-22 23:21           ` J. Bruce Fields
2010-10-23  3:32             ` J. Bruce Fields
2010-10-25  1:09               ` J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 1/4] svcrpc: never clear XPT_BUSY on dead xprt J. Bruce Fields
2010-10-25  1:43                   ` Neil Brown
2010-10-25 20:21                     ` J. Bruce Fields
2010-10-25 22:58                       ` Neil Brown
2010-10-25 23:03                         ` J. Bruce Fields
2010-10-25 23:54                           ` Neil Brown
2010-10-26  0:11                             ` J. Bruce Fields
2010-10-26  0:28                               ` J. Bruce Fields
2010-10-26  0:30                                 ` J. Bruce Fields
2010-10-26  1:28                                   ` Neil Brown
2010-10-26 12:59                                     ` J. Bruce Fields
2010-10-26 16:05                                       ` J. Bruce Fields
2010-11-12 19:00                                         ` J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 2/4] svcrpc: assume svc_delete_xprt() called only once J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 3/4] svcrpc: no need for XPT_DEAD check in svc_xprt_enqueue J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 4/4] svcrpc: svc_tcp_sendto XTP_DEAD check is redundant J. Bruce Fields
2010-10-25  2:10                   ` Neil Brown
2010-10-25 15:03                     ` J. Bruce Fields
2010-10-25 17:46                       ` J. Bruce Fields
2010-10-25 23:08                         ` Neil Brown
2010-10-26  1:33                           ` J. Bruce Fields
2010-10-25 23:23                       ` Neil Brown
2010-10-26  1:25                         ` J. Bruce Fields
2010-10-25 11:56         ` "xprt" reference count drops to 0 Menyhart Zoltan
2010-10-25 14:36           ` 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=4CC1A722.4060907@bull.net \
    --to=zoltan.menyhart@bull.net \
    --cc=bfields@fieldses.org \
    --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 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.