Kernel crash "Out of memory error by X" when using NTFS file system on external USB Hard drive

https://bugzilla.kernel.org/show_bug.cgi?id=42578

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 1 line · On Wed, 18 Jan 2012 09:22:12 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=42578

Stuart has an 8GB x86_32 machine.

It has large amounts of NTFS
pagecache in highmem. NTFS is using 512-byte buffer_heads. All of the machine's lowmem is being consumed by struct buffer_heads which are attached to the highmem pagecache and the machine is dead in the water, getting a storm of ooms.

A regression, I think. A box-killing one on a pretty simple workload on a not uncommon machine.

We used to handle this by scanning highmem even when there was plenty of free highmem and the request is for a lowmmem pages. We have made a few changes in this area and I guess that's what broke it.

I think a suitable fix here would be to extend the buffer_heads_over_limit special-case. If buffer_heads_over_limit is true, both direct-reclaimers and kswapd should scan the highmem zone regardless of incoming gfp_mask and regardless of the highmem free pages count.

In this mode, we only scan the file lru. We should perform writeback as well, because the buffer_heads might be dirty.

[aside: If all of a page's buffer_heads are dirty we can in fact reclaim them and mark the entire page dirty. If some of the buffer_heads are dirty and the others are uptodate we can even reclaim them in this case, and mark the entire page dirty, causing extra I/O later. But try_to_release_page() doesn't do these things.]

I think it is was always wrong that we only strip buffer_heads when moving pages to the inactive list. What happens if those 600MB of buffer_heads are all attached to inactive pages?

Quoted 4 lines · Andrew Morton

I think it is was always wrong that we only strip buffer_heads when moving pages to the inactive list. What happens if those 600MB of buffer_heads are all attached to inactive pages?

I wondered the same thing myself. With some use-once logic, there is no guarantee that they even get promoted to the active list in the first place. It's "always" been like this but we've changed how pages gets promoted quite a bit and this use case could have been easily missed.

Quoted 9 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 1 line · On Wed, 18 Jan 2012 09:22:12 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=42578

Sorry again for taking so long to look at this.

Quoted 1 line

Stuart has an 8GB x86_32 machine.

The bugzilla talks about a 16G machine. Is 8G a typo?

Quoted 6 lines

It has large amounts of NTFS
pagecache in highmem. NTFS is using 512-byte buffer_heads. All of the machine's lowmem is being consumed by struct buffer_heads which are attached to the highmem pagecache and the machine is dead in the water, getting a storm of ooms.

Ok, I was at least able to confirm with an 8G machine that there are a lot of buffer_heads allocated as you'd expect but it did not crash. I suspect it's because the ratio of highmem/normal was insufficient to trigger the bug. Stuart, if this is a 16G machine, can you test booting with mem=8G to confirm the ratio of highmem/normal is the important factor please?

Quoted 3 lines

A regression, I think. A box-killing one on a pretty simple workload on a not uncommon machine.

Because of the trigger, it's the type of bug that could have existed for a long time without being noticed. When I went to reproduce this, I found that my distro by default was using fuse to access the NTFS partition which could have also contributed to hiding this.

Quoted 4 lines

We used to handle this by scanning highmem even when there was plenty of free highmem and the request is for a lowmmem pages. We have made a few changes in this area and I guess that's what broke it.

I don't have much time to look at this unfortunately so I didn't dig too deep but this assessment looks accurate. In direct reclaim for example, we used to always scan all zones unconditionally. Now we filter what zones we reclaim from based on the gfp mask of the caller.

Quoted 6 lines

I think a suitable fix here would be to extend the buffer_heads_over_limit special-case. If buffer_heads_over_limit is true, both direct-reclaimers and kswapd should scan the highmem zone regardless of incoming gfp_mask and regardless of the highmem free pages count.

I've included a quick hatchet job below to test the basic theory. It has not been tested properly I'm afraid but the basic idea is there.

Quoted 3 lines

In this mode, we only scan the file lru. We should perform writeback as well, because the buffer_heads might be dirty.

With this patch against 3.3-rc3, it won't immediately initiate writeback by kswapd. Direct reclaim cannot initiate writeback at all so there is still a risk that enough dirty pages could exist to pin low memory and go OOM but the machine would need at least 30G of machine and running in 32-bit mode.

Quoted 6 lines

[aside: If all of a page's buffer_heads are dirty we can in fact reclaim them and mark the entire page dirty. If some of the buffer_heads are dirty and the others are uptodate we can even reclaim them in this case, and mark the entire page dirty, causing extra I/O later. But try_to_release_page() doesn't do these things.]

Good tip.

Quoted 4 lines

I think it is was always wrong that we only strip buffer_heads when moving pages to the inactive list. What happens if those 600MB of buffer_heads are all attached to inactive pages?

I wondered the same thing myself. With some use-once logic, there is no guarantee that they even get promoted to the active list in the first place. It's "always" been like this but we've changed how pages gets promoted quite a bit and this use case could have been easily missed.

mm/vmscan.c +19 -0

