linux-stable.git/fs, branch v3.11.8

seq_file: always update file->f_pos in seq_lseek()

2013-11-13T03:08:12+00:00

commit 05e16745c0c471bba313961b605b6da3b21a853d upstream.

This issue was first pointed out by Jiaxing Wang several months ago, but no
further comments:
https://lkml.org/lkml/2013/6/29/41

As we know pread() does not change f_pos, so after pread(), file->f_pos
and m->read_pos become different. And seq_lseek() does not update file->f_pos
if offset equals to m->read_pos, so after pread() and seq_lseek()(lseek to
m->read_pos), then a subsequent read may read from a wrong position, the
following program produces the problem:

    char str1[32] = { 0 };
    char str2[32] = { 0 };
    int poffset = 10;
    int count = 20;

    /*open any seq file*/
    int fd = open("/proc/modules", O_RDONLY);

    pread(fd, str1, count, poffset);
    printf("pread:%s\n", str1);

    /*seek to where m->read_pos is*/
    lseek(fd, poffset+count, SEEK_SET);

    /*supposed to read from poffset+count, but this read from position 0*/
    read(fd, str2, count);
    printf("read:%s\n", str2);

out put:
pread:
 ck_netbios_ns 12665
read:
 nf_conntrack_netbios

/proc/modules:
nf_conntrack_netbios_ns 12665 0 - Live 0xffffffffa038b000
nf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0xffffffffa0386000

So we always update file->f_pos to offset in seq_lseek() to fix this issue.

Signed-off-by: Jiaxing Wang 
Signed-off-by: Gu Zheng 
Signed-off-by: Al Viro 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

mm: /proc/pid/pagemap: inspect _PAGE_SOFT_DIRTY only on present pages

2013-11-13T03:08:11+00:00

commit e9cdd6e771580e6ff872e5c64e8b766972c7d1bc upstream.

If a page we are inspecting is in swap we may occasionally report it as
having soft dirty bit (even if it is clean).  The pte_soft_dirty helper
should be called on present pte only.

Signed-off-by: Cyrill Gorcunov 
Cc: Pavel Emelyanov 
Cc: Andy Lutomirski 
Cc: Matt Mackall 
Cc: Xiao Guangrong 
Cc: Marcelo Tosatti 
Cc: KOSAKI Motohiro 
Cc: Stephen Rothwell 
Cc: Peter Zijlstra 
Cc: "Aneesh Kumar K.V" 
Reviewed-by: Naoya Horiguchi 
Cc: Mel Gorman 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Revert "select: use freezable blocking call"

2013-11-13T03:08:08+00:00

commit 59612d187912750f416fbffe0c00bc0811c54ab5 upstream.

This reverts commit 9745cdb36da8 (select: use freezable blocking call)
that triggers problems during resume from suspend to RAM on Paul Bolle's
32-bit x86 machines.  Paul says:

  Ever since I tried running (release candidates of) v3.11 on the two
  working i686s I still have lying around I ran into issues on resuming
  from suspend. Reverting 9745cdb36da8 (select: use freezable blocking
  call) resolves those issues.

  Resuming from suspend on i686 on (release candidates of) v3.11 and
  later triggers issues like:

  traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b0000]

  and

  traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000]

  Once I hit the systemd error I can only get out of the mess that the
  system is at that point by power cycling it.

Since we are reverting another freezer-related change causing similar
problems to happen, this one should be reverted as well.

References: https://lkml.org/lkml/2013/10/29/583
Reported-by: Paul Bolle 
Fixes: 9745cdb36da8 (select: use freezable blocking call)
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Revert "epoll: use freezable blocking call"

2013-11-13T03:08:08+00:00

commit c511851de162e8ec03d62e7d7feecbdf590d881d upstream.

This reverts commit 1c441e921201 (epoll: use freezable blocking call)
which is reported to cause user space memory corruption to happen
after suspend to RAM.

Since it appears to be extremely difficult to root cause this
problem, it is best to revert the offending commit and try to address
the original issue in a better way later.

References: https://bugzilla.kernel.org/show_bug.cgi?id=61781
Reported-by: Natrio 
Reported-by: Jeff Pohlmeyer 
Bisected-by: Leo Wolf 
Fixes: 1c441e921201 (epoll: use freezable blocking call)
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: fix 32 bit corruption issue

2013-11-13T03:08:08+00:00

commit 43b7c6c6a4e3916edd186ceb61be0c67d1e0969e upstream.

Shifting page->index on 32 bit systems was overflowing, causing
data corruption of > 4GB files. Fix this by casting it first.

https://launchpad.net/bugs/1243636

Signed-off-by: Colin Ian King 
Reported-by: Lars Duesing 
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

ecryptfs: Fix memory leakage in keystore.c

2013-11-13T03:08:08+00:00

commit 3edc8376c06133e3386265a824869cad03a4efd4 upstream.

In 'decrypt_pki_encrypted_session_key' function:

Initializes 'payload' pointer and releases it on exit.

Signed-off-by: Geyslan G. Bem 
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

jfs: fix error path in ialloc

2013-11-13T03:08:08+00:00

commit 8660998608cfa1077e560034db81885af8e1e885 upstream.

If insert_inode_locked() fails, we shouldn't be calling
unlock_new_inode().

Signed-off-by: Dave Kleikamp 
Tested-by: Michael L. Semon 
Signed-off-by: Greg Kroah-Hartman

cifs: Fix inability to write files >2GB to SMB2/3 shares

2013-11-13T03:08:06+00:00

commit 2f6c9479633780ba4a3484bba7eba5a721a5cf20 upstream.

When connecting to SMB2/3 shares, maximum file size is set to non-LFS maximum in superblock. This is due to cap_large_files bit being different for SMB1 and SMB2/3 (where it is just an internal flag that is not negotiated and the SMB1 one corresponds to multichannel capability, so maybe LFS works correctly if server sends 0x08 flag) while capabilities are checked always for the SMB1 bit in cifs_read_super().

The patch fixes this by checking for the correct bit according to the protocol version.

Signed-off-by: Jan Klos 
Reviewed-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

ext[34]: fix double put in tmpfile

2013-11-04T12:35:19+00:00

commit 43ae9e3fc70ca0057ae0a24ef5eedff05e3fae06 upstream.

d_tmpfile() already swallowed the inode ref.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

ext4: fix memory leak in xattr

2013-10-18T17:54:55+00:00

commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.

If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations.  If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.

Spotted with Coverity.

[ Fixed by tytso to set is and bs to NULL after freeing these
  pointers, in case in the retry loop we later end up triggering an
  error causing a jump to cleanup, at which point we could have a double
  free bug. -- Ted ]

Signed-off-by: Dave Jones 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Eric Sandeen 
Signed-off-by: Greg Kroah-Hartman