Re: [PATCH] Make kernel taint on invalid module signatures configurable

fedoraproject.org/en-US/Fedora/23/html/System_Administrators_Guide/sect-kernel-module-authentication.html> and I'm trying to get my UEFI keys added to the Linux keyring. I want to sign my modules with that "external" key instead of embedding the key into the Linux kernel itself. Thanks in adva

Re: [PATCH] Make kernel taint on invalid module signatures configurable

ora/23/html/System_Administrators_Guide/sect-kernel-module-authentication.html> and I'm trying to get my UEFI keys added to the Linux keyring. I want to sign my modules with that "external" key instead of embedding the key into the Linux kernel itself. Thanks in advance. Philipp PS: I'm not

Re: [PATCH] namei: fix hardlink speeling error

Hello, Am 15.02.2018 um 03:28 schrieb Richard Guy Briggs: > Fix handlink to hardlink. and introduce a new sp*el*ling error in the subject line ;-) Philipp

Re: [PATCH] namei: fix hardlink speeling error

Hello, Am 15.02.2018 um 03:28 schrieb Richard Guy Briggs: > Fix handlink to hardlink. and introduce a new sp*el*ling error in the subject line ;-) Philipp

Re: [Xen-devel] 4.9.52: INFO: task X blocked for more than 300 seconds.

Hello Ankur, Am 05.10.2017 um 19:59 schrieb Ankur Arora: > On 2017-10-05 06:20 AM, Konrad Rzeszutek Wilk wrote: >> On Wed, Oct 04, 2017 at 08:26:27PM +0200, Philipp Hahn wrote: ... >> Adding Ankur to this as I think he saw something similar. >> >> But i

Re: [Xen-devel] 4.9.52: INFO: task X blocked for more than 300 seconds.

Hello Ankur, Am 05.10.2017 um 19:59 schrieb Ankur Arora: > On 2017-10-05 06:20 AM, Konrad Rzeszutek Wilk wrote: >> On Wed, Oct 04, 2017 at 08:26:27PM +0200, Philipp Hahn wrote: ... >> Adding Ankur to this as I think he saw something similar. >> >> But i

[RFH] 4.9.52: task blocked for more than 300 seconds - xen_clocksource_get_cycles?

