Re: Linux 5.10

On Mon, Dec 14, 2020 at 10:21:59AM -0700, Jens Axboe wrote: > [ 87.290698] attempt to access beyond end of device > md0: rw=4096, want=13996467328, limit=6261202944 > [ 87.293371] attempt to access beyond end of device > md0: rw=4096,

Re: Linux 5.10

On Sun, Dec 13, 2020 at 03:03:29PM -0800, Linus Torvalds wrote: > Ok, here it is - 5.10 is tagged and pushed out. > > I pretty much always wish that the last week was even calmer than it > was, and that's true here too. There's a fair amount of fixes in here, > including a few last-minute

Re: Linux 5.10

On Mon, Dec 14, 2020 at 12:31:47AM -0500, Dave Jones wrote: > On Sun, Dec 13, 2020 at 03:03:29PM -0800, Linus Torvalds wrote: > > Ok, here it is - 5.10 is tagged and pushed out. > > > > I pretty much always wish that the last week was even calmer than it > > wa

Re: weird loadavg on idle machine post 5.7

On Mon, Jul 06, 2020 at 04:59:52PM +0200, Peter Zijlstra wrote: > On Fri, Jul 03, 2020 at 04:51:53PM -0400, Dave Jones wrote: > > On Fri, Jul 03, 2020 at 12:40:33PM +0200, Peter Zijlstra wrote: > > > > looked promising the first few hours, but as soon as it hit four

Re: weird loadavg on idle machine post 5.7

On Fri, Jul 03, 2020 at 12:40:33PM +0200, Peter Zijlstra wrote: > So ARM/Power/etc.. can speculate the load such that the > task_contributes_to_load() value is from before ->on_rq. > > The compiler might similar re-order things -- although I've not found it > doing so with the few builds I

Re: weird loadavg on idle machine post 5.7

On Thu, Jul 02, 2020 at 10:36:27PM +0100, Mel Gorman wrote: > I'm thinking that the !!task_contributes_to_load(p) should still happen > after smp_cond_load_acquire() when on_cpu is stable and the pi_lock is > held to stabilised p->state against a parallel wakeup or updating the > task rq. I

Re: weird loadavg on idle machine post 5.7

On Thu, Jul 02, 2020 at 01:15:48PM -0400, Dave Jones wrote: > When I upgraded my firewall to 5.7-rc2 I noticed that on a mostly > idle machine (that usually sees loadavg hover in the 0.xx range) > that it was consistently above 1.00 even when there was nothing running. > All that

weird loadavg on idle machine post 5.7

When I upgraded my firewall to 5.7-rc2 I noticed that on a mostly idle machine (that usually sees loadavg hover in the 0.xx range) that it was consistently above 1.00 even when there was nothing running. All that perf showed was the kernel was spending time in the idle loop (and running perf).

ntp audit spew.

I have some hosts that are constantly spewing audit messages like so: [46897.591182] audit: type=1333 audit(1569250288.663:220): op=offset old=2543677901372 new=2980866217213 [46897.591184] audit: type=1333 audit(1569250288.663:221): op=freq old=-2443166611284 new=-2436281764244 [48850.604005]

5.3-rc1 panic in dma_direct_max_mapping_size

only got a partial panic, but when I threw 5.3-rc1 on a linode vm, it hit this: bus_add_driver+0x1a9/0x1c0 ? scsi_init_sysctl+0x22/0x22 driver_register+0x6b/0xa6 ? scsi_init_sysctl+0x22/0x22 init+0x86/0xcc do_one_initcall+0x69/0x334 kernel_init_freeable+0x367/0x3ff ? rest_init+0x247/0x247

kernel BUG at kernel/cred.c:825!

[ 53.980701] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 53.981216] NFSD: starting 45-second grace period (net f098) [ 54.006802] CRED: Invalid credentials [ 54.006880] CRED: At ./include/linux/cred.h:253 [ 54.006899] CRED: Specified credentials:

Re: Kernel 4.17.4 lockup

On Wed, Jul 11, 2018 at 10:50:22AM -0700, Dave Hansen wrote: > On 07/11/2018 10:29 AM, H.J. Lu wrote: > >> I have seen it on machines with various amounts of cores and RAMs. > >> It triggers the fastest on 8 cores with 6GB RAM reliably. > > Here is the first kernel message. > > This looks

