On Thu 16-05-19 21:17:14, Tetsuo Handa wrote:
> On 2019/05/16 20:48, Jan Kara wrote:
> > OK, so non-racy fix was a bit more involved and I've ended up just
> > upgrading the file reference to an exclusive one in loop_set_fd() instead
> > of trying to hand-craft some locking solution. The result is
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+10007d66ca02b08f0...@syzkaller.appspotmail.com
Tested on:
commit: e93c9c99 Linux 5.1
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
On 2019/05/15 19:21, Jan Kara wrote:
> The question is how to fix this problem. The simplest fix I can see is that
> we'd just refuse to do LOOP_SET_FD if someone has the block device
> exclusively open as there are high chances such user will be unpleasantly
> surprised by the device changing unde
Since lo_ioctl() is calling sb_set_blocksize() immediately after udf_load_vrs()
called sb_set_blocksize(), udf_tread() can't use expected i_blkbits settings...
[ 48.685672][ T7322] fs/block_dev.c:135 bdev=14fa0ec2 12 -> 9
[ 48.694675][ T7322] CPU: 4 PID: 7322 Comm: a.out Not tainted 5.
Hello, Jan.
syzbot is still reporting livelocks inside __getblk_gfp() [1] (similar to
commit 04906b2f542c2362 ("blockdev: Fix livelocks on loop device")).
[1]
https://syzkaller.appspot.com/bug?id=835a0b9e75b14b55112661cbc61ca8b8f0edf767
A debug printk() patch shown below revealed that since b
On 2019/05/01 0:34, Tetsuo Handa wrote:
> I still cannot understand what the problem is.
(...snipped...)
> I guessed that something went wrong with 8083 inside __getblk_gfp().
> How can loop_ctl_mutex be relevant to this problem?
>
syzbot got similar NMI backtrace. No loop_ctl_mutex is involved.
On 2019/05/01 0:07, Jan Kara wrote:
> Ah, right. I've missed that in your patch. So your patch should be really
> fixing the problem. Will you post it officially? Thanks!
I still cannot understand what the problem is.
According to console output,
--
INFO: task syz-executor274:8097 blocked
On Tue 30-04-19 14:18:21, Al Viro wrote:
> On Tue, Apr 30, 2019 at 03:07:39PM +0200, Jan Kara wrote:
> > On Tue 30-04-19 04:11:44, Al Viro wrote:
> > > On Tue, Apr 30, 2019 at 04:55:01AM +0200, Jan Kara wrote:
> > >
> > > > Yeah, you're right. And if we push the patch a bit further to not take
> >
On Tue, Apr 30, 2019 at 03:07:39PM +0200, Jan Kara wrote:
> On Tue 30-04-19 04:11:44, Al Viro wrote:
> > On Tue, Apr 30, 2019 at 04:55:01AM +0200, Jan Kara wrote:
> >
> > > Yeah, you're right. And if we push the patch a bit further to not take
> > > loop_ctl_mutex for invalid ioctl number, that wo
On Tue 30-04-19 04:11:44, Al Viro wrote:
> On Tue, Apr 30, 2019 at 04:55:01AM +0200, Jan Kara wrote:
>
> > Yeah, you're right. And if we push the patch a bit further to not take
> > loop_ctl_mutex for invalid ioctl number, that would fix the problem. I
> > can send a fix.
>
> Huh? We don't take
On Tue, Apr 30, 2019 at 04:55:01AM +0200, Jan Kara wrote:
> Yeah, you're right. And if we push the patch a bit further to not take
> loop_ctl_mutex for invalid ioctl number, that would fix the problem. I
> can send a fix.
Huh? We don't take it until in lo_simple_ioctl(), and that patch doesn't
g
On Sun 28-04-19 19:51:09, Al Viro wrote:
> On Sun, Apr 28, 2019 at 11:14:06AM -0700, syzbot wrote:
> > down_read+0x49/0x90 kernel/locking/rwsem.c:26
> > __get_super.part.0+0x203/0x2e0 fs/super.c:788
> > __get_super include/linux/spinlock.h:329 [inline]
> > get_super+0x2e/0x50 fs/super.c:817
> >
On Sun, Apr 28, 2019 at 8:51 PM Al Viro wrote:
>
> On Sun, Apr 28, 2019 at 11:14:06AM -0700, syzbot wrote:
> > down_read+0x49/0x90 kernel/locking/rwsem.c:26
> > __get_super.part.0+0x203/0x2e0 fs/super.c:788
> > __get_super include/linux/spinlock.h:329 [inline]
> > get_super+0x2e/0x50 fs/super.
On 2019/04/29 3:51, Al Viro wrote:
> ioctl(..., BLKRRPART) blocked on ->s_umount in __get_super().
> The trouble is, the only things holding ->s_umount appears to be
> these:
Not always true. lockdep_print_held_locks() from debug_show_all_locks() can not
report locks held by TASK_RUNNING threads.
On Sun, Apr 28, 2019 at 11:14:06AM -0700, syzbot wrote:
> down_read+0x49/0x90 kernel/locking/rwsem.c:26
> __get_super.part.0+0x203/0x2e0 fs/super.c:788
> __get_super include/linux/spinlock.h:329 [inline]
> get_super+0x2e/0x50 fs/super.c:817
> fsync_bdev+0x19/0xd0 fs/block_dev.c:525
> invalida
syzbot has found a reproducer for the following crash on:
HEAD commit:037904a2 Merge branch 'x86-urgent-for-linus' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=135ff034a0
kernel config: https://syzkaller.appspot.com/x/.config?x=a42d11
Dmitry Vyukov wrote:
> On Tue, Jun 19, 2018 at 4:10 PM, Tetsuo Handa
> wrote:
> > On 2018/06/19 20:53, Dmitry Vyukov wrote:
> >> On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
> >> wrote:
> >>> This bug report is getting no feedback, but I guess that this bug is in
> >>> block or mm or locking lay
On Tue, Jun 19, 2018 at 4:10 PM, Tetsuo Handa
wrote:
> On 2018/06/19 20:53, Dmitry Vyukov wrote:
>> On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
>> wrote:
>>> This bug report is getting no feedback, but I guess that this bug is in
>>> block or mm or locking layer rather than fs layer.
>>>
>>> NM
On 2018/06/19 20:53, Dmitry Vyukov wrote:
> On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
> wrote:
>> This bug report is getting no feedback, but I guess that this bug is in
>> block or mm or locking layer rather than fs layer.
>>
>> NMI backtrace for this bug tends to report that sb_bread() from
On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
wrote:
> This bug report is getting no feedback, but I guess that this bug is in
> block or mm or locking layer rather than fs layer.
>
> NMI backtrace for this bug tends to report that sb_bread() from fill_super()
> from mount_bdev() is stalling is t
This bug report is getting no feedback, but I guess that this bug is in
block or mm or locking layer rather than fs layer.
NMI backtrace for this bug tends to report that sb_bread() from fill_super()
from mount_bdev() is stalling is the cause of keep holding s_umount_key for
more than 120 seconds
Hello,
syzbot hit the following crash on upstream commit
10b84daddbec72c6b440216a69de9a9605127f7a (Sat Mar 31 17:59:00 2018 +)
Merge branch 'perf-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=10007
22 matches
Mail list logo
