3.16.65-rc1 review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.
The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
while still holding the xattr semaphore. This is
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.
The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
while still holding the xattr semaphore. This is
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.
The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
while still holding the xattr semaphore. This is
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.
The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
while still holding the xattr semaphore. This is
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.
The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
while still holding the xattr semaphore. This is
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.
The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
while still holding the xattr semaphore. This is
7.849058] [] do_mmap_pgoff+0x34e/0x3d0
>> >> [ 27.849070] [] vm_mmap_pgoff+0x90/0xc0
>> >> [ 27.849080] [] SyS_mmap_pgoff+0x1d5/0x270
>> >> [ 27.849092] [] ? syscall_trace_enter+0x145/0x270
>> >> [ 27.849102] [] SyS_mmap+0x22/0x30
>> >> [ 27.849112] [] trac
gt; [ 27.849102] [] SyS_mmap+0x22/0x30
> >> [ 27.849112] [] tracesys+0xe1/0xe6
> >>
> >>
> >> I think it is a real deadlock, and it is caused by commit
> >> 3124eb1679b28726 "sysfs: merge regular and bin file handling".
> >>
ith that commit, sysfs_bin_mmap will hold of->mutex.
>>
>> So assume cpu0 called sysfs_bin_mmap, acquired mmap_sem and trying
>> to get of->mutex.
>>
>> CPU1 called sysfs_seq_show, acqured of->mutex and trying to
>> get mddev->reconfig_mutex.
>>
>> CPU2
ith that commit, sysfs_bin_mmap will hold of->mutex.
>>
>> So assume cpu0 called sysfs_bin_mmap, acquired mmap_sem and trying
>> to get of->mutex.
>>
>> CPU1 called sysfs_seq_show, acqured of->mutex and trying to
>> get mddev->reconfig_mutex.
>>
>> CPU2
chset and many commits after that. But I do
> believe it's buggy and the root cause of my system hang.
>
> CPU0: CPU1:
> CPU2:
> lock(&mm->mmap_sem)
>
y system hang.
CPU0: CPU1:
CPU2:
lock(&mm->mmap_sem)
lock(&of->mutex);
lock(&mddev->reconfig_mutex)
Thanks for the remarks.
On 05/14/2013 01:32 PM, Ming Lei wrote:
> If the user buffer passed to driver A is mapped against file on the block
> device, single thread 1 may still deadlock on the mutex A.
Good point, thanks. It is unlikely to ever be a use case for us, but
still worth considering for
On Tue, May 14, 2013 at 2:13 AM, Dmitry Maluka wrote:
> Hi,
>
> Sometimes we run into an interesting deadlock on mm->mmap_sem. I see it
> is similar to these deadlocks:
>
> https://lkml.org/lkml/2005/2/22/123
> https://lkml.org/lkml/2001/9/17/105
>
> in the sense that it is too triggered by page f
Hi,
Sometimes we run into an interesting deadlock on mm->mmap_sem. I see it
is similar to these deadlocks:
https://lkml.org/lkml/2005/2/22/123
https://lkml.org/lkml/2001/9/17/105
in the sense that it is too triggered by page faults and is explained by
"fair" rwsem semantics (pending write lock b
15 matches
Mail list logo