Re: Kernel 4.17.4 lockup

On Wed, Jul 11, 2018 at 10:50:22AM -0700, Dave Hansen wrote: > On 07/11/2018 10:29 AM, H.J. Lu wrote: > >> I have seen it on machines with various amounts of cores and RAMs. > >> It triggers the fastest on 8 cores with 6GB RAM reliably. > > Here is the first kernel message. > > This looks

fscache kasan splat on v4.17-rc3

[ 46.333213] == [ 46.336298] BUG: KASAN: slab-out-of-bounds in fscache_alloc_cookie+0x129/0x310 [ 46.338208] Read of size 4 at addr 8803ea90261c by task mount.nfs/839 [ 46.342780] CPU: 2 PID: 839 Comm: mount.nfs Not

fscache kasan splat on v4.17-rc3

[ 46.333213] == [ 46.336298] BUG: KASAN: slab-out-of-bounds in fscache_alloc_cookie+0x129/0x310 [ 46.338208] Read of size 4 at addr 8803ea90261c by task mount.nfs/839 [ 46.342780] CPU: 2 PID: 839 Comm: mount.nfs Not

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 07:02:02PM -0400, Dave Jones wrote: > On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > > > Can you tell me a bit about your system? What distribution, what > > hardware is present in your sytsem (what architecture, what

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 07:02:02PM -0400, Dave Jones wrote: > On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > > > Can you tell me a bit about your system? What distribution, what > > hardware is present in your sytsem (what architecture, what

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > Can you tell me a bit about your system? What distribution, what > hardware is present in your sytsem (what architecture, what > peripherals are attached, etc.)? > > There's a reason why we made this --- we were declaring

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > Can you tell me a bit about your system? What distribution, what > hardware is present in your sytsem (what architecture, what > peripherals are attached, etc.)? > > There's a reason why we made this --- we were declaring

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

On Thu, Apr 26, 2018 at 06:25:13PM +0300, Ville Syrjälä wrote: > On Thu, Apr 26, 2018 at 06:16:41PM +0300, Ville Syrjälä wrote: > > On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote: > > > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote: >

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

On Thu, Apr 26, 2018 at 06:25:13PM +0300, Ville Syrjälä wrote: > On Thu, Apr 26, 2018 at 06:16:41PM +0300, Ville Syrjälä wrote: > > On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote: > > > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote: >

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

On Thu, Apr 26, 2018 at 04:10:45PM +0300, Ville Syrjälä wrote: > On Mon, Apr 23, 2018 at 11:27:13AM -0400, Dave Jones wrote: > > This warning just started appearing during boot on a machine I upgraded > > to 4.17-rc2. The warning seems to have been there since 2015, but it

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

On Thu, Apr 26, 2018 at 04:10:45PM +0300, Ville Syrjälä wrote: > On Mon, Apr 23, 2018 at 11:27:13AM -0400, Dave Jones wrote: > > This warning just started appearing during boot on a machine I upgraded > > to 4.17-rc2. The warning seems to have been there since 2015, but it

4.17-rc2: Could not determine valid watermarks for inherited state

This warning just started appearing during boot on a machine I upgraded to 4.17-rc2. The warning seems to have been there since 2015, but it has never triggered before today. Dave [1.158500] fb: switching to inteldrmfb from EFI VGA [1.159073] Console: switching to colour dummy

4.17-rc2: Could not determine valid watermarks for inherited state

This warning just started appearing during boot on a machine I upgraded to 4.17-rc2. The warning seems to have been there since 2015, but it has never triggered before today. Dave [1.158500] fb: switching to inteldrmfb from EFI VGA [1.159073] Console: switching to colour dummy

Re: [4.15-rc9] fs_reclaim lockdep trace

+0900 > Subject: [PATCH] lockdep: Fix fs_reclaim warning. Seems to suppress the warning for me. Tested-by: Dave Jones <da...@codemonkey.org.uk>

Re: [4.15-rc9] fs_reclaim lockdep trace

ix fs_reclaim warning. Seems to suppress the warning for me. Tested-by: Dave Jones

Re: [4.15-rc9] fs_reclaim lockdep trace

On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: > Just triggered this on a server I was rsync'ing to. Actually, I can trigger this really easily, even with an rsync from one disk to another. Though that also smells a little like networking in the traces. Maybe netdev has id

Re: [4.15-rc9] fs_reclaim lockdep trace

On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: > Just triggered this on a server I was rsync'ing to. Actually, I can trigger this really easily, even with an rsync from one disk to another. Though that also smells a little like networking in the traces. Maybe netdev has id

[4.15-rc9] fs_reclaim lockdep trace

Just triggered this on a server I was rsync'ing to. WARNING: possible recursive locking detected 4.15.0-rc9-backup-debug+ #1 Not tainted sshd/24800 is trying to acquire lock: (fs_reclaim){+.+.}, at:

[4.15-rc9] fs_reclaim lockdep trace

Just triggered this on a server I was rsync'ing to. WARNING: possible recursive locking detected 4.15.0-rc9-backup-debug+ #1 Not tainted sshd/24800 is trying to acquire lock: (fs_reclaim){+.+.}, at:

problematic rc9 futex changes.

c1e2f0eaf015fb: "futex: Avoid violating the 10th rule of futex" seems to make up a few new rules to violate. Coverity picked up these two problems in the same code: First it or's a value with stack garbage.

problematic rc9 futex changes.

c1e2f0eaf015fb: "futex: Avoid violating the 10th rule of futex" seems to make up a few new rules to violate. Coverity picked up these two problems in the same code: First it or's a value with stack garbage.

Re: proc_flush_task oops

On Thu, Dec 21, 2017 at 07:31:26PM -0600, Eric W. Biederman wrote: > Dave Jones <da...@codemonkey.org.uk> writes: > > > On Thu, Dec 21, 2017 at 12:38:12PM +0200, Alexey Dobriyan wrote: > > > > > > with proc_mnt still set to NULL is a mystery to me. &g

Re: proc_flush_task oops

On Thu, Dec 21, 2017 at 07:31:26PM -0600, Eric W. Biederman wrote: > Dave Jones writes: > > > On Thu, Dec 21, 2017 at 12:38:12PM +0200, Alexey Dobriyan wrote: > > > > > > with proc_mnt still set to NULL is a mystery to me. > > > > > &g

Re: proc_flush_task oops

On Thu, Dec 21, 2017 at 12:38:12PM +0200, Alexey Dobriyan wrote: > > with proc_mnt still set to NULL is a mystery to me. > > > > Is there any chance the idr code doesn't always return the lowest valid > > free number? So init gets assigned something other than 1? > > Well, this theory is

Re: proc_flush_task oops

On Thu, Dec 21, 2017 at 12:38:12PM +0200, Alexey Dobriyan wrote: > > with proc_mnt still set to NULL is a mystery to me. > > > > Is there any chance the idr code doesn't always return the lowest valid > > free number? So init gets assigned something other than 1? > > Well, this theory is

Re: proc_flush_task oops

On Thu, Dec 21, 2017 at 12:38:12PM +0200, Alexey Dobriyan wrote: > On 12/21/17, Eric W. Biederman wrote: > > I have stared at this code, and written some test programs and I can't > > see what is going on. alloc_pid by design and in implementation (as far > > as I can

Re: proc_flush_task oops

On Thu, Dec 21, 2017 at 12:38:12PM +0200, Alexey Dobriyan wrote: > On 12/21/17, Eric W. Biederman wrote: > > I have stared at this code, and written some test programs and I can't > > see what is going on. alloc_pid by design and in implementation (as far > > as I can see) is always single

Re: proc_flush_task oops

On Wed, Dec 20, 2017 at 12:25:52PM -0600, Eric W. Biederman wrote: > > > > > > If the warning triggers it means the bug is in alloc_pid and somehow > > > something has gotten past the is_child_reaper check. > > > > You're onto something. > > > I am not seeing where things go wrong, but

Re: proc_flush_task oops

On Wed, Dec 20, 2017 at 12:25:52PM -0600, Eric W. Biederman wrote: > > > > > > If the warning triggers it means the bug is in alloc_pid and somehow > > > something has gotten past the is_child_reaper check. > > > > You're onto something. > > > I am not seeing where things go wrong, but

Re: proc_flush_task oops

On Tue, Dec 19, 2017 at 07:54:24PM -0600, Eric W. Biederman wrote: > > *Scratches my head* I am not seeing anything obvious. > > Can you try this patch as you reproduce this issue? > > diff --git a/kernel/pid.c b/kernel/pid.c > index b13b624e2c49..df9e5d4d8f83 100644 > ---

Re: proc_flush_task oops

On Tue, Dec 19, 2017 at 07:54:24PM -0600, Eric W. Biederman wrote: > > *Scratches my head* I am not seeing anything obvious. > > Can you try this patch as you reproduce this issue? > > diff --git a/kernel/pid.c b/kernel/pid.c > index b13b624e2c49..df9e5d4d8f83 100644 > ---

Re: proc_flush_task oops

On Tue, Dec 19, 2017 at 12:27:30PM -0600, Eric W. Biederman wrote: > Dave Jones <da...@codemonkey.org.uk> writes: > > > On Mon, Dec 18, 2017 at 03:50:52PM -0800, Linus Torvalds wrote: > > > > > But I don't see what would have changed in this area recentl

Re: proc_flush_task oops

On Tue, Dec 19, 2017 at 12:27:30PM -0600, Eric W. Biederman wrote: > Dave Jones writes: > > > On Mon, Dec 18, 2017 at 03:50:52PM -0800, Linus Torvalds wrote: > > > > > But I don't see what would have changed in this area recently. > > > > > &

Re: proc_flush_task oops

On Mon, Dec 18, 2017 at 03:50:52PM -0800, Linus Torvalds wrote: > But I don't see what would have changed in this area recently. > > Do you end up saving the seeds that cause crashes? Is this > reproducible? (Other than seeing it twoce, of course) Only clue so far, is every time I'm able to

Re: proc_flush_task oops

On Mon, Dec 18, 2017 at 03:50:52PM -0800, Linus Torvalds wrote: > But I don't see what would have changed in this area recently. > > Do you end up saving the seeds that cause crashes? Is this > reproducible? (Other than seeing it twoce, of course) Only clue so far, is every time I'm able to

Re: proc_flush_task oops

On Mon, Dec 18, 2017 at 03:50:52PM -0800, Linus Torvalds wrote: > On Mon, Dec 18, 2017 at 3:10 PM, Dave Jones <da...@codemonkey.org.uk> wrote: > > On Mon, Dec 18, 2017 at 10:15:41PM +, Al Viro wrote: > > > On Mon, Dec 18, 2017 at 04:44:38PM -0500, Dave Jones w

Re: proc_flush_task oops

On Mon, Dec 18, 2017 at 03:50:52PM -0800, Linus Torvalds wrote: > On Mon, Dec 18, 2017 at 3:10 PM, Dave Jones wrote: > > On Mon, Dec 18, 2017 at 10:15:41PM +, Al Viro wrote: > > > On Mon, Dec 18, 2017 at 04:44:38PM -0500, Dave Jones wrote: > > > > I've

Re: proc_flush_task oops

On Mon, Dec 18, 2017 at 10:15:41PM +, Al Viro wrote: > On Mon, Dec 18, 2017 at 04:44:38PM -0500, Dave Jones wrote: > > I've hit this twice today. It's odd, because afaics, none of this code > > has really changed in a long time. > > Which tree had that been? Linus, rc4. Dave

Re: proc_flush_task oops

On Mon, Dec 18, 2017 at 10:15:41PM +, Al Viro wrote: > On Mon, Dec 18, 2017 at 04:44:38PM -0500, Dave Jones wrote: > > I've hit this twice today. It's odd, because afaics, none of this code > > has really changed in a long time. > > Which tree had that been? Linus, rc4. Dave

proc_flush_task oops

I've hit this twice today. It's odd, because afaics, none of this code has really changed in a long time. Dave Oops: [#1] SMP CPU: 2 PID: 6743 Comm: trinity-c117 Not tainted 4.15.0-rc4-think+ #2 RIP: 0010:proc_flush_task+0x8e/0x1b0 RSP: 0018:c9000bbffc40 EFLAGS: 00010286 RAX:

proc_flush_task oops

I've hit this twice today. It's odd, because afaics, none of this code has really changed in a long time. Dave Oops: [#1] SMP CPU: 2 PID: 6743 Comm: trinity-c117 Not tainted 4.15.0-rc4-think+ #2 RIP: 0010:proc_flush_task+0x8e/0x1b0 RSP: 0018:c9000bbffc40 EFLAGS: 00010286 RAX:

Re: drm/amd/display: Restructuring and cleaning up DML

On Sat, Nov 18, 2017 at 12:02:01AM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/6d04ee9dc10149db842d41de66eca201c9d91b60 > Commit: 6d04ee9dc10149db842d41de66eca201c9d91b60 > Parent: 19b7fe4a48efbe0f7e8c496b040c4eb16ff02313 > Refname:

Re: drm/amd/display: Restructuring and cleaning up DML

On Sat, Nov 18, 2017 at 12:02:01AM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/6d04ee9dc10149db842d41de66eca201c9d91b60 > Commit: 6d04ee9dc10149db842d41de66eca201c9d91b60 > Parent: 19b7fe4a48efbe0f7e8c496b040c4eb16ff02313 > Refname:

Re: [trinity] WARNING: CPU: 0 PID: 515 at drivers/pci/pci-sysfs.c:1224 pci_mmap_resource+0xd6/0x10e

On Fri, Nov 24, 2017 at 08:11:39AM +0800, Fengguang Wu wrote: > Hello, > > FYI this happens in mainline kernel 4.14.0-12995-g0c86a6b. > It at least dates back to v4.9 . > > I wonder where can we avoid this warning, by improving trinity (or how > we use it), or the pci subsystem? > >

Re: [trinity] WARNING: CPU: 0 PID: 515 at drivers/pci/pci-sysfs.c:1224 pci_mmap_resource+0xd6/0x10e

On Fri, Nov 24, 2017 at 08:11:39AM +0800, Fengguang Wu wrote: > Hello, > > FYI this happens in mainline kernel 4.14.0-12995-g0c86a6b. > It at least dates back to v4.9 . > > I wonder where can we avoid this warning, by improving trinity (or how > we use it), or the pci subsystem? > >

Re: x86/umip: Enable User-Mode Instruction Prevention at runtime

On Mon, Nov 13, 2017 at 11:44:02PM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/aa35f896979d9610bb11df485cf7bb6ca241febb > Commit: aa35f896979d9610bb11df485cf7bb6ca241febb > Parent: c6a960bbf6a36572a06bde866d94a7338c7f256a > Refname:

Re: x86/umip: Enable User-Mode Instruction Prevention at runtime

On Mon, Nov 13, 2017 at 11:44:02PM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/aa35f896979d9610bb11df485cf7bb6ca241febb > Commit: aa35f896979d9610bb11df485cf7bb6ca241febb > Parent: c6a960bbf6a36572a06bde866d94a7338c7f256a > Refname:

Re: [4.14-rc7] task struct corruption after fork

On Mon, Oct 30, 2017 at 11:59:30AM -0700, Linus Torvalds wrote: > and that location would *almost* make sense in that it's the end of > the same page that contained a "struct task_struct". > > Are you running with VMAP_STACK? Is there perhaps some stale code that > ends up doing the old

Re: [4.14-rc7] task struct corruption after fork

On Mon, Oct 30, 2017 at 11:59:30AM -0700, Linus Torvalds wrote: > and that location would *almost* make sense in that it's the end of > the same page that contained a "struct task_struct". > > Are you running with VMAP_STACK? Is there perhaps some stale code that > ends up doing the old

[4.14-rc7] task struct corruption after fork

Something scary for halloween. Only saw this once so far. [10737.049397] = [10737.052151] BUG task_struct (Not tainted): Padding overwritten. 0x880458befef8-0x880458beffcf [10737.055172]

[4.14-rc7] task struct corruption after fork

Something scary for halloween. Only saw this once so far. [10737.049397] = [10737.052151] BUG task_struct (Not tainted): Padding overwritten. 0x880458befef8-0x880458beffcf [10737.055172]

[4.14rc6] suspicious nfs rcu dereference

WARNING: suspicious RCU usage 4.14.0-rc6-think+ #2 Not tainted - net/sunrpc/clnt.c:1206 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by kworker/2:0/9104: #0: ( "rpciod"

[4.14rc6] suspicious nfs rcu dereference

WARNING: suspicious RCU usage 4.14.0-rc6-think+ #2 Not tainted - net/sunrpc/clnt.c:1206 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by kworker/2:0/9104: #0: ( "rpciod"

Re: out of bounds strscpy from seccomp_actions_logged_handler

On Tue, Oct 24, 2017 at 06:54:25PM -0500, Tyler Hicks wrote: > On 10/24/2017 06:46 PM, Dave Jones wrote: > > (Triggered with trinity, but it seems just a 'cat > > /proc/sys/kernel/seccomp/actions_logged' reproduces just as easily). > > Hi Dave - Thanks for the re

Re: out of bounds strscpy from seccomp_actions_logged_handler

On Tue, Oct 24, 2017 at 06:54:25PM -0500, Tyler Hicks wrote: > On 10/24/2017 06:46 PM, Dave Jones wrote: > > (Triggered with trinity, but it seems just a 'cat > > /proc/sys/kernel/seccomp/actions_logged' reproduces just as easily). > > Hi Dave - Thanks for the re

out of bounds strscpy from seccomp_actions_logged_handler

(Triggered with trinity, but it seems just a 'cat /proc/sys/kernel/seccomp/actions_logged' reproduces just as easily). BUG: KASAN: global-out-of-bounds in strscpy+0x133/0x2d0 Read of size 8 at addr 824b0028 by task trinity-c63/6883 CPU: 3 PID: 6883 Comm: trinity-c63 Not tainted

out of bounds strscpy from seccomp_actions_logged_handler

(Triggered with trinity, but it seems just a 'cat /proc/sys/kernel/seccomp/actions_logged' reproduces just as easily). BUG: KASAN: global-out-of-bounds in strscpy+0x133/0x2d0 Read of size 8 at addr 824b0028 by task trinity-c63/6883 CPU: 3 PID: 6883 Comm: trinity-c63 Not tainted

[4.14rc5] corrupted stack end detected inside scheduler

Just hit this fairly quickly by fuzzing writev calls. Attempting to reproduce, but so far only seeing floods of page allocation stalls. Kernel panic - not syncing: corrupted stack end detected inside scheduler\x0a CPU: 1 PID: 2531 Comm: kworker/u8:4 Not tainted 4.14.0-rc5-think+ #1 Workqueue:

[4.14rc5] corrupted stack end detected inside scheduler

Just hit this fairly quickly by fuzzing writev calls. Attempting to reproduce, but so far only seeing floods of page allocation stalls. Kernel panic - not syncing: corrupted stack end detected inside scheduler\x0a CPU: 1 PID: 2531 Comm: kworker/u8:4 Not tainted 4.14.0-rc5-think+ #1 Workqueue:

Re: WARN_ON_ONCE in fs/iomap.c:993

On Mon, Sep 11, 2017 at 06:56:05AM -0400, Shankara Pailoor wrote: > Hi, > > I am fuzzing linux 4.13-rc7 with XFS using syzkaller on x86_64 and I > found the following warning: > > WARNING: CPU: 2 PID: 5391 at fs/iomap.c:993 iomap_dio_rw+0xc79/0xe70 > > Here is a reproducer program:

Re: WARN_ON_ONCE in fs/iomap.c:993

On Mon, Sep 11, 2017 at 06:56:05AM -0400, Shankara Pailoor wrote: > Hi, > > I am fuzzing linux 4.13-rc7 with XFS using syzkaller on x86_64 and I > found the following warning: > > WARNING: CPU: 2 PID: 5391 at fs/iomap.c:993 iomap_dio_rw+0xc79/0xe70 > > Here is a reproducer program:

Re: iov_iter_pipe warning.

On Sun, Sep 10, 2017 at 09:05:48PM +0100, Al Viro wrote: > On Sun, Sep 10, 2017 at 12:07:10PM -0400, Dave Jones wrote: > > On Sun, Sep 10, 2017 at 03:57:21AM +0100, Al Viro wrote: > > > On Sat, Sep 09, 2017 at 09:07:56PM -0400, Dave Jones wrote: > > > > >

Re: iov_iter_pipe warning.

On Sun, Sep 10, 2017 at 09:05:48PM +0100, Al Viro wrote: > On Sun, Sep 10, 2017 at 12:07:10PM -0400, Dave Jones wrote: > > On Sun, Sep 10, 2017 at 03:57:21AM +0100, Al Viro wrote: > > > On Sat, Sep 09, 2017 at 09:07:56PM -0400, Dave Jones wrote: > > > > >

Re: iov_iter_pipe warning.

On Sun, Sep 10, 2017 at 03:57:21AM +0100, Al Viro wrote: > On Sat, Sep 09, 2017 at 09:07:56PM -0400, Dave Jones wrote: > > > With this in place, I'm still seeing -EBUSY from > > invalidate_inode_pages2_range > > which doesn't end well... > > Differe

Re: iov_iter_pipe warning.

On Sun, Sep 10, 2017 at 03:57:21AM +0100, Al Viro wrote: > On Sat, Sep 09, 2017 at 09:07:56PM -0400, Dave Jones wrote: > > > With this in place, I'm still seeing -EBUSY from > > invalidate_inode_pages2_range > > which doesn't end well... > > Differe

Re: iov_iter_pipe warning.

On Fri, Sep 08, 2017 at 02:04:41AM +0100, Al Viro wrote: > There's at least one suspicious place in iomap_dio_actor() - > if (!(dio->flags & IOMAP_DIO_WRITE)) { > iov_iter_zero(length, dio->submit.iter); > dio->size += length;

Re: iov_iter_pipe warning.

On Fri, Sep 08, 2017 at 02:04:41AM +0100, Al Viro wrote: > There's at least one suspicious place in iomap_dio_actor() - > if (!(dio->flags & IOMAP_DIO_WRITE)) { > iov_iter_zero(length, dio->submit.iter); > dio->size += length;

Re: iov_iter_pipe warning.

On Thu, Sep 07, 2017 at 09:46:17AM +1000, Dave Chinner wrote: > On Wed, Sep 06, 2017 at 04:03:37PM -0400, Dave Jones wrote: > > On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote: > > > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote: > &g

Re: iov_iter_pipe warning.

On Thu, Sep 07, 2017 at 09:46:17AM +1000, Dave Chinner wrote: > On Wed, Sep 06, 2017 at 04:03:37PM -0400, Dave Jones wrote: > > On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote: > > > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote: > &g

Re: x86/kconfig: Consolidate unwinders into multiple choice selection

On Wed, Sep 06, 2017 at 04:49:45PM -0500, Josh Poimboeuf wrote: > > Choose kernel unwinder > > > 1. Frame pointer unwinder (FRAME_POINTER_UNWINDER) (NEW) > > 2. ORC unwinder (ORC_UNWINDER) (NEW) > > 3. Guess unwinder (GUESS_UNWINDER) (NEW) > > choice[1-3?]: > > This is a quirk of

Re: x86/kconfig: Consolidate unwinders into multiple choice selection

On Wed, Sep 06, 2017 at 04:49:45PM -0500, Josh Poimboeuf wrote: > > Choose kernel unwinder > > > 1. Frame pointer unwinder (FRAME_POINTER_UNWINDER) (NEW) > > 2. ORC unwinder (ORC_UNWINDER) (NEW) > > 3. Guess unwinder (GUESS_UNWINDER) (NEW) > > choice[1-3?]: > > This is a quirk of

Re: iov_iter_pipe warning.

On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote: > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote: > > On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote: > > > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > > > >

Re: iov_iter_pipe warning.

On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote: > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote: > > On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote: > > > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > > > >

Re: x86/kconfig: Consolidate unwinders into multiple choice selection

On Mon, Sep 04, 2017 at 08:05:13PM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/81d387190039c14edac8de2b3ec789beb899afd9 > Commit: 81d387190039c14edac8de2b3ec789beb899afd9 > Parent: a34a766ff96d9e88572e35a45066279e40a85d84 > Refname:

Re: x86/kconfig: Consolidate unwinders into multiple choice selection

On Mon, Sep 04, 2017 at 08:05:13PM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/81d387190039c14edac8de2b3ec789beb899afd9 > Commit: 81d387190039c14edac8de2b3ec789beb899afd9 > Parent: a34a766ff96d9e88572e35a45066279e40a85d84 > Refname:

Re: iov_iter_pipe warning.

On Wed, Aug 30, 2017 at 10:13:43AM -0700, Darrick J. Wong wrote: > > I reverted the debug patches mentioned above, and ran trinity for a while > > again, > > and got this which smells really suspiciously related > > > > WARNING: CPU: 1 PID: 10380 at fs/iomap.c:993 iomap_dio_rw+0x825/0x840

Re: iov_iter_pipe warning.

On Wed, Aug 30, 2017 at 10:13:43AM -0700, Darrick J. Wong wrote: > > I reverted the debug patches mentioned above, and ran trinity for a while > > again, > > and got this which smells really suspiciously related > > > > WARNING: CPU: 1 PID: 10380 at fs/iomap.c:993 iomap_dio_rw+0x825/0x840

Re: iov_iter_pipe warning.

On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote: > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote: > > On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote: > > > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > > > >

Re: iov_iter_pipe warning.

On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote: > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote: > > On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote: > > > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > > > >

Re: iov_iter_pipe warning.

On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote: > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote: > > > currently running v4.11-rc8-75-gf83246089ca0 > > > > > > s

Re: iov_iter_pipe warning.

On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote: > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote: > > > currently running v4.11-rc8-75-gf83246089ca0 > > > > > > s

Re: nvmet_fc: add defer_req callback for deferment of cmd buffer return

On Fri, Aug 11, 2017 at 07:44:19PM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/0fb228d30b8d72bfee51f57e638d412324d44a11 > Commit: 0fb228d30b8d72bfee51f57e638d412324d44a11 > Parent: 758f3735580c21b8a36d644128af6608120a1dde > Refname:

Re: nvmet_fc: add defer_req callback for deferment of cmd buffer return

On Fri, Aug 11, 2017 at 07:44:19PM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/0fb228d30b8d72bfee51f57e638d412324d44a11 > Commit: 0fb228d30b8d72bfee51f57e638d412324d44a11 > Parent: 758f3735580c21b8a36d644128af6608120a1dde > Refname:

Re: iov_iter_pipe warning.

On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote: > > currently running v4.11-rc8-75-gf83246089ca0 > > > > sunrpc bit is for the other unrelated problem I'm chasing. > > > > note also, I

Re: iov_iter_pipe warning.

On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote: > > currently running v4.11-rc8-75-gf83246089ca0 > > > > sunrpc bit is for the other unrelated problem I'm chasing. > > > > note also, I

use-after-free. [libata/block]

Found this in the logs this morning after an overnight fuzz run.. BUG: KASAN: use-after-free in __lock_acquire+0x1aa/0x1970 Read of size 8 at addr 880406805e30 by task trinity-c8/25954 CPU: 1 PID: 25954 Comm: trinity-c8 Not tainted 4.13.0-rc2-think+ #1 Call Trace: dump_stack+0x68/0xa1

use-after-free. [libata/block]

Found this in the logs this morning after an overnight fuzz run.. BUG: KASAN: use-after-free in __lock_acquire+0x1aa/0x1970 Read of size 8 at addr 880406805e30 by task trinity-c8/25954 CPU: 1 PID: 25954 Comm: trinity-c8 Not tainted 4.13.0-rc2-think+ #1 Call Trace: dump_stack+0x68/0xa1

Re: [PATCH] lib/strscpy: avoid KASAN false positive

On Wed, Jul 19, 2017 at 11:39:32AM -0400, Chris Metcalf wrote: > > We could just remove all that word-at-a-time logic. Do we have any > > evidence that this would harm anything? > > The word-at-a-time logic was part of the initial commit since I wanted > to ensure that strscpy could be

  1   2   3   4   5   6   7   8   9   10   >