linux-stable.git/fs, branch v4.4.4

hpfs: don't truncate the file when delete fails

2016-03-03T23:07:30+00:00

commit b6853f78e763d42c7a158d8de3549c9827c604ab upstream.

The delete opration can allocate additional space on the HPFS filesystem
due to btree split. The HPFS driver checks in advance if there is
available space, so that it won't corrupt the btree if we run out of space
during splitting.

If there is not enough available space, the HPFS driver attempted to
truncate the file, but this results in a deadlock since the commit
7dd29d8d865efdb00c0542a5d2c87af8c52ea6c7 ("HPFS: Introduce a global mutex
and lock it on every callback from VFS").

This patch removes the code that tries to truncate the file and -ENOSPC is
returned instead. If the user hits -ENOSPC on delete, he should try to
delete other files (that are stored in a leaf btree node), so that the
delete operation will make some space for deleting the file stored in
non-leaf btree node.

Reported-by: Al Viro 
Signed-off-by: Mikulas Patocka 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

do_last(): ELOOP failure exit should be done after leaving RCU mode

2016-03-03T23:07:30+00:00

commit 5129fa482b16615fd4464d2f5d23acb1b7056c66 upstream.

... or we risk seeing a bogus value of d_is_symlink() there.

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

should_follow_link(): validate ->d_seq after having decided to follow

2016-03-03T23:07:30+00:00

commit a7f775428b8f5808815c0e3004020cedb94cbe3b upstream.

... otherwise d_is_symlink() above might have nothing to do with
the inode value we've got.

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

do_last(): don't let a bogus return value from ->open() et.al. to confuse us

2016-03-03T23:07:29+00:00

commit c80567c82ae4814a41287618e315a60ecf513be6 upstream.

... into returning a positive to path_openat(), which would interpret that
as "symlink had been encountered" and proceed to corrupt memory, etc.
It can only happen due to a bug in some ->open() instance or in some LSM
hook, etc., so we report any such event *and* make sure it doesn't trick
us into further unpleasantness.

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

NFSv4: Fix a dentry leak on alias use

2016-03-03T23:07:28+00:00

commit d9dfd8d741683347ee159d25f5b50c346a0df557 upstream.

In the case where d_add_unique() finds an appropriate alias to use it will
have already incremented the reference count.  An additional dget() to swap
the open context's dentry is unnecessary and will leak a reference.

Signed-off-by: Benjamin Coddington 
Fixes: 275bb307865a3 ("NFSv4: Move dentry instantiation into the NFSv4-...")
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

block: fix use-after-free in dio_bio_complete

2016-03-03T23:07:28+00:00

commit 7ddc971f86aa0a4cee9f6886c356a052461957ae upstream.

kasan reported the following error when i ran xfstest:

[  701.826854] ==================================================================
[  701.826864] BUG: KASAN: use-after-free in dio_bio_complete+0x41a/0x600 at addr ffff880080b95f94
[  701.826870] Read of size 4 by task loop2/3874
[  701.826879] page:ffffea000202e540 count:0 mapcount:0 mapping:          (null) index:0x0
[  701.826890] flags: 0x100000000000000()
[  701.826895] page dumped because: kasan: bad access detected
[  701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: G    B   W    L  4.5.0-rc1-next-20160129 #83
[  701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[  701.826917]  ffff88008fadf800 ffff88008fadf758 ffffffff81ca67bb 0000000041b58ab3
[  701.826941]  ffffffff830d1e74 ffffffff81ca6724 ffff88008fadf748 ffffffff8161c05c
[  701.826963]  0000000000000282 ffff88008fadf800 ffffed0010172bf2 ffffea000202e540
[  701.826987] Call Trace:
[  701.826997]  [] dump_stack+0x97/0xdc
[  701.827005]  [] ? _atomic_dec_and_lock+0xc4/0xc4
[  701.827014]  [] ? __dump_page+0x32c/0x490
[  701.827023]  [] kasan_report_error+0x5f3/0x8b0
[  701.827033]  [] ? dio_bio_complete+0x41a/0x600
[  701.827040]  [] __asan_report_load4_noabort+0x59/0x80
[  701.827048]  [] ? dio_bio_complete+0x41a/0x600
[  701.827053]  [] dio_bio_complete+0x41a/0x600
[  701.827057]  [] ? blk_queue_exit+0x108/0x270
[  701.827060]  [] dio_bio_end_aio+0xa0/0x4d0
[  701.827063]  [] ? dio_bio_complete+0x600/0x600
[  701.827067]  [] ? blk_account_io_completion+0x316/0x5d0
[  701.827070]  [] bio_endio+0x79/0x200
[  701.827074]  [] blk_update_request+0x1df/0xc50
[  701.827078]  [] blk_mq_end_request+0x57/0x120
[  701.827081]  [] __blk_mq_complete_request+0x310/0x590
[  701.827084]  [] ? set_next_entity+0x2f8/0x2ed0
[  701.827088]  [] ? put_prev_entity+0x22d/0x2a70
[  701.827091]  [] blk_mq_complete_request+0x5b/0x80
[  701.827094]  [] loop_queue_work+0x273/0x19d0
[  701.827098]  [] ? finish_task_switch+0x1c8/0x8e0
[  701.827101]  [] ? trace_hardirqs_on_caller+0x18/0x6c0
[  701.827104]  [] ? lo_read_simple+0x890/0x890
[  701.827108]  [] ? debug_check_no_locks_freed+0x350/0x350
[  701.827111]  [] ? __hrtick_start+0x130/0x130
[  701.827115]  [] ? __schedule+0x936/0x20b0
[  701.827118]  [] ? kthread_worker_fn+0x3ed/0x8d0
[  701.827121]  [] ? kthread_worker_fn+0x21d/0x8d0
[  701.827125]  [] ? trace_hardirqs_on_caller+0x18/0x6c0
[  701.827128]  [] kthread_worker_fn+0x2af/0x8d0
[  701.827132]  [] ? __init_kthread_worker+0x170/0x170
[  701.827135]  [] ? _raw_spin_unlock_irqrestore+0x36/0x60
[  701.827138]  [] ? __init_kthread_worker+0x170/0x170
[  701.827141]  [] ? __init_kthread_worker+0x170/0x170
[  701.827144]  [] kthread+0x24b/0x3a0
[  701.827148]  [] ? kthread_create_on_node+0x4c0/0x4c0
[  701.827151]  [] ? trace_hardirqs_on+0xd/0x10
[  701.827155]  [] ? do_group_exit+0xdd/0x350
[  701.827158]  [] ? kthread_create_on_node+0x4c0/0x4c0
[  701.827161]  [] ret_from_fork+0x3f/0x70
[  701.827165]  [] ? kthread_create_on_node+0x4c0/0x4c0
[  701.827167] Memory state around the buggy address:
[  701.827170]  ffff880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827172]  ffff880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827175] >ffff880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827177]                          ^
[  701.827179]  ffff880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827182]  ffff880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827183] ==================================================================

