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]
Message-ID: <ff841fdc-4db7-7a3d-8caf-d0cddd0dfa31@leemhuis.info>
Date:   Tue, 10 May 2022 13:27:54 +0200
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Zhangfei Gao <zhangfei.gao@...mail.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Link: tag and links to submission and reports (was: Re: [GIT pull]
 core/urgent for v5.18-rc6)

On 08.05.22 20:00, Linus Torvalds wrote:
> On Sun, May 8, 2022 at 5:05 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> A single bugfix for the PASID management code, which freed the PASID too
>> early. The PASID needs to be tied to the mm lifetime, not to the address
>> space lifetime.
> 
> So I have to once more complain about the -tip tree "Link:" usage.

Many thx for reminding people about the tag.  FWIW, that's a problem in
a lot or subsystems and makes my regression tracking efforts hard, as my
tracking bot relies on the 'Link:' tag. If it's missing I thus have to
manually search if patches were posted or committed to fix a regression,
which makes the tracking hard and annoying. :-/

> Again, the commit has a link to the patch *submission*, which is
> almost entirely useless. There's no link to the actual problem the
> patch fixes.

It seems quite a few developers are under the impressions that "Link:"
is just for the patch submission and not to be used for other things.
That's why some people invented other tags. I see "BugLink" quite often
these days, but there are also other tags in use (some drm people used
"References:" for a while).

Do we care? Should we try to clean this up while making things a bit
more straight forward at the same time by making it more obvious what a
link is actually about? I once suggested we use something like
* "Submitted:" or "Posted:" for the patch submission
* "Reported:" or "BugLink:" for any reports that lead to the

That would leave "Link:" ambiguous and usable for anything else (and b4
likely could be fixed easily to set a different tag; but sure, there
would be a transition period).

But there was not much feedback on the idea. Do you think I should pick
up this again? Or is this something I should bring up during this years
kernel summit?

> [...]
> Put another way: I can see that
>     Reported-by: Zhangfei Gao <zhangfei.gao@...mail.com>

With a "Reported:" tag like mentioned above we could stop using
"Reported-by:" if we wanted to reduce the overhead (or make it
optional). But OTOH I guess it's a bad idea, as having this in there
will motivate some people to submit reports. And is good for stats reg.
syzbot and 0-day (but I guess those could be generated from proper
links, too).

BTW: Documentation/process/5.Posting.rst states '''Be careful in the
addition of tags to your patches: only Cc: is appropriate for addition
without the explicit permission of the person named.''' Is that actually
true? A lot of people seem to set "Reported-by:" without getting
explicit permission. If that is fine I'd prepare a patch to fix the docs.

Ciao, Thorsten

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