index c52b235..3622765 100644
@@ -2235,6 +2235,14 @@ static bool shrink_zones(int priority, struct zonelist *zonelist,
  	unsigned long nr_soft_scanned;
  	bool aborted_reclaim = false;
 
+	/*
+	 * If the number of buffer_heads in the machine exceeds the maximum
+	 * allowed level, force direct reclaim to scan the highmem zone as
+	 * highmem pages could be pinning lowmem pages storing buffer_heads
+	 */
+	if (buffer_heads_over_limit)
+		sc->gfp_mask |= __GFP_HIGHMEM;
+
  	for_each_zone_zonelist_nodemask(zone, z, zonelist,
  					gfp_zone(sc->gfp_mask), sc->nodemask) {
  		if (!populated_zone(zone))

@@ -2724,6 +2732,17 @@ loop_again:
  			 */
  			age_active_anon(zone,&sc, priority);
 
+			/*
+			 * If the number of buffer_heads in the machine
+			 * exceeds the maximum allowed level and this node
+			 * has a highmem zone, force kswapd to reclaim from
+			 * it to relieve lowmem pressure.
+			 */
+			if (buffer_heads_over_limit&&  is_highmem_idx(i)) {
+				end_zone = i;
+				break;
+			}
+
  			if (!zone_watermark_ok_safe(zone, order,
  					high_wmark_pages(zone), 0, 0)) {
  				end_zone = i;

Quoted 7 lines · Mel Gorman

Quoted 4 lines · Andrew Morton

I think it is was always wrong that we only strip buffer_heads when moving pages to the inactive list. What happens if those 600MB of buffer_heads are all attached to inactive pages?

Quoted 4 lines

I wondered the same thing myself. With some use-once logic, there is no guarantee that they even get promoted to the active list in the first place. It's "always" been like this but we've changed how pages gets promoted quite a bit and this use case could have been easily missed.

It may be possible to also strip the buffer heads from pages when they are moved to the active list, in activate_page().

Thanks for the update, my test results using kernel 3.3-rc3 are as follows:

1 With all 16Gbyte enabled the system fails as previously reported.

2 With memory limited to 8Gbyte the system does not fail.

3 With the patch applied and the system using the full 16Gbyte the system does not fail.

Thanks Stuart. Rik, Andrew, should the following be improved in some way? I did not come to any decent conclusion on what to do with pages in the inactive list with buffer_head as we are already stripping them when the pages reach the end of the LRU.

Quoted 4 lines · Mel Gorman

Thanks Stuart. Rik, Andrew, should the following be improved in some way? I did not come to any decent conclusion on what to do with pages in the inactive list with buffer_head as we are already stripping them when the pages reach the end of the LRU.

We have made the statement in the past that configurations > 8GB on 32 bit should not be considered stable or supported? The fact is the more memory you add on 32 bit the less low mem memory is available and the more likely that an OOM will occur for any number of reasons.

Stuart Foster reported on https://bugzilla.kernel.org/show_bug.cgi?id=42578
that copying large amounts of data from NTFS caused an OOM kill on 32-bit X86 with 16G of memory. Andrew Morton correctly identified that the problem was NTFS was using 512 blocks meaning each page had 8 buffer_heads in low memory pinning it.

In the past, direct reclaim used to scan highmem even if the allocating process did not specify __GFP_HIGHMEM but not any more. kswapd no longer will reclaim from zones that are above the high watermark. The intention in both cases was to minimise unnecessary reclaim. The downside is on machines with large amounts of highmem that lowmem can be fully consumed by buffer_heads with nothing trying to free them.

The following patch is based on a suggestion by Andrew Morton to extend the buffer_heads_over_limit case to force kswapd and direct reclaim to scan the highmem zone regardless of the allocation request or watermarks.

Quoted 7 lines · On Tue, 14 Feb 2012 14:00:47 -0600 (CST) Christoph Lameter <[email protected]> wrote:

Quoted 4 lines · Mel Gorman

Thanks Stuart. Rik, Andrew, should the following be improved in some way? I did not come to any decent conclusion on what to do with pages in the inactive list with buffer_head as we are already stripping them when the pages reach the end of the LRU.

Quoted 4 lines

We have made the statement in the past that configurations > 8GB on 32 bit should not be considered stable or supported? The fact is the more memory you add on 32 bit the less low mem memory is available and the more likely that an OOM will occur for any number of reasons.

I have memories of 16G being usable in earlier kernels.

Also, if an 8G machine works OK at present, it's only by luck. sizeof(buffer_head) is around 100, so it takes 1.6GB of buffer_heads to support 8G of 512-byte blocksize pagecache.

Quoted 13 lines · On Tue, 14 Feb 2012 13:09:55 +0000 Mel Gorman <[email protected]> wrote:

Stuart Foster reported on https://bugzilla.kernel.org/show_bug.cgi?id=42578
that copying large amounts of data from NTFS caused an OOM kill on 32-bit X86 with 16G of memory. Andrew Morton correctly identified that the problem was NTFS was using 512 blocks meaning each page had 8 buffer_heads in low memory pinning it.

In the past, direct reclaim used to scan highmem even if the allocating process did not specify __GFP_HIGHMEM but not any more. kswapd no longer will reclaim from zones that are above the high watermark. The intention in both cases was to minimise unnecessary reclaim. The downside is on machines with large amounts of highmem that lowmem can be fully consumed by buffer_heads with nothing trying to free them.

Quoted 4 lines

The following patch is based on a suggestion by Andrew Morton to extend the buffer_heads_over_limit case to force kswapd and direct reclaim to scan the highmem zone regardless of the allocation request or watermarks.

Seems reasonable, thanks.

I wonder if we really needed to change balance_pdgat(). The smaller we can make profile of the special-case-hack the better. Perhaps poking it into direct reclaim was sufficient?