All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Milosz Tanski <milosz@adfin.com>
Cc: dhowells@redhat.com,
	"linux-cachefs@redhat.com" <linux-cachefs@redhat.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, NeilBrown <neilb@suse.de>,
	Shantanu Goel <sgoel01@yahoo.com>
Subject: Re: [PATCH 2/3] FS-Cache: Reduce cookie ref count if submit fails.
Date: Tue, 12 Aug 2014 13:47:45 +0100	[thread overview]
Message-ID: <17620.1407847665@warthog.procyon.org.uk> (raw)
In-Reply-To: <CANP1eJG572cAR1t+pzCExk7EQWb=aDz77-PuP50GAP2j2mETiw@mail.gmail.com>

Milosz Tanski <milosz@adfin.com> wrote:

> The honest answer is I don't know if it know if needs to be unlocked
> before or after. I saw a same pattern with unlocking order inside of
> __fscache_attr_changed in the failure case.

Following the enomem label, I'm calling fscache_unuse_cookie() which does this
without holding the lock in the same function.

I don't think the lock is required because:

 (1) We hold a ref on cookie->n_active so the cookie cannot go away until we
     release it, so calling __fscache_unuse_cookie() without the lock held
     should be fine.

 (2) wake_up_atomic_t() does not access cookie->n_active.  The address is
     merely needed as a key for the waiters to match on.

David

WARNING: multiple messages have this Message-ID (diff)
From: David Howells <dhowells@redhat.com>
To: Milosz Tanski <milosz@adfin.com>
Cc: Shantanu Goel <sgoel01@yahoo.com>, NeilBrown <neilb@suse.de>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-cachefs@redhat.com" <linux-cachefs@redhat.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 2/3] FS-Cache: Reduce cookie ref count if submit fails.
Date: Tue, 12 Aug 2014 13:47:45 +0100	[thread overview]
Message-ID: <17620.1407847665@warthog.procyon.org.uk> (raw)
In-Reply-To: <CANP1eJG572cAR1t+pzCExk7EQWb=aDz77-PuP50GAP2j2mETiw@mail.gmail.com>

Milosz Tanski <milosz@adfin.com> wrote:

> The honest answer is I don't know if it know if needs to be unlocked
> before or after. I saw a same pattern with unlocking order inside of
> __fscache_attr_changed in the failure case.

Following the enomem label, I'm calling fscache_unuse_cookie() which does this
without holding the lock in the same function.

I don't think the lock is required because:

 (1) We hold a ref on cookie->n_active so the cookie cannot go away until we
     release it, so calling __fscache_unuse_cookie() without the lock held
     should be fine.

 (2) wake_up_atomic_t() does not access cookie->n_active.  The address is
     merely needed as a key for the waiters to match on.

David

  parent reply	other threads:[~2014-08-12 12:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1406043029.git.milosz@adfin.com>
2014-07-22 15:50 ` [PATCH 1/3] FS-Cache: Timeout for releasepage() Milosz Tanski
2014-07-22 15:50 ` [PATCH 2/3] FS-Cache: Reduce cookie ref count if submit fails Milosz Tanski
2014-07-22 15:51 ` [PATCH 3/3] FS-Cache: refcount becomes corrupt under vma preasure Milosz Tanski
2014-07-22 15:51   ` Milosz Tanski
2014-07-29 15:32 ` [PATCH 1/3] FS-Cache: Timeout for releasepage() David Howells
2014-07-29 15:32   ` David Howells
2014-07-29 15:35   ` Milosz Tanski
2014-07-29 15:37 ` [PATCH 2/3] FS-Cache: Reduce cookie ref count if submit fails David Howells
2014-07-29 15:37   ` David Howells
2014-08-06 15:21   ` Milosz Tanski
2014-08-11 18:37     ` Milosz Tanski
2014-08-12 12:47   ` David Howells [this message]
2014-08-12 12:47     ` David Howells
2014-07-29 16:03 ` [PATCH 3/3] FS-Cache: refcount becomes corrupt under vma preasure David Howells
     [not found] <cover.1407948737.git.milosz@adfin.com>
2014-08-13 16:58 ` [PATCH 2/3] FS-Cache: Reduce cookie ref count if submit fails Milosz Tanski
2014-08-13 16:58   ` Milosz Tanski
2014-08-14  4:23   ` NeilBrown
2014-08-14  4:23     ` NeilBrown
2014-08-27 14:31 ` David Howells
2014-08-27 14:31   ` David Howells
2014-09-04 16:00   ` Milosz Tanski
2014-09-08 15:55     ` Milosz Tanski
2014-09-17 20:23     ` David Howells
2014-09-17 20:23       ` David Howells
2014-09-17 20:24       ` Milosz Tanski

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=17620.1407847665@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=milosz@adfin.com \
    --cc=neilb@suse.de \
    --cc=sgoel01@yahoo.com \
    /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.