On Wed, Nov 25, 2020 at 2:11 AM Oleksandr Natalenko
wrote:
>
> Hello.
>
> On 25.11.2020 09:32, Greg Kroah-Hartman wrote:
> > On Tue, Nov 24, 2020 at 10:24:27PM +0100, Oleksandr Natalenko wrote:
> >> Hi.
> >>
> >> On 24.11.2020 15:23, Ard Biesheuvel wrote:
> >> > Surely caused by
> >> >
> >> > http
Hello.
On 25.11.2020 09:32, Greg Kroah-Hartman wrote:
On Tue, Nov 24, 2020 at 10:24:27PM +0100, Oleksandr Natalenko wrote:
Hi.
On 24.11.2020 15:23, Ard Biesheuvel wrote:
> Surely caused by
>
>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/efivarfs?id=fe5186cf12e
On Tue, Nov 24, 2020 at 10:24:27PM +0100, Oleksandr Natalenko wrote:
> Hi.
>
> On 24.11.2020 15:23, Ard Biesheuvel wrote:
> > Surely caused by
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/efivarfs?id=fe5186cf12e30facfe261e9be6c7904a170bd822
>
> This also s
Hi.
On 24.11.2020 15:23, Ard Biesheuvel wrote:
Surely caused by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/efivarfs?id=fe5186cf12e30facfe261e9be6c7904a170bd822
This also soaked through the stable queue into v5.9.11, and now the same
BUG is triggered in the l
From: Ard Biesheuvel
> Sent: 24 November 2020 15:02
> On Tue, 24 Nov 2020 at 15:58, David Laight wrote:
> >
> > From: Ard Biesheuvel
> > > Sent: 24 November 2020 14:24
> > >
> > > On Tue, 24 Nov 2020 at 15:22, David Laight
> > > wrote:
> > > >
> > > > I've just updated to the head of Linus's tre
On Tue, 24 Nov 2020 at 15:58, David Laight wrote:
>
> From: Ard Biesheuvel
> > Sent: 24 November 2020 14:24
> >
> > On Tue, 24 Nov 2020 at 15:22, David Laight wrote:
> > >
> > > I've just updated to the head of Linus's tree (5.10-rc5) and got the
> > > following
> > > 'splat' during shutdown.
>
From: Ard Biesheuvel
> Sent: 24 November 2020 14:24
>
> On Tue, 24 Nov 2020 at 15:22, David Laight wrote:
> >
> > I've just updated to the head of Linus's tree (5.10-rc5) and got the
> > following
> > 'splat' during shutdown.
> >
> > Userspace is Ubuntu 20.04.
> >
> > rc4 rebooted fine.
> >
> >
From: Ard Biesheuvel
> Sent: 24 November 2020 14:24
>
> On Tue, 24 Nov 2020 at 15:22, David Laight wrote:
> >
> > I've just updated to the head of Linus's tree (5.10-rc5) and got the
> > following
> > 'splat' during shutdown.
> >
> > Userspace is Ubuntu 20.04.
Anyone from ubuntu know how to get
On Tue, 24 Nov 2020 at 15:22, David Laight wrote:
>
> I've just updated to the head of Linus's tree (5.10-rc5) and got the following
> 'splat' during shutdown.
>
> Userspace is Ubuntu 20.04.
>
> rc4 rebooted fine.
>
> I'll try to bisect - but it isn't quick.
>
Surely caused by
https://git.kernel
On Mon, Aug 17, 2020 at 10:44:57AM -0300, Marcelo Ricardo Leitner wrote:
> On Sun, Aug 16, 2020 at 06:06:24PM -0500, Corey Minyard wrote:
> > I'm seeing the following when an SCTP connection terminates. This is on
> > Raspian on a Raspberry Pi, version is Linux version 5.4.51-v7+. That's
> > 32-b
On Sun, Aug 16, 2020 at 06:06:24PM -0500, Corey Minyard wrote:
> I'm seeing the following when an SCTP connection terminates. This is on
> Raspian on a Raspberry Pi, version is Linux version 5.4.51-v7+. That's
> 32-bit ARM.
>
> I haven't looked into it yet, I thought I would report before trying
On Sun, Jul 19, 2020 at 5:47 PM Bhaskar Chowdhury wrote:
>
>CLEAN arch/x86/entry/vdso
>make[3]: *** arch/x86/platform/sfi/Makefile: Input/output error.
>Stop.
That _sounds_ like filesystem corruption on your end. EIO isn't
exactly the usual "it won't compile" problem.
On 16:03 Sun 19 Jul 2020, Linus Torvalds wrote:
Things continue to look very normal, even if this is a big release.
rc6 is pretty much par for the course, and nothing in here stands out
size-wise or otherwise.
The stats all look normal, with a fairly flat diffstat (so no huge
hotspots, no big sc
On Fri, 2020-05-29 at 09:45 +0200, Takashi Iwai wrote:
> On Fri, 29 May 2020 09:33:34 +0200,
> Roberto Sassu wrote:
> >
> > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > On Thu, 28 May 2020 19:36:55 +0200,
> > > Roberto Sassu wrote:
> > > >
> > > > > From: linux-integrity-ow...@vger.kernel.org
On Fri, 29 May 2020 09:33:34 +0200,
Roberto Sassu wrote:
>
> > From: Takashi Iwai [mailto:ti...@suse.de]
> > On Thu, 28 May 2020 19:36:55 +0200,
> > Roberto Sassu wrote:
> > >
> > > > From: linux-integrity-ow...@vger.kernel.org [mailto:linux-integrity-
> > > > ow...@vger.kernel.org] On Behalf Of T
> From: Takashi Iwai [mailto:ti...@suse.de]
> On Thu, 28 May 2020 19:36:55 +0200,
> Roberto Sassu wrote:
> >
> > > From: linux-integrity-ow...@vger.kernel.org [mailto:linux-integrity-
> > > ow...@vger.kernel.org] On Behalf Of Takashi Iwai
> > > On Thu, 28 May 2020 17:35:16 +0200,
> > > Takashi Iwai
On Thu, 28 May 2020 19:36:55 +0200,
Roberto Sassu wrote:
>
> > From: linux-integrity-ow...@vger.kernel.org [mailto:linux-integrity-
> > ow...@vger.kernel.org] On Behalf Of Takashi Iwai
> > On Thu, 28 May 2020 17:35:16 +0200,
> > Takashi Iwai wrote:
> > >
> > > Hi Roberto,
> > >
> > > it seems that
> From: linux-integrity-ow...@vger.kernel.org [mailto:linux-integrity-
> ow...@vger.kernel.org] On Behalf Of Takashi Iwai
> On Thu, 28 May 2020 17:35:16 +0200,
> Takashi Iwai wrote:
> >
> > Hi Roberto,
> >
> > it seems that the recent changes in IMA in linux-next caused a
> > regression: namely it
On Thu, 28 May 2020 17:35:16 +0200,
Takashi Iwai wrote:
>
> Hi Roberto,
>
> it seems that the recent changes in IMA in linux-next caused a
> regression: namely it triggers an Oops when booting with the options
> ima_policy=tcb ima_template_fmt='d-ng|n-ng|d|ng'
And further experiment revealed t
Hi Hillf,
Would you like to me to put you down as the author of this patch? If so, I'll
need a Signed-off-by from you.
David
---
commit df882ad6d4e24a3763719c1798ea58e87d56c2d7
Author: Hillf Danton
Date: Fri Aug 30 15:54:33 2019 +0100
keys: Fix missing null pointer check in request_key_a
> On 30-Aug-2019, at 8:43 PM, David Howells wrote:
>
> Can you try this patch instead of Hillf’s?
Works for me. Test ran fine without any problem.
Tested-by: Sachin Sant
Thanks
-Sachin
Can you try this patch instead of Hillf's?
David
---
commit df882ad6d4e24a3763719c1798ea58e87d56c2d7
Author: Hillf Danton
Date: Fri Aug 30 15:54:33 2019 +0100
keys: Fix missing null pointer check in request_key_auth_describe()
If a request_key authentication token key gets revoked
Hillf Danton wrote:
> 1, callee has no pre defined duty to help caller in general; they should not
> try to do anything, however, to help their callers in principle due to
> limited info on their hands IMO.
Ah, no. It's entirely reasonable for an API to specify that one of its
methods will be c
Hillf Danton wrote:
> - struct request_key_auth *rka = dereference_key_rcu(key);
> + struct request_key_auth *rka;
> +
> + rcu_read_lock();
> + rka = dereference_key_rcu(key);
This shouldn't help as the caller, proc_keys_show(), is holding the RCU read
lock across the call. The
> On 30-Aug-2019, at 2:26 PM, Hillf Danton wrote:
>
>
> On Fri, 30 Aug 2019 12:18:07 +0530 Sachin Sant wrote:
>>
>> [ 8074.351033] BUG: Kernel NULL pointer dereference at 0x0038
>> [ 8074.351046] Faulting instruction address: 0xc04ddf30
>> [ 8074.351052] Oops: Kernel access of ba
+++ Josh Poimboeuf [29/05/19 12:39 -0500]:
On Wed, May 29, 2019 at 07:29:04PM +0200, Jessica Yu wrote:
+++ Josh Poimboeuf [21/05/19 11:42 -0500]:
> On Tue, May 21, 2019 at 10:42:04AM -0400, Steven Rostedt wrote:
> > On Tue, 21 May 2019 09:16:29 -0500
> > Josh Poimboeuf wrote:
> >
> > > > Hmm, t
On Wed, May 29, 2019 at 07:29:04PM +0200, Jessica Yu wrote:
> +++ Josh Poimboeuf [21/05/19 11:42 -0500]:
> > On Tue, May 21, 2019 at 10:42:04AM -0400, Steven Rostedt wrote:
> > > On Tue, 21 May 2019 09:16:29 -0500
> > > Josh Poimboeuf wrote:
> > >
> > > > > Hmm, this may blow up with lockdep, as
+++ Josh Poimboeuf [21/05/19 11:42 -0500]:
On Tue, May 21, 2019 at 10:42:04AM -0400, Steven Rostedt wrote:
On Tue, 21 May 2019 09:16:29 -0500
Josh Poimboeuf wrote:
> > Hmm, this may blow up with lockdep, as I believe we already have a
> > locking dependency of:
> >
> > text_mutex -> ftrace_lo
On Wed, May 29, 2019 at 08:06:48AM -0400, Steven Rostedt wrote:
> On Wed, 29 May 2019 13:17:21 +0200 (CEST)
> Jiri Kosina wrote:
>
> > > > From: Josh Poimboeuf
> > > > Subject: [PATCH] livepatch: Fix ftrace module text permissions race
> > >
> > > Thanks,
> > >
> > > I'll try to find some ti
On Wed, 29 May 2019 13:17:21 +0200 (CEST)
Jiri Kosina wrote:
> > > From: Josh Poimboeuf
> > > Subject: [PATCH] livepatch: Fix ftrace module text permissions race
> >
> > Thanks,
> >
> > I'll try to find some time to test this as well.
>
> Steve, Jessica, any final word on this?
I was und
On Tue, 21 May 2019, Steven Rostedt wrote:
> > Hm. I suppose using ftrace_lock might be less risky since that lock
> > is only used internally by ftrace (up until now). But I think it
> > would also make less sense because the text_mutex is supposed to
> > protect code patching. And presumab
On Tue, May 21, 2019 at 11:42:27AM -0500, Josh Poimboeuf wrote:
> void module_enable_ro(const struct module *mod, bool after_init)
> {
> + lockdep_assert_held(&text_mutex);
> +
This assertion fails, it turns out the module code also calls this
function (oops). I may move the meat of this fu
On Tue, May 21, 2019 at 03:27:47PM -0400, Joe Lawrence wrote:
> BTW, livepatching folks -- speaking of this window, does it make sense for
> klp_init_object_loaded() to unconditionally frob the module section
> permissions? Should it only bother iff it's going to apply
> relocations/alternatives/p
On 5/20/19 5:19 PM, Joe Lawrence wrote:
On 5/20/19 5:09 PM, Johannes Erdfelt wrote:
On Mon, May 20, 2019, Joe Lawrence wrote:
These two testing scenarios might be interesting to add to our selftests
suite. Can you post or add the source(s) to livepatch-test.ko to the
tarball?
I made the liv
On Tue, 21 May 2019 11:42:27 -0500
Josh Poimboeuf wrote:
> Hm. I suppose using ftrace_lock might be less risky since that lock is
> only used internally by ftrace (up until now). But I think it would
> also make less sense because the text_mutex is supposed to protect code
> patching. And pres
On Tue, May 21, 2019 at 10:42:04AM -0400, Steven Rostedt wrote:
> On Tue, 21 May 2019 09:16:29 -0500
> Josh Poimboeuf wrote:
>
> > > Hmm, this may blow up with lockdep, as I believe we already have a
> > > locking dependency of:
> > >
> > > text_mutex -> ftrace_lock
> > >
> > > And this will r
On Tue, 21 May 2019 09:16:29 -0500
Josh Poimboeuf wrote:
> > Hmm, this may blow up with lockdep, as I believe we already have a
> > locking dependency of:
> >
> > text_mutex -> ftrace_lock
> >
> > And this will reverses it. (kprobes appears to take the locks in this
> > order).
> >
> > Perhap
On Mon, May 20, 2019 at 05:39:10PM -0400, Steven Rostedt wrote:
> On Mon, 20 May 2019 16:19:31 -0500
> Josh Poimboeuf wrote:
>
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index a12aff849c04..8259d4ba8b00 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
On Mon, May 20, 2019, Josh Poimboeuf wrote:
> I think you must have been looking at an old version.
>
> [(v5.2-rc1)] ~/git/linux $ grep jeyu MAINTAINERS
> M:Jessica Yu
Operator error on my part. I was looking at a different directory with
an old branch checked out. Sorry!
> Can you try thi
On Mon, 20 May 2019 16:19:31 -0500
Josh Poimboeuf wrote:
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index a12aff849c04..8259d4ba8b00 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
>
On Mon, May 20, 2019 at 02:09:05PM -0700, Johannes Erdfelt wrote:
> On Mon, May 20, 2019, Joe Lawrence wrote:
> > [ fixed jeyu's email address ]
>
> Thank you, the bounce message made it seem like my mail server was
> blocked and not that the address didn't exist.
>
> I think MAINTAINERS needs a
On 5/20/19 5:09 PM, Johannes Erdfelt wrote:
On Mon, May 20, 2019, Joe Lawrence wrote:
[ fixed jeyu's email address ]
Thank you, the bounce message made it seem like my mail server was
blocked and not that the address didn't exist.
I think MAINTAINERS needs an update since it still has the @r
On Mon, May 20, 2019, Joe Lawrence wrote:
> [ fixed jeyu's email address ]
Thank you, the bounce message made it seem like my mail server was
blocked and not that the address didn't exist.
I think MAINTAINERS needs an update since it still has the @redhat.com
address.
> On 5/20/19 3:49 PM, Joha
[ fixed jeyu's email address ]
On 5/20/19 3:49 PM, Johannes Erdfelt wrote:
[ ... snip ... ]
I have put together a test case that can reproduce the crash using
KVM. The tarball includes a minimal kernel and initramfs, along with
a script to run qemu and the .config used to build the kernel. By
d
Thanks! I just tested the patch with 4.19.36 and it works for me.
On Wed, Apr 24, 2019 at 7:04 PM Greg KH wrote:
>
> On Wed, Apr 24, 2019 at 06:59:09PM +0200, Ambrož Bizjak wrote:
> > Hi everyone,
> >
> > This buggy i2c patch (see https://lkml.org/lkml/2018/10/27/248) has
> > just landed in stabl
On Wed, Apr 24, 2019 at 06:59:09PM +0200, Ambrož Bizjak wrote:
> Hi everyone,
>
> This buggy i2c patch (see https://lkml.org/lkml/2018/10/27/248) has
> just landed in stable 4.19.36 without the appropriate fix, causing
> oops on boot on many machines. For example we're experiencing this
> issue wi
Hi everyone,
This buggy i2c patch (see https://lkml.org/lkml/2018/10/27/248) has
just landed in stable 4.19.36 without the appropriate fix, causing
oops on boot on many machines. For example we're experiencing this
issue with the NixOS distribution
(https://github.com/NixOS/nixpkgs/issues/60126).
Greg Kroah-Hartman wrote:
> And, if you want my larger fix that I will be sending to netdev one of
> these days, here's that one. It includes the above patch as part of it.
That works.
Tested-by: David Howells
On Tue, Feb 12, 2019 at 04:04:59PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 12, 2019 at 02:57:34PM +, David Howells wrote:
> > Greg Kroah-Hartman wrote:
> >
> > > - if (!xprt->debugfs) {
> > > + if (IS_ERR_OR_NULL(xprt->debugfs)) {
> >
> > That works, though I don't much like the idea
On Tue, Feb 12, 2019 at 02:57:34PM +, David Howells wrote:
> Greg Kroah-Hartman wrote:
>
> > - if (!xprt->debugfs) {
> > + if (IS_ERR_OR_NULL(xprt->debugfs)) {
>
> That works, though I don't much like the idea of there being an error there.
>
> Looking in rpc_xprt_debugfs_register() the
On Tue, Feb 12, 2019 at 03:42:14PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 12, 2019 at 03:37:20PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Feb 12, 2019 at 02:31:14PM +, David Howells wrote:
> > > I've bisected an oops that occurs in rpc_clnt_debugfs_register() trying to
> > > derefer
Greg Kroah-Hartman wrote:
> - if (!xprt->debugfs) {
> + if (IS_ERR_OR_NULL(xprt->debugfs)) {
That works, though I don't much like the idea of there being an error there.
Looking in rpc_xprt_debugfs_register() there are two now-dodgy looking checks
on the result of debugfs calls.
David
On Tue, Feb 12, 2019 at 03:37:20PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 12, 2019 at 02:31:14PM +, David Howells wrote:
> > I've bisected an oops that occurs in rpc_clnt_debugfs_register() trying to
> > dereference a pointer with -EACCES in it. This is the causing commit,
> > though
On Tue, Feb 12, 2019 at 02:31:14PM +, David Howells wrote:
> I've bisected an oops that occurs in rpc_clnt_debugfs_register() trying to
> dereference a pointer with -EACCES in it. This is the causing commit, though
> I suspect the bug is in sunrpc expecting to see NULL rather than an error.
>
On Wed, Nov 28, 2018 at 08:50:39AM +, Willy Wolff wrote:
> I got a Oops when the hard drive was COMPLETELY full using a ext4 fs.
> After it, any command on the directory where the last write should have
> occurred freezes, while any other directory behave just fine.
Was this true after you re
On Wed, Nov 28, 2018 at 08:50:39AM +, Willy Wolff wrote:
> Hi,
> I got a Oops when the hard drive was COMPLETELY full using a ext4 fs.
> After it, any command on the directory where the last write should have
> occurred freezes, while any other directory behave just fine.
>
> If this email is
On Thu, Nov 15, 2018 at 8:29 PM Kyle Sanderson wrote:
>
> 2008(!) dual-core Atom box.
> [1027541.963573] BUG: unable to handle kernel paging request at
> b0428a44
> [1027541.963647] IP: format_decode+0x20/0x3d0
The code decodes to:
0: 55push %rbp
1: 48 8d 2e
Hi,
On Sun, Oct 28, 2018 at 11:45 AM Hans de Goede wrote:
>
> Hi Linus,
>
> On 27-10-18 18:08, Linus Torvalds wrote:
> > Julian, Jiri,
> > On my laptop I'm getting a kernel page fault with the current git
> > tree, and I'm tentatively blaming commit
> >
> >9ee3e06610fd ("HID: i2c-hid: overr
Hi Linus,
On 27-10-18 18:08, Linus Torvalds wrote:
Julian, Jiri,
On my laptop I'm getting a kernel page fault with the current git
tree, and I'm tentatively blaming commit
9ee3e06610fd ("HID: i2c-hid: override HID descriptors for certain devices")
but that's simply because it's the only t
On Sat, Oct 27, 2018 at 9:08 AM Linus Torvalds
wrote:
>
> I *think* the problem is that the i2c_hid_dmi_desc_override_table[]
> isn't terminated by a NULL entry, and I will test that next.
Confirmed. That makes my laptop boot cleanly.
See commit b59dfdaef173 ("i2c-hid: properly terminate
i2c_hi
On Sat, 27 Oct 2018, Linus Torvalds wrote:
> I *think* the problem is that the i2c_hid_dmi_desc_override_table[]
> isn't terminated by a NULL entry, and I will test that next.
Hm, that almost certainly is indeed the issue, thanks a lot for reporting
it.
> What makes me *very* unhappy about this
On 5/4/18 6:35 PM, Ben Greear wrote:
> Hello,
>
> I am trying to bisect a pktgen related performance regression that appears to
> be between the 4.13 and 4.14 kernels. But, my system keeps crashing due to
> part_in_flight
> oops so bisecting is not going well.
>
> It looks like this oops was fi
Hello,
I am trying to bisect a pktgen related performance regression that appears to
be between the 4.13 and 4.14 kernels. But, my system keeps crashing due to
part_in_flight
oops so bisecting is not going well.
It looks like this oops was fixed, but the link to the patch in the email is no
l
On 11/12/17 17:17, Bjorn Helgaas wrote:
> [+cc linux-pci]
>
> On Mon, Dec 11, 2017 at 11:29:50AM -0500, Sinan Kaya wrote:
>> Hi Chris,
>>
>>>
>>> I'm more than happy to provide additional diagnostics and test proposed
>>> fixes. As a starter for ten, I've attached the
>>> output from 'lspci -v'.
On 11/12/17 17:24, Sinan Kaya wrote:
> On 12/11/2017 12:06 PM, Chris Clayton wrote:
>> Here's the output of dmesg for 4.15.0-rc3. I'll open a bugzilla later and
>> add this and the lspci output that I sent with
>> my original repoart.
>
> This was helpful. I don't see any AER/DPC in your log. I
On 12/11/2017 12:06 PM, Chris Clayton wrote:
> Here's the output of dmesg for 4.15.0-rc3. I'll open a bugzilla later and add
> this and the lspci output that I sent with
> my original repoart.
This was helpful. I don't see any AER/DPC in your log. It looks like the only
PCIe
portdrv service you
[+cc linux-pci]
On Mon, Dec 11, 2017 at 11:29:50AM -0500, Sinan Kaya wrote:
> Hi Chris,
>
> >
> > I'm more than happy to provide additional diagnostics and test proposed
> > fixes. As a starter for ten, I've attached the
> > output from 'lspci -v'. If, however, you need to see the backtrace, I'
On 11/12/17 16:29, Sinan Kaya wrote:
> Hi Chris,
>
>>
>> I'm more than happy to provide additional diagnostics and test proposed
>> fixes. As a starter for ten, I've attached the
>> output from 'lspci -v'. If, however, you need to see the backtrace, I'll
>> need some advice on how to capture t
Hi Chris,
>
> I'm more than happy to provide additional diagnostics and test proposed
> fixes. As a starter for ten, I've attached the
> output from 'lspci -v'. If, however, you need to see the backtrace, I'll need
> some advice on how to capture that.
>
Can you open a bugzilla and also share
On Wed, Nov 08, 2017 at 02:26:34PM +0100, Rasmus Villemoes wrote:
> Running current master (4.14.0-rc8-9-gfbc3edf) I can reproduce the
> below quite consistently, though there are some variations in the stack
> trace. It happens when I start and stop busybox watchdog on
> /dev/watchdog0 a few t
Hello Eric,
Am 03.10.2017 um 18:48 schrieb Eric W. Biederman:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> Philipp Hahn writes:
>>
>>> We will try 4.9.52 next and see, if we can still reproduce it.
>
> Can you still reproduce this on 4.9.52?
My college Dirk is able to reproduce it
ebied...@xmission.com (Eric W. Biederman) writes:
> Philipp Hahn writes:
>
>> We will try 4.9.52 next and see, if we can still reproduce it.
Can you still reproduce this on 4.9.52?
I am not seeing anything obvious that would result in last_source
becomming NULL there so knowing I am not looknin
Philipp Hahn writes:
> Hello Eric,
>
> we have observed the following OOPS with linux-4.9.33 on several
> occasions when starting a Docker container:
>
>> [ 531.801537] Oops: [#1] SMP
>> [ 531.801565] Modules linked in: xt_nat veth ipt_MASQUERADE
>> nf_nat_masquerade_ipv4 xfrm_user xfrm_a
list ; linux-
> bl...@vger.kernel.org; Don Brace ; Scott
> Benesh ; Scott Teel
> ; Kevin Barnett
> ; linux-s...@vger.kernel.org; Hannes
> Reinecke
> Subject: Re: device support in hpsa, was: Re: OOPS from cciss_ioctl in
> 4.12+git
>
> EXTERNAL EMAIL
>
>
>
> On Fri, Jul 07, 2017 at 11:42:38AM -0400, Laurence Oberman wrote:
> > What happens when hpsa_allow_any=1 with the Smart Array 64xx
> > It should probe.
>
> But only if it has a HP vendor ID as far as I can tell. We'd
> still need to add the compaq ids so that these controllers get
> probed. B
; Kevin Barnett
> ; linux-s...@vger.kernel.org
> Subject: Re: device support in hpasa, was: Re: OOPS from cciss_ioctl in
> 4.12+git
>
> EXTERNAL EMAIL
>
>
> On 07/07/2017 05:03 PM, Jens Axboe wrote:
> > On 07/07/2017 09:00 AM, Christoph Hellwig wrote:
> &g
On 07/07/2017 02:08 PM, Christoph Hellwig wrote:
On Fri, Jul 07, 2017 at 11:42:38AM -0400, Laurence Oberman wrote:
What happens when hpsa_allow_any=1 with the Smart Array 64xx
It should probe.
But only if it has a HP vendor ID as far as I can tell. We'd
still need to add the compaq ids so
On Fri, Jul 07, 2017 at 11:42:38AM -0400, Laurence Oberman wrote:
> What happens when hpsa_allow_any=1 with the Smart Array 64xx
> It should probe.
But only if it has a HP vendor ID as far as I can tell. We'd
still need to add the compaq ids so that these controllers get
probed. But maybe it's
On 07/07/2017 05:03 PM, Jens Axboe wrote:
> On 07/07/2017 09:00 AM, Christoph Hellwig wrote:
>> On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote:
Also we're trying to move people away from the cciss driver, can you
check if the hpsa SCSI driver works for you as well?
>>>
>>> I
On 07/07/2017 11:03 AM, Jens Axboe wrote:
On 07/07/2017 09:00 AM, Christoph Hellwig wrote:
On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote:
Also we're trying to move people away from the cciss driver, can you
check if the hpsa SCSI driver works for you as well?
I have older adap
On 07/07/2017 09:00 AM, Christoph Hellwig wrote:
> On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote:
>>> Also we're trying to move people away from the cciss driver, can you
>>> check if the hpsa SCSI driver works for you as well?
>>
>> I have older adapter:
>>
>> Compaq Computer Corpora
On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote:
> > Also we're trying to move people away from the cciss driver, can you
> > check if the hpsa SCSI driver works for you as well?
>
> I have older adapter:
>
> Compaq Computer Corporation Smart Array 64xx [0e11:0046] (rev 01)
>
> That
> Hi Meelis,
>
> can you try the patch below?
Yes, the OOPS is gone and everything seems to be working.
> Also we're trying to move people away from the cciss driver, can you
> check if the hpsa SCSI driver works for you as well?
I have older adapter:
Compaq Computer Corporation Smart Array 64
Hi Meelis,
can you try the patch below?
Also we're trying to move people away from the cciss driver, can you
check if the hpsa SCSI driver works for you as well?
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 02a611993bb4..678af946be30 100644
--- a/drivers/block/cciss.c
+++ b/d
Stephen Rothwell writes:
> On Fri, 16 Jun 2017 11:13:35 +1000 Stephen Rothwell
> wrote:
>> On Fri, 16 Jun 2017 10:57:22 +1000 Michael Ellerman
>> wrote:
>> > "Rowand, Frank" writes:
>> > > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem
>> > > [mailto:abdha...@linux.vnet.ibm.com] wrote:
Hi all,
On Fri, 16 Jun 2017 11:13:35 +1000 Stephen Rothwell
wrote:
>
> On Fri, 16 Jun 2017 10:57:22 +1000 Michael Ellerman
> wrote:
> >
> > "Rowand, Frank" writes:
> >
> > > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem
> > > [mailto:abdha...@linux.vnet.ibm.com] wrote:
> > >>
> >
Hi Michael,
On Fri, 16 Jun 2017 10:57:22 +1000 Michael Ellerman wrote:
>
> "Rowand, Frank" writes:
>
> > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem
> > [mailto:abdha...@linux.vnet.ibm.com] wrote:
> >>
> >> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
> >>>
> >>> linux-next
"Rowand, Frank" writes:
> On Thursday, June 15, 2017 2:25 AM, Abdul Haleem
> [mailto:abdha...@linux.vnet.ibm.com] wrote:
>>
>> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
>>> Hi,
>>>
>>> linux-next fails to boot on powerpc Bare-metal with these warnings.
>>>
>>> machine booted fine o
On Thu, 2017-06-15 at 17:06 +, Rowand, Frank wrote:
> On Thursday, June 15, 2017 2:25 AM, Abdul Haleem
> [mailto:abdha...@linux.vnet.ibm.com] wrote:
> >
> > On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
> > > Hi,
> > >
> > > linux-next fails to boot on powerpc Bare-metal with these
On Thursday, June 15, 2017 2:25 AM, Abdul Haleem
[mailto:abdha...@linux.vnet.ibm.com] wrote:
>
> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
>> Hi,
>>
>> linux-next fails to boot on powerpc Bare-metal with these warnings.
>>
>> machine booted fine on next-20170613
>
> Thanks Michael, Y
On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
> Hi,
>
> linux-next fails to boot on powerpc Bare-metal with these warnings.
>
> machine booted fine on next-20170613
Thanks Michael, Yes it is (75fe04e59 of: remove *phandle properties from
expanded device tree)
Frank, would you please ta
On 01/06/17 17:16, Nikolay Aleksandrov wrote:
> On 01/06/17 17:00, Nikolay Aleksandrov wrote:
>> On 01/06/17 15:34, Sebastian Ott wrote:
>>> On Thu, 1 Jun 2017, Xin Long wrote:
On Thu, Jun 1, 2017 at 12:32 AM, Sebastian Ott
wrote:
> [...]
I couldn't see any bridge-related thing
On 01/06/17 17:00, Nikolay Aleksandrov wrote:
> On 01/06/17 15:34, Sebastian Ott wrote:
>> On Thu, 1 Jun 2017, Xin Long wrote:
>>> On Thu, Jun 1, 2017 at 12:32 AM, Sebastian Ott
>>> wrote:
[...]
>>> I couldn't see any bridge-related thing here, and it couldn't be reproduced
>>> with virbr0 (s
On 01/06/17 15:34, Sebastian Ott wrote:
> On Thu, 1 Jun 2017, Xin Long wrote:
>> On Thu, Jun 1, 2017 at 12:32 AM, Sebastian Ott
>> wrote:
>>> [...]
>> I couldn't see any bridge-related thing here, and it couldn't be reproduced
>> with virbr0 (stp=1) on my box (on both s390x and x86_64), I guess th
On Thu, 1 Jun 2017, Xin Long wrote:
> On Thu, Jun 1, 2017 at 12:32 AM, Sebastian Ott
> wrote:
> > [...]
> I couldn't see any bridge-related thing here, and it couldn't be reproduced
> with virbr0 (stp=1) on my box (on both s390x and x86_64), I guess there
> is something else in you machine.
>
> W
On Thu, Jun 1, 2017 at 12:32 AM, Sebastian Ott
wrote:
[...]
>
> A system running v4.12-rc3-11-gf511c0b on s390 hangs after boot with no
> messages on the console. The message buffer obtained via a system dump
> looked like this:
>
> [...]
> [ 17.870712] virbr0: port 1(virbr0-nic) entered disable
On 2017-03-10 19:47:17 [+], Nicholas Mc Guire wrote:
>
> Hi !
Hello Nicholas,
> [ 5329.000726] EXT4-fs (sda2): unable to read superblock
> [ 5329.001648] EXT4-fs (sda2): unable to read superblock
> [ 5329.002564] EXT4-fs (sda2): unable to read superblock
> [ 5329.003584] FAT-fs (sda2): bogus
On Fri, 2017-03-10 at 19:47 +, Nicholas Mc Guire wrote:
> Has anyone seen 4.9.13-rt12 oopses related to ext4 or vfs in general ?
FWIW, here it's seen quite a bit of hefty use on boxen large and small
with no trouble. That said, @stable has a large pile queued for 4.9, 8
for ext4, some of wh
On Mon, Dec 5, 2016 at 3:53 PM, Laura Abbott wrote:
> This looks like an issue with CONFIG_VMAP_STACK since bond_enslave uses
> struct sockaddr from the stack and virtnet_set_mac_address calls
> sg_init_one which triggers BUG_ON(!virt_addr_valid(buf));
>
> I know there have been a lot of CONFIG_VM
Tejun Heo writes:
> Hello, Michael.
>
> On Tue, Oct 18, 2016 at 03:37:42PM +1100, Michael Ellerman wrote:
>> That doesn't compile, wq doesn't exist.
>>
>> I guessed that you meant:
>>
>> + wq_numa_init();
>> + list_for_each_entry(wq, &workqueues, list)
>> + wq_update_u
1 - 100 of 1275 matches
Mail list logo
