From: Hugh Dickins <hughd@google.com>
To: Konstantin Khlebnikov <khlebnikov@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] tmpfs: fix race between umount and writepage
Date: Tue, 10 May 2011 11:55:26 -0700 [thread overview]
Message-ID: <BANLkTi=pev65quykAhp6SeisxyW7=A3fGA@mail.gmail.com> (raw)
In-Reply-To: <4DC90AE8.101@parallels.com>
On Tue, May 10, 2011 at 2:52 AM, Konstantin Khlebnikov
<khlebnikov@parallels.com> wrote:
> Hugh Dickins wrote:
>>
>> On Sun, 8 May 2011, Konstantin Khlebnikov wrote:
>>>
>>> Ok, I can test final patch-set on the next week.
>>> Also I can try to add some swapoff test-cases.
>>
>> That would be helpful if you have the time: thank you.
>
> I Confirm, patch 1/3 really fixes race between writepage and umount, as
> expected.
Good, thank you (but that path was identical to what you'd already tested).
>
> In patch 2/3: race-window between unlock_page and iput extremely small.
(I should clarify that the main race window is actually much wider
than that. That page lock is only effective at holding off
shmem_evict_inode() while the page is in the file's pagecache -
between the (old positioning of) mutex_unlock(&shmem_swaplist_mutex)
and the add_to_page_cache_locked(), the page is just in swapcache and
so not recognizably attached to the file: shmem_evict_inode() will
call shmem_truncate_range(), and that would find the swp_entry_t, but
it frees it with a free_swap_and_cache() - which does not wait if it
cannot trylock the page.)
> My test works fine in parallel with thirty random swapon-swapoff,
> but it works without this patch too, thus I cannot catch this race.
Thanks for trying. Given my difficulty in reproducing your umount
case, I'm not at all surprised that you didn't manage to reproduce
this swapoff case. Indeed, I didn't even try to reproduce it myself:
I just saw the theoretical possibility once you'd warned me of
igrab(), and tested that this igrab-less approach works as well as the
old approach, without risking that race.
>
> I apply patch 3/3 too, but have not tested this case.
Fine, that part I could reproduce fairly easily for myself, and the
fix tested out fine.
Thanks,
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-05-10 18:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-05 10:34 [PATCH] " Konstantin Khlebnikov
2011-04-08 12:27 ` Konstantin Khlebnikov
2011-04-20 20:04 ` Andrew Morton
2011-04-21 6:37 ` Konstantin Khlebnikov
2011-04-21 6:41 ` [PATCH v2] " Konstantin Khlebnikov
2011-04-21 19:44 ` Andrew Morton
2011-04-22 4:05 ` Konstantin Khlebnikov
2011-05-03 20:06 ` Hugh Dickins
2011-05-07 5:33 ` Konstantin Khlebnikov
2011-05-07 23:56 ` Hugh Dickins
2011-05-08 12:51 ` Konstantin Khlebnikov
2011-05-08 19:36 ` Hugh Dickins
2011-05-10 9:52 ` Konstantin Khlebnikov
2011-05-10 18:55 ` Hugh Dickins [this message]
2011-05-08 19:41 ` [PATCH 1/3] " Hugh Dickins
2011-05-08 19:43 ` [PATCH 2/3] tmpfs: fix race between umount and swapoff Hugh Dickins
2011-05-08 19:45 ` [PATCH 3/3] tmpfs: fix spurious ENOSPC when racing with unswap Hugh Dickins
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='BANLkTi=pev65quykAhp6SeisxyW7=A3fGA@mail.gmail.com' \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=khlebnikov@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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