(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 l
(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
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.
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 infrastr
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 subsystem
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 issu
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/nsacc
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
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
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 into
(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 mea
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
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
#PF:
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 to
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 oper
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
cho $merge
}
This will open the editor to edit the patchset description 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:
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
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 sa
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,
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 t
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 use
return 0;
> }
>
> mlock(addr, 4UL << 10);
> mbind(addr, 2UL << 20, MPOL_PREFERRED | MPOL_F_RELATIVE_NODES,
> &nodemask, 4, MPOL_MF_MOVE | MPOL_MF_MOVE_ALL);
MPOL_MF_MOVE_ALL is actually
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 ]
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 isolate_lru_page+0x235/0x
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 v4.
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 followin
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
+ libunwin
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: warnin
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
.
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
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
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 +0
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
: openr...@lists.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
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 to
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 use-afte
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
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] 4.12.0-rc1-next-2017
passes my LOCKDEP/PROVE_LOCKING testing but more testing is
always welcome.
Found using syzkaller.
Cc:
Signed-off-by: Vegard Nossum
---
drivers/tty/tty_port.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 1d21
> 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
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 show_cpu_su
Zijlstra
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
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 inherited
fr
Zijlstra
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
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
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
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
>> > (5362544b
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/
> tags/tty-4.11
50
> 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(-)
&
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
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 change,
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
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
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 Noss
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 d
d -i
's/atomic_inc(&\(.*\)\.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
Sig
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
the helper, but 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
x27;s/atomic_inc(&\(.*\)\.mm_users);/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 Nos
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
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-c14) total-vm:37280kB, anon-rss:236kB,
file-rss:112kB, shmem-rss:112kB
BUG: unable to handle
On 12/16/2016 02:14 PM, Vegard Nossum wrote:
On 12/16/2016 11:11 AM, Michal Hocko wrote:
On Fri 16-12-16 10:43:52, Vegard Nossum wrote:
[...]
I don't think it's a bug in the OOM reaper itself, but either of the
following two patches will fix the problem (without my understand
On 12/16/2016 11:11 AM, Michal Hocko wrote:
On Fri 16-12-16 10:43:52, Vegard Nossum wrote:
[...]
I don't think it's a bug in the OOM reaper itself, but either of the
following two patches will fix the problem (without my understand how or
why):
What is the atual crash?
Annoyingly
On 12/16/2016 10:56 AM, Peter Zijlstra wrote:
On Fri, Dec 16, 2016 at 09:21:59AM +0100, Vegard Nossum wrote:
Apart from adding the helper function itself, the rest of the kernel is
converted mechanically using:
git grep -l 'atomic_inc.*mm_count' | xargs sed -i
&#x
On 12/16/2016 11:19 AM, Kirill A. Shutemov wrote:
On Fri, Dec 16, 2016 at 10:56:24AM +0100, Peter Zijlstra wrote:
But I must say mmget() vs mmgrab() is a wee bit confusing.
mm_count vs mm_users is not very clear too. :)
I was about to say, I'm not sure it's much better than mmput() vs
mmdro
d be
mostly straightforward (the main challenge was fork/exec).
Thanks-to: Rik van Riel
Thanks-to: Matthew Wilcox
Thanks-to: Peter Zijlstra
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Al Viro
Cc: Ingo Molnar
Cc: Linus Torvalds
Signed-off-by: Vegard Nossum
---
arch/x86/kernel/cpu/common.c
x27;s/atomic_inc(&\(.*\)\.mm_users);/mmget\(\&\1\);/'
This is needed for a later patch that hooks into the helper, but might be
a worthwhile cleanup on its own.
Cc: Andrew Morton
Cc: Michal Hocko
Signed-off-by: Vegard Nossum
---
arch/arc/kernel/smp.c | 2 +-
arch/blackf
On 12/16/2016 10:01 AM, Michal Hocko wrote:
On Fri 16-12-16 09:22:02, Vegard Nossum wrote:
Reference counting bugs are hard to debug by their nature since the actual
manifestation of one can occur very far from where the error is introduced
(e.g. a missing get() only manifest as a use-after
the helper, but might be
a worthwhile cleanup on its own.
Cc: Andrew Morton
Cc: 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
d -i
's/atomic_inc(&\(.*\)\.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.
Cc: Andrew Morton
Cc: Michal Hocko
Signed-off-by: Vegard Nossum
---
arch/alpha/kernel/smp.c | 2 +-
ar
On 11 December 2016 at 07:46, Dmitry Vyukov wrote:
> Hello,
>
> I am getting the following use-after-free reports while running
> syzkaller fuzzer.
> On commit 318c8932ddec5c1c26a4af0f3c053784841c598e (Dec 7).
> Unfortunately it is not reproducible, but all reports look sane and
> very similar, so
On 9 December 2016 at 19:36, Jason A. Donenfeld wrote:
> SipHash is a 64-bit keyed hash function that is actually a
> cryptographically secure PRF, like HMAC. Except SipHash is super fast,
> and is meant to be used as a hashtable keyed lookup function.
>
> SipHash isn't just some new trendy hash f
On 5 December 2016 at 22:33, Vegard Nossum wrote:
> On 5 December 2016 at 21:35, Linus Torvalds
> wrote:
>> Note for Ingo and Peter: this patch has not been tested at all. But
>> Vegard did test an earlier patch of mine that just verified that yes,
>> the issue really was
On 5 December 2016 at 21:35, Linus Torvalds
wrote:
> Note for Ingo and Peter: this patch has not been tested at all. But
> Vegard did test an earlier patch of mine that just verified that yes,
> the issue really was that wait queue entries remained on the wait
> queue head just as we were about to
On 5 December 2016 at 20:11, Vegard Nossum wrote:
> On 5 December 2016 at 18:55, Linus Torvalds
> wrote:
>> On Mon, Dec 5, 2016 at 9:09 AM, Vegard Nossum
>> wrote:
>> Since you apparently can recreate this fairly easily, how about trying
>> this stupid patch
On 5 December 2016 at 18:55, Linus Torvalds
wrote:
> On Mon, Dec 5, 2016 at 9:09 AM, Vegard Nossum wrote:
>>
>> The warning shows that it made it past the list_empty_careful() check
>> in finish_wait() but then bugs out on the &wait->task_list
>> dereference.
&g
On 5 December 2016 at 19:11, Andy Lutomirski wrote:
> On Sun, Dec 4, 2016 at 3:04 PM, Vegard Nossum wrote:
>> On 23 November 2016 at 20:58, Dave Jones wrote:
>>> On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote:
>>>
>>> > [ 317.689216] BUG:
On 5 December 2016 at 12:10, Vegard Nossum wrote:
> On 5 December 2016 at 00:04, Vegard Nossum wrote:
>> FWIW I hit this as well:
>>
>> BUG: unable to handle kernel paging request at 81ff08b7
>> IP: [] __lock_acquire.isra.32+0xda/0x1a30
>> CPU: 0 PID: 2
On 5 December 2016 at 00:04, Vegard Nossum wrote:
> FWIW I hit this as well:
>
> BUG: unable to handle kernel paging request at 81ff08b7
> IP: [] __lock_acquire.isra.32+0xda/0x1a30
> CPU: 0 PID: 21744 Comm: trinity-c56 Tainted: GB 4.9.0-rc7+ #217
[...]
&g
On 23 November 2016 at 20:58, Dave Jones wrote:
> On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote:
>
> > [ 317.689216] BUG: Bad page state in process kworker/u8:8 pfn:4d8fd4
> > trace from just before this happened. Does this shed any light ?
> >
> > https://codemonkey.org.uk/junk
On 10 August 2015 at 11:43, Jan Kara wrote:
> On Sun 09-08-15 10:49:33, Sasha Levin wrote:
>> I saw the following warning while fuzzing with trinity:
>>
>> [385644.689209] WARNING: CPU: 1 PID: 23536 at mm/truncate.c:740
>> pagecache_isize_extended+0x124/0x180()
>> [385644.691780] Modules linked i
ame set_proc_pid_nlink() to proc_pid_nlink_init() to make it 100%
clear it's a one time thing
- move pid_entry_nlink() down to just above where it is called
Either way,
Acked-by/Reviewed-by: Vegard Nossum
Vegard
Hi,
I updated my config and set CONFIG_WDAT_WDT=y, got this:
drivers/built-in.o: In function `wdat_wdt_probe':
/home/vegard/linux/drivers/watchdog/wdat_wdt.c:444: undefined
reference to `devm_watchdog_register_device'
Makefile:962: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
L
ot. It should be pretty easy to script on
your end(s) for the benefit of everybody.
Just my 2 cents. Thanks,
Vegard
--
From: Vegard Nossum
commit f70749ca42943faa4d4dcce46dfdcaadb1d0c4b6 upstream.
An extent with lblock = 4294967295 and len = 1 will pass the
ext4_valid_ext
On 28 October 2016 at 11:35, Ingo Molnar wrote:
>
> * Vegard Nossum wrote:
>
>> Would it make sense to sample the counter on context switch, do some
>> accounting on a per-task cache miss counter, and slow down just the
>> single task(s) with a too high cache mis
On 28 October 2016 at 11:04, Peter Zijlstra wrote:
> On Fri, Oct 28, 2016 at 10:50:39AM +0200, Pavel Machek wrote:
>> On Fri 2016-10-28 09:07:01, Ingo Molnar wrote:
>> >
>> > * Pavel Machek wrote:
>> >
>> > > +static void rh_overflow(struct perf_event *event, struct
>> > > perf_sample_data *data
On 10/17/2016 01:45 PM, Peter Zijlstra wrote:
On Mon, Oct 17, 2016 at 01:27:08PM +0200, Vegard Nossum wrote:
On 10/17/2016 11:09 AM, Peter Zijlstra wrote:
On Mon, Oct 17, 2016 at 11:01:13AM +0200, Jiri Slaby wrote:
On the top of that, it's incorrect C according to the standard.
Accordi
On 10/17/2016 11:09 AM, Peter Zijlstra wrote:
On Mon, Oct 17, 2016 at 11:01:13AM +0200, Jiri Slaby wrote:
On the top of that, it's incorrect C according to the standard.
According to the standard non of the kernel has any chance in hell of
working, so don't pretend you care about that :-)
I
On 10/16/2016 06:14 PM, Greg Kroah-Hartman wrote:
On Sun, Oct 16, 2016 at 05:16:04PM +0200, Vegard Nossum wrote:
Hi,
The first two patches in the series fix the concrete bug (a boot crash
when using gcc 7.0+) by defining new wrappers for arrays defined in
linker scripts. These two patches
On 10/16/2016 06:25 PM, Peter Zijlstra wrote:
On Sun, Oct 16, 2016 at 05:16:15PM +0200, Vegard Nossum wrote:
Cc: Jason Baron
Cc: Peter Zijlstra
Cc: Steven Rostedt
Signed-off-by: Vegard Nossum
NAK, -ENOCHANGELOG.
Hi Peter,
It's true I didn't put an RFC tag on this (mostly b
Cc: Steven Rostedt
Signed-off-by: Vegard Nossum
---
kernel/trace/trace_syscalls.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 5e10395..2b1c1c3 100644
--- a/kernel/trace/trace_syscalls.c
+++ b
Cc: Peter Zijlstra
Cc: Ingo Molnar
Signed-off-by: Vegard Nossum
---
kernel/locking/mutex.c | 32
lib/Kconfig.debug | 6 ++
2 files changed, 38 insertions(+)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index a70b90d..0651ca6 100644
Cc: Steven Rostedt
Signed-off-by: Vegard Nossum
---
kernel/trace/trace.c| 2 +-
kernel/trace/trace.h| 7 +++
kernel/trace/trace_printk.c | 8
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index d1bee81
Cc: Peter Zijlstra
Cc: Ingo Molnar
Signed-off-by: Vegard Nossum
---
kernel/locking/rtmutex.c | 26 ++
lib/Kconfig.debug| 6 ++
2 files changed, 32 insertions(+)
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 1ec0f48..22ff6da 100644
Cc: Peter Hurley
Cc: Greg Kroah-Hartman
Signed-off-by: Vegard Nossum
---
drivers/of/fdt.c | 2 +-
drivers/tty/serial/earlycon.c | 2 +-
include/asm-generic/vmlinux.lds.h | 8
include/linux/serial_core.h | 4 ++--
4 files changed, 8 insertions(+), 8 deletions
observe no problems whatsoever with this today and in fact
it's been very useful for debugging. Let's allow it again.
Cc: Akinobu Mita
Signed-off-by: Vegard Nossum
---
lib/Kconfig.debug | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index d7cc65
Cc: Peter Zijlstra
Cc: Ingo Molnar
Signed-off-by: Vegard Nossum
---
kernel/locking/semaphore.c | 26 ++
lib/Kconfig.debug | 6 ++
2 files changed, 32 insertions(+)
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index b8120ab..367bae3
Cc: Peter Zijlstra
Cc: Ingo Molnar
Signed-off-by: Vegard Nossum
---
include/linux/spinlock.h | 12
kernel/locking/spinlock.c | 19 +++
lib/Kconfig.debug | 6 ++
3 files changed, 37 insertions(+)
diff --git a/include/linux/spinlock.h b/include/linux
new_callsites
Signed-off-by: Vegard Nossum
---
v2: turned this into a runtime knob as suggested by Akinobu Mita and
bumped the hashtable size from 32 to 128 KiB (16 to 64 KiB on 32-bit).
---
Documentation/fault-injection/fault-injection.txt | 8 +
include/linux/fault-inject.h
1 - 100 of 375 matches
Mail list logo
