linux.git/fs/fscache, branch v4.5

FS-Cache: Handle a write to the page immediately beyond the EOF marker

2015-11-11T07:11:02+00:00

Handle a write being requested to the page immediately beyond the EOF
marker on a cache object.  Currently this gets an assertion failure in
CacheFiles because the EOF marker is used there to encode information about
a partial page at the EOF - which could lead to an unknown blank spot in
the file if we extend the file over it.

The problem is actually in fscache where we check the index of the page
being written against store_limit.  store_limit is set to the number of
pages that we're allowed to store by fscache_set_store_limit() - which
means it's one more than the index of the last page we're allowed to store.
The problem is that we permit writing to a page with an index _equal_ to
the store limit - when we should reject that case.

Whilst we're at it, change the triggered assertion in CacheFiles to just
return -ENOBUFS instead.

The assertion failure looks something like this:

CacheFiles: Assertion failed
1000 < 7b1 is false
------------[ cut here ]------------
kernel BUG at fs/cachefiles/rdwr.c:962!
...
RIP: 0010:[]  [] cachefiles_write_page+0x273/0x2d0 [cachefiles]

Cc: stable@vger.kernel.org # v2.6.31+; earlier - that + backport of a17754f (at least)
Signed-off-by: David Howells 
Signed-off-by: Al Viro

FS-Cache: Don't override netfs's primary_index if registering failed

2015-11-11T07:07:51+00:00

Only override netfs->primary_index when registering success.

Cc: stable@vger.kernel.org # v2.6.30+
Signed-off-by: Kinglong Mee 
Signed-off-by: David Howells 
Signed-off-by: Al Viro

FS-Cache: Increase reference of parent after registering, netfs success

2015-11-11T07:06:53+00:00

If netfs exist, fscache should not increase the reference of parent's
usage and n_children, otherwise, never be decreased.

v2: thanks David's suggest,
 move increasing reference of parent if success
 use kmem_cache_free() freeing primary_index directly

v3: don't move "netfs->primary_index->parent = &fscache_fsdef_index;"

Cc: stable@vger.kernel.org # v2.6.30+
Signed-off-by: Kinglong Mee 
Signed-off-by: David Howells 
Signed-off-by: Al Viro

mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd

2015-11-07T01:50:42+00:00

__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts.  They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve".  __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".

Over time, callers had a requirement to not block when fallback options
were available.  Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.

This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative.  High priority users continue to use
__GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.

This patch then converts a number of sites

o __GFP_ATOMIC is used by callers that are high priority and have memory
  pools for those requests. GFP_ATOMIC uses this flag.

o Callers that have a limited mempool to guarantee forward progress clear
  __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
  into this category where kswapd will still be woken but atomic reserves
  are not used as there is a one-entry mempool to guarantee progress.

o Callers that are checking if they are non-blocking should use the
  helper gfpflags_allow_blocking() where possible. This is because
  checking for __GFP_WAIT as was done historically now can trigger false
  positives. Some exceptions like dm-crypt.c exist where the code intent
  is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
  flag manipulations.

o Callers that built their own GFP flags instead of starting with GFP_KERNEL
  and friends now also need to specify __GFP_KSWAPD_RECLAIM.

The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.

The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL.  They may
now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.

Signed-off-by: Mel Gorman 
Acked-by: Vlastimil Babka 
Acked-by: Michal Hocko 
Acked-by: Johannes Weiner 
Cc: Christoph Lameter 
Cc: David Rientjes 
Cc: Vitaly Wool 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

KEYS: Merge the type-specific data with the payload data

2015-10-21T14:18:36+00:00

Merge the type-specific data with the payload data into one four-word chunk
as it seems pointless to keep them separate.

Use user_key_payload() for accessing the payloads of overloaded
user-defined keys.

Signed-off-by: David Howells 
cc: linux-cifs@vger.kernel.org
cc: ecryptfs@vger.kernel.org
cc: linux-ext4@vger.kernel.org
cc: linux-f2fs-devel@lists.sourceforge.net
cc: linux-nfs@vger.kernel.org
cc: ceph-devel@vger.kernel.org
cc: linux-ima-devel@lists.sourceforge.net

FS-Cache: Retain the netfs context in the retrieval op earlier

2015-04-02T13:28:53+00:00

Now that the retrieval operation may be disposed of by fscache_put_operation()
before we actually set the context, the retrieval-specific cleanup operation
can produce a NULL-pointer dereference when it tries to unconditionally clean
up the netfs context.

Given that it is expected that we'll get at least as far as the place where we
currently set the context pointer and it is unlikely we'll go through the
error handling paths prior to that point, retain the context right from the
point that the retrieval op is allocated.

Concomitant to this, we need to retain the cookie pointer in the retrieval op
also so that we can call the netfs to release its context in the release
method.

In addition, we might now get into fscache_release_retrieval_op() with the op
only initialised.  To this end, set the operation to DEAD only after the
release method has been called and skip the n_pages test upon cleanup if the
op is still in the INITIALISED state.

