[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Oct 2018 18:36:40 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: syzbot <syzbot+2222c34dc40b515f30dc@...kaller.appspotmail.com>,
David Miller <davem@...emloft.net>,
Eric Van Hensbergen <ericvh@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Latchesar Ionkov <lucho@...kov.net>,
netdev <netdev@...r.kernel.org>,
Ron Minnich <rminnich@...dia.gov>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
v9fs-developer@...ts.sourceforge.net
Subject: Re: Re: BUG: corrupted list in p9_read_work
On Wed, Oct 10, 2018 at 6:10 PM, Dominique Martinet
<asmadeus@...ewreck.org> wrote:
> Dominique Martinet wrote on Wed, Oct 10, 2018:
>> It works though, is it just picky because I didn't end it in .git? let's
>> try again, sorry for the noise...
>>
>> #syz test: git://github.com/martinetd/linux.git e4ca13f7d075e551dc158df6af18fb412a1dba0a
>
> And I guess the commit hash needs to be in the default clone branch to
> work ?
> ('git fetch <repo> <hash>' happily fetches the commit in a new clone for
> me... But that feels like a github specific behaviour maybe)
yeeeep, this is bug:
https://github.com/google/syzkaller/issues/728
Turns out git fetch of a named remote and just a tree work
differently. The latter only fetches the main branch.
'git fetch <repo> <hash>' is it a thing? Is it something that requires
special server configuration? I remember something similar that wasn't
able to fetch a random commit hash all the time...
The plan was to make a named remote and then fetch it, this should
fetch everything.
> Oh, well; made a branch for it, last try for me.
>
> #syz test: git://github.com/martinetd/linux.git for-syzbot
>
> --
> Dominique
Powered by blists - more mailing lists