openbsd build error (13)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 050ff868 Skip test if web server cannot be pinged.
git tree: openbsd
console output: https://syzkaller.appspot.com/x/log.txt?x=12566852500000
kernel config: https://syzkaller.appspot.com/x/.config?x=fe55924c11e64b0a
dashboard link: https://syzkaller.appspot.com/bug?extid=badc83af4aac6e58c236

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+badc83...@syzkaller.appspotmail.com

failed to run ["/bin/sh" "-c" "set -eux\nOVERLAY=\"/syzkaller/userspace/overlay\"\n# Cleanup in case something failed before.\ndoas umount /altroot || true\ndoas vnconfig -u vnd0 || true\n\ndoas /sbin/vnconfig vnd0 image\ndoas mount /dev/vnd0a /altroot\ndoas cp kernel /altroot/bsd\ntest -d \"$OVERLAY\" && doas cp -Rf \"$OVERLAY\"/. /altroot\ndoas umount /altroot\ndoas vnconfig -u vnd0\n"]: exit status 1

---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[Greg Steuck]

We hit this before[1] and I punted it then. I want to understand why this fails. Anton, any clue why we get this error?

https://syzkaller.appspot.com/text?tag=CrashLog&x=12566852500000

+ OVERLAY=/syzkaller/userspace/overlay
+ doas umount /altroot
umount: /altroot: not currently mounted
+ true
+ doas vnconfig -u vnd0
vnconfig: VNDIOCCLR: Device not configured
+ true
+ doas /sbin/vnconfig vnd0 image
+ doas mount /dev/vnd0a /altroot
+ doas cp kernel /altroot/bsd
+ test -d /syzkaller/userspace/overlay
+ doas umount /altroot
umount: /altroot: Device busy

This code[0] should copy the kernel over and succeed umounting as I don't see anything else using /altroot all of a sudden. I could complicate the script to use a unique temporary directory, but this immediately runs into another problem of potentially leaking resources if something dies at the wrong time.

[0]https://github.com/google/syzkaller/blob/22f8756722ad4bbf532a6861776b24cbb513755e/pkg/build/openbsd.go#L82

[1]https://syzkaller.appspot.com/x/log.txt?x=13543663900000

--
You received this message because you are subscribed to the Google Groups "syzkaller-openbsd-bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-openbsd...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-openbsd-bugs/000000000000d10b3c05b3670168%40google.com.

--

nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

[Anton Lindqvist]

On Thu, Nov 05, 2020 at 06:48:08PM -0800, Greg Steuck wrote:
> We hit this before[1] and I punted it then. I want to understand why this
> fails. Anton, any clue why we get this error?
> https://syzkaller.appspot.com/text?tag=CrashLog&x=12566852500000
>
> + OVERLAY=/syzkaller/userspace/overlay
> + doas umount /altroot
> umount: /altroot: not currently mounted
> + true
> + doas vnconfig -u vnd0
> vnconfig: VNDIOCCLR: Device not configured
> + true
> + doas /sbin/vnconfig vnd0 image
> + doas mount /dev/vnd0a /altroot
> + doas cp kernel /altroot/bsd
> + test -d /syzkaller/userspace/overlay
> + doas umount /altroot
> umount: /altroot: Device busy
>
> This code[0] should copy the kernel over and succeed umounting as I don't
> see anything else using /altroot all of a sudden. I could complicate the
> script to use a unique temporary directory, but this immediately runs into
> another problem of potentially leaking resources if something dies at the
> wrong time.

Could be caused by incorrect vnode reference accounting, either by the
file system or unveil. Are you able to reproduce it by running the
commands above outside of the syzkaller instance?

[Greg Steuck]

I'm running this script in a loop on my desktop machine now. Doing a `cd /altroot; ls` concurrently with this loop causes the same diagnostics (as expected). I still don't understand what kind of parallel activity could be happening on the syz-bot machine unless we somehow manage to run two such builds concurrently. I was under the impression syz-bot only runs one build at a time.

[Anton Lindqvist]

On Sun, Nov 08, 2020 at 09:36:24PM -0800, Greg Steuck wrote:
> I'm running this script in a loop on my desktop machine now. Doing a `cd
> /altroot; ls` concurrently with this loop causes the same diagnostics (as
> expected). I still don't understand what kind of parallel activity could be
> happening on the syz-bot machine unless we somehow manage to run two such
> builds concurrently. I was under the impression syz-bot only runs one build
> at a time.

No trigger without the concurrent `cd /altroot; ls'?

[Greg Steuck]

Nope, it has been running for 12 hours straight. Only stopped after I issued cd /altroot. Something we don't understand is happening on that syz-bot machine.

[Dmitry Vyukov]

On Mon, Nov 9, 2020 at 6:36 AM Greg Steuck <gr...@nest.cx> wrote:
>
> I'm running this script in a loop on my desktop machine now. Doing a `cd /altroot; ls` concurrently with this loop causes the same diagnostics (as expected). I still don't understand what kind of parallel activity could be happening on the syz-bot machine unless we somehow manage to run two such builds concurrently. I was under the impression syz-bot only runs one build at a time.

There should be no parallel builds (assuming we have no bugs, of course :)).
But is it possible that a previous failed build leaves things in some
inconsistent state? Is there any correlation between this build error
and other build errors?

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-openbsd-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-openbsd...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-openbsd-bugs/CANMcDo8XTAvS6BVCGmGXMzpqvdmovPQ3Hme0foVNXDf4Wi3QDg%40mail.gmail.com.

[Anton Lindqvist]

On Mon, Nov 09, 2020 at 09:58:02AM -0800, Greg Steuck wrote:
> Nope, it has been running for 12 hours straight. Only stopped after I
> issued cd /altroot. Something we don't understand is happening on that
> syz-bot machine.

How about adding a call to sync(8) before the call to `umount /altroot`?

[Greg Steuck]

We could, but it is not easy to imagine how it would happen. Surely the kernel would know to wait for any stuff underway before reporting it can't umount?

[Anton Lindqvist]

On Wed, Jan 27, 2021 at 07:21:37PM -0800, Greg Steuck wrote:
> We could, but it is not easy to imagine how it would happen. Surely the
> kernel would know to wait for any stuff underway before reporting it can't
> umount?

Took a brief look at the code, it looks like vfs_busy() could return
EBUSY in sys_unmount() if it ended up sleeping while trying to acquire
the mount point lock.

[Greg Steuck]

#syz invalid