syzbot suspects this issue was fixed by commit:
commit 6f861765464f43a71462d52026fbddfc858239a5
Author: Jan Kara <[email protected]>
Date: Wed Nov 1 17:43:10 2023 +0000
fs: Block writes to mounted block devices
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
start commit: 2ccdd1b13c59 Linux 6.5-rc6
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
If the result looks correct, please mark the issue as fixed by replying with:
#syz fix: fs: Block writes to mounted block devices
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit 6f861765464f43a71462d52026fbddfc858239a5
> Author: Jan Kara <[email protected]>
> Date: Wed Nov 1 17:43:10 2023 +0000
>
> fs: Block writes to mounted block devices
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> start commit: 2ccdd1b13c59 Linux 6.5-rc6
> git tree: upstream
> kernel config: https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
>
> If the result looks correct, please mark the issue as fixed by replying with:
#syz fix: fs: Block writes to mounted block devices
On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <[email protected]> wrote:
>
> On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > syzbot suspects this issue was fixed by commit:
> >
> > commit 6f861765464f43a71462d52026fbddfc858239a5
> > Author: Jan Kara <[email protected]>
> > Date: Wed Nov 1 17:43:10 2023 +0000
> >
> > fs: Block writes to mounted block devices
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > start commit: 2ccdd1b13c59 Linux 6.5-rc6
> > git tree: upstream
> > kernel config: https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> >
> > If the result looks correct, please mark the issue as fixed by replying with:
>
> #syz fix: fs: Block writes to mounted block devices
Like Dave replied a few days ago, I'm kind of skeptical on all of these
bugs being closed by this change. I'm guessing that they are all
resolved now because a) the block writes while mounted option was set to
Y, and b) the actual bug is just masked by that.
Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
really fixed, and what happens if someone doesn't turn on that option?
If it's required, perhaps it should not be an option at all? Though
that'd seem to be likely to break some funky use cases, whether they are
valid or not.
--
Jens Axboe
On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <[email protected]> wrote:
> >
> > On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > > syzbot suspects this issue was fixed by commit:
> > >
> > > commit 6f861765464f43a71462d52026fbddfc858239a5
> > > Author: Jan Kara <[email protected]>
> > > Date: Wed Nov 1 17:43:10 2023 +0000
> > >
> > > fs: Block writes to mounted block devices
> > >
> > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > > start commit: 2ccdd1b13c59 Linux 6.5-rc6
> > > git tree: upstream
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> > >
> > > If the result looks correct, please mark the issue as fixed by replying with:
> >
> > #syz fix: fs: Block writes to mounted block devices
>
> Like Dave replied a few days ago, I'm kind of skeptical on all of these
> bugs being closed by this change. I'm guessing that they are all
> resolved now because a) the block writes while mounted option was set to
> Y, and b) the actual bug is just masked by that.
>
> Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> really fixed, and what happens if someone doesn't turn on that option?
> If it's required, perhaps it should not be an option at all? Though
> that'd seem to be likely to break some funky use cases, whether they are
> valid or not.
We have no way of actually testing or verifying this stuff and a lot of
these have been around for a long time. For example, this report here
has a C reproducer but following the actual dashboard link that
reproducer is striked-through which supposedly means that it isn't valid
or reliable. And no other reproducer ever showed up.
As far as I can see we should just close reports such as. If this is a
real bug that is separate from the ability to mount to writed block
devices then one should hope that syzbot finds another reproducer that
let's us really analyze the bug?
A separate issue is that syzbot keeps suggesting as all of these being
closable because of this. So how serious can we take this and how much
time can/should we spend given that we got ~20 or more of these mails in
the last two weeks or so.
I have no better answers than this tbh. And fwiw, apart from this one I
haven't closed a single bug based on this.
And yes, ideally the ability to write to mounted block devices should be
turned off. But we'll have to let it trickle into the individual
distributions first and make remaining userspace tools that rely on this
move to alternate apis before we can make any serious effort.
On 1/25/24 9:47 AM, Christian Brauner wrote:
> On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
>> On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <[email protected]> wrote:
>>>
>>> On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
>>>> syzbot suspects this issue was fixed by commit:
>>>>
>>>> commit 6f861765464f43a71462d52026fbddfc858239a5
>>>> Author: Jan Kara <[email protected]>
>>>> Date: Wed Nov 1 17:43:10 2023 +0000
>>>>
>>>> fs: Block writes to mounted block devices
>>>>
>>>> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
>>>> start commit: 2ccdd1b13c59 Linux 6.5-rc6
>>>> git tree: upstream
>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
>>>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
>>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
>>>>
>>>> If the result looks correct, please mark the issue as fixed by replying with:
>>>
>>> #syz fix: fs: Block writes to mounted block devices
>>
>> Like Dave replied a few days ago, I'm kind of skeptical on all of these
>> bugs being closed by this change. I'm guessing that they are all
>> resolved now because a) the block writes while mounted option was set to
>> Y, and b) the actual bug is just masked by that.
>>
>> Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
>> really fixed, and what happens if someone doesn't turn on that option?
>> If it's required, perhaps it should not be an option at all? Though
>> that'd seem to be likely to break some funky use cases, whether they are
>> valid or not.
>
> We have no way of actually testing or verifying this stuff and a lot of
> these have been around for a long time. For example, this report here
> has a C reproducer but following the actual dashboard link that
> reproducer is striked-through which supposedly means that it isn't valid
> or reliable. And no other reproducer ever showed up.
>
> As far as I can see we should just close reports such as. If this is a
> real bug that is separate from the ability to mount to writed block
> devices then one should hope that syzbot finds another reproducer that
> let's us really analyze the bug?
>
> A separate issue is that syzbot keeps suggesting as all of these being
> closable because of this. So how serious can we take this and how much
> time can/should we spend given that we got ~20 or more of these mails in
> the last two weeks or so.
>
> I have no better answers than this tbh. And fwiw, apart from this one I
> haven't closed a single bug based on this.
Oh yeah, it wasn't directed at you specifically, just the overall class
of bugs that get closed due to this in general.
> And yes, ideally the ability to write to mounted block devices should be
> turned off. But we'll have to let it trickle into the individual
> distributions first and make remaining userspace tools that rely on this
> move to alternate apis before we can make any serious effort.
Hopefully it's all fine on the distro front and we can just make it the
default some years from now. May even make sense to backport some of
this to stable and get it in their hands faster?
--
Jens Axboe
On Thu, Jan 25, 2024 at 09:51:43AM -0700, Jens Axboe wrote:
> On 1/25/24 9:47 AM, Christian Brauner wrote:
> > On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> >> On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <[email protected]> wrote:
> >>>
> >>> On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> >>>> syzbot suspects this issue was fixed by commit:
> >>>>
> >>>> commit 6f861765464f43a71462d52026fbddfc858239a5
> >>>> Author: Jan Kara <[email protected]>
> >>>> Date: Wed Nov 1 17:43:10 2023 +0000
> >>>>
> >>>> fs: Block writes to mounted block devices
> >>>>
> >>>> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> >>>> start commit: 2ccdd1b13c59 Linux 6.5-rc6
> >>>> git tree: upstream
> >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> >>>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> >>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> >>>>
> >>>> If the result looks correct, please mark the issue as fixed by replying with:
> >>>
> >>> #syz fix: fs: Block writes to mounted block devices
> >>
> >> Like Dave replied a few days ago, I'm kind of skeptical on all of these
> >> bugs being closed by this change. I'm guessing that they are all
> >> resolved now because a) the block writes while mounted option was set to
> >> Y, and b) the actual bug is just masked by that.
> >>
> >> Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> >> really fixed, and what happens if someone doesn't turn on that option?
> >> If it's required, perhaps it should not be an option at all? Though
> >> that'd seem to be likely to break some funky use cases, whether they are
> >> valid or not.
> >
> > We have no way of actually testing or verifying this stuff and a lot of
> > these have been around for a long time. For example, this report here
> > has a C reproducer but following the actual dashboard link that
> > reproducer is striked-through which supposedly means that it isn't valid
> > or reliable. And no other reproducer ever showed up.
> >
> > As far as I can see we should just close reports such as. If this is a
> > real bug that is separate from the ability to mount to writed block
> > devices then one should hope that syzbot finds another reproducer that
> > let's us really analyze the bug?
> >
> > A separate issue is that syzbot keeps suggesting as all of these being
> > closable because of this. So how serious can we take this and how much
> > time can/should we spend given that we got ~20 or more of these mails in
> > the last two weeks or so.
> >
> > I have no better answers than this tbh. And fwiw, apart from this one I
> > haven't closed a single bug based on this.
>
> Oh yeah, it wasn't directed at you specifically, just the overall class
> of bugs that get closed due to this in general.
>
> > And yes, ideally the ability to write to mounted block devices should be
> > turned off. But we'll have to let it trickle into the individual
> > distributions first and make remaining userspace tools that rely on this
> > move to alternate apis before we can make any serious effort.
>
> Hopefully it's all fine on the distro front and we can just make it the
> default some years from now. May even make sense to backport some of
> this to stable and get it in their hands faster?
Yes, I agree that this would be good.
On Thu, Jan 25, 2024 at 5:47 PM Christian Brauner <[email protected]> wrote:
>
> On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> > On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <[email protected]> wrote:
> > >
> > > On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > > > syzbot suspects this issue was fixed by commit:
> > > >
> > > > commit 6f861765464f43a71462d52026fbddfc858239a5
> > > > Author: Jan Kara <[email protected]>
> > > > Date: Wed Nov 1 17:43:10 2023 +0000
> > > >
> > > > fs: Block writes to mounted block devices
> > > >
> > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > > > start commit: 2ccdd1b13c59 Linux 6.5-rc6
> > > > git tree: upstream
> > > > kernel config: https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> > > >
> > > > If the result looks correct, please mark the issue as fixed by replying with:
> > >
> > > #syz fix: fs: Block writes to mounted block devices
> >
> > Like Dave replied a few days ago, I'm kind of skeptical on all of these
> > bugs being closed by this change. I'm guessing that they are all
> > resolved now because a) the block writes while mounted option was set to
> > Y, and b) the actual bug is just masked by that.
Yes, that's true. For a) there are also two sub-reasons:
1) The bug itself is indeed no longer reproducible because of this new
kernel option.
2) The bug is not reproducible because the change broke the way
syzkaller did the mounts -- we used to hold an fd to the loop device
while doing the mount. That was fixed[1] soon after the commit reached
torvalds, but for bisections syzbot has to build syzkaller exactly at
the revision when the reproducer was found (otherwise it may parse the
syz reproducer incorrectly). So this kernel commit becomes exactly the
point where the reproducer stops working.
For most of the recently closed fs bugs (2) should not be the primary
reason though -- these fix bisections are done only when syzbot
stopped seeing crashes with the corresponding titles, which was very
likely caused by (1) in the first place.
[1] https://github.com/google/syzkaller/commit/551587c192ecb4df26fcdab775ed145ee69c07d4
> >
> > Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> > really fixed, and what happens if someone doesn't turn on that option?
> > If it's required, perhaps it should not be an option at all? Though
> > that'd seem to be likely to break some funky use cases, whether they are
> > valid or not.
>
> We have no way of actually testing or verifying this stuff and a lot of
> these have been around for a long time. For example, this report here
> has a C reproducer but following the actual dashboard link that
> reproducer is striked-through which supposedly means that it isn't valid
> or reliable. And no other reproducer ever showed up.
>
> As far as I can see we should just close reports such as. If this is a
> real bug that is separate from the ability to mount to writed block
> devices then one should hope that syzbot finds another reproducer that
> let's us really analyze the bug?
Yes, if the ability to write to the block device is not really
necessary to trigger the bug, syzbot should find it again in some
time.
>
> A separate issue is that syzbot keeps suggesting as all of these being
> closable because of this. So how serious can we take this and how much
> time can/should we spend given that we got ~20 or more of these mails in
> the last two weeks or so.
I can add the "fs: Block writes to mounted block devices" commit to
the black list for syzbot bisections -- it will stop sending such
emails then.
--
Aleksandr
>
> I have no better answers than this tbh. And fwiw, apart from this one I
> haven't closed a single bug based on this.
>
> And yes, ideally the ability to write to mounted block devices should be
> turned off. But we'll have to let it trickle into the individual
> distributions first and make remaining userspace tools that rely on this
> move to alternate apis before we can make any serious effort.
>
On Thu, Jan 25, 2024 at 07:24:01PM +0100, Aleksandr Nogikh wrote:
> On Thu, Jan 25, 2024 at 5:47 PM Christian Brauner <[email protected]> wrote:
> >
> > On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> > > On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <[email protected]> wrote:
> > > >
> > > > On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > > > > syzbot suspects this issue was fixed by commit:
> > > > >
> > > > > commit 6f861765464f43a71462d52026fbddfc858239a5
> > > > > Author: Jan Kara <[email protected]>
> > > > > Date: Wed Nov 1 17:43:10 2023 +0000
> > > > >
> > > > > fs: Block writes to mounted block devices
> > > > >
> > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > > > > start commit: 2ccdd1b13c59 Linux 6.5-rc6
> > > > > git tree: upstream
> > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> > > > >
> > > > > If the result looks correct, please mark the issue as fixed by replying with:
> > > >
> > > > #syz fix: fs: Block writes to mounted block devices
> > >
> > > Like Dave replied a few days ago, I'm kind of skeptical on all of these
> > > bugs being closed by this change. I'm guessing that they are all
> > > resolved now because a) the block writes while mounted option was set to
> > > Y, and b) the actual bug is just masked by that.
>
> Yes, that's true. For a) there are also two sub-reasons:
> 1) The bug itself is indeed no longer reproducible because of this new
> kernel option.
> 2) The bug is not reproducible because the change broke the way
> syzkaller did the mounts -- we used to hold an fd to the loop device
> while doing the mount. That was fixed[1] soon after the commit reached
> torvalds, but for bisections syzbot has to build syzkaller exactly at
> the revision when the reproducer was found (otherwise it may parse the
> syz reproducer incorrectly). So this kernel commit becomes exactly the
> point where the reproducer stops working.
>
> For most of the recently closed fs bugs (2) should not be the primary
> reason though -- these fix bisections are done only when syzbot
> stopped seeing crashes with the corresponding titles, which was very
> likely caused by (1) in the first place.
>
> [1] https://github.com/google/syzkaller/commit/551587c192ecb4df26fcdab775ed145ee69c07d4
>
> > >
> > > Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> > > really fixed, and what happens if someone doesn't turn on that option?
> > > If it's required, perhaps it should not be an option at all? Though
> > > that'd seem to be likely to break some funky use cases, whether they are
> > > valid or not.
> >
> > We have no way of actually testing or verifying this stuff and a lot of
> > these have been around for a long time. For example, this report here
> > has a C reproducer but following the actual dashboard link that
> > reproducer is striked-through which supposedly means that it isn't valid
> > or reliable. And no other reproducer ever showed up.
> >
> > As far as I can see we should just close reports such as. If this is a
> > real bug that is separate from the ability to mount to writed block
> > devices then one should hope that syzbot finds another reproducer that
> > let's us really analyze the bug?
>
> Yes, if the ability to write to the block device is not really
> necessary to trigger the bug, syzbot should find it again in some
> time.
>
> >
> > A separate issue is that syzbot keeps suggesting as all of these being
> > closable because of this. So how serious can we take this and how much
> > time can/should we spend given that we got ~20 or more of these mails in
> > the last two weeks or so.
>
> I can add the "fs: Block writes to mounted block devices" commit to
> the black list for syzbot bisections -- it will stop sending such
> emails then.
No, I think it's helpful. I was just saying that we can't be expected to
spend hours per report to check whether this makes sense or not. I
wasn't complaining about this per se.