Re: Re: BUG: Bad rss-counter state (4)

(trimmed off the batman/bpf Ccs) On 2020-05-18 14:28, syzbot wrote: syzbot has bisected this bug to: commit 0d8dd67be013727ae57645ecd3ea2c36365d7da8 Author: Song Liu Date: Wed Dec 6 22:45:14 2017 + perf/headers: Sync new perf_event.h with the tools/include/uapi version bisection

Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018

(trimmed CCs) On 2021-03-23 19:32, Kirill A. Shutemov wrote: On Fri, Jun 12, 2020 at 02:26:58PM +0200, Rafael J. Wysocki wrote: On 6/11/2020 3:40 AM, Kaneda, Erik wrote: -Original Message- From: Vegard Nossum Sent: Friday, June 5, 2020 7:45 AM To: Vlastimil Babka ; Rafael J

Re: Minor RST rant

On 2020-08-06 08:48, Christoph Hellwig wrote: On Wed, Aug 05, 2020 at 05:12:30PM +0200, pet...@infradead.org wrote: On Wed, Aug 05, 2020 at 04:49:50PM +0200, Vegard Nossum wrote: FWIW, I *really* like how the extra markup renders in a browser, and I don't think I'm the only one. The thing

Re: Re: Minor RST rant

On 2020-07-29 14:44, pet...@infradead.org wrote: On Sat, Jul 25, 2020 at 09:46:55AM +1000, NeilBrown wrote: Constant names stand out least effectively by themselves. In kernel-doc comments they are preceded by a '%'. Would that make the text more readable for you? Does our doc

Re: [merged] exec-open-code-copy_string_kernel.patch removed from -mm tree

On 2020-06-05 22:19, a...@linux-foundation.org wrote: The patch titled Subject: exec: open code copy_string_kernel has been removed from the -mm tree. Its filename was exec-open-code-copy_string_kernel.patch This patch was dropped because it was merged into mainline or a

Re: WARNING: CPU: 1 PID: 52 at mm/page_alloc.c:4826 __alloc_pages_nodemask (Re: [PATCH 5/5] sysctl: pass kernel pointers to ->proc_handler)

On 2020-06-08 08:51, Christoph Hellwig wrote: On Thu, Jun 04, 2020 at 10:22:21PM +0200, Vegard Nossum wrote: It's easy to reproduce by just doing read(open("/proc/sys/vm/swappiness", O_RDONLY), 0, 512UL * 1024 * 1024 * 1024); or so. Reverting the commit fixes the issue for

Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018

On 2020-06-05 17:44, Kees Cook wrote: On Fri, Jun 05, 2020 at 04:44:51PM +0200, Vegard Nossum wrote: That's it :-) This fixes it for me: diff --git a/drivers/acpi/acpica/nsaccess.c b/drivers/acpi/acpica/nsaccess.c index 2566e2d4c7803..b76bbab917941 100644 --- a/drivers/acpi/acpica/nsaccess.c

Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018

On 2020-06-05 16:08, Vlastimil Babka wrote: On 6/5/20 3:12 PM, Rafael J. Wysocki wrote: On Fri, Jun 5, 2020 at 2:48 PM Vegard Nossum wrote: On 2020-06-05 11:36, Vegard Nossum wrote: On 2020-06-05 11:11, Vlastimil Babka wrote: On 6/4/20 8:46 PM, Vlastimil Babka wrote: On 6/4/20 7:57 PM

Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018

On 2020-06-05 11:36, Vegard Nossum wrote: On 2020-06-05 11:11, Vlastimil Babka wrote: On 6/4/20 8:46 PM, Vlastimil Babka wrote: On 6/4/20 7:57 PM, Kees Cook wrote: On Thu, Jun 04, 2020 at 07:20:18PM +0200, Vegard Nossum wrote: On 2020-06-04 19:18, Vlastimil Babka wrote: On 6/4/20 7:14 PM

Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018

On 2020-06-05 11:11, Vlastimil Babka wrote: On 6/4/20 8:46 PM, Vlastimil Babka wrote: On 6/4/20 7:57 PM, Kees Cook wrote: On Thu, Jun 04, 2020 at 07:20:18PM +0200, Vegard Nossum wrote: On 2020-06-04 19:18, Vlastimil Babka wrote: On 6/4/20 7:14 PM, Vegard Nossum wrote: Hi all, I ran

WARNING: CPU: 1 PID: 52 at mm/page_alloc.c:4826 __alloc_pages_nodemask (Re: [PATCH 5/5] sysctl: pass kernel pointers to ->proc_handler)

(Trimmed original Ccs due to outgoing email policy.) Hi, On 2020-04-24 08:43, Christoph Hellwig wrote: Instead of having all the sysctl handlers deal with user pointers, which is rather hairy in terms of the BPF interaction, copy the input to and from userspace in common code. This also

Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018

