From: Konstantin Khlebnikov <khlebnikov@parallels.com>
To: Hugh Dickins <hughd@google.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: Sun, 8 May 2011 16:51:28 +0400 [thread overview]
Message-ID: <4DC691D0.6050104@parallels.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1105071621330.3668@sister.anvils>
Hugh Dickins wrote:
> On Sat, 7 May 2011, Konstantin Khlebnikov wrote:
>> Hugh Dickins wrote:
>>
>>> Here's the patch I was testing last night, but I do want to test it
>>> some more (I've not even tried your unmounting case yet), and I do want
>>> to make some changes to it (some comments, and see if I can move the
>>> mem_cgroup_cache_charge outside of the mutex, making it GFP_KERNEL
>>> rather than GFP_NOFS - at the time that mem_cgroup charging went in,
>>> we did not know here if it was actually a shmem swap page, whereas
>>> nowadays we can be sure, since that's noted in the swap_map).
>>>
>>> In shmem_unuse_inode I'm widening the shmem_swaplist_mutex to protect
>>> against shmem_evict_inode; and in shmem_writepage adding to the list
>>> earlier, while holding lock on page still in pagecache to protect it.
>>>
>>> But testing last night showed corruption on this laptop (no problem
>>> on other machines): I'm guessing it's unrelated, but I can't be sure
>>> of that without more extended testing.
>>
>> This patch fixed my problem, I didn't catch any crashes on my test-case:
>> swapout-unmount.
>
> Thank you, Konstantin, for testing that and reporting back.
>
> I tried using your script on Thursday, but couldn't get the tuning right
> for this machine: with numbers too big everything would go OOM, with
> numbers too small it wouldn't even go to swap, with numbers on the edge
> it would soon settle into a steady state with almost nothing in swap.
>
> Just once, without the patch, I did get to "Self-destruct in 5 seconds",
> but that was not reproducible enough for me to test that the patch would
> be fixing anything.
>
> I was going to try today on other machines with more cpus and more memory,
> though not as much as yours; but now I'll let your report save me the time,
> and just add your Tested-by. Big thank you for that!
>
> Besides adding comments, I have changed the patch around since then, at
> the shmem_unuse_inode end: to avoid any memory allocation while holding
> the mutex (and then we no longer need to drop and retake info->lock,
> so it gets a little simpler). It would be dishonest of me to claim your
> Tested-by for the changed code (and your mount/write/umount loop would
> not have been testing swapoff): since it is an independent fix with a
> different justification, I'll split that part off into a 2/3.
Ok, I can test final patch-set on the next week.
Also I can try to add some swapoff test-cases.
>
> 3/3 being the fix to the "corruption" I noticed while testing, corruption
> being on the filesystem I had on /dev/loop0, over a tmpfs file filling its
> filesystem: when I wrote, I'd missed the "I/O" errors in /var/log/messages.
>
> It was another case of a long-standing but largely theoretical race,
> now made easily reproducible by recent changes (the preallocation in
> between find_lock_page and taking info->lock): when the filesystem is
> full, you could get ENOSPC from a race in bringing back a previously
> allocated page from swap.
>
> I'll write these three up now and send off to Andrew.
>
> Hugh
WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@parallels.com>
To: Hugh Dickins <hughd@google.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: Sun, 8 May 2011 16:51:28 +0400 [thread overview]
Message-ID: <4DC691D0.6050104@parallels.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1105071621330.3668@sister.anvils>
Hugh Dickins wrote:
> On Sat, 7 May 2011, Konstantin Khlebnikov wrote:
>> Hugh Dickins wrote:
>>
>>> Here's the patch I was testing last night, but I do want to test it
>>> some more (I've not even tried your unmounting case yet), and I do want
>>> to make some changes to it (some comments, and see if I can move the
>>> mem_cgroup_cache_charge outside of the mutex, making it GFP_KERNEL
>>> rather than GFP_NOFS - at the time that mem_cgroup charging went in,
>>> we did not know here if it was actually a shmem swap page, whereas
>>> nowadays we can be sure, since that's noted in the swap_map).
>>>
>>> In shmem_unuse_inode I'm widening the shmem_swaplist_mutex to protect
>>> against shmem_evict_inode; and in shmem_writepage adding to the list
>>> earlier, while holding lock on page still in pagecache to protect it.
>>>
>>> But testing last night showed corruption on this laptop (no problem
>>> on other machines): I'm guessing it's unrelated, but I can't be sure
>>> of that without more extended testing.
>>
>> This patch fixed my problem, I didn't catch any crashes on my test-case:
>> swapout-unmount.
>
> Thank you, Konstantin, for testing that and reporting back.
>
> I tried using your script on Thursday, but couldn't get the tuning right
> for this machine: with numbers too big everything would go OOM, with
> numbers too small it wouldn't even go to swap, with numbers on the edge
> it would soon settle into a steady state with almost nothing in swap.
>
> Just once, without the patch, I did get to "Self-destruct in 5 seconds",
> but that was not reproducible enough for me to test that the patch would
> be fixing anything.
>
> I was going to try today on other machines with more cpus and more memory,
> though not as much as yours; but now I'll let your report save me the time,
> and just add your Tested-by. Big thank you for that!
>
> Besides adding comments, I have changed the patch around since then, at
> the shmem_unuse_inode end: to avoid any memory allocation while holding
> the mutex (and then we no longer need to drop and retake info->lock,
> so it gets a little simpler). It would be dishonest of me to claim your
> Tested-by for the changed code (and your mount/write/umount loop would
> not have been testing swapoff): since it is an independent fix with a
> different justification, I'll split that part off into a 2/3.
Ok, I can test final patch-set on the next week.
Also I can try to add some swapoff test-cases.
>
> 3/3 being the fix to the "corruption" I noticed while testing, corruption
> being on the filesystem I had on /dev/loop0, over a tmpfs file filling its
> filesystem: when I wrote, I'd missed the "I/O" errors in /var/log/messages.
>
> It was another case of a long-standing but largely theoretical race,
> now made easily reproducible by recent changes (the preallocation in
> between find_lock_page and taking info->lock): when the filesystem is
> full, you could get ENOSPC from a race in bringing back a previously
> allocated page from swap.
>
> I'll write these three up now and send off to Andrew.
>
> 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-08 12:51 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-05 10:34 [PATCH] tmpfs: fix race between umount and writepage Konstantin Khlebnikov
2011-04-05 10:34 ` Konstantin Khlebnikov
2011-04-08 12:27 ` Konstantin Khlebnikov
2011-04-08 12:27 ` Konstantin Khlebnikov
2011-04-20 20:04 ` Andrew Morton
2011-04-20 20:04 ` Andrew Morton
2011-04-21 6:37 ` Konstantin Khlebnikov
2011-04-21 6:37 ` Konstantin Khlebnikov
2011-04-21 6:41 ` [PATCH v2] " Konstantin Khlebnikov
2011-04-21 6:41 ` Konstantin Khlebnikov
2011-04-21 19:44 ` Andrew Morton
2011-04-21 19:44 ` Andrew Morton
2011-04-22 4:05 ` Konstantin Khlebnikov
2011-04-22 4:05 ` Konstantin Khlebnikov
2011-05-03 20:06 ` Hugh Dickins
2011-05-03 20:06 ` Hugh Dickins
2011-05-07 5:33 ` Konstantin Khlebnikov
2011-05-07 5:33 ` Konstantin Khlebnikov
2011-05-07 23:56 ` Hugh Dickins
2011-05-07 23:56 ` Hugh Dickins
2011-05-08 12:51 ` Konstantin Khlebnikov [this message]
2011-05-08 12:51 ` Konstantin Khlebnikov
2011-05-08 19:36 ` Hugh Dickins
2011-05-08 19:36 ` Hugh Dickins
2011-05-10 9:52 ` Konstantin Khlebnikov
2011-05-10 9:52 ` Konstantin Khlebnikov
2011-05-10 18:55 ` Hugh Dickins
2011-05-10 18:55 ` Hugh Dickins
2011-05-08 19:41 ` [PATCH 1/3] " Hugh Dickins
2011-05-08 19:41 ` Hugh Dickins
2011-05-08 19:43 ` [PATCH 2/3] tmpfs: fix race between umount and swapoff Hugh Dickins
2011-05-08 19:43 ` Hugh Dickins
2011-05-08 19:45 ` [PATCH 3/3] tmpfs: fix spurious ENOSPC when racing with unswap Hugh Dickins
2011-05-08 19:45 ` 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=4DC691D0.6050104@parallels.com \
--to=khlebnikov@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.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 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.