From 13d518074a952d33d47c428419693f63389547e9 Mon Sep 17 00:00:00 2001 From: Jason Baron Date: Wed, 25 Apr 2012 16:01:47 -0700 Subject: epoll: clear the tfile_check_list on -ELOOP An epoll_ctl(,EPOLL_CTL_ADD,,) operation can return '-ELOOP' to prevent circular epoll dependencies from being created. However, in that case we do not properly clear the 'tfile_check_list'. Thus, add a call to clear_tfile_check_list() for the -ELOOP case. Signed-off-by: Jason Baron Reported-by: Yurij M. Plotnikov Cc: Nelson Elhage Cc: Davide Libenzi Tested-by: Alexandra N. Kossovsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- fs/eventpoll.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'fs') diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 739b0985b398..c0b3c70ee87a 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1663,8 +1663,10 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd, if (op == EPOLL_CTL_ADD) { if (is_file_epoll(tfile)) { error = -ELOOP; - if (ep_loop_check(ep, tfile) != 0) + if (ep_loop_check(ep, tfile) != 0) { + clear_tfile_check_list(); goto error_tgt_fput; + } } else list_add(&tfile->f_tfile_llink, &tfile_check_list); } -- cgit From 61065a30af8df4b8989c2ac7a1f4b4034e4df2d5 Mon Sep 17 00:00:00 2001 From: Glauber Costa Date: Wed, 25 Apr 2012 16:01:48 -0700 Subject: fs/buffer.c: remove BUG() in possible but rare condition While stressing the kernel with with failing allocations today, I hit the following chain of events: alloc_page_buffers(): bh = alloc_buffer_head(GFP_NOFS); if (!bh) goto no_grow; <= path taken grow_dev_page(): bh = alloc_page_buffers(page, size, 0); if (!bh) goto failed; <= taken, consequence of the above and then the failed path BUG()s the kernel. The failure is inserted a litte bit artificially, but even then, I see no reason why it should be deemed impossible in a real box. Even though this is not a condition that we expect to see around every time, failed allocations are expected to be handled, and BUG() sounds just too much. As a matter of fact, grow_dev_page() can return NULL just fine in other circumstances, so I propose we just remove it, then. Signed-off-by: Glauber Costa Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- fs/buffer.c | 1 - 1 file changed, 1 deletion(-) (limited to 'fs') diff --git a/fs/buffer.c b/fs/buffer.c index 36d66653b931..351e18ea2e53 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -985,7 +985,6 @@ grow_dev_page(struct block_device *bdev, sector_t block, return page; failed: - BUG(); unlock_page(page); page_cache_release(page); return NULL; -- cgit From 65ed76010dfed3cb75c863c9052c367a1bacf80a Mon Sep 17 00:00:00 2001 From: "Aneesh Kumar K.V" Date: Wed, 25 Apr 2012 16:01:50 -0700 Subject: hugetlbfs: lockdep annotate root inode properly This fixes the below reported false lockdep warning. e096d0c7e2e4 ("lockdep: Add helper function for dir vs file i_mutex annotation") added a similar annotation for every other inode in hugetlbfs but missed the root inode because it was allocated by a separate function. For HugeTLB fs we allow taking i_mutex in mmap. HugeTLB fs doesn't support file write and its file read callback is modified in a05b0855fd ("hugetlbfs: avoid taking i_mutex from hugetlbfs_read()") to not take i_mutex. Hence for HugeTLB fs with regular files we really don't take i_mutex with mmap_sem held. ====================================================== [ INFO: possible circular locking dependency detected ] 3.4.0-rc1+ #322 Not tainted ------------------------------------------------------- bash/1572 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [] might_fault+0x40/0x90 but task is already holding lock: (&sb->s_type->i_mutex_key#12){+.+.+.}, at: [] vfs_readdir+0x56/0xa8 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sb->s_type->i_mutex_key#12){+.+.+.}: [] lock_acquire+0xd5/0xfa [] __mutex_lock_common+0x48/0x350 [] mutex_lock_nested+0x2a/0x31 [] hugetlbfs_file_mmap+0x7d/0x104 [] mmap_region+0x272/0x47d [] do_mmap_pgoff+0x294/0x2ee [] sys_mmap_pgoff+0xd2/0x10e [] sys_mmap+0x1d/0x1f [] system_call_fastpath+0x16/0x1b -> #0 (&mm->mmap_sem){++++++}: [] __lock_acquire+0xa81/0xd75 [] lock_acquire+0xd5/0xfa [] might_fault+0x6d/0x90 [] filldir+0x6a/0xc2 [] dcache_readdir+0x5c/0x222 [] vfs_readdir+0x76/0xa8 [] sys_getdents+0x79/0xc9 [] system_call_fastpath+0x16/0x1b other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sb->s_type->i_mutex_key#12); lock(&mm->mmap_sem); lock(&sb->s_type->i_mutex_key#12); lock(&mm->mmap_sem); *** DEADLOCK *** 1 lock held by bash/1572: #0: (&sb->s_type->i_mutex_key#12){+.+.+.}, at: [] vfs_readdir+0x56/0xa8 stack backtrace: Pid: 1572, comm: bash Not tainted 3.4.0-rc1+ #322 Call Trace: [] print_circular_bug+0x1f8/0x209 [] __lock_acquire+0xa81/0xd75 [] ? handle_pte_fault+0x5ff/0x614 [] ? mark_lock+0x2d/0x258 [] ? might_fault+0x40/0x90 [] lock_acquire+0xd5/0xfa [] ? might_fault+0x40/0x90 [] ? __mutex_lock_common+0x333/0x350 [] might_fault+0x6d/0x90 [] ? might_fault+0x40/0x90 [] filldir+0x6a/0xc2 [] dcache_readdir+0x5c/0x222 [] ? sys_ioctl+0x74/0x74 [] ? sys_ioctl+0x74/0x74 [] ? sys_ioctl+0x74/0x74 [] vfs_readdir+0x76/0xa8 [] sys_getdents+0x79/0xc9 [] system_call_fastpath+0x16/0x1b Signed-off-by: Aneesh Kumar K.V Cc: Dave Jones Cc: Al Viro Cc: Josh Boyer Cc: Peter Zijlstra Cc: Mimi Zohar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- fs/hugetlbfs/inode.c | 1 + 1 file changed, 1 insertion(+) (limited to 'fs') diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 28cf06e4ec84..001ef01d2fe2 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -485,6 +485,7 @@ static struct inode *hugetlbfs_get_root(struct super_block *sb, inode->i_fop = &simple_dir_operations; /* directory inodes start off with i_nlink == 2 (for "." entry) */ inc_nlink(inode); + lockdep_annotate_inode_mutex_key(inode); } return inode; } -- cgit From 63f61a6f4633ff34c17bea7a0ed827eaeb0733e1 Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Wed, 25 Apr 2012 16:01:52 -0700 Subject: revert "proc: clear_refs: do not clear reserved pages" Revert commit 85e72aa5384 ("proc: clear_refs: do not clear reserved pages"), which was a quick fix suitable for -stable until ARM had been moved over to the gate_vma mechanism: https://lkml.org/lkml/2012/1/14/55 With commit f9d4861f ("ARM: 7294/1: vectors: use gate_vma for vectors user mapping"), ARM does now use the gate_vma, so the PageReserved check can be removed from the proc code. Signed-off-by: Will Deacon Cc: Nicolas Pitre Acked-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- fs/proc/task_mmu.c | 3 --- 1 file changed, 3 deletions(-) (limited to 'fs') diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 2b9a7607cbd5..2d60492d6df8 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -597,9 +597,6 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr, if (!page) continue; - if (PageReserved(page)) - continue; - /* Clear accessed and referenced bits. */ ptep_test_and_clear_young(vma, addr, pte); ClearPageReferenced(page); -- cgit