linux-toradex.git/fs, branch v2.6.20.7

fix page leak during core dump

2007-04-13T20:47:18+00:00

When the dump cannot occur most likely because of a full file system and
the page to be written is the zero page, the call to page_cache_release()
is missed.

Signed-off-by: Brian Pomerantz 
Cc: Hugh Dickins 
Cc: Nick Piggin 
Cc: David Howells 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

revert "retries in ext4_prepare_write() violate ordering requirements"

2007-04-13T20:47:18+00:00

Revert b46be05004abb419e303e66e143eed9f8a6e9f3f.  Same reasoning as for ext3.

Cc: Kirill Korotaev 
Cc: Ingo Molnar 
Cc: Ken Chen 
Cc: Andrey Savochkin 
Cc: 
Cc: Dmitriy Monakhov 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

revert "retries in ext3_prepare_write() violate ordering requirements"

2007-04-13T20:47:18+00:00

Revert e92a4d595b464c4aae64be39ca61a9ffe9c8b278.

Dmitry points out

"When we block_prepare_write() failed while ext3_prepare_write() we jump to
 "failure" label and call ext3_prepare_failure() witch search last mapped bh
 and invoke commit_write untill it.  This is wrong!!  because some bh from
 begining to the last mapped bh may be not uptodate.  As a result we commit to
 disk not uptodate page content witch contains garbage from previous usage."

and

"Unexpected file size increasing."

   Call trace the same as it was in first issue but result is different. 
   For example we have file with i_size is zero.  we want write two blocks ,
   but fs has only one free block.

   ->ext3_prepare_write(...from == 0, to == 2048)
     retry:
     ->block_prepare_write() == -ENOSPC# we failed but allocated one block here.
     ->ext3_prepare_failure()
       ->commit_write( from == 0, to == 1024) # after this i_size becomes 1024 :)
     if (ret == -ENOSPC && ext3_should_retry_alloc(inode->i_sb, &retries))
        goto retry;

   Finally when all retries will be spended ext3_prepare_failure return
   -ENOSPC, but i_size was increased and later block trimm procedures can't
   help here.

We don't appear to have the horsepower to fix these issues, so let's put
things back the way they were for now.

Cc: Kirill Korotaev 
Cc: Ingo Molnar 
Cc: Ken Chen 
Cc: Andrey Savochkin 
Cc: 
Cc: Dmitriy Monakhov 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

knfsd: allow nfsd READDIR to return 64bit cookies

2007-04-13T20:47:17+00:00

From Neil Brown 

[PATCH] knfsd: allow nfsd READDIR to return 64bit cookies

->readdir passes lofft_t offsets (used as nfs cookies) to
nfs3svc_encode_entry{,_plus}, but when they pass it on to encode_entry it
becomes an 'off_t', which isn't good.

So filesystems that returned 64bit offsets would lose.

Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

CIFS: reset mode when client notices that ATTR_READONLY is no longer set

2007-04-06T10:43:17+00:00

[CIFS] reset mode when client notices that ATTR_READONLY is no longer set

[: removed changelog part of patch]

Cc: Chuck Ebbert 
Signed-off-by: Alan Tyso 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

CIFS: Allow reset of file to ATTR_NORMAL when archive bit not set

2007-04-06T10:43:16+00:00

[CIFS] Allow reset of file to ATTR_NORMAL when archive bit not set

When a file had a dos attribute of 0x1 (readonly - but dos attribute
of archive was not set) - doing chmod 0777 or equivalent would
try to set a dos attribute of 0 (which some servers ignore)
rather than ATTR_NORMAL (0x20) which most servers accept.
Does not affect servers which support the CIFS Unix Extensions.

[: removed changelog part of patch]

Cc: Chuck Ebbert 
Acked-by: Prasad Potluri 
Acked-by: Shirish Pargaonkar 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

nfs: nfs_getattr() can't call nfs_sync_mapping_range() for non-regular files

2007-03-23T19:49:23+00:00

Looks like we need a check in nfs_getattr() for a regular file. It makes
no sense to call nfs_sync_mapping_range() on anything else. I think that
should fix your problem: it will stop the NFS client from interfering
with dirty pages on that inode's mapping.

Signed-off-by: Trond Myklebust 
Acked-by: Olof Johansson 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

gfs2: fix locking mistake

2007-03-09T18:50:32+00:00

Fix a locking mistake in the quota code, we do a mutex_lock instead of a
mutex_unlock.

Signed-off-by: Josef Whiter 
Cc: Steven Whitehouse 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

buffer: memorder fix

2007-03-09T18:50:30+00:00

unlock_buffer(), like unlock_page(), must not clear the lock without
ensuring that the critical section is closed.


Mingming later sent the same patch, saying:

We are running SDET benchmark and saw double free issue for ext3 extended
attributes block, which complains the same xattr block already being freed (in
ext3_xattr_release_block()).  The problem could also been triggered by
multiple threads loop untar/rm a kernel tree.

The race is caused by missing a memory barrier at unlock_buffer() before the
lock bit being cleared, resulting in possible concurrent h_refcounter update. 
That causes a reference counter leak, then later leads to the double free that
we have seen.

Inside unlock_buffer(), there is a memory barrier is placed *after* the lock
bit is being cleared, however, there is no memory barrier *before* the bit is
cleared.  On some arch the h_refcount update instruction and the clear bit
instruction could be reordered, thus leave the critical section re-entered.

The race is like this: For example, if the h_refcount is initialized as 1,

cpu 0:                                   cpu1

hugetlb: preserve hugetlb pte dirty state

2007-03-09T18:50:30+00:00

__unmap_hugepage_range() is buggy that it does not preserve dirty state of
huge_pte when unmapping hugepage range.  It causes data corruption in the
event of dop_caches being used by sys admin.  For example, an application
creates a hugetlb file, modify pages, then unmap it.  While leaving the
hugetlb file alive, comes along sys admin doing a "echo 3 >
/proc/sys/vm/drop_caches".

drop_pagecache_sb() will happily free all pages that aren't marked dirty if
there are no active mapping.  Later when application remaps the hugetlb
file back and all data are gone, triggering catastrophic flip over on
application.

Not only that, the internal resv_huge_pages count will also get all messed
up.  Fix it up by marking page dirty appropriately.

Signed-off-by: Ken Chen 
Cc: "Nish Aravamudan" 
Cc: Adam Litke 
Cc: David Gibson 
Acked-by: William Irwin 
Cc: Hugh Dickins 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman