From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A4FDE346AD5 for ; Wed, 7 Jan 2026 14:30:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767796260; cv=none; b=kcvvM6iPWFJnJ3uQBh2PyKWE44mw+rU76B0qz16ib6ppVbpYPOpE603K7ppkfkKzeDijTFjeNvSZu2hAZVo//wmj+sFsQmaAxG0di22Vp5AJUV2F2i21lcG7plzI5ik4hBWIddE8eSRpfygVEwlBAAZTY5wfp1coJHis5WT0pIc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767796260; c=relaxed/simple; bh=cnJ6slY0lJYDh7merlNYVvnlxz+F0Dl9MoTqxmW/VBo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OrSmEmV04OnPIdcmPzkJTz5mGcluzCF9mGHTELTGsUDXPI2jfOzGrrno2lZurvbgwyld8YH3CavwCC9kTH/qCpvdvPWJwrV45yW22odBc5M/FkgICoNh22zO1PSZOPMWc3+4AAtsqjLrBdGWZrqzYKlD0pK1oo99kxNBntkeSDw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=W4/WYGDI; arc=none smtp.client-ip=209.85.221.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="W4/WYGDI" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-42fbc3056afso1134470f8f.2 for ; Wed, 07 Jan 2026 06:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767796257; x=1768401057; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=zepxcukj3N8ZfTl9wQMKSiBzvGa55itrtnFkxuIulSo=; b=W4/WYGDI4Jg2rXJ9VMOUoJnTunlXY6KgKqQaI7DNreV/G3cEVvEgVDWIlgq8QGwvQS orL62rRI/EQHgRHxUGDaoHTH7d4ohdcT8yN8BKHTwHkd8lMJ+IfF32ORJz4tDo0KMpTf J7Bcb81MkkNOD4wukHmAmZOvZ9mKQObDq1aQNAnNMuzbU3LK8ISkdy4lXfTubn7QU3K9 IC6YXt39q0Suk7FQdjlN1RlljIWkk1rYlQx2qlDL80WSOYJJG8GI+YbQTtZ8JNrgWI5/ g5Qh+20fX+DlGwLOx7n1EUdaauAFK//ixxwIvxTdymgbIIsavxefoE5XHGnpIiyVWe9l JNGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767796257; x=1768401057; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zepxcukj3N8ZfTl9wQMKSiBzvGa55itrtnFkxuIulSo=; b=wd/SbTnFoi0UDVayefrs6i7jypy6bdA7HGKD6bG6wBDO4yZQDUPsi8zGGF01M7sA0T erlMuNDRAgBbAff7x4Gjm6pDFo/srOICdw2eTnua1HA4IepU685DXIVA6eU13jRDcPj/ hSsh1agflmxfclbhNM1sLeU7w9ikx81wrIvs127LCMcMXzz2RyEIj/9f3NAaWLkCLvKS ZCcpCxiKJ1iFfORH0Mj/1vm5ZE/Tp9F/HVbttK2gASHfEKL4Uaa/gN3lLh6vzmsgPp8G e52Ddsgi0Hj4SnFyaueehJo/EDIVEbW7GL///Sj5Hj2YFg7VZAusYiI3vsRUARkkU29m OnHA== X-Forwarded-Encrypted: i=1; AJvYcCWTDhcXL24/XKLWw6GA/hrm/RHXhASl3f4djVVFS3BvEJ4e7vJwn3+zTTdGFdndDycByR9adNOVWZe1yMY=@vger.kernel.org X-Gm-Message-State: AOJu0YxKko++Uo1BVnw+x9cG/449UyMkI5aIapAbQLSjizGibikrXOSV 5TOKNOwqGlJ0gGgW5C5gYqkcBM5Pd4gZAhNahRynLCMEtA2GQUTcZ003 X-Gm-Gg: AY/fxX5jwoAhpa2+F54myvNPyJL8WrA4ExrbpzpDDtmxRv5ia4QhHi/Syf4mD3Sfwc3 8ZfPq0mELWIJCdf5lmWqfHFS1M2s2WhC7tJiaJBNQCF1+x5kDSJzjRuq+7CCoiHaWzUtLssx3Wv usllHZRfVug2+XvLLPEv7FL1+nUBjCX/4zPMBWTvgTEIxAzMAkow2YTR+q8JihqeLeyDRRtiibR HTudBL72SodA1MR6YFr6WrpBYtFR9HOrYbOhzYemU5TloutErhOJqDLjVBictLbS1Yi+EZ3A2Qe hY6s9/RkmI7MIwXZrrG/oSf54zmPIi5/75+JLosUg27fwQ/h5RQbqeYmZYfgudJwnjkKEnGb049 M0iqh3EKoGF/OeoX6JuUpjTIgGsmr+v3O3MSsU8MnenjGgK2FoPpP46wYOjWXZLK2L12ACs3mAU rTaLAUZ3pVvNDNqp5G9ygxBaP8Eak+kzgXD06Jiy5AZdnD549jtg79 X-Google-Smtp-Source: AGHT+IHvPCjXtF9R9/1rI/nnYnj/o59crigYfKlF0040BU9vo9wDIf+ad24xEDQ1fO1NdXXD1ACZ8w== X-Received: by 2002:a5d:5f54:0:b0:432:5ce4:6fed with SMTP id ffacd0b85a97d-432c3629ad1mr3237397f8f.9.1767796256695; Wed, 07 Jan 2026 06:30:56 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5feaf8sm10576130f8f.39.2026.01.07.06.30.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 06:30:56 -0800 (PST) Date: Wed, 7 Jan 2026 14:30:54 +0000 From: David Laight To: Petr Mladek Cc: John Ogness , syzbot , linux-kernel@vger.kernel.org, rostedt@goodmis.org, senozhatsky@chromium.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [kernel?] Internal error in div_u64_rem (4) Message-ID: <20260107143054.57752fad@pumpkin> In-Reply-To: References: <695569e0.050a0220.a1b6.0321.GAE@google.com> <87eco1hhxl.fsf@jogness.linutronix.de> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 7 Jan 2026 13:34:52 +0100 Petr Mladek wrote: > On Wed 2026-01-07 10:54:38, John Ogness wrote: > > On 2025-12-31, syzbot wrote: > > > syzbot found the following issue on: > > > > > > HEAD commit: c8ebd433459b Merge tag 'nfsd-6.19-2' of git://git.kernel.o.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=15caa7da580000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=e5753ed355722af > > > dashboard link: https://syzkaller.appspot.com/bug?extid=22a26d9b6c0a64335bf7 > > > compiler: arm-linux-gnueabi-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 > > > userspace arch: arm > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > Downloadable assets: > > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/98a89b9f34e4/non_bootable_disk-c8ebd433.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/fd848bb7d9d0/vmlinux-c8ebd433.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/439934b22d51/zImage-c8ebd433.xz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+22a26d9b6c0a64335bf7@syzkaller.appspotmail.com > > > > > > Insufficient stack space to handle exception! > > > Task stack: [0xeda4c000..0xeda4e000] > > > IRQ stack: [0xdf804000..0xdf806000] > > > Overflow stack: [0x830bc000..0x830bd000] > > > Internal error: kernel stack overflow: 0 [#1] SMP ARM > > > Modules linked in: > > > CPU: 1 UID: 0 PID: 2128 Comm: syz-executor Tainted: G L syzkaller #0 PREEMPT > > > Tainted: [L]=SOFTLOCKUP > > > Hardware name: ARM-Versatile Express > > > PC is at div_u64_rem+0x4/0x4c include/linux/math64.h:91 > > > LR is at div_u64 include/linux/math64.h:130 [inline] > > > LR is at ___update_load_avg kernel/sched/pelt.c:265 [inline] > > > LR is at __update_load_avg_se+0x150/0x518 kernel/sched/pelt.c:312 > > > pc : [<802abd9c>] lr : [<802b54f0>] psr: 20000193 > > > sp : df804010 ip : df804010 fp : df80406c > /> > r10: 00000000 r9 : 00000029 r8 : 0000b993 > > > r7 : 85f68c00 r6 : 00000538 r5 : 00000000 r4 : 846c3e80 > > > r3 : df804038 r2 : 0000b993 r1 : 00000000 r0 : 00000000 > > > Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none > > > Control: 30c5387d Table: 8612bb00 DAC: 00000000 > > > Register r0 information: NULL pointer > > > Register r1 information: NULL pointer > > > Register r2 information: non-paged memory > > > Register r3 information: 2-page vmalloc region starting at 0xdf804000 allocated at start_kernel+0x6b0/0x860 init/main.c:1111 > > > Register r4 information: slab task_struct start 846c3c00 pointer offset 640 size 3072 > > > Register r5 information: NULL pointer > > > Register r6 information: non-paged memory > > > Register r7 information: slab task_struct start 85f68c00 pointer offset 0 size 3072 > > > Register r8 information: non-paged memory > > > Register r9 information: non-paged memory > > > Register r10 information: NULL pointer > > > Register r11 information: 2-page vmalloc region starting at 0xdf804000 allocated at start_kernel+0x6b0/0x860 init/main.c:1111 > > > Register r12 information: 2-page vmalloc region starting at 0xdf804000 allocated at start_kernel+0x6b0/0x860 init/main.c:1111 > > > Process syz-executor (pid: 2128, stack limit = 0xeda4c000) > > > Stack: (0xdf804010 to 0xdf806000) > > > 4000: 00000018 00000000 9837f050 00000000 > [...] > > > 44c0: df804594 df8044e0 815cdeec 80203e84 8245bc84 85db88d8 00001501 85f68c00 > ^^^^^^^^ > [...] > > > 5fc0: 8025be48 8025b9cc df805ffc df805fd8 81aaeb14 8025be44 81abcf40 60000013 > > > 5fe0: ffffffff eda4dbac 82aed0d0 85f68c00 eda4db74 df806000 81a7eaa8 81aaeaa4 > > > Call trace: frame pointer underflow > [...] > > > [<802e463c>] (vprintk) from [<80203ea8>] (_printk+0x34/0x58 kernel/printk/printk.c:2451) > > > [<80203e74>] (_printk) from [<815cdeec>] (__dev_queue_xmit+0xcb4/0x1244 net/core/dev.c:4834) > ^^^^^^^^ > > I wanted to double check whether printk() was responsible for > eating the stack. It might use some buffers somewhere... > > If I get it correctly then "815cdeec" is the return > address for printk(). And if I cound it correctly then printk was > called when almost 7k from the 8k stack has already been used: > > stack size: 0x6000-0x4000 = 0x2000 = 8192 = 8k > printk at: 0x6000-0x44c0 = 0x1b40 = 6976 > remaining: 0x44c0-0x4000 = 0x4c0 = 1216 > > My conclusion is that printk() is _not_ the sinner here. Did you look at the stack offset for the IPI? That would show how much printk() was using. (Can someone fix the traceback to include the stack pointers? The address where the link register is stored would do.) Even without recursion I suspect there are printk() calls well down the stack. A call at 7k (of 8k) could be quite common. Especially since they can happen for unusual error conditions. Some of the $px formats probably use a lot of stack. In this case the 'softint' callbacks are also running. They can run anywhere where interrupts are enabled - and usually run at exactly the same place as the hardware interrupt that requested the callback. I believe there is a stack switch for hardware interrupts. Is there a stack switch for softints? Is there a stack switch for IPIs? So did the process stack or the per-cpu interrupt stack overflow. Is there scope for a conditional stack switch for things like printk()? David > > > > r3:85f68c00 r2:00001501 r1:85db88d8 r0:8245bc84 > > > > Note that net/core/dev.c:4834 from __dev_queue_xmit() is: > > > > /* Recursion is detected! It is possible, > > * unfortunately > > */ > > recursion_alert: > > net_crit_ratelimited("Dead loop on virtual device %s, fix it urgently!\n", > > dev->name); > > > > Yeah, this seems to be the culprit. If I get it correctly then > "81888f18" is the return address (__dev_queue_xmit) and I see > it repeated more times on the stack... > > > > [<815cd238>] (__dev_queue_xmit) from [<81888f18>] (dev_queue_xmit include/linux/netdevice.h:3381 [inline]) > ^^^^^^^^^ > > > [<815cd238>] (__dev_queue_xmit) from [<81888f18>] (neigh_hh_output include/net/neighbour.h:540 [inline]) > > Best Regards, > Petr >