From: Sasha Levin <sasha.levin@oracle.com>
To: Jeff Layton <jeff.layton@primarydata.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: fs: locks: WARNING: CPU: 16 PID: 4296 at fs/locks.c:236 locks_free_lock_context+0x10d/0x240()
Date: Fri, 16 Jan 2015 13:10:46 -0500 [thread overview]
Message-ID: <54B95426.5020509@oracle.com> (raw)
In-Reply-To: <20150116094028.4ffd675f@tlielax.poochiereds.net>
On 01/16/2015 09:40 AM, Jeff Layton wrote:
> On Fri, 16 Jan 2015 09:31:23 -0500
> Sasha Levin <sasha.levin@oracle.com> wrote:
>
>> On 01/15/2015 03:22 PM, Jeff Layton wrote:
>>> Ok, I tried to reproduce it with that and several variations but it
>>> still doesn't seem to do it for me. Can you try the latest linux-next
>>> tree and see if it's still reproducible there?
>>
>> It's still not in in today's -next, could you send me a patch for testing
>> instead?
>>
>
> Seems to be there for me:
>
> ----------------------[snip]-----------------------
> /*
> * This function is called on the last close of an open file.
> */
> void locks_remove_file(struct file *filp)
> {
> /* ensure that we see any assignment of i_flctx */
> smp_rmb();
>
> /* remove any OFD locks */
> locks_remove_posix(filp, filp);
> ----------------------[snip]-----------------------
>
> That's actually the right place to put the barrier, I think. We just
> need to ensure that this function sees any assignment to i_flctx that
> occurred before this point. By the time we're here, we shouldn't be
> getting any new locks that matter to this close since the fcheck call
> should fail on any new requests.
>
> If that works, then I'll probably make some other changes to the set
> and re-post it next week.
>
> Many thanks for helping me test this!
You're right, I somehow missed that.
But it doesn't fix the issue, I still see it happening, but it seems
to be less frequent(?).
Thanks,
Sasha
next prev parent reply other threads:[~2015-01-16 18:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-13 5:11 fs: locks: WARNING: CPU: 16 PID: 4296 at fs/locks.c:236 locks_free_lock_context+0x10d/0x240() Sasha Levin
2015-01-13 13:20 ` Jeff Layton
2015-01-13 13:25 ` Sasha Levin
2015-01-13 21:44 ` Jeff Layton
2015-01-13 22:50 ` Sasha Levin
2015-01-13 23:32 ` Jeff Layton
2015-01-14 14:27 ` Jeff Layton
2015-01-14 23:44 ` Sasha Levin
2015-01-15 2:26 ` Jeff Layton
2015-01-15 20:22 ` Jeff Layton
2015-01-16 14:31 ` Sasha Levin
2015-01-16 14:40 ` Jeff Layton
2015-01-16 18:10 ` Sasha Levin [this message]
2015-01-16 18:53 ` Jeff Layton
2015-01-16 21:16 ` Jeff Layton
2015-01-16 21:20 ` Sasha Levin
2015-01-21 13:25 ` Sasha Levin
2015-01-21 13:33 ` Jeff Layton
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=54B95426.5020509@oracle.com \
--to=sasha.levin@oracle.com \
--cc=jeff.layton@primarydata.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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.