The problem is that bio_check_pages_dirty calls bio_put, so we must
not access bio fields after bio_check_pages_dirty.

Fixes: 9b81c842355ac96097ba ("block: don't access bio->bi_error after bio_put()").
Signed-off-by: Mike Krinkin 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

writeback: keep superblock pinned during cgroup writeback association switches

2016-03-03T23:07:28+00:00

commit 5ff8eaac1636bf6deae86491f4818c4c69d1a9ac upstream.

If cgroup writeback is in use, an inode is associated with a cgroup
for writeback.  If the inode's main dirtier changes to another cgroup,
the association gets updated asynchronously.  Nothing was pinning the
superblock while such switches are in progress and superblock could go
away while async switching is pending or in progress leading to
crashes like the following.

 kernel BUG at fs/jbd2/transaction.c:319!
 invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
 CPU: 1 PID: 29158 Comm: kworker/1:10 Not tainted 4.5.0-rc3 #51
 Hardware name: Google Google, BIOS Google 01/01/2011
 Workqueue: events inode_switch_wbs_work_fn
 task: ffff880213dbbd40 ti: ffff880209264000 task.ti: ffff880209264000
 RIP: 0010:[]  [] start_this_handle+0x382/0x3e0
 RSP: 0018:ffff880209267c30  EFLAGS: 00010202
 ...
 Call Trace:
  [] jbd2__journal_start+0xf4/0x190
  [] __ext4_journal_start_sb+0x4e/0x70
  [] ext4_evict_inode+0x12c/0x3d0
  [] evict+0xbb/0x190
  [] iput+0x130/0x190
  [] inode_switch_wbs_work_fn+0x343/0x4c0
  [] process_one_work+0x129/0x300
  [] worker_thread+0x126/0x480
  [] kthread+0xc4/0xe0
  [] ret_from_fork+0x3f/0x70

