linux-kernel - Re: [PATCH] FS-Cache: Fix handling of an attempt to store a page that is now beyond EOF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANP1eJFt_A30hYxA+8scEuPrnw_B=pOBojrkGicPH0gvB90SMQ@mail.gmail.com>
Date:	Tue, 17 Dec 2013 18:59:40 -0500
From:	Milosz Tanski <milosz@...in.com>
To:	David Howells <dhowells@...hat.com>
Cc:	torvalds@...ux-foundation.org,
	"linux-cachefs@...hat.com" <linux-cachefs@...hat.com>,
	linux-kernel@...r.kernel.org,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	ceph-devel <ceph-devel@...r.kernel.org>
Subject: Re: [PATCH] FS-Cache: Fix handling of an attempt to store a page that
 is now beyond EOF

I hate to be that guy and keep bugging you guys. Can I get an
acknowledgment of the original patch? It fixed a very real issue for
fscache users that occurs semi-frequently under moderate concurrency.

- M

On Mon, Dec 16, 2013 at 12:20 PM, Milosz Tanski <milosz@...in.com> wrote:
> Hey guys it looks like this patch got lost in the shuffle. I checked
> out a recent kernel and learned this wasn't applied the hard way (by
> running into it).
>
> Can this please get applied to master as it fixes a real issue?
>
> Thanks,
> - Milosz
>
> On Mon, Nov 11, 2013 at 5:18 PM, David Howells <dhowells@...hat.com> wrote:
>> Fix the handling of an attempt to store a page that is now beyond EOF.  This
>> may happen, for example, if the page got pushed for storage before the netfs
>> file got truncated on the server.  In such a case, we should just remove the
>> excessive pages from the cookie->stores radix tree and wake up the waiter.
>>
>> This can be seen in /proc/fs/fscache/stats on this line:
>>
>>         Stores : ops=350 run=1895 pgs=1545 rxd=1727 olm=9
>>
>> where olm=N has N > 0.
>>
>> Reported-by: Milosz Tanski <milosz@...in.com>
>> Signed-off-by: David Howells <dhowells@...hat.com>
>> Acked-by: Milosz Tanski <milosz@...in.com>
>> ---
>>
>>  fs/fscache/page.c |   37 ++++++++++++++++++++++++++++++++++++-
>>  1 file changed, 36 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/fscache/page.c b/fs/fscache/page.c
>> index 7f5c658af755..b4730cf52aec 100644
>> --- a/fs/fscache/page.c
>> +++ b/fs/fscache/page.c
>> @@ -755,6 +755,7 @@ static void fscache_write_op(struct fscache_operation *_op)
>>         struct fscache_object *object = op->op.object;
>>         struct fscache_cookie *cookie;
>>         struct page *page;
>> +       pgoff_t index;
>>         unsigned n;
>>         void *results[1];
>>         int ret;
>> @@ -803,7 +804,7 @@ static void fscache_write_op(struct fscache_operation *_op)
>>         _debug("gang %d [%lx]", n, page->index);
>>         if (page->index > op->store_limit) {
>>                 fscache_stat(&fscache_n_store_pages_over_limit);
>> -               goto superseded;
>> +               goto page_beyond_limit;
>>         }
>>
>>         radix_tree_tag_set(&cookie->stores, page->index,
>> @@ -829,6 +830,40 @@ static void fscache_write_op(struct fscache_operation *_op)
>>         _leave("");
>>         return;
>>
>> +page_beyond_limit:
>> +       spin_unlock(&object->lock);
>> +
>> +page_beyond_limit_unlocked:
>> +       /* pages that are now beyond the end of the storage object must have
>> +        * their pending storage records cleared.
>> +        */
>> +       index = page->index;
>> +       radix_tree_tag_clear(&cookie->stores, page->index,
>> +                            FSCACHE_COOKIE_PENDING_TAG);
>> +       if (!radix_tree_tag_get(&cookie->stores, page->index,
>> +                               FSCACHE_COOKIE_STORING_TAG)) {
>> +               fscache_stat(&fscache_n_store_radix_deletes);
>> +               radix_tree_delete(&cookie->stores, page->index);
>> +               page_cache_release(page);
>> +       }
>> +       if (!need_resched()) {
>> +               n = radix_tree_gang_lookup_tag(&cookie->stores, results,
>> +                                              index + 1, 1,
>> +                                              FSCACHE_COOKIE_PENDING_TAG);
>> +               if (n == 1) {
>> +                       page = results[0];
>> +                       goto page_beyond_limit_unlocked;
>> +               }
>> +               spin_unlock(&cookie->stores_lock);
>> +               wake_up_bit(&cookie->flags, 0);
>> +       } else {
>> +               spin_unlock(&cookie->stores_lock);
>> +       }
>> +
>> +       fscache_enqueue_operation(&op->op);
>> +       _leave("");
>> +       return;
>> +
>>  superseded:
>>         /* this writer is going away and there aren't any more things to
>>          * write */
>>
>
>
>
> --
> Milosz Tanski
> CTO
> 10 East 53rd Street, 37th floor
> New York, NY 10022
>
> p: 646-253-9055
> e: milosz@...in.com



-- 
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022

p: 646-253-9055
e: milosz@...in.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/