On 2020-06-04 19:18, Vlastimil Babka wrote: On 6/4/20 7:14 PM, Vegard Nossum wrote: Hi all, I ran into a boot problem with latest linus/master (6929f71e46bdddbf1c4d67c2728648176c67c555) that manifests like this: Hi, what's the .config you use? Pretty much x86_64 defconfig minus a few

slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018

Hi all, I ran into a boot problem with latest linus/master (6929f71e46bdddbf1c4d67c2728648176c67c555) that manifests like this: hpet0: 3 comparators, 64-bit 100.00 MHz counter clocksource: Switched to clocksource tsc-early BUG: unable to handle page fault for address: 3ffe0018

Re: [PATCH v10 00/18] Enable FSGSBASE instructions

On 5/10/20 10:09 AM, Vegard Nossum wrote: On 4/24/20 1:21 AM, Sasha Levin wrote: Benefits: Currently a user process that wishes to read or write the FS/GS base must make a system call. But recent X86 processors have added new instructions for use in 64-bit mode that allow direct access

Re: [PATCH v10 00/18] Enable FSGSBASE instructions

On 4/24/20 1:21 AM, Sasha Levin wrote: Benefits: Currently a user process that wishes to read or write the FS/GS base must make a system call. But recent X86 processors have added new instructions for use in 64-bit mode that allow direct access to the FS and GS segment base addresses. The

Re: email as a bona fide git transport

On 10/22/19 3:53 PM, Theodore Y. Ts'o wrote: On Tue, Oct 22, 2019 at 02:11:22PM +0200, Vegard Nossum wrote: As I wrote in there, we could already today start using git am --message-id when applying patches and this would provide something that a bot could annotate with git notes

email as a bona fide git transport

on and create a merge commit that encompasses the patches in the patchset (use sha1^- to view the patches in it). >From 622a0469a4970c5daac0c0323e2d6a77b3bebbdb Mon Sep 17 00:00:00 2001 From: Vegard Nossum Date: Sat, 5 Oct 2019 16:15:59 +0200 Subject: [PATCH 1/3] format-patch: add --complete Include the raw commit

Re: [PATCH v3 0/6] Tracing vs CR2

On 7/17/19 10:07 AM, Peter Zijlstra wrote: On Tue, Jul 16, 2019 at 09:33:50PM +0200, Vegard Nossum wrote: [ cut here ] General protection fault in user access. Non-canonical address? WARNING: CPU: 0 PID: 5039 at arch/x86/mm/extable.c:126 ex_handler_uaccess+0x5d/0x70

Re: [PATCH v3 0/6] Tracing vs CR2

On 7/17/19 3:02 AM, Andy Lutomirski wrote: On Tue, Jul 16, 2019 at 2:53 PM Vegard Nossum wrote: On 7/16/19 9:33 PM, Vegard Nossum wrote: On 7/11/19 1:40 PM, Peter Zijlstra wrote: Hi, Here's the latest (and hopefully final) set of tracing vs CR2 patches. They are basically the same

Re: [PATCH v3 0/6] Tracing vs CR2

On 7/16/19 9:33 PM, Vegard Nossum wrote: On 7/11/19 1:40 PM, Peter Zijlstra wrote: Hi, Here's the latest (and hopefully final) set of tracing vs CR2 patches. They are basically the same as v2, with only minor edits and tags collected from the last review. Please consider. Hi, I ran

Re: [PATCH v3 0/6] Tracing vs CR2

On 7/11/19 1:40 PM, Peter Zijlstra wrote: Hi, Here's the latest (and hopefully final) set of tracing vs CR2 patches. They are basically the same as v2, with only minor edits and tags collected from the last review. Please consider. Hi, I ran my own battery of tests on your patch set on

Re: [PATCH v8 4/5] x86/xsave: Make XSAVE check the base CPUID features before enabling

On 10/5/17 11:52 PM, Andi Kleen wrote: From: Andi Kleen Before enabling XSAVE, not only check the XSAVE specific CPUID bits, but also the base CPUID features of the respective XSAVE feature. This allows to disable individual XSAVE states using the existing clearcpuid= option, which can be

Re: [PATCH] mm, thp: Fix mlocking THP page with migration enabled

return 0; > } > > mlock(addr, 4UL << 10); > mbind(addr, 2UL << 20, MPOL_PREFERRED | MPOL_F_RELATIVE_NODES, > , 4, MPOL_MF_MOVE | MPOL_MF_MOVE_ALL); MPOL_MF_MOVE_ALL is actually not requ

Re: [PATCH] mm, thp: Fix mlocking THP page with migration enabled

return 0; > } > > mlock(addr, 4UL << 10); > mbind(addr, 2UL << 20, MPOL_PREFERRED | MPOL_F_RELATIVE_NODES, > , 4, MPOL_MF_MOVE | MPOL_MF_MOVE_ALL); MPOL_MF_MOVE_ALL is actually not requ