Without these changes, the following oops might be seen:

	BUG: unable to handle kernel NULL pointer dereference at 00000000000000b8
	...
	RIP: 0010:[] fscache_release_retrieval_op+0xae/0x100
	...
	Call Trace:
	 [] fscache_put_operation+0x117/0x2e0
	 [] __fscache_read_or_alloc_pages+0x351/0x3ac
	 [] __nfs_readpages_from_fscache+0x59/0xbf [nfs]
	 [] nfs_readpages+0x10c/0x185 [nfs]
	 [] ? alloc_pages_current+0x119/0x13e
	 [] ? __page_cache_alloc+0xfb/0x10a
	 [] __do_page_cache_readahead+0x188/0x22c
	 [] ondemand_readahead+0x29e/0x2af
	 [] page_cache_sync_readahead+0x38/0x3a
	 [] generic_file_read_iter+0x1a2/0x55a
	 [] ? nfs_revalidate_mapping+0xd6/0x288 [nfs]
	 [] nfs_file_read+0x49/0x70 [nfs]
	 [] new_sync_read+0x78/0x9c
	 [] __vfs_read+0x13/0x38
	 [] vfs_read+0x95/0x121
	 [] SyS_read+0x4c/0x8a
	 [] system_call_fastpath+0x12/0x17

Signed-off-by: David Howells 
Reviewed-by: Steve Dickson 
Acked-by: Jeff Layton

FS-Cache: The operation cancellation method needs calling in more places

2015-04-02T13:28:53+00:00

Any time an incomplete operation is cancelled, the operation cancellation
function needs to be called to clean up.  This is currently being passed
directly to some of the functions that might want to call it, but not all.

Instead, pass the cancellation method pointer to the fscache_operation_init()
and have that cache it in the operation struct.  Further, plug in a dummy
cancellation handler if the caller declines to set one as this allows us to
call the function unconditionally (the extra overhead isn't worth bothering
about as we don't expect to be calling this typically).

The cancellation method must thence be called everywhere the CANCELLED state
is set.  Note that we call it *before* setting the CANCELLED state such that
the method can use the old state value to guide its operation.

fscache_do_cancel_retrieval() needs moving higher up in the sources so that
the init function can use it now.

Without this, the following oops may be seen:

	FS-Cache: Assertion failed
	FS-Cache: 3 == 0 is false
	------------[ cut here ]------------
	kernel BUG at ../fs/fscache/page.c:261!
	...
	RIP: 0010:[]  fscache_release_retrieval_op+0x77/0x100
	 [] fscache_put_operation+0x114/0x2da
	 [] __fscache_read_or_alloc_pages+0x358/0x3b3
	 [] __nfs_readpages_from_fscache+0x59/0xbf [nfs]
	 [] nfs_readpages+0x10c/0x185 [nfs]
	 [] ? alloc_pages_current+0x119/0x13e
	 [] ? __page_cache_alloc+0xfb/0x10a
	 [] __do_page_cache_readahead+0x188/0x22c
	 [] ondemand_readahead+0x29e/0x2af
	 [] page_cache_sync_readahead+0x38/0x3a
	 [] generic_file_read_iter+0x1a2/0x55a
	 [] ? nfs_revalidate_mapping+0xd6/0x288 [nfs]
	 [] nfs_file_read+0x49/0x70 [nfs]
	 [] new_sync_read+0x78/0x9c
	 [] __vfs_read+0x13/0x38
	 [] vfs_read+0x95/0x121
	 [] SyS_read+0x4c/0x8a
	 [] system_call_fastpath+0x12/0x17

The assertion is showing that the remaining number of pages (n_pages) is not 0
when the operation is being released.

Signed-off-by: David Howells 
Reviewed-by: Steve Dickson 
Acked-by: Jeff Layton

FS-Cache: Put an aborted initialised op so that it is accounted correctly

2015-04-02T13:28:53+00:00

Call fscache_put_operation() or a wrapper on any op that has gone through
fscache_operation_init() so that the accounting shown in /proc is done
correctly, specifically fscache_n_op_release.

fscache_put_operation() therefore now allows an op in the INITIALISED state as
well as in the CANCELLED and COMPLETE states.

Note that this means that an operation can get put that doesn't have its
->object pointer filled in, so anything that depends on the object needs to be
conditional in fscache_put_operation().

Signed-off-by: David Howells 
Reviewed-by: Steve Dickson 
Acked-by: Jeff Layton

FS-Cache: Fix cancellation of in-progress operation

2015-04-02T13:28:53+00:00

Cancellation of an in-progress operation needs to update the relevant counters
and start any operations that are pending waiting on this one.

Signed-off-by: David Howells 
Reviewed-by: Steve Dickson 
Acked-by: Jeff Layton

FS-Cache: Count the number of initialised operations

2015-04-02T13:28:53+00:00

Count and display through /proc/fs/fscache/stats the number of initialised
operations.

Signed-off-by: David Howells 
Reviewed-by: Steve Dickson 
Acked-by: Jeff Layton