On Wed, 20 Dec 2017, at 3:14 PM, Tejun Heo wrote:
> On Tue, Dec 19, 2017 at 05:42:39AM -0800, Tejun Heo wrote:
> > On Sun, Dec 17, 2017 at 03:24:48PM -0800, vcap...@pengaru.com wrote:
> > > On Sun, Dec 17, 2017 at 05:49:44PM +0000, Bronek Kozicki wrote:
> > > > I jus
On 17/12/2017 23:24, vcap...@pengaru.com wrote:
On Sun, Dec 17, 2017 at 05:49:44PM +, Bronek Kozicki wrote:
I just upgraded to 4.14.7 and tried to reproduce this error, this time under
strace. As you can see this happens when systemctl tries to read a specific
entry under /sys/fs . In
FWIW, I can do "cat" . I get a single number seemingly followed by an
infinite stream of 0s (I tried wc -l, but did not want to wait very long
and killed it). Here is what it looks like, if limited by "head":
root@gdansk ~ # cat
'/sys/fs/cgroup/unified/machine.slice/machine-qemu\x2d1\x2dkartuzy\x2
On 17/12/2017 18:25, Randy Dunlap wrote:
On 12/17/2017 09:49 AM, Bronek Kozicki wrote:
I just upgraded to 4.14.7 and tried to reproduce this error, this time under
strace. As you can see this happens when systemctl tries to read a specific
entry under /sys/fs . In case this matters, the entry
I just upgraded to 4.14.7 and tried to reproduce this error, this time under
strace. As you can see this happens when systemctl tries to read a specific
entry under /sys/fs . In case this matters, the entry is for a small virtual
machine running under qemu/kvm and managed by libvirt.
open("/sy
This has happend again, and hopefully the report is not as mangled as
the previous one. I was also trying to start "systemctl status", only
once this time. The kernel build is different because I've just disabled
RCU tracing/debugging options. One more thing, this kernel was built with gcc
7.2.1
1:06:55,571722+ CR2: 00b0
2017-12-17T11:06:55,575101+0000 ---[ end trace 8979357ae8817e5c ]---
--
Bronek Kozicki
b...@incorrekt.com
config.gz
Description: GNU Zip compressed data
On 11/01/2017 15:50, Jiri Slaby wrote:
On 01/08/2017, 03:28 PM, Bronek Kozicki wrote:
Hello,
any particular reason why this fix
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79dc7e3f1cd323be4c81aa1a94faa1b3ed987fb2
was missed from stable 4.8 line? Apparently the
Hello,
any particular reason why this fix
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79dc7e3f1cd323be4c81aa1a94faa1b3ed987fb2
was missed from stable 4.8 line? Apparently the bug being fixed has its
own https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9919
On 27/08/2014 19:57, Alex Williamson wrote:
If we have a GPU on the PCI root bus that calls
drm_pcie_get_speed_cap_mask() we end up with a NULL pointer
dereference since pdev->bus->self is NULL. We already protect
against callers passing non-PCI devices, so let's also catch this
case and return
10 matches
Mail list logo