Fix it by bumping s_active while cgroup association switching is in
flight.

Signed-off-by: Tejun Heo 
Reported-and-tested-by: Tahsin Erdogan 
Link: http://lkml.kernel.org/g/CAAeU0aNCq7LGODvVGRU-oU_o-6enii5ey0p1c26D1ZzYwkDc5A@mail.gmail.com
Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching")
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

namei: ->d_inode of a pinned dentry is stable only for positives

2016-03-03T23:07:13+00:00

commit d4565649b6d6923369112758212b851adc407f0c upstream.

both do_last() and walk_component() risk picking a NULL inode out
of dentry about to become positive, *then* checking its flags and
seeing that it's not negative anymore and using (already stale by
then) value they'd fetched earlier.  Usually ends up oopsing soon
after that...

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

locks: fix unlock when fcntl_setlk races with a close

2016-03-03T23:07:12+00:00

commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 upstream.

Dmitry reported that he was able to reproduce the WARN_ON_ONCE that
fires in locks_free_lock_context when the flc_posix list isn't empty.

The problem turns out to be that we're basically rebuilding the
file_lock from scratch in fcntl_setlk when we discover that the setlk
has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END,
then we may end up with fl_start and fl_end values that differ from
when the lock was initially set, if the file position or length of the
file has changed in the interim.

Fix this by just reusing the same lock request structure, and simply
override fl_type value with F_UNLCK as appropriate. That ensures that
we really are unlocking the lock that was initially set.

While we're there, make sure that we do pop a WARN_ON_ONCE if the
removal ever fails. Also return -EBADF in this event, since that's
what we would have returned if the close had happened earlier.

Cc: Alexander Viro 
Fixes: c293621bbf67 (stale POSIX lock handling)
Reported-by: Dmitry Vyukov 
Signed-off-by: Jeff Layton 
Acked-by: "J. Bruce Fields" 
Signed-off-by: Greg Kroah-Hartman

uml: fix hostfs mknod()

2016-03-03T23:07:12+00:00

commit 9f2dfda2f2f1c6181c3732c16b85c59ab2d195e0 upstream.

An inverted return value check in hostfs_mknod() caused the function
to return success after handling it as an error (and cleaning up).

It resulted in the following segfault when trying to bind() a named
unix socket:

  Pid: 198, comm: a.out Not tainted 4.4.0-rc4
  RIP: 0033:[<0000000061077df6>]
  RSP: 00000000daae5d60  EFLAGS: 00010202
  RAX: 0000000000000000 RBX: 000000006092a460 RCX: 00000000dfc54208
  RDX: 0000000061073ef1 RSI: 0000000000000070 RDI: 00000000e027d600
  RBP: 00000000daae5de0 R08: 00000000da980ac0 R09: 0000000000000000
  R10: 0000000000000003 R11: 00007fb1ae08f72a R12: 0000000000000000
  R13: 000000006092a460 R14: 00000000daaa97c0 R15: 00000000daaa9a88
  Kernel panic - not syncing: Kernel mode fault at addr 0x40, ip 0x61077df6
  CPU: 0 PID: 198 Comm: a.out Not tainted 4.4.0-rc4 #1
  Stack:
   e027d620 dfc54208 0000006f da981398
   61bee000 0000c1ed daae5de0 0000006e
   e027d620 dfcd4208 00000005 6092a460
  Call Trace:
   [<60dedc67>] SyS_bind+0xf7/0x110
   [<600587be>] handle_syscall+0x7e/0x80
   [<60066ad7>] userspace+0x3e7/0x4e0
   [<6006321f>] ? save_registers+0x1f/0x40
   [<6006c88e>] ? arch_prctl+0x1be/0x1f0
   [<60054985>] fork_handler+0x85/0x90

Let's also get rid of the "cosmic ray protection" while we're at it.

Fixes: e9193059b1b3 "hostfs: fix races in dentry_name() and inode_name()"
Signed-off-by: Vegard Nossum 
Cc: Jeff Dike 
Cc: Al Viro 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman