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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 19 Dec 2022 13:15:03 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Aleksandr Nogikh <nogikh@...gle.com>
Cc:     Lee Jones <lee@...nel.org>,
        syzbot <syzbot+15cd994e273307bf5cfa@...kaller.appspotmail.com>,
        adilger.kernel@...ger.ca, gregkh@...uxfoundation.org,
        lczerner@...hat.com, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, sashal@...nel.org,
        stable@...r.kernel.org, syzkaller-android-bugs@...glegroups.com,
        tadeusz.struk@...aro.org
Subject: Re: kernel BUG in ext4_free_blocks (2)

On Mon, Dec 19, 2022 at 05:12:47PM +0100, Aleksandr Nogikh wrote:
> (a) Once you have opened the bug report page, you can find the
> namespace at the top of the page.
> (b) One can at least see the list of the tested trees on the main page
> of the namespace -- we do share the latest commits for each manager
> instance. Also see the comment below.

It's not obvious what you mean by the "main page" of the namespace.
I'm guessing, but from the bug report page, there is a horizontal set
of icons, "Open", "Fixed", "Invalid" .... (which all have the same
icons), that the "Open" icon is the one that gets to the main page?

Assuming that this[1] is what was meant by "main page" (which is also
implied by the URL, but it's otherwise **really** not obvious), where
is the list of tested trees?

[1] https://syzkaller.appspot.com/android-5-10

I see the table "Instances", but it looks like the only two instances,
ci2-android-5-10 and ci2-android-5-10-perf, are both apparently
looking at the same commit --- but there's nothing that tells you what
kernel tree those commits are from.  I can't see **anything* that
looks like an explicit git repo URL plus branch name.  Is it perhaps
one of these?

https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10
https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.10

It also appears that the android-5-10 "namespace" doesn't track any
other trees other than the Android 5.10 tree.  Which means the e-mail
message, "I can't find the commit on any tested tree" is ***super***
misleading.  At least for the android-5-10 namespace, why not just
say, "I don't see that commit on the git branch <explicit git repo and
branch name>"?

I did finally find the missing information, but it required a lot of
clicking and searching.  From the bug page [2], the status line is:

    Status: upstream: reported C repro on 2022/11/27 00:51

Has a link to the e-mail sent to the upstream developers[3].  And in
*that* e-mail, we can find the git tree involved: 

   git tree: android12-5.10-lts

[3] https://groups.google.com/g/syzkaller-android-bugs/c/LmaUwJpTXkA/m/HjsARFKWCQAJ


Going back to your pull request[4] to add a link to the dashboard in
the e-mail, how about also adding to the e-mail an indication about
the Syzkaller namespace.  That way, the upstream developer can quickly
determine that the namespace is "Android-X.Y" and simply hit the 'd'
key as not really relevant to the upstream developer.

[4] https://github.com/google/syzkaller/pull/3591

I assume that there's someone in the Android kernel ecosystem that is
responsible for figuring out how to make sure commits are backported
from upstream into the LTS kernels, and the LTS kernels to the
relevant Android branch.

I do know one thing for certain --- I don't scale to the point where
this can made my problem.  So I want to be able to more quickly triage
e-mails that are Not My Problem.

More generally, I think we need some kind of MAINTAINERS-like file
which explicitly lists who does have that responsibility, and which
can be used by Syzkaller so we aren't just blindly spamming all of the
upstream developers in the hopes that one of them will do somebody
else's job just to shut up the nag mail.  Otherwise, the natural
reaction will be to resort to a mail filter to /dev/null the nag mail.
:-/

					- Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