linux-kernel - Re: [RFC PATCH 0/2] Introduce unlocked version of igrab

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110328044334.GA1022@dastard>
Date:	Mon, 28 Mar 2011 15:43:34 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Ryan Mallon <ryan@...ewatersys.com>
Cc:	viro@...iv.linux.org.uk, dchinner@...hat.com,
	Trond.Myklebust@...app.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Introduce unlocked version of igrab

On Mon, Mar 28, 2011 at 02:55:59PM +1300, Ryan Mallon wrote:
> Commit 250df6ed274d767da844a5d9f05720b804240197 "fs: protect 
> inode->i_state with inode->i_lock" introduces a change to igrab to acquire
> inode->i_lock. 
> 
> This change causes a panic on boot on my ARM EP93xx board when the rootfs
> uses NFS. The problem occurs because nfs_inode_add_request acquires
> inode->i_lock and then calls igrab, resulting in the following panic:
> 
> BUG: spinlock recursion on CPU#0, getty/262
>  lock: cc421cb4, .magic: dead4ead, .owner: getty/262, .owner_cpu: 0
> [<c0031b0c>] (unwind_backtrace+0x0/0xe4) from [<c015f16c>] (do_raw_spin_lock+0x40/0x13c)
> [<c015f16c>] (do_raw_spin_lock+0x40/0x13c) from [<c00a938c>] (igrab+0x14/0x48)
> [<c00a938c>] (igrab+0x14/0x48) from [<c01186bc>] (nfs_updatepage+0x2e0/0x524)
> [<c01186bc>] (nfs_updatepage+0x2e0/0x524) from [<c010b19c>] (nfs_write_end+0x23c/0x270)
> [<c010b19c>] (nfs_write_end+0x23c/0x270) from [<c006b484>] (generic_file_buffered_write+0x180/0x248)
> [<c006b484>] (generic_file_buffered_write+0x180/0x248) from [<c006d060>] (__generic_file_aio_write+0x3b8/0x3f4)
> [<c006d060>] (__generic_file_aio_write+0x3b8/0x3f4) from [<c006d108>] (generic_file_aio_write+0x6c/0xdc)
> [<c006d108>] (generic_file_aio_write+0x6c/0xdc) from [<c010bce0>] (nfs_file_write+0xec/0x178)
> [<c010bce0>] (nfs_file_write+0xec/0x178) from [<c00956ac>] (do_sync_write+0xa4/0xe4)
> [<c00956ac>] (do_sync_write+0xa4/0xe4) from [<c00960c8>] (vfs_write+0xb4/0x12c)
> [<c00960c8>] (vfs_write+0xb4/0x12c) from [<c00961f0>] (sys_write+0x3c/0x68)
> [<c00961f0>] (sys_write+0x3c/0x68) from [<c002c8e0>] (ret_fast_syscall+0x0/0x2c)
> 
> This series introduces a new function called __igrab, which is an unlocked
> version of igrab and modifies nfs_inode_add_request to use the unlocked
> version.

It's called ihold() and already exists.

As it is, I thought I posted a igrab->ihold fix to lkml a couple of
days ago when this first came up. Trond then posted a better fix by
removingthe igrab() altoegther in the same thread.

Turns out, someone removed LKML from the cc list on the thread half
way through so neither of those patches made it to lkml.

Trond, can you push your fix for this (NFS: Fix a hang in the
writeback path) to Linus?

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.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/