0 > [] ? do_get_write_access+0x208/0x420 [jbd2] > [] ? jbd2_journal_get_write_access+0x2e/0x60 [jbd2] > [] ? __ext4_journal_get_write_access+0x36/0x70 [ext4] > [] ? ext4_orphan_add+0xd3/0x230 [ext4] > [] ? ext4_mark_inode_dirty+0x6a/0x200 [ext4] > [] ? ext4_unlink+0x36a/0x380 [e

[RFH] 4.9.52: task blocked for more than 300 seconds - xen_clocksource_get_cycles?

[ext4] > [] ? ext4_unlink+0x36a/0x380 [ext4] > [] ? vfs_unlink+0xe7/0x180 > [] ? do_unlinkat+0x289/0x300 > [] ? system_call_fast_compare_end+0xc/0x9b This does not look normal to me or did I miss something? Where can I get more information on why there is no progress for 300s, what sh

Re: OOPS: linux-4.9.33/fs/pnode.c:propagate_one()

Hello Eric, Am 03.10.2017 um 18:48 schrieb Eric W. Biederman: > ebied...@xmission.com (Eric W. Biederman) writes: > >> Philipp Hahn <h...@univention.de> writes: >> >>> We will try 4.9.52 next and see, if we can still reproduce it. > > Can you still rep

Re: OOPS: linux-4.9.33/fs/pnode.c:propagate_one()

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

OOPS: linux-4.9.33/fs/pnode.c:propagate_one()

t; 02ad <propagate_one+0x16d> jne 000002ee > <propagate_one+0x1ae> > 02af <propagate_one+0x16f> test %r8b,%r8b > 02b2 <propagate_one+0x172> jne0309 > <propagate_one+0x1c9> > 000

OOPS: linux-4.9.33/fs/pnode.c:propagate_one()

done = parent->mnt_master == p; > if (done && peers(n, parent)) > 000002a6 cmp0xd8(%rdx),%rdi > 02ad jne02ee > > 02af test %r8b,%r8b > 02b2 jne000

Re: [BUG] Slow SATA disk - waiting in balance_dirty_pages() on i686-pae.html

Hello, Am 02.08.2017 um 14:29 schrieb Michal Hocko: > On Tue 01-08-17 12:32:40, Philipp Hahn wrote: >> ;TL,DR: apt-get is blocked by balance_dirty_pages() with linux-{3,16 >> 4.2, 4.9}, but fast after reboot. >> >> >> We still have several systems running 4.9.0-uc

Re: [BUG] Slow SATA disk - waiting in balance_dirty_pages() on i686-pae.html

Hello, Am 02.08.2017 um 14:29 schrieb Michal Hocko: > On Tue 01-08-17 12:32:40, Philipp Hahn wrote: >> ;TL,DR: apt-get is blocked by balance_dirty_pages() with linux-{3,16 >> 4.2, 4.9}, but fast after reboot. >> >> >> We still have several systems running 4.9.0-uc

[BUG] Slow SATA disk - waiting in balance_dirty_pages() on i686-pae.html

[] ? block_page_mkwrite+0xe5/0x120 > [148498.778801] [] ? balance_dirty_pages_ratelimited+0x283/0x3c0 > [148498.778804] [] ? do_wp_page+0x6ac/0x7c0 > [148498.778807] [] ? kmap_atomic_prot+0xdb/0x100 > [148498.778810] [] ? handle_mm_fault+0x7e6/0x10d0 > [148498.778812] [] ? vfs_r

[BUG] Slow SATA disk - waiting in balance_dirty_pages() on i686-pae.html

[] ? block_page_mkwrite+0xe5/0x120 > [148498.778801] [] ? balance_dirty_pages_ratelimited+0x283/0x3c0 > [148498.778804] [] ? do_wp_page+0x6ac/0x7c0 > [148498.778807] [] ? kmap_atomic_prot+0xdb/0x100 > [148498.778810] [] ? handle_mm_fault+0x7e6/0x10d0 > [148498.778812] [] ? vfs_r

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

Hello, Am 18.06.2017 um 20:22 schrieb Philipp Hahn: > Am 17.06.2017 um 18:51 schrieb Laszlo Ersek: >> (I also recommend using the "vbindiff" tool for such problems, it is >> great for picking out patterns.) >> >> ** ** ** **

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

Hello, Am 18.06.2017 um 20:22 schrieb Philipp Hahn: > Am 17.06.2017 um 18:51 schrieb Laszlo Ersek: >> (I also recommend using the "vbindiff" tool for such problems, it is >> great for picking out patterns.) >> >> ** ** ** **

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

Am 18.06.2017 um 20:27 schrieb Dr. David Alan Gilbert: > * Philipp Hahn (h...@univention.de) wrote: >> Hello, >> >> Am 17.06.2017 um 18:51 schrieb Laszlo Ersek: >>> (I also recommend using the "vbindiff" tool for such problems,

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

Am 18.06.2017 um 20:27 schrieb Dr. David Alan Gilbert: > * Philipp Hahn (h...@univention.de) wrote: >> Hello, >> >> Am 17.06.2017 um 18:51 schrieb Laszlo Ersek: >>> (I also recommend using the "vbindiff" tool for such problems,

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

Hello, Am 17.06.2017 um 18:51 schrieb Laszlo Ersek: > (I also recommend using the "vbindiff" tool for such problems, it is > great for picking out patterns.) > > ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15 > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 01

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

Hello, Am 17.06.2017 um 18:51 schrieb Laszlo Ersek: > (I also recommend using the "vbindiff" tool for such problems, it is > great for picking out patterns.) > > ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15 > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 01

[RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

1:0 -device > cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device > intel-hda,id=sound0,bus=pci.0,addr=0x4 -device > hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -global > isa-debugcon.iobase=0x402 -debugcon file:/tmp/

[RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

1:0 -device > cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device > intel-hda,id=sound0,bus=pci.0,addr=0x4 -device > hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -global > isa-debugcon.iobase=0x402 -debugcon file:/tmp/

Re: bio linked list corruption.

t. Nearly a month ago I reported also a "list_add corruption", but with 4.1.6: <http://marc.info/?l=linux-kernel=147508265316854=2> That server rungs Samba4, which also is a heavy user of xattr. Might be that it is related. Philipp Hahn

Re: bio linked list corruption.

go I reported also a "list_add corruption", but with 4.1.6: <http://marc.info/?l=linux-kernel=147508265316854=2> That server rungs Samba4, which also is a heavy user of xattr. Might be that it is related. Philipp Hahn

4.1.16 crash: list_add corruption

do_IRQ+0x64/0x110 > [3689738.157797] [] ? common_interrupt+0x6e/0x6e Has anyone seen a similar issue and knows if it is fixed post 4.1.16? If you need more data, just ask and I will see what else I can gather. Thank you in advance. Philipp -- Philipp Hahn Open Source Software Engineer Uni

4.1.16 crash: list_add corruption

do_IRQ+0x64/0x110 > [3689738.157797] [] ? common_interrupt+0x6e/0x6e Has anyone seen a similar issue and knows if it is fixed post 4.1.16? If you need more data, just ask and I will see what else I can gather. Thank you in advance. Philipp -- Philipp Hahn Open Source Software Engineer Uni

Re: RFH: virnet: page allocation failure: order:0

Hello, Am 15.08.2016 um 15:26 schrieb Philipp Hahn: > this Sunday one of our virtual servers running linux-4.1.16 inside > OpenStack using qemu "crashed" while doing a backup using rsync to a > slow NFS server. This happened again last weekend, with the same stack tr

Re: RFH: virnet: page allocation failure: order:0

Hello, Am 15.08.2016 um 15:26 schrieb Philipp Hahn: > this Sunday one of our virtual servers running linux-4.1.16 inside > OpenStack using qemu "crashed" while doing a backup using rsync to a > slow NFS server. This happened again last weekend, with the same stack tr

virnet: page allocation failure: order:0

Hello, this Sunday one of our virtual servers running linux-4.1.16 inside OpenStack using qemu "crashed" while doing a backup using rsync to a slow NFS server. Crash here means that the server became unresponsive to network traffic: - it was no longer able to contact the two LDAP servers - no ssh

virnet: page allocation failure: order:0

Hello, this Sunday one of our virtual servers running linux-4.1.16 inside OpenStack using qemu "crashed" while doing a backup using rsync to a slow NFS server. Crash here means that the server became unresponsive to network traffic: - it was no longer able to contact the two LDAP servers - no ssh

Re: kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

Hello, Am 02.06.2016 um 22:02 schrieb J. Bruce Fields: > On Thu, Jun 02, 2016 at 09:51:27AM +0200, Philipp Hahn wrote: >> probably during heavy IO our file server crashed on a BUG_ON in dache.c, >> probably triggered by NFS: >> >>> [ cut here ]--

Re: kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

Hello, Am 02.06.2016 um 22:02 schrieb J. Bruce Fields: > On Thu, Jun 02, 2016 at 09:51:27AM +0200, Philipp Hahn wrote: >> probably during heavy IO our file server crashed on a BUG_ON in dache.c, >> probably triggered by NFS: >> >>> [ cut here ]--

kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

4 0f 1f 84 00 00 > 00 00 00 48 8b 1b 48 85 db 0f 84 84 00 00 00 4c 8d 63 f8 <8b> 43 fc 48 39 6b > 10 75 e7 48 83 7b 08 00 74 e0 89 c2 83 e2 fe The trace-back triggered by arch_trigger_all_cpu_backtrace() shows the following two functions in addition on top of link_path_walk(): >

kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

4 0f 1f 84 00 00 > 00 00 00 48 8b 1b 48 85 db 0f 84 84 00 00 00 4c 8d 63 f8 <8b> 43 fc 48 39 6b > 10 75 e7 48 83 7b 08 00 74 e0 89 c2 83 e2 fe The trace-back triggered by arch_trigger_all_cpu_backtrace() shows the following two functions in addition on top of link_path_walk(): >

Re: EXT4 bad block - ext4_xattr_block_get

Hello, Am 28.04.2016 um 11:44 schrieb Lay, Kuan Loon: > I encounter random bad block on different file, the message looks like > "EXT4-fs error (device mmcblk0p14): ext4_xattr_block_get:298: inode #77: comm > (syslogd): bad block 7288". Interesting; I posted a similar bug report on 2016-04-19

Re: EXT4 bad block - ext4_xattr_block_get

Hello, Am 28.04.2016 um 11:44 schrieb Lay, Kuan Loon: > I encounter random bad block on different file, the message looks like > "EXT4-fs error (device mmcblk0p14): ext4_xattr_block_get:298: inode #77: comm > (syslogd): bad block 7288". Interesting; I posted a similar bug report on 2016-04-19

[BUG 4.1.11] EXT4-fs error: ext4_xattr_block_get:299 - Remounting filesystem read-only

el.org/show_bug.cgi?id=107301>- Here smbd doesn't get stuck, but the fs gets mounted read-only. * There is <http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01585.html>, which has "ext4_xattr_block_get" in it, but is with 4.5. Any ideas? Philipp PS: I'm subscribed to LK

[BUG 4.1.11] EXT4-fs error: ext4_xattr_block_get:299 - Remounting filesystem read-only

el.org/show_bug.cgi?id=107301>- Here smbd doesn't get stuck, but the fs gets mounted read-only. * There is <http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01585.html>, which has "ext4_xattr_block_get" in it, but is with 4.5. Any ideas? Philipp PS: I'm subscribed to LK

[PATCH] [doc] Fix spelling mistakes in ABI/sysfs-class-net

Remove extra article and blank. --- Documentation/ABI/testing/sysfs-class-net | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net index 668604f..83f7894 100644 ---

[PATCH] [doc] Fix spelling mistakes in ABI/sysfs-class-net

Remove extra article and blank. --- Documentation/ABI/testing/sysfs-class-net | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net index 668604f..83f7894 100644 ---

Re: [PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

uard against this. > > Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue") > Reported-By: Philipp Hahn > Signed-off-by: Rainer Weikusat > --- > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c > index 29be035..f1ca279 100644 > --- a/n

Re: [PATCH 3.12 32/64] unix: properly account for FDs passed over unix sockets

Am 12.02.2016 um 08:57 schrieb Jiri Slaby: > On 02/11/2016, 06:32 PM, Willy Tarreau wrote: >> On Thu, Feb 11, 2016 at 02:59:08PM +0100, Jiri Slaby wrote: >>> From: willy tarreau >>> >>> 3.12-stable review patch. If anyone has any objections, please let me know. >>> >>> === >>> >>> [

Re: [PATCH 3.12 32/64] unix: properly account for FDs passed over unix sockets

Am 12.02.2016 um 08:57 schrieb Jiri Slaby: > On 02/11/2016, 06:32 PM, Willy Tarreau wrote: >> On Thu, Feb 11, 2016 at 02:59:08PM +0100, Jiri Slaby wrote: >>> From: willy tarreau >>> >>> 3.12-stable review patch. If anyone has any objections, please let me know. >>> >>>

Re: [PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

uard against this. > > Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue") > Reported-By: Philipp Hahn <pmh...@pmhahn.de> > Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> > --- > diff --git a/net/unix/af_unix.c b/net/

Re: Bug 4.1.16: self-detected stall in net/unix/?

Hi, Am 05.02.2016 um 16:28 schrieb Philipp Hahn: > Am 03.02.2016 um 02:43 schrieb Hannes Frederic Sowa: >> On 02.02.2016 17:25, Philipp Hahn wrote: >>> we recently updated our kernel to 4.1.16 + patch for "unix: properly >>> account for FDs passed over unix socke

Re: [GIT PULL] Miscellaneous keyrings and modsign fixes

into each branch without any fuzz. We hit that bug and Ubuntu did too: <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1494943> Thanks. Philipp Hahn

Re: [GIT PULL] Miscellaneous keyrings and modsign fixes

into each branch without any fuzz. We hit that bug and Ubuntu did too: <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1494943> Thanks. Philipp Hahn

Re: Bug 4.1.16: self-detected stall in net/unix/?

Hi, Am 05.02.2016 um 16:28 schrieb Philipp Hahn: > Am 03.02.2016 um 02:43 schrieb Hannes Frederic Sowa: >> On 02.02.2016 17:25, Philipp Hahn wrote: >>> we recently updated our kernel to 4.1.16 + patch for "unix: properly >>> account for FDs passed over unix socke

Re: Bug 4.1.16: self-detected stall in net/unix/?

Hello Hannes, thank you for your previous reply. Am 03.02.2016 um 02:43 schrieb Hannes Frederic Sowa: > On 02.02.2016 17:25, Philipp Hahn wrote: >> we recently updated our kernel to 4.1.16 + patch for "unix: properly >> account for FDs passed over unix sockets" an

Re: Bug 4.1.16: self-detected stall in net/unix/?

Hello Hannes, thank you for your previous reply. Am 03.02.2016 um 02:43 schrieb Hannes Frederic Sowa: > On 02.02.2016 17:25, Philipp Hahn wrote: >> we recently updated our kernel to 4.1.16 + patch for "unix: properly >> account for FDs passed over unix sockets" an

Bug 4.1.16: self-detected stall in net/unix/?

Hi, we recently updated our kernel to 4.1.16 + patch for "unix: properly account for FDs passed over unix sockets" and have since then self-detected stalls triggered by the Samba daemon: > Feb 1 09:03:14 dcs1 kernel: [ 1152.840007] INFO: rcu_sched self-detected > stall on CPU { 3} (t=162780

Bug 4.1.16: self-detected stall in net/unix/?

Hi, we recently updated our kernel to 4.1.16 + patch for "unix: properly account for FDs passed over unix sockets" and have since then self-detected stalls triggered by the Samba daemon: > Feb 1 09:03:14 dcs1 kernel: [ 1152.840007] INFO: rcu_sched self-detected > stall on CPU { 3} (t=162780

Re: Asterisk deadlocks since Kernel 4.1

Hello Stefan, Am 06.12.2015 um 21:56 schrieb Stefan Priebe: > i think i found the issue in 4.1 with netlink. Somebody made a mistake > while backporting or cherry-picking your patch "netlink: Fix autobind > race condition that leads to zero port ID" to 4.1. > > It misses a goto in 4.1. > > This

Re: Asterisk deadlocks since Kernel 4.1

Hello Stefan, Am 06.12.2015 um 21:56 schrieb Stefan Priebe: > i think i found the issue in 4.1 with netlink. Somebody made a mistake > while backporting or cherry-picking your patch "netlink: Fix autobind > race condition that leads to zero port ID" to 4.1. > > It misses a goto in 4.1. > > This

Re: Asterisk deadlocks since Kernel 4.1

Hi, Am 02.12.2015 um 10:45 schrieb Stefan Priebe - Profihost AG: > here are the results. > > It works with 4.1. > It works with 4.2. > It does not work with 4.1.13. the patches were first commitet in v4.3-rc3 and appear as backports only since v4.2.3 and v4.1.10 > git bisect tells me it

Re: Asterisk deadlocks since Kernel 4.1

Hi, Am 02.12.2015 um 12:40 schrieb Hannes Frederic Sowa: > Cool, thanks a lot. Does this patch make a difference? > > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c > index 59651af..278e94c 100644 > --- a/net/netlink/af_netlink.c > +++ b/net/netlink/af_netlink.c > @@ -1137,7

Re: Asterisk deadlocks since Kernel 4.1

Hi, Am 02.12.2015 um 10:45 schrieb Stefan Priebe - Profihost AG: > here are the results. > > It works with 4.1. > It works with 4.2. > It does not work with 4.1.13. the patches were first commitet in v4.3-rc3 and appear as backports only since v4.2.3 and v4.1.10 > git bisect tells me it

Re: Asterisk deadlocks since Kernel 4.1

Hi, Am 02.12.2015 um 12:40 schrieb Hannes Frederic Sowa: > Cool, thanks a lot. Does this patch make a difference? > > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c > index 59651af..278e94c 100644 > --- a/net/netlink/af_netlink.c > +++ b/net/netlink/af_netlink.c > @@ -1137,7

Strange PF_NETLINK NETLINK_ROUTE stall: netlink: Fix autobind race condition that leads to zero port ID

t leads to zero port ID > 62f43b5 netlink, mmap: transform mmap skb into full skb on taps ring I no longer have an idea where to look next, as something outside of af_netlink.c seems to have fixed the issue for at least 4.3. Any idea? Kernel: 4.1.12 (Debian) GLIBC: 2.13-38+deb7u8 CPU: Intel(R) Co

Strange PF_NETLINK NETLINK_ROUTE stall: netlink: Fix autobind race condition that leads to zero port ID

tlink/af_netlink.c > 326ce2c netlink: Trim skb to alloc size to avoid MSG_TRUNC > e2a3131 netlink: Replace rhash_portid with bound > 6e32e73 netlink: Fix autobind race condition that leads to zero port ID > 62f43b5 netlink, mmap: transform mmap skb into full skb on taps ring I no lon

Re: RFH: stale (f)lock in /proc/locks - process no longer exists

To answer my own question: Am 14.10.2015 um 10:30 schrieb Philipp Hahn: > I have several shell scripts using "/usr/bin/flock -x > /run/lock/jenkins-ip.lock" to acquiring the exclusive lock. Today they > hang, while the lock is owned by a process which no longer exist

RFH: stale (f)lock in /proc/locks - process no longer exists

Hi, I have several shell scripts using "/usr/bin/flock -x /run/lock/jenkins-ip.lock" to acquiring the exclusive lock. Today they hang, while the lock is owned by a process which no longer exists: # ls -i /run/lock/jenkins-ip.lock 766711440 /run/lock/jenkins-ip.lock # grep 766711440 /proc/locks

Re: RFH: stale (f)lock in /proc/locks - process no longer exists

To answer my own question: Am 14.10.2015 um 10:30 schrieb Philipp Hahn: > I have several shell scripts using "/usr/bin/flock -x > /run/lock/jenkins-ip.lock" to acquiring the exclusive lock. Today they > hang, while the lock is owned by a process which no longer exist

RFH: stale (f)lock in /proc/locks - process no longer exists

Hi, I have several shell scripts using "/usr/bin/flock -x /run/lock/jenkins-ip.lock" to acquiring the exclusive lock. Today they hang, while the lock is owned by a process which no longer exists: # ls -i /run/lock/jenkins-ip.lock 766711440 /run/lock/jenkins-ip.lock # grep 766711440 /proc/locks

core dump files do not include all CPU registers?

Hello Linux folk, while investigating some strange process crashes (SIGSEGV) we noticed that the core files generated by the Linux kernel (3.10-amd64) do not include all CPU registers; here namely the SSE2 (FPREGSET?) related registers: # eu-readelf --notes core ... CORE 336

core dump files do not include all CPU registers?

Hello Linux folk, while investigating some strange process crashes (SIGSEGV) we noticed that the core files generated by the Linux kernel (3.10-amd64) do not include all CPU registers; here namely the SSE2 (FPREGSET?) related registers: # eu-readelf --notes core ... CORE 336

Re: KVM: x86: handle idiv overflow at kvm_write_tsc for stable-3.10

Hello Marcelo, On 03.09.2014 20:42, Marcelo Tosatti wrote: > On Wed, Sep 03, 2014 at 10:16:40AM +0200, Philipp Hahn wrote: >> can we please 8915aa27d5efbb9185357175b0acf884325565f9 get applied to >> 3.10 too? >> >>> commit 8915aa27d5efbb9185357175b0acf884325565

Re: KVM: x86: handle idiv overflow at kvm_write_tsc for stable-3.10

Hello Marcelo, On 03.09.2014 20:42, Marcelo Tosatti wrote: On Wed, Sep 03, 2014 at 10:16:40AM +0200, Philipp Hahn wrote: can we please 8915aa27d5efbb9185357175b0acf884325565f9 get applied to 3.10 too? commit 8915aa27d5efbb9185357175b0acf884325565f9 Author: Marcelo Tosatti mtosa