On Mon, Oct 30, 2017 at 8:47 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Mon, 2017-10-30 at 18:40 +0100, Dmitry Vyukov wrote: >> On Mon, Oct 30, 2017 at 6:30 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > On Mon, 2017-10-30 at 18:06 +0100, Dmitry Vyukov wrote: >> > >> >> Yes, but hashes in random trees also don't tell much. A tree can be >> >> rebased so the hash will be lost. It can be a tree unknown to the >> >> system. Even if we find the commit by hash, in order to match it >> >> against other trees we will have to use the title anyway (or are there >> >> better options?), so using hashes becomes pointless. >> > >> > We do not send hashes on random trees, but official SHA1 in David Miller >> > trees. They will be the same SHA1 in official Linus Torvalds tree. >> > >> > Really, you make our life more difficult by pretending that hashes are >> > not the proper way. >> > >> > They are reasons we use Fixes: tags all over the places, they are unique >> > in Linus tree. >> > >> > Since syzbot gives a SHA1 itself, it must be using a tree, right ? >> > >> > So a SHA1 that is guaranteed to enter the same tree is correct. >> > >> > Please fix your bot. >> >> >> They don't necessary enter the same tree (that's more of an exception >> than the rule). For bugs that we find in Linus tree, fixes enter usb, >> kvm, block, sound, linux-next and a bunch of other trees that I never >> heard of. At the very least we will need a git repo address + commit >> hash. But then for say linux-next hashes disappear. And mm which is >> not a git tree at all (no hashes). >> And still the hashes will need to be explicitly marked as fixes (with >> #syz fix or something else). So that would look like: >> ##syz fix: git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git >> e7989f973ae1b90ec7c0b671c81f7f553affccbe >> which does not look much better than: >> ##syz fix: tun: do not arm flow_gc_timer in tun_flow_init() >> which also I think makes it easier for humans to ensure that they >> actually reference what they meant to reference (and maybe find the >> fix in other trees). > > > I suggested that syzbot catches up on standard way : > > <SHA1> patch title > > It contains way more information than : > > sys fix: patch title > > I never suggested to only use <SHA1>
But people reference patches for other reasons (I've sent you examples offline). If you mean syz fix: <SHA1> patch title then that's doable. If we agree on this format, then I am ready to implement this.
