> The kernel stack is not very useful in this case, it's a common faulting
> stack.
> Maybe it will shed some light if you install gdb in the image, attach
> it to the systemd process, then trigger the segfault and then unwind
> stack in the systemd process at the time of fault, dump registers,
>
On Wed, Mar 10, 2021 at 10:02 AM Palash Oswal wrote:
>
> On Tue, Mar 9, 2021 at 7:58 PM Al Viro wrote:
> > Lovely. So something in that sequence of syscalls manages to trigger
> > segfault in unrelated process. What happens if you put it to sleep
> > right after open_by_handle_at() (e.g. by rea
On Tue, Mar 9, 2021 at 7:58 PM Al Viro wrote:
> Lovely. So something in that sequence of syscalls manages to trigger
> segfault in unrelated process. What happens if you put it to sleep
> right after open_by_handle_at() (e.g. by read(2) from fd 0, etc.)?
Added read(2) call in the reproducer, an
On Tue, Mar 9, 2021 at 8:36 PM Dmitry Vyukov wrote:
> FWIW the code looks reasonable:
>
> All code
>
>0: 00 00add%al,(%rax)
>2: 00 00add%al,(%rax)
>4: 41 57push %r15
>6: 41 56push %r14
>8: 41 5
Al Viro writes:
> On Tue, Mar 09, 2021 at 11:29:14AM +0530, Palash Oswal wrote:
>
>> I observe the following result(notice the segfault in systemd):
>> root@sandbox:~# ./repro
>> [9.457767] got to 221
>> [9.457791] got to 183
>> [9.459144] got to 201
>> [9.459471] got to 208
>> [
On Tue, Mar 9, 2021 at 3:31 PM Al Viro wrote:
> > I observe the following result(notice the segfault in systemd):
> > root@sandbox:~# ./repro
> > [9.457767] got to 221
> > [9.457791] got to 183
> > [9.459144] got to 201
> > [9.459471] got to 208
> > [9.459773] got to 210
> > [
On Tue, Mar 09, 2021 at 11:29:14AM +0530, Palash Oswal wrote:
> I observe the following result(notice the segfault in systemd):
> root@sandbox:~# ./repro
> [9.457767] got to 221
> [9.457791] got to 183
> [9.459144] got to 201
> [9.459471] got to 208
> [9.459773] got to 210
> [
On Mon, Mar 8, 2021 at 10:50 PM Al Viro wrote:
> I'd suggest to add printk(KERN_ERR "got to %d", __LINE__); in fs/fhandle.c at
> beginning of do_handle_open()
> right before each copy_from_user() in handle_to_path()
> right before and right after the call of do_handle_to_p
On Mon, Mar 08, 2021 at 10:06:10PM +0530, Palash Oswal wrote:
> I was running syzkaller and I found the following issue :
> Head Commit : 27e543cca13fab05689b2d0d61d200a83cfb00b6 ( v5.11.2 )
> Git Tree : stable
>
> Console Logs:
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x
On Fri, Nov 13, 2020 at 9:27 AM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit a49145acfb975d921464b84fe00279f99827d816
> Author: George Kennedy
> Date: Tue Jul 7 19:26:03 2020 +
>
> fbmem: add margin check to fb_check_caps()
>
> bisection log: https://syz
syzbot suspects this issue was fixed by commit:
commit a49145acfb975d921464b84fe00279f99827d816
Author: George Kennedy
Date: Tue Jul 7 19:26:03 2020 +
fbmem: add margin check to fb_check_caps()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10ff757250
start commit:
On Wed, Jul 15, 2020 at 8:04 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Wed, 15 Jul 2020 13:54:04 +0800 Yafang Shao wrote:
> >
> > On Wed, Jul 15, 2020 at 12:49 PM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:d31958b3 Add li
On 28-08-20, 14:23, Ulf Hansson wrote:
> Anders, Naresh - thanks for testing and reporting. I am dropping the
> patch from my tree.
>
> Viresh, I suggest to keep Anders/Naresh in the cc, for the next
> version. Then I can wait for their tested-by tag before I apply again.
Sorry for the trouble, I
On Fri, 28 Aug 2020 at 12:29, Anders Roxell wrote:
>
> On Fri, 28 Aug 2020 at 11:35, Ulf Hansson wrote:
> >
> > On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > > wrote:
> > > >
> > > > On Thu, 27 Aug 2020 at 15:42, Viresh Ku
On Fri, 28 Aug 2020 at 11:35, Ulf Hansson wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar
> > > wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann wro
On Fri, 28 Aug 2020 at 15:05, Ulf Hansson wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar
> > > wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann wro
On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju wrote:
>
> On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
> > >
> > > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > > [
On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju wrote:
>
> On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
> >
> > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > [3.683431] sdhci_msm_probe+0x284/0x9a0
> > >
> > > dev_pm_opp_put_cl
On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
>
> On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > [3.683431] sdhci_msm_probe+0x284/0x9a0
> >
> > dev_pm_opp_put_clkname() is part of the error handling in the
> > probe function, so I
On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > [3.683431] sdhci_msm_probe+0x284/0x9a0
>
> dev_pm_opp_put_clkname() is part of the error handling in the
> probe function, so I would deduct there are two problems:
>
> - something failed du
On Thu, Aug 27, 2020 at 11:08 AM Viresh Kumar wrote:
>
> +Rajendra
>
> On 27-08-20, 14:02, Naresh Kamboju wrote:
> > arm64 dragonboard db410c boot failed while running linux next 20200827
> > kernel.
> >
> > metadata:
> > git branch: master
> > git repo:
> > https://git.kernel.org/pub/scm/li
On Thu, 27 Aug 2020 at 14:02, Naresh Kamboju wrote:
>
> arm64 dragonboard db410c boot failed while running linux next 20200827 kernel.
>
> metadata:
> git branch: master
> git repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git commit: 88abac0b753dfdd85362a26d2
+Rajendra
On 27-08-20, 14:02, Naresh Kamboju wrote:
> arm64 dragonboard db410c boot failed while running linux next 20200827 kernel.
>
> metadata:
> git branch: master
> git repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git commit: 88abac0b753dfdd85362a26d2d
On Mon, Aug 3, 2020 at 6:55 AM Dmitry Vyukov wrote:
>
> On Mon, Aug 3, 2020 at 5:24 AM butt3rflyh4ck
> wrote:
> >
> > Hi, syzkaller always get this crashes, I think this crash is not a
> > bug, maybe some wrong configs
> > cause, can you give me some help. thanks.
> >
> > log is below:
> > 8
On Mon, Aug 3, 2020 at 5:24 AM butt3rflyh4ck wrote:
>
> Hi, syzkaller always get this crashes, I think this crash is not a
> bug, maybe some wrong configs
> cause, can you give me some help. thanks.
>
> log is below:
> 888063151a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> 888063
Hi Tom,
On 2020-07-29 11:29 a.m., Tom Lendacky wrote:
> On 7/29/20 4:50 AM, Thomas Gleixner wrote:
>> Scott,
>>
>> Scott Branden writes:
>>> On 2020-07-28 1:22 a.m., Thomas Gleixner wrote:
Scott Branden writes:
> Bios now updated to latest. Same kernel panic issue. Log below.
>
>>
On 7/29/20 4:50 AM, Thomas Gleixner wrote:
> Scott,
>
> Scott Branden writes:
>> On 2020-07-28 1:22 a.m., Thomas Gleixner wrote:
>>> Scott Branden writes:
Bios now updated to latest. Same kernel panic issue. Log below.
I think it is related to power cycling quickly.
Should
Scott,
Scott Branden writes:
> On 2020-07-28 1:22 a.m., Thomas Gleixner wrote:
>> Scott Branden writes:
>>> Bios now updated to latest. Same kernel panic issue. Log below.
>>>
>>> I think it is related to power cycling quickly.
>>> Should APIC work if PC power cycled in a few seconds or is tha
Hi Thomas,
On 2020-07-28 1:22 a.m., Thomas Gleixner wrote:
> Scott,
>
> Scott Branden writes:
>> Bios now updated to latest. Same kernel panic issue. Log below.
>>
>> I think it is related to power cycling quickly.
>> Should APIC work if PC power cycled in a few seconds or is that the
>> proble
Scott,
Scott Branden writes:
> Bios now updated to latest. Same kernel panic issue. Log below.
>
> I think it is related to power cycling quickly.
> Should APIC work if PC power cycled in a few seconds or is that the
> problem?
Yes, emphasis on should. Just to clarify, if you reboot it works a
Bios now updated to latest. Same kernel panic issue. Log below.
I think it is related to power cycling quickly.
Should APIC work if PC power cycled in a few seconds or is that the problem?
On 2020-07-27 1:51 p.m., Thomas Gleixner wrote:
> Scott,
>
> Scott Branden writes:
>
>> Occasionally I g
Scott,
Scott Branden writes:
> Occasionally I get the following Kernel panic on boot. This is
> running on the latest kernel but have seen it previously as well.
> "Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with
> apic=debug and send a report."
>
> I don't know who I am su
On Mon, Jul 27, 2020 at 10:20 PM Scott Branden
wrote:
>
> Occasionally I get the following Kernel panic on boot. This is running on
> the latest kernel but have seen it previously as well.
> "Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with
> apic=debug and send a report."
>
Hi all,
On Wed, 15 Jul 2020 13:54:04 +0800 Yafang Shao wrote:
>
> On Wed, Jul 15, 2020 at 12:49 PM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:d31958b3 Add linux-next specific files for 20200710
> > git tree: linux-next
> > console ou
On Wed, Jul 15, 2020 at 12:49 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:d31958b3 Add linux-next specific files for 20200710
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=11a2fe1310
> kernel config: https
Hi Casey,
On Mon, Mar 30, 2020 at 06:51:18AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:1b649e0b Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14957099e000
On Wed, Oct 23, 2019 at 10:15:40AM -0500, Bjorn Helgaas wrote:
> I don't like being one of a handful of callers of __add_wait_queue(),
> so I like that solution from that point of view.
>
> The 7ea7e98fd8d0 ("PCI: Block on access to temporarily unavailable pci
> device") commit log suggests that u
On Wed, Oct 23, 2019 at 05:40:20PM +0800, Xiang Zheng wrote:
> Hi Bjorn,
>
> Thanks for your reply!
>
> On 2019/10/18 21:58, Bjorn Helgaas wrote:
> > [+cc Matthew]
> >
> > On Wed, Oct 16, 2019 at 09:36:23PM +0800, Xiang Zheng wrote:
> >> Hi all,
> >>
> >> Recently I encountered a kernel panic wh
Hi Bjorn,
Thanks for your reply!
On 2019/10/18 21:58, Bjorn Helgaas wrote:
> [+cc Matthew]
>
> On Wed, Oct 16, 2019 at 09:36:23PM +0800, Xiang Zheng wrote:
>> Hi all,
>>
>> Recently I encountered a kernel panic while doing vfio-pci hot-plug/unplug
>> test repeatly on my Arm-KVM virtual machines
[+cc Matthew]
On Wed, Oct 16, 2019 at 09:36:23PM +0800, Xiang Zheng wrote:
> Hi all,
>
> Recently I encountered a kernel panic while doing vfio-pci hot-plug/unplug
> test repeatly on my Arm-KVM virtual machines.
> See the call stack below:
>
> [66628.697280] vfio-pci :06:03.5: enabling devi
On Thu, Oct 17, 2019 at 09:25:05AM -0700, Eric Biggers wrote:
> On Sun, Sep 01, 2019 at 08:23:42PM -0700, 'Dmitry Vyukov' via syzkaller-bugs
> wrote:
> > On Sun, Sep 1, 2019 at 3:48 PM syzbot
> > wrote:
> > >
> > > syzbot has found a reproducer for the following crash on:
> > >
> > > HEAD commit:
On Sun, Sep 01, 2019 at 08:23:42PM -0700, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Sun, Sep 1, 2019 at 3:48 PM syzbot
> wrote:
> >
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit:38320f69 Merge branch 'Minor-cleanup-in-devlink'
> > git tree: net-n
On Mon, Sep 9, 2019 at 1:21 PM Stephen Rothwell wrote:
>
> Hi,
>
> On Mon, 9 Sep 2019 20:11:59 +1000 Stephen Rothwell
> wrote:
> >
> > If you are bisecting linux-next, I will suggest bisecting between the
> > stable branch on linux-next (which is just Linus' tree when I started
> > that day) and
On Sat, Sep 07, 2019 at 12:32:41PM +0200, Daniel Vetter wrote:
> On Sat, Sep 7, 2019 at 11:05 AM Alexander Kapshuk
> wrote:
> >
> > To Whom It May Concern
> >
> > Every kernel I have built since 5.3.0-rc2-next-20190730 and up to
> > 5.3.0-rc7-next-20190903 has resulted in the kernel panic describe
On Sun, Sep 1, 2019 at 4:27 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:dd7078f0 enetc: Add missing call to 'pci_free_irq_vectors(..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=115fe0fa60
> kernel config: https
On Sun, Sep 1, 2019 at 3:48 PM syzbot
wrote:
>
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:38320f69 Merge branch 'Minor-cleanup-in-devlink'
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13d7435660
> kernel config: ht
syzbot has found a reproducer for the following crash on:
HEAD commit:38320f69 Merge branch 'Minor-cleanup-in-devlink'
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13d7435660
kernel config: https://syzkaller.appspot.com/x/.config?x=1bbf70b6300045af
d
Hi, Bruce, Dan,
This patch took care the panic issue.
thanks,
-jane
On 8/21/19 7:12 AM, J. Bruce Fields wrote:
Probably just needs the following.
I've been slow to get some bugfixes upstream, sorry--I'll go send a pull
request now
--b.
commit 78e70e780b28
Author: He Zhe
Date: Tue Aug
Hi, Dan,
On 8/20/19 8:48 PM, Dan Williams wrote:
On Tue, Aug 20, 2019 at 6:39 PM wrote:
Hi,
Apology if there is a better channel reporting the issue, if so, please
let me know.
I just saw below regression in 5.3-rc5 kernel, but not in 5.2-rc7 or
earlier kernels.
Is the error stable enough
Probably just needs the following.
I've been slow to get some bugfixes upstream, sorry--I'll go send a pull
request now
--b.
commit 78e70e780b28
Author: He Zhe
Date: Tue Aug 6 17:41:04 2019 +0800
nfsd4: Fix kernel crash when reading proc file reply_cache_stats
reply_cache_st
On Tue, Aug 20, 2019 at 6:39 PM wrote:
>
> Hi,
>
> Apology if there is a better channel reporting the issue, if so, please
> let me know.
>
> I just saw below regression in 5.3-rc5 kernel, but not in 5.2-rc7 or
> earlier kernels.
Is the error stable enough to bisect?
Dmitry Vyukov wrote:
> On Wed, Jul 17, 2019 at 10:58 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:1438cde7 Add linux-next specific files for 20190716
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt
Eric Biggers wrote:
> [+bpf and tls maintainers]
>
> On Wed, Jul 03, 2019 at 04:23:34PM +0100, Al Viro wrote:
> > On Wed, Jul 03, 2019 at 03:40:00PM +0100, Al Viro wrote:
> > > On Wed, Jul 03, 2019 at 02:43:07PM +0800, Hillf Danton wrote:
> > >
> > > > > This is very much *NOT* fine.
> > > > >
[+bpf and tls maintainers]
On Wed, Jul 03, 2019 at 04:23:34PM +0100, Al Viro wrote:
> On Wed, Jul 03, 2019 at 03:40:00PM +0100, Al Viro wrote:
> > On Wed, Jul 03, 2019 at 02:43:07PM +0800, Hillf Danton wrote:
> >
> > > > This is very much *NOT* fine.
> > > > 1) trylock can fail from any n
On Wed, Jul 03, 2019 at 03:40:00PM +0100, Al Viro wrote:
> On Wed, Jul 03, 2019 at 02:43:07PM +0800, Hillf Danton wrote:
>
> > > This is very much *NOT* fine.
> > > 1) trylock can fail from any number of reasons, starting
> > > with "somebody is going through the hash chain doing a lookup on
> >
On Wed, Jul 03, 2019 at 02:43:07PM +0800, Hillf Danton wrote:
> > This is very much *NOT* fine.
> > 1) trylock can fail from any number of reasons, starting
> > with "somebody is going through the hash chain doing a lookup on
> > something completely unrelated"
>
> They are also a red light t
On Tue, Jul 02, 2019 at 05:21:26PM +0800, Hillf Danton wrote:
> Hello,
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -673,14 +673,11 @@ static struct dentry *dentry_kill(struct dentry *dentry)
> if (!IS_ROOT(dentry)) {
> parent = dentry->d_parent;
> if (unlikely(!
syzbot has bisected this bug to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend
Date: Sat Jun 30 13:17:47 2018 +
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17f7f4d5a0
start commit: 7b7
syzbot has bisected this bug to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend
Date: Sat Jun 30 13:17:47 2018 +
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11d4e129a0
start commit: 249
syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:29f785ff Merge branch 'fixes' of git://git.kernel.org/pub/..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1158d411a0
> kernel config: https://syzkaller.appspot.com/x/.conf
F.Y.I. Nothing is wrong with that commit. That commit merely allows enabling
TOMOYO and
one of SELinux/Smack/AppArmor at the same time for syzbot's kernel command line
options.
This problem will be handled by a patch at
https://lore.kernel.org/linux-security-module/1551362770-8655-1-git-send-emai
syzbot has bisected this bug to:
commit 89a9684ea158dd7eef1728be9f0aed9a7d41cf19
Author: Kees Cook
Date: Tue Feb 12 18:23:18 2019 +
LSM: Ignore "security=" when "lsm=" is specified
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1157272320
start commit: 89a9684e LS
On 2019/02/28 19:58, Tetsuo Handa wrote:
> But the problem is that since syzbot is automated, there is no chance to
> edit the content of security/tomoyo/policy/ directory when building the
> kernels.
Thinking again, I realized that it would be possible to automatically
generate the content of sec
On 2019/02/28 19:23, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 11:20 AM Tetsuo Handa
> wrote:
>>
>> On 2019/02/28 15:51, Dmitry Vyukov wrote:
>>> On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
Thank you. The LSM stacking seems to be working as expected.
But this one should not b
On Thu, Feb 28, 2019 at 11:20 AM Tetsuo Handa
wrote:
>
> On 2019/02/28 15:51, Dmitry Vyukov wrote:
> > On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
> >>
> >> Thank you. The LSM stacking seems to be working as expected.
> >> But this one should not be considered as a bug.
> >>
> >> If something we
On 2019/02/28 15:51, Dmitry Vyukov wrote:
> On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
>>
>> Thank you. The LSM stacking seems to be working as expected.
>> But this one should not be considered as a bug.
>>
>> If something went wrong before loading access control rules,
>> it is pointless to co
On Thu, Feb 28, 2019 at 11:11 AM Tetsuo Handa
wrote:
>
> On 2019/02/28 15:42, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:7b827ff9af88 Add linux-next specific files for 20190227
> > git tree: linux-next
> > console output: https://syzkaller.a
On 2019/02/28 15:42, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7b827ff9af88 Add linux-next specific files for 20190227
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10f71894c0
> kernel config: https://syzkal
On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
wrote:
>
> On 2019/02/28 2:02, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:7b827ff9af88 Add linux-next specific files for 20190227
> > git tree: linux-next
> > console output: https://syzkaller.ap
On 2019/02/28 2:02, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:7b827ff9af88 Add linux-next specific files for 20190227
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15336f14c0
> kernel config: https://syzkall
On Mon 28-01-19 10:42:25, Linus Torvalds wrote:
> On Mon, Jan 28, 2019 at 3:44 AM Michal Hocko wrote:
> >
> > >
> > > Linus, could you take the revert please?
> >
> > or should I post the patch as a reply to make your life easier?
>
> I've taken that revert now, but yes, in general, it's much bet
On Mon, Jan 28, 2019 at 3:44 AM Michal Hocko wrote:
>
> >
> > Linus, could you take the revert please?
>
> or should I post the patch as a reply to make your life easier?
I've taken that revert now, but yes, in general, it's much better if a
patch is sent separately from the discussion as a very
On Fri 25-01-19 19:15:49, Michal Hocko wrote:
> On Fri 25-01-19 18:33:15, Michal Hocko wrote:
> > On Fri 25-01-19 17:39:38, Michal Hocko wrote:
> > > On Fri 25-01-19 11:16:30, robert shteynfeld wrote:
> > > > Attached is the dmesg from patched kernel.
> > >
> > > Your Node1 physical memory range p
On Mon 28-01-19 11:37:00, Mikhail Gavrilov wrote:
> > Linus, could you take the revert please?
> >
> > From 817b18d3db36a6900ca9043af8c1416c56358be3 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko
> > Date: Fri, 25 Jan 2019 19:08:58 +0100
> > Subject: [PATCH] Revert "mm, memory_hotplug: initialize
> Linus, could you take the revert please?
>
> From 817b18d3db36a6900ca9043af8c1416c56358be3 Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Fri, 25 Jan 2019 19:08:58 +0100
> Subject: [PATCH] Revert "mm, memory_hotplug: initialize struct pages for the
> full memory section"
>
> This reverts
On Fri 25-01-19 18:33:15, Michal Hocko wrote:
> On Fri 25-01-19 17:39:38, Michal Hocko wrote:
> > On Fri 25-01-19 11:16:30, robert shteynfeld wrote:
> > > Attached is the dmesg from patched kernel.
> >
> > Your Node1 physical memory range precedes Node0 which is quite unusual
> > but it shouldn't
On Fri 25-01-19 17:39:38, Michal Hocko wrote:
> On Fri 25-01-19 11:16:30, robert shteynfeld wrote:
> > Attached is the dmesg from patched kernel.
>
> Your Node1 physical memory range precedes Node0 which is quite unusual
> but it shouldn't be a huge problem on its own. But memory ranges are
> not
Could the unusual memory config be due to one empty DIMM slot on my
motherboard? I have 9 slots, but only 8 x 16G filled. The 6th slot
on the motherboard is empty -- which is a valid config according to
the manual.
On Fri, Jan 25, 2019 at 11:39 AM Michal Hocko wrote:
>
> On Fri 25-01-19 11:16:3
On Fri 25-01-19 11:16:30, robert shteynfeld wrote:
> Attached is the dmesg from patched kernel.
Your Node1 physical memory range precedes Node0 which is quite unusual
but it shouldn't be a huge problem on its own. But memory ranges are
not aligned to the memory section
[0.286954] Early memory
Attached is the dmesg from patched kernel.
I'm not an expert at debugging the kernel, obviously. I tried setting
up a serial console before without much luck as part of this debugging
session. I'll try again when I have some time, but I couldn't get to
the exact message before -- it scrolled by
On Fri 25-01-19 10:52:06, robert shteynfeld wrote:
> The person who pointed to mm/page_alloc.c commits likely causing the
> issue did not have time to build a patched/reverted kernel to confirm
> his hypothesis. When I tried backing out the two separate commits he
> suggested, the first commit (ie
The person who pointed to mm/page_alloc.c commits likely causing the
issue did not have time to build a patched/reverted kernel to confirm
his hypothesis. When I tried backing out the two separate commits he
suggested, the first commit (ie. the one in the subject) was the one
that when backed out
On Fri 25-01-19 09:19:24, Michal Hocko wrote:
> On Fri 25-01-19 08:37:04, Michal Hocko wrote:
> > On Fri 25-01-19 17:48:32, Linus Torvalds wrote:
> > > [ Just adding a lot of other people to the cc ]
> > >
> > > Robert, could you add a dmesg of a successful boot to that bugzilla,
> > > or just as
On Fri 25-01-19 08:37:04, Michal Hocko wrote:
> On Fri 25-01-19 17:48:32, Linus Torvalds wrote:
> > [ Just adding a lot of other people to the cc ]
> >
> > Robert, could you add a dmesg of a successful boot to that bugzilla,
> > or just as an attachement in email to this group of people..
> >
> >
On Fri 25-01-19 17:48:32, Linus Torvalds wrote:
> [ Just adding a lot of other people to the cc ]
>
> Robert, could you add a dmesg of a successful boot to that bugzilla,
> or just as an attachement in email to this group of people..
>
> This looks to be with the Fedora kernel config. Two people
[ Just adding a lot of other people to the cc ]
Robert, could you add a dmesg of a successful boot to that bugzilla,
or just as an attachement in email to this group of people..
This looks to be with the Fedora kernel config. Two people reporting
it, it looks like similar machines.
I assume it's
On Fri, Jan 4, 2019 at 7:05 PM Stefano Brivio wrote:
>
> On Fri, 4 Jan 2019 18:26:16 +0100
> Dmitry Vyukov wrote:
>
> > On Fri, Jan 4, 2019 at 6:14 PM Stefano Brivio wrote:
> > >
> > > On Fri, 4 Jan 2019 12:05:04 +0100
> > > Dmitry Vyukov wrote:
> > >
> > > > I've added these as tests:
> > > >
On Fri, 4 Jan 2019 18:26:16 +0100
Dmitry Vyukov wrote:
> On Fri, Jan 4, 2019 at 6:14 PM Stefano Brivio wrote:
> >
> > On Fri, 4 Jan 2019 12:05:04 +0100
> > Dmitry Vyukov wrote:
> >
> > > I've added these as tests:
> > >
> > > https://github.com/google/syzkaller/blob/master/pkg/report/testdata/l
On Fri, 4 Jan 2019 12:24:18 -0500
Willem de Bruijn wrote:
> On Fri, Jan 4, 2019 at 12:14 PM Stefano Brivio wrote:
> >
> > On Fri, 4 Jan 2019 12:05:04 +0100
> > Dmitry Vyukov wrote:
> >
> > > On Fri, Jan 4, 2019 at 11:54 AM Stefano Brivio
> > > wrote:
> > > >
> > > > On Fri, 4 Jan 2019 11:
On Fri, Jan 4, 2019 at 6:14 PM Stefano Brivio wrote:
>
> On Fri, 4 Jan 2019 12:05:04 +0100
> Dmitry Vyukov wrote:
>
> > On Fri, Jan 4, 2019 at 11:54 AM Stefano Brivio wrote:
> > >
> > > On Fri, 4 Jan 2019 11:32:12 +0100
> > > Dmitry Vyukov wrote:
> > >
> > > > On Thu, Jan 3, 2019 at 10:54 PM St
On Fri, Jan 4, 2019 at 12:14 PM Stefano Brivio wrote:
>
> On Fri, 4 Jan 2019 12:05:04 +0100
> Dmitry Vyukov wrote:
>
> > On Fri, Jan 4, 2019 at 11:54 AM Stefano Brivio wrote:
> > >
> > > On Fri, 4 Jan 2019 11:32:12 +0100
> > > Dmitry Vyukov wrote:
> > >
> > > > On Thu, Jan 3, 2019 at 10:54 PM S
On Fri, 4 Jan 2019 12:05:04 +0100
Dmitry Vyukov wrote:
> On Fri, Jan 4, 2019 at 11:54 AM Stefano Brivio wrote:
> >
> > On Fri, 4 Jan 2019 11:32:12 +0100
> > Dmitry Vyukov wrote:
> >
> > > On Thu, Jan 3, 2019 at 10:54 PM Stefano Brivio
> > > wrote:
> > > >
> > > > On Thu, 3 Jan 2019 15:15:
On Thu, Aug 2, 2018 at 10:14 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:fea49f60c9b7 net: ethernet: ti: cpsw: replace unnecessaril..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16d5fae840
> kernel config:
On Fri, Jan 4, 2019 at 11:54 AM Stefano Brivio wrote:
>
> On Fri, 4 Jan 2019 11:32:12 +0100
> Dmitry Vyukov wrote:
>
> > On Thu, Jan 3, 2019 at 10:54 PM Stefano Brivio wrote:
> > >
> > > On Thu, 3 Jan 2019 15:15:06 -0600
> > > Willem de Bruijn wrote:
> > >
> > > > syzbot generated stack traces
On Fri, 4 Jan 2019 11:32:12 +0100
Dmitry Vyukov wrote:
> On Thu, Jan 3, 2019 at 10:54 PM Stefano Brivio wrote:
> >
> > On Thu, 3 Jan 2019 15:15:06 -0600
> > Willem de Bruijn wrote:
> >
> > > syzbot generated stack traces with
> > >
> > > [ 183.517380] udpv6_err+0x46/0x60
> > > [ 183.520739
On Fri, Jan 4, 2019 at 11:32 AM Dmitry Vyukov wrote:
>
> On Thu, Jan 3, 2019 at 10:54 PM Stefano Brivio wrote:
> >
> > On Thu, 3 Jan 2019 15:15:06 -0600
> > Willem de Bruijn wrote:
> >
> > > syzbot generated stack traces with
> > >
> > > [ 183.517380] udpv6_err+0x46/0x60
> > > [ 183.520739]
On Thu, Jan 3, 2019 at 10:54 PM Stefano Brivio wrote:
>
> On Thu, 3 Jan 2019 15:15:06 -0600
> Willem de Bruijn wrote:
>
> > syzbot generated stack traces with
> >
> > [ 183.517380] udpv6_err+0x46/0x60
> > [ 183.520739] ? __udp6_lib_err+0x1890/0x1890
> > [ 183.525054] gue6_err_proto_handler+
On Thu, 3 Jan 2019 15:15:06 -0600
Willem de Bruijn wrote:
> syzbot generated stack traces with
>
> [ 183.517380] udpv6_err+0x46/0x60
> [ 183.520739] ? __udp6_lib_err+0x1890/0x1890
> [ 183.525054] gue6_err_proto_handler+0x199/0x280
Where? I can't find that in any logs linked from the dashb
On Thu, Jan 3, 2019 at 2:07 PM Stefano Brivio wrote:
>
> On Thu, 3 Jan 2019 12:01:29 -0800
> Eric Dumazet wrote:
>
> > On 01/03/2019 05:07 AM, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:195303136f19 Merge tag 'kconfig-v4.21-2' of
> > >
On Thu, 3 Jan 2019 12:01:29 -0800
Eric Dumazet wrote:
> On 01/03/2019 05:07 AM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 195303136f19 Merge tag 'kconfig-v4.21-2' of git://git.kern..
> > git tree: upstream
> > console output: https://syz
1 - 100 of 436 matches
Mail list logo