Re: v4.18.0+ WARNING: at mm/vmscan.c:1756 isolate_lru_page + bad page state

On Thu, 30 Aug 2018 at 15:31, Vegard Nossum wrote: > > Hi, > > Got this on a recent kernel (pretty sure it was > 2ad0d52699700a91660a406a4046017a2d7f246a but annoyingly the oops > itself doesn't tell me the exact version): > > [ cut here ] >

Re: v4.18.0+ WARNING: at mm/vmscan.c:1756 isolate_lru_page + bad page state

On Thu, 30 Aug 2018 at 15:31, Vegard Nossum wrote: > > Hi, > > Got this on a recent kernel (pretty sure it was > 2ad0d52699700a91660a406a4046017a2d7f246a but annoyingly the oops > itself doesn't tell me the exact version): > > [ cut here ] >

v4.18.0+ WARNING: at mm/vmscan.c:1756 isolate_lru_page + bad page state

Hi, Got this on a recent kernel (pretty sure it was 2ad0d52699700a91660a406a4046017a2d7f246a but annoyingly the oops itself doesn't tell me the exact version): [ cut here ] trying to isolate tail page WARNING: CPU: 2 PID: 19156 at mm/vmscan.c:1756

v4.18.0+ WARNING: at mm/vmscan.c:1756 isolate_lru_page + bad page state

Hi, Got this on a recent kernel (pretty sure it was 2ad0d52699700a91660a406a4046017a2d7f246a but annoyingly the oops itself doesn't tell me the exact version): [ cut here ] trying to isolate tail page WARNING: CPU: 2 PID: 19156 at mm/vmscan.c:1756

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

On 16 August 2018 at 17:42, Richard Weinberger wrote: > On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote: >> >> Hi Linus, >> >> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch. >> Unfortunately, this is no more available in the tip Git-tree. >> >> Then I saw Linux

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

On 16 August 2018 at 17:42, Richard Weinberger wrote: > On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote: >> >> Hi Linus, >> >> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch. >> Unfortunately, this is no more available in the tip Git-tree. >> >> Then I saw Linux

Re: [PATCH] fscache: fix a kernel BUG at fs/fscache/operation.c:69!

On 22 February 2018 at 08:33, wrote: > From: Lei Xue > > There is a potential race in fscache operation enqueuing for reading and > copying multiple pages from cachefiles to netfs. > Under some heavy load system, it will happen very often. > > If

Re: [PATCH] fscache: fix a kernel BUG at fs/fscache/operation.c:69!

On 22 February 2018 at 08:33, wrote: > From: Lei Xue > > There is a potential race in fscache operation enqueuing for reading and > copying multiple pages from cachefiles to netfs. > Under some heavy load system, it will happen very often. > > If this race occurs, an oops similar to the

Re: [PATCH 00/45] C++: Convert the kernel to C++

On 1 April 2018 at 22:40, David Howells wrote: > > Here are a series of patches to start converting the kernel to C++. It > requires g++ v8. Nice! I tried something similar a few years ago, but I don't think it was nearly as neat. I did get RTTI and exceptions to work

Re: [PATCH 00/45] C++: Convert the kernel to C++

On 1 April 2018 at 22:40, David Howells wrote: > > Here are a series of patches to start converting the kernel to C++. It > requires g++ v8. Nice! I tried something similar a few years ago, but I don't think it was nearly as neat. I did get RTTI and exceptions to work (using libcxxrt +

parallel make broken with ORC unwinder

Hi, When I run make -j64 on a v4.14 kernel or newer with ORC_UNWINDER=y the kernel build breaks like this: $ make -j64 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h DESCEND objtool CC scripts/mod/empty.o [...] security/smack/smack_lsm.o:

parallel make broken with ORC unwinder

Hi, When I run make -j64 on a v4.14 kernel or newer with ORC_UNWINDER=y the kernel build breaks like this: $ make -j64 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h DESCEND objtool CC scripts/mod/empty.o [...] security/smack/smack_lsm.o:

Re: [PATCH] mm: kill kmemcheck again

ernel. It has been compile and run tested on x86_64. Vegard From b06e2b3b833b02ecb0afb9dd92422e89c7fbb6d9 Mon Sep 17 00:00:00 2001 From: Vegard Nossum <vegard.nos...@oracle.com> Date: Thu, 30 Mar 2017 13:26:15 +0200 Subject: [PATCH] kmemcheck: remove core (x86 + mm) code With KASAN/KMSAN and compiler-based instrumentation,

Re: [PATCH] mm: kill kmemcheck again

b0afb9dd92422e89c7fbb6d9 Mon Sep 17 00:00:00 2001 From: Vegard Nossum Date: Thu, 30 Mar 2017 13:26:15 +0200 Subject: [PATCH] kmemcheck: remove core (x86 + mm) code With KASAN/KMSAN and compiler-based instrumentation, this code is way past its expiry date. There is zero reason to be using kmemc

Re: [bisected] Re: tty lockdep trace

. 925bb1ce47f429f69aad35876df7ecd8c53deb7e is the first bad commit commit 925bb1ce47f429f69aad35876df7ecd8c53deb7e Author: Vegard Nossum <vegard.nos...@oracle.com> Date: Thu May 11 12:18:52 2017 +0200 tty: fix port buffer locking Now reverting this. Oops, sorry, forgot to add Dave and your names to the patch revert. Th

Re: [bisected] Re: tty lockdep trace

. 925bb1ce47f429f69aad35876df7ecd8c53deb7e is the first bad commit commit 925bb1ce47f429f69aad35876df7ecd8c53deb7e Author: Vegard Nossum Date: Thu May 11 12:18:52 2017 +0200 tty: fix port buffer locking Now reverting this. Oops, sorry, forgot to add Dave and your names to the patch revert. The list of people who reported

Re: [linux-next / tty] possible circular locking dependency detected

On 06/03/17 11:34, Greg Kroah-Hartman wrote: On Mon, May 29, 2017 at 12:43:39PM +0200, Vegard Nossum wrote: On 05/22/17 12:27, Vegard Nossum wrote: On 05/22/17 12:24, Greg Kroah-Hartman wrote: On Mon, May 22, 2017 at 04:39:43PM +0900, Sergey Senozhatsky wrote: Hello, [ 1274.378287

Re: [linux-next / tty] possible circular locking dependency detected

On 06/03/17 11:34, Greg Kroah-Hartman wrote: On Mon, May 29, 2017 at 12:43:39PM +0200, Vegard Nossum wrote: On 05/22/17 12:27, Vegard Nossum wrote: On 05/22/17 12:24, Greg Kroah-Hartman wrote: On Mon, May 22, 2017 at 04:39:43PM +0900, Sergey Senozhatsky wrote: Hello, [ 1274.378287

Re: linux-next 20170519 and later - ^S/^Q borkage on ttys.

k+0xd00/0xd00 [ 1844.182310] ? kthread_create_on_node+0x70/0x70 [ 1844.182321] ret_from_fork+0x27/0x40 [ 1844.182608] INFO: lockdep is turned off. Bisects down to this commit, and things work when it's reverted. Commit 925bb1ce47f4. Author: Vegard Nossum <vegard.nos...@oracle.com> Date:

Re: linux-next 20170519 and later - ^S/^Q borkage on ttys.

k+0xd00/0xd00 [ 1844.182310] ? kthread_create_on_node+0x70/0x70 [ 1844.182321] ret_from_fork+0x27/0x40 [ 1844.182608] INFO: lockdep is turned off. Bisects down to this commit, and things work when it's reverted. Commit 925bb1ce47f4. Author: Vegard Nossum Date: Thu May 11 12:18:52 2017 +0200

Re: [linux-next / tty] possible circular locking dependency detected

On 05/22/17 12:27, Vegard Nossum wrote: On 05/22/17 12:24, Greg Kroah-Hartman wrote: On Mon, May 22, 2017 at 04:39:43PM +0900, Sergey Senozhatsky wrote: Hello, [ 1274.378287] == [ 1274.378289] WARNING: possible circular locking dependency

Re: [linux-next / tty] possible circular locking dependency detected

On 05/22/17 12:27, Vegard Nossum wrote: On 05/22/17 12:24, Greg Kroah-Hartman wrote: On Mon, May 22, 2017 at 04:39:43PM +0900, Sergey Senozhatsky wrote: Hello, [ 1274.378287] == [ 1274.378289] WARNING: possible circular locking dependency

[PATCH] kthread: fix boot hang (regression) on MIPS/OpenRISC

c: Jonas Bonn <jo...@southpole.se> Cc: Stefan Kristiansson <stefan.kristians...@saunalahti.fi> Cc: Stafford Horne <sho...@gmail.com> Cc: openr...@lists.librecores.org Cc: Oleg Nesterov <o...@redhat.com> Cc: Jamie Iles <jamie.i...@oracle.com> Cc: Thomas Gleixner <t...

[PATCH] kthread: fix boot hang (regression) on MIPS/OpenRISC

s.librecores.org Cc: Oleg Nesterov Cc: Jamie Iles Cc: Thomas Gleixner Signed-off-by: Vegard Nossum --- Not sure who this should go through, the last patch went through tglx/the core-urgent-for-linus tree, but it does touch arch code + fix a mainline boot hang regression on at least MIPS (Guenter s

Re: mips qemu test failures in -next due to "kthread: Fix use-after-free if kthread fork fails"

On 05/28/17 13:45, Vegard Nossum wrote: On 05/27/17 19:56, Guenter Roeck wrote: Hi, my qemu testis of mips images are failing in -next. Symptom is a hang during boot; see http://kerneltests.org/builders/qemu-mips-next for some examples. I bisected the problem in next-20170526. It points

Re: mips qemu test failures in -next due to "kthread: Fix use-after-free if kthread fork fails"

On 05/28/17 13:45, Vegard Nossum wrote: On 05/27/17 19:56, Guenter Roeck wrote: Hi, my qemu testis of mips images are failing in -next. Symptom is a hang during boot; see http://kerneltests.org/builders/qemu-mips-next for some examples. I bisected the problem in next-20170526. It points

Re: mips qemu test failures in -next due to "kthread: Fix use-after-free if kthread fork fails"

On 05/27/17 19:56, Guenter Roeck wrote: Hi, my qemu testis of mips images are failing in -next. Symptom is a hang during boot; see http://kerneltests.org/builders/qemu-mips-next for some examples. I bisected the problem in next-20170526. It points to commit 4d6501dce079c ("kthread: Fix

Re: mips qemu test failures in -next due to "kthread: Fix use-after-free if kthread fork fails"

On 05/27/17 19:56, Guenter Roeck wrote: Hi, my qemu testis of mips images are failing in -next. Symptom is a hang during boot; see http://kerneltests.org/builders/qemu-mips-next for some examples. I bisected the problem in next-20170526. It points to commit 4d6501dce079c ("kthread: Fix

[tip:core/urgent] kthread: Fix use-after-free if kthread fork fails

Commit-ID: 4d6501dce079c1eb6bf0b1d8f528a5e81770109e Gitweb: http://git.kernel.org/tip/4d6501dce079c1eb6bf0b1d8f528a5e81770109e Author: Vegard Nossum <vegard.nos...@oracle.com> AuthorDate: Tue, 9 May 2017 09:39:59 +0200 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

[tip:core/urgent] kthread: Fix use-after-free if kthread fork fails

Commit-ID: 4d6501dce079c1eb6bf0b1d8f528a5e81770109e Gitweb: http://git.kernel.org/tip/4d6501dce079c1eb6bf0b1d8f528a5e81770109e Author: Vegard Nossum AuthorDate: Tue, 9 May 2017 09:39:59 +0200 Committer: Thomas Gleixner CommitDate: Mon, 22 May 2017 22:21:16 +0200 kthread: Fix use-after

Re: [linux-next / tty] possible circular locking dependency detected

On 05/22/17 12:24, Greg Kroah-Hartman wrote: On Mon, May 22, 2017 at 04:39:43PM +0900, Sergey Senozhatsky wrote: Hello, [ 1274.378287] == [ 1274.378289] WARNING: possible circular locking dependency detected [ 1274.378290]

Re: [linux-next / tty] possible circular locking dependency detected

On 05/22/17 12:24, Greg Kroah-Hartman wrote: On Mon, May 22, 2017 at 04:39:43PM +0900, Sergey Senozhatsky wrote: Hello, [ 1274.378287] == [ 1274.378289] WARNING: possible circular locking dependency detected [ 1274.378290]

[PATCH] tty: fix port buffer locking

m) __vfs_write vfs_write SyS_write The bug can result in about a dozen different crashes depending on what exactly gets corrupted when port->buf.tail->used points outside the buffer. The patch passes my LOCKDEP/PROVE_LOCKING testing but more testing is always welcome. Found using syzkaller

[PATCH] tty: fix port buffer locking

m) __vfs_write vfs_write SyS_write The bug can result in about a dozen different crashes depending on what exactly gets corrupted when port->buf.tail->used points outside the buffer. The patch passes my LOCKDEP/PROVE_LOCKING testing but more testing is always welcome. Found using syzkal

[PATCH] tracing: use %pF in trace_dump_stack()

> SyS_write+0x44/0xa0 => entry_SYSCALL_64_fastpath+0x18/0xad $ scripts/faddr2line vmlinux tty_write+0x189/0x2f0 tty_write+0x189/0x2f0: do_tty_write at drivers/tty/tty_io.c:1174 (inlined by) tty_write at drivers/tty/tty_io.c:1257 Signed-off-by: Vegard Nossum <vegard.

[PATCH] tracing: use %pF in trace_dump_stack()

> SyS_write+0x44/0xa0 => entry_SYSCALL_64_fastpath+0x18/0xad $ scripts/faddr2line vmlinux tty_write+0x189/0x2f0 tty_write+0x189/0x2f0: do_tty_write at drivers/tty/tty_io.c:1174 (inlined by) tty_write at drivers/tty/tty_io.c:1257 Signed-off-by: Vegard Nossum --- kern

Re: [PATCH 0/4] S390: Fine-tuning for six function implementations

On 05/07/17 19:12, SF Markus Elfring wrote: From: Markus Elfring Date: Sun, 7 May 2017 19:00:09 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Combine two function calls into one in show_cacheinfo()

Re: [PATCH 0/4] S390: Fine-tuning for six function implementations

On 05/07/17 19:12, SF Markus Elfring wrote: From: Markus Elfring Date: Sun, 7 May 2017 19:00:09 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Combine two function calls into one in show_cacheinfo() Use seq_putc() in

[PATCH v2] kthread: fix use-after-free if kthread fork fails

.@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Andy Lutomirski <l...@kernel.org> Debugged-by: Jamie Iles <jamie.i...@oracle.com> Signed-off-by: Vegard Nossum <vegard.nos...@oracle.com> --- kernel/fork.c | 17 -

[PATCH v2] kthread: fix use-after-free if kthread fork fails

tra Cc: Thomas Gleixner Cc: Andy Lutomirski Debugged-by: Jamie Iles Signed-off-by: Vegard Nossum --- kernel/fork.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index dd5a371c392a..03b2f9606a54 100644 --- a/kernel/fork.c +++ b

Re: [PATCH] kthread: fix use-after-free if kthread fork fails

On 05/05/17 18:44, Oleg Nesterov wrote: On 05/05, Vegard Nossum wrote: If a kthread forks (e.g. usermodehelper since commit 1da5c46fa965) but fails in copy_process() between calling dup_task_struct() and setting p->set_child_tid, then the value of p->set_child_tid will be inherite

Re: [PATCH] kthread: fix use-after-free if kthread fork fails

On 05/05/17 18:44, Oleg Nesterov wrote: On 05/05, Vegard Nossum wrote: If a kthread forks (e.g. usermodehelper since commit 1da5c46fa965) but fails in copy_process() between calling dup_task_struct() and setting p->set_child_tid, then the value of p->set_child_tid will be inherite

[PATCH] kthread: fix use-after-free if kthread fork fails

.@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Andy Lutomirski <l...@kernel.org> Debugged-by: Jamie Iles <jamie.i...@oracle.com> Signed-off-by: Vegard Nossum <vegard.nos...@oracle.com> --- kernel/fork.c | 7 +++ 1 fil

[PATCH] kthread: fix use-after-free if kthread fork fails

tra Cc: Thomas Gleixner Cc: Andy Lutomirski Debugged-by: Jamie Iles Signed-off-by: Vegard Nossum --- kernel/fork.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/fork.c b/kernel/fork.c index dd5a371c392a..fbdc29365b83 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -518,6 +5

Re: [GIT PULL] TTY/Serial driver fixes for 4.11-rc4

On 2 May 2017 at 18:35, Dmitry Vyukov <dvyu...@google.com> wrote: > On Fri, Apr 14, 2017 at 2:30 PM, Greg KH <gre...@linuxfoundation.org> wrote: >> On Fri, Apr 14, 2017 at 11:41:26AM +0200, Vegard Nossum wrote: >>> On 13 April 2017 at 20:34, Greg KH <gre...@linuxfo

Re: [GIT PULL] TTY/Serial driver fixes for 4.11-rc4

On 2 May 2017 at 18:35, Dmitry Vyukov wrote: > On Fri, Apr 14, 2017 at 2:30 PM, Greg KH wrote: >> On Fri, Apr 14, 2017 at 11:41:26AM +0200, Vegard Nossum wrote: >>> On 13 April 2017 at 20:34, Greg KH wrote: >>> > On Thu, Apr 13, 2017 at 09:07:40AM -0700, Linus Torv

Re: [git pull] vfs fixes

On 9 April 2017 at 07:40, Al Viro wrote: > > The following changes since commit a71c9a1c779f2499fb2afc0553e543f18aff6edf: > > Linux 4.11-rc5 (2017-04-02 17:23:54 -0700) > > are available in the git repository at: > >

Re: [git pull] vfs fixes

On 9 April 2017 at 07:40, Al Viro wrote: > > The following changes since commit a71c9a1c779f2499fb2afc0553e543f18aff6edf: > > Linux 4.11-rc5 (2017-04-02 17:23:54 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus > > for

Re: [GIT PULL] TTY/Serial driver fixes for 4.11-rc4

On 13 April 2017 at 20:34, Greg KH <gre...@linuxfoundation.org> wrote: > On Thu, Apr 13, 2017 at 09:07:40AM -0700, Linus Torvalds wrote: >> On Thu, Apr 13, 2017 at 3:50 AM, Vegard Nossum <vegard.nos...@gmail.com> >> wrote: >> > >> > I've b

Re: [GIT PULL] TTY/Serial driver fixes for 4.11-rc4

On 13 April 2017 at 20:34, Greg KH wrote: > On Thu, Apr 13, 2017 at 09:07:40AM -0700, Linus Torvalds wrote: >> On Thu, Apr 13, 2017 at 3:50 AM, Vegard Nossum >> wrote: >> > >> > I've bisected a syzkaller crash down to this commit >> > (5362544beb

Re: [GIT PULL] TTY/Serial driver fixes for 4.11-rc4

On 26 March 2017 at 13:04, Greg KH wrote: > The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81: > > Linux 4.11-rc2 (2017-03-12 14:47:08 -0700) > > are available in the git repository at: > >

Re: [GIT PULL] TTY/Serial driver fixes for 4.11-rc4

On 26 March 2017 at 13:04, Greg KH wrote: > The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81: > > Linux 4.11-rc2 (2017-03-12 14:47:08 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ >

Re: [PATCH] hugetlbfs: fix offset overflow in huegtlbfs mmap

sermode_loop+0x133/0x150 > syscall_return_slowpath+0x184/0x1c0 > entry_SYSCALL_64_fastpath+0xab/0xad > > Reported-by: Vegard Nossum <vegard.nos...@gmail.com> Please use <vegard.nos...@oracle.com> if possible :-) > Signed-off-by: Mike Kravetz <mike.krav...@oracle.

Re: [PATCH] hugetlbfs: fix offset overflow in huegtlbfs mmap

> syscall_return_slowpath+0x184/0x1c0 > entry_SYSCALL_64_fastpath+0xab/0xad > > Reported-by: Vegard Nossum Please use if possible :-) > Signed-off-by: Mike Kravetz > --- > fs/hugetlbfs/inode.c | 15 --- > 1 file changed, 12 insertions(+), 3 deletions(-) > &

Re: [PATCH] um: use KERN_CONT in stack dump

On 12 March 2017 at 10:47, Vegard Nossum <vegard.nos...@oracle.com> wrote: > On 12/03/2017 10:45, Richard Weinberger wrote: >> diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c >> index aa1b56f5ac68..18eddf677ec6 100644 >> --- a/arch/um/kernel/sysrq.c >

Re: [PATCH] um: use KERN_CONT in stack dump

On 12 March 2017 at 10:47, Vegard Nossum wrote: > On 12/03/2017 10:45, Richard Weinberger wrote: >> diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c >> index aa1b56f5ac68..18eddf677ec6 100644 >> --- a/arch/um/kernel/sysrq.c >> +++ b/arch/um/kernel

Re: [PATCH RESEND] mm/hugetlb: Don't call region_abort if region_chg fails

On 29 March 2017 at 23:08, Mike Kravetz wrote: > Changes to hugetlbfs reservation maps is a two step process. The first > step is a call to region_chg to determine what needs to be changed, and > prepare that change. This should be followed by a call to call to >

Re: [PATCH RESEND] mm/hugetlb: Don't call region_abort if region_chg fails

On 29 March 2017 at 23:08, Mike Kravetz wrote: > Changes to hugetlbfs reservation maps is a two step process. The first > step is a call to region_chg to determine what needs to be changed, and > prepare that change. This should be followed by a call to call to > region_add to commit the

Re: [PATCH] um: use KERN_CONT in stack dump

On 12/03/2017 10:45, Richard Weinberger wrote: Am 12.03.2017 um 10:38 schrieb Vegard Nossum: Without KERN_CONT, the symbol will appear on a new line, making stack traces completely unreadable: [snip] I think it is better to fix the root of the problem by using a single printk. i.e. diff

Re: [PATCH] um: use KERN_CONT in stack dump

On 12/03/2017 10:45, Richard Weinberger wrote: Am 12.03.2017 um 10:38 schrieb Vegard Nossum: Without KERN_CONT, the symbol will appear on a new line, making stack traces completely unreadable: [snip] I think it is better to fix the root of the problem by using a single printk. i.e. diff

[PATCH] um: use KERN_CONT in stack dump

rintk+0x0/0x94 [<6001cce6>] show_stack+0xfe/0x15b [<600666ec>] ? dump_stack_print_info+0xe1/0xea [<6008e891>] ? printk+0x0/0x94 [<6023e826>] ? bust_spinlocks+0x0/0x4f [<602343b8>] dump_stack+0x2a/0x2c [<6008e662>] panic+0x170/0x31e Signed-o

[PATCH] um: use KERN_CONT in stack dump

rintk+0x0/0x94 [<6001cce6>] show_stack+0xfe/0x15b [<600666ec>] ? dump_stack_print_info+0xe1/0xea [<6008e891>] ? printk+0x0/0x94 [<6023e826>] ? bust_spinlocks+0x0/0x4f [<602343b8>] dump_stack+0x2a/0x2c [<6008e662>] panic+0x170/0x31e Sig

Re: [PATCH] locking/hung_task: Defer showing held locks

guin-ker...@i-love.sakura.ne.jp> Cc: Vegard Nossum <vegard.nos...@oracle.com> --- kernel/hung_task.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/hung_task.c b/kernel/hung_task.c index f0f8e2a..751593e 100644 --- a/kernel/hung_task.c +++ b/kernel/hung_task.c

Re: [PATCH] locking/hung_task: Defer showing held locks

id calling debug_show_all_locks() from for_each_process_thread() loop because debug_show_all_locks() effectively calls for_each_process_thread() loop. Let's defer calling debug_show_all_locks() till before panic() or leaving for_each_process_thread() loop. Signed-off-by: Tetsuo Handa Cc: Vegard Nossum -

Re: [PATCH] locking/hung_task: Defer showing held locks

On 13 December 2016 at 15:45, Tetsuo Handa wrote: > When I was running my testcase which may block hundreds of threads > on fs locks, I got lockup due to output from debug_show_all_locks() > added by commit b2d4c2edb2e4f89a ("locking/hung_task: Show all

Re: [PATCH] locking/hung_task: Defer showing held locks

On 13 December 2016 at 15:45, Tetsuo Handa wrote: > When I was running my testcase which may block hundreds of threads > on fs locks, I got lockup due to output from debug_show_all_locks() > added by commit b2d4c2edb2e4f89a ("locking/hung_task: Show all locks"). > > I think we don't need to call

[PATCH 1/4] mm: add new mmgrab() helper

)\.mm_count);/mmgrab\(\&\1\);/' This is needed for a later patch that hooks into the helper, but might be a worthwhile cleanup on its own. (Michal Hocko provided most of the kerneldoc comment.) Cc: Andrew Morton <a...@linux-foundation.org> Acked-by: Michal Hocko <mho...@suse.com> S

[PATCH 1/4] mm: add new mmgrab() helper

)\.mm_count);/mmgrab\(\&\1\);/' This is needed for a later patch that hooks into the helper, but might be a worthwhile cleanup on its own. (Michal Hocko provided most of the kerneldoc comment.) Cc: Andrew Morton Acked-by: Michal Hocko Signed-off-by: Vegard Nossum --- arch/alp

[PATCH 4/4] mm: clarify mm_struct.mm_{users,count} documentation

Clarify documentation relating to mm_users and mm_count, and switch to kernel-doc syntax. Signed-off-by: Vegard Nossum <vegard.nos...@oracle.com> --- include/linux/mm_types.h | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/include/linux/mm_typ

[PATCH 3/4] mm: use mmget_not_zero() helper

t might be a worthwhile cleanup on its own. Cc: Andrew Morton <a...@linux-foundation.org> Acked-by: Michal Hocko <mho...@suse.com> Signed-off-by: Vegard Nossum <vegard.nos...@oracle.com> --- drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +- drivers/iommu/intel-svm.c

[PATCH 4/4] mm: clarify mm_struct.mm_{users,count} documentation

Clarify documentation relating to mm_users and mm_count, and switch to kernel-doc syntax. Signed-off-by: Vegard Nossum --- include/linux/mm_types.h | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h

[PATCH 3/4] mm: use mmget_not_zero() helper

t might be a worthwhile cleanup on its own. Cc: Andrew Morton Acked-by: Michal Hocko Signed-off-by: Vegard Nossum --- drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +- drivers/iommu/intel-svm.c | 2 +- fs/proc/base.c | 4 ++-- fs/proc/task_mmu.c

[PATCH 2/4] mm: add new mmget() helper

ers);/mmget\(\&\1\);/' This is needed for a later patch that hooks into the helper, but might be a worthwhile cleanup on its own. (Michal Hocko provided most of the kerneldoc comment.) Cc: Andrew Morton <a...@linux-foundation.org> Acked-by: Michal Hocko <mho...@suse.com> S

[PATCH 2/4] mm: add new mmget() helper

ers);/mmget\(\&\1\);/' This is needed for a later patch that hooks into the helper, but might be a worthwhile cleanup on its own. (Michal Hocko provided most of the kerneldoc comment.) Cc: Andrew Morton Acked-by: Michal Hocko Signed-off-by: Vegard Nossum --- arch/arc/kernel/smp.c

Re: crash during oom reaper

On 12/16/2016 03:32 PM, Michal Hocko wrote: On Fri 16-12-16 15:25:27, Vegard Nossum wrote: On 12/16/2016 03:00 PM, Michal Hocko wrote: On Fri 16-12-16 14:14:17, Vegard Nossum wrote: [...] Out of memory: Kill process 1650 (trinity-main) score 90 or sacrifice child Killed process 1724 (trinity

Re: crash during oom reaper

On 12/16/2016 03:32 PM, Michal Hocko wrote: On Fri 16-12-16 15:25:27, Vegard Nossum wrote: On 12/16/2016 03:00 PM, Michal Hocko wrote: On Fri 16-12-16 14:14:17, Vegard Nossum wrote: [...] Out of memory: Kill process 1650 (trinity-main) score 90 or sacrifice child Killed process 1724 (trinity

  1   2   3   4   5   6   7   8   >