On Fri, Feb 07, 2025 at 10:45:39AM -0800, Breno Leitao wrote:
> On Fri, Feb 07, 2025 at 05:26:06PM +, Mark Brown wrote:
> > On Fri, Feb 07, 2025 at 03:06:42AM -0800, Breno Leitao wrote:
> > > Fix compiler warning about potentially uninitialized orig_fpmr variable:
Hello Mark,
On Fri, Feb 07, 2025 at 05:26:06PM +, Mark Brown wrote:
> On Fri, Feb 07, 2025 at 03:06:42AM -0800, Breno Leitao wrote:
> > Fix compiler warning about potentially uninitialized orig_fpmr variable:
> >
> > testcases/fpmr_siginfo.c: In function ‘fpmr_presen
Since long time ago, the only user of vq->log is vhost-net. The concern is
to add support for more devices (i.e. vhost-scsi or vsock) may reveals
unknown issue in the vhost API. Add a WARNING.
Suggested-by: Joao Martins
Signed-off-by: Dongli Zhang
---
drivers/vhost/vhost.c |
On Fri, Feb 07, 2025 at 03:06:42AM -0800, Breno Leitao wrote:
> Fix compiler warning about potentially uninitialized orig_fpmr variable:
>
> testcases/fpmr_siginfo.c: In function ‘fpmr_present’:
> testcases/fpmr_siginfo.c:68:25: warning: ‘orig_fpmr’ may be used
> u
Fix compiler warning about potentially uninitialized orig_fpmr variable:
testcases/fpmr_siginfo.c: In function ‘fpmr_present’:
testcases/fpmr_siginfo.c:68:25: warning: ‘orig_fpmr’ may be used
uninitialized in this function [-Wmaybe-uninitialized
On Thu, Feb 06, 2025 at 02:15:09AM -0800, Paul E. McKenney wrote:
> The WARN_ON_ONCE() in ct_kernel_exit_state() follows the call to
> ct_state_inc(), which means that RCU is not watching this WARN_ON_ONCE().
> This can (and does) result in extraneous lockdep warnings when this
> WARN_ON_ONCE() tri
The WARN_ON_ONCE() in ct_kernel_exit_state() follows the call to
ct_state_inc(), which means that RCU is not watching this WARN_ON_ONCE().
This can (and does) result in extraneous lockdep warnings when this
WARN_ON_ONCE() triggers. These extraneous warnings are the opposite
of helpful.
Therefore,
ll pop out as the following.
> >
> > CC pidfd_fdinfo_test
> > pidfd_fdinfo_test.c: In function ‘child_fdinfo_nspid_test’:
> > pidfd_fdinfo_test.c:231:13: warning: implicit declaration of function \
> > ‘mount’ [-Wimplicit-function-declaration]
> >
Hello *,
On Wed, 5 Feb 2025 13:50:31 +0800, I Hsin Cheng
wrote:
> In the compilation of pidfs_setns_test.c , a warning as the following
> will pop out.
>
> pidfd_setns_test.c: In function ‘current_nsset_setup’:
> pidfd_setns_test.c:173:54: warning: implicit declaration of func
.c: In function ‘child_fdinfo_nspid_test’:
> pidfd_fdinfo_test.c:231:13: warning: implicit declaration of function \
> ‘mount’ [-Wimplicit-function-declaration]
> 231 | r = mount(NULL, "/", NULL, MS_REC | MS_PRIVATE, 0);
> | ^
> pidfd_fdinfo_test.c:231:36: erro
When compiling selftests files under tools/testing/selftests/pidfd/ ,
some compiling errors and warnings will pop out as the following.
CC pidfd_fdinfo_test
pidfd_fdinfo_test.c: In function ‘child_fdinfo_nspid_test’:
pidfd_fdinfo_test.c:231:13: warning: implicit declaration of function
In the compilation of pidfs_setns_test.c , a warning as the following
will pop out.
pidfd_setns_test.c: In function ‘current_nsset_setup’:
pidfd_setns_test.c:173:54: warning: implicit declaration of function \
‘ioctl’ [-Wimplicit-function-declaration]
173 | self
From: Brian Norris
[ Upstream commit 7687c66c18c66d4ccd9949c6f641c0e7b5773483 ]
If the header is included in a test without
certain other headers, it produces compiler warnings like:
In file included from [...]
../include/kunit/platform_device.h:15:57: warning: ‘struct completion’
declared
From: Brian Norris
[ Upstream commit 7687c66c18c66d4ccd9949c6f641c0e7b5773483 ]
If the header is included in a test without
certain other headers, it produces compiler warnings like:
In file included from [...]
../include/kunit/platform_device.h:15:57: warning: ‘struct completion’
declared
On Thu, Jan 16, 2025 at 03:03:56PM +0100, Uladzislau Rezki wrote:
> Hello, Cheung Wall!
>
> >
> > I am writing to report a potential vulnerability identified in the
> > Linux Kernel version v6.12-rc4. This vulnerability was discovered
> > while i was testing the kernel.
> >
> > Linux Kernel Repo
Hello, Cheung Wall!
>
> I am writing to report a potential vulnerability identified in the
> Linux Kernel version v6.12-rc4. This vulnerability was discovered
> while i was testing the kernel.
>
> Linux Kernel Repository Git Commit:
> 42f7652d3eb527d03665b09edac47f85fb600924 (tag: v6.12-rc4)
>
Hello,
I am writing to report a potential vulnerability identified in the
Linux Kernel version v6.12-rc4. This vulnerability was discovered
while i was testing the kernel.
Linux Kernel Repository Git Commit:
42f7652d3eb527d03665b09edac47f85fb600924 (tag: v6.12-rc4)
Bug Location: 0010:rcu_sr_norm
On Wed, Dec 11, 2024 at 11:09:46AM +0530, Naresh Kamboju wrote:
[Gentle Reminder]
On Mon, 26 Aug 2024 at 18:50, Naresh Kamboju wrote:
The following kernel warning is noticed on all arch and all devices while
running selftests: core: unshare_test on Linux next-20240823 and next-20240826
[ cut here ]--------
WARNING: CPU: 0 PID: 5837 at net/ieee802154/core.c:258
cfg802154_switch_netns+0x3c7/0x3d0 net/ieee802154/core.c:258
Modules linked in:
CPU: 0 UID: 0 PID: 5837 Comm: syz-executor125 Not tainted
6.13.0-rc6-syzkaller-00918-g7b24f164cf00 #0
Hardware name: Google Google Compute Engine/Goog
On Sun, 5 Jan 2025 at 19:52, Sasha Levin wrote:
>
> I'm sorry, this is my bad: I haven't realized anyone else will be
> looking at these results...
>
> Naresh, I'm cheating and using this tree to bisect the issue you've
> originally reported in
> https://lore.kernel.org/all/ca+g9fyvcbvbabg+m7brkfp
I'm sorry, this is my bad: I haven't realized anyone else will be
looking at these results...
Naresh, I'm cheating and using this tree to bisect the issue you've
originally reported in
https://lore.kernel.org/all/ca+g9fyvcbvbabg+m7brkfpgcgzuck+khhtfx7hfvw6gmn2x...@mail.gmail.com/
.
It seems we c
On Sun, Jan 5, 2025 at 2:33 PM Miguel Ojeda
wrote:
>
> Thanks for the report! I think there is nothing to be done here given
> the details above.
To clarify: v6.11.y is newer (and EOL), v6.12.y LTS is newer, and
older LTSs had the Rust toolchain pinned.
If there is something I am missing, please
eem unrelated, old but rebased/recommitted recently (without SoB).
> warning: the feature `new_uninit` has been stable since 1.82.0 and no
> longer requires an attribute to enable
> --> /rust/kernel/lib.rs:17:12
>|
> 17 | #![feature(new_uninit)]
>|
The following kselftest rust builds failed on sashal/linus-next.git
due to following build warnings / errors.
Good: 829d8581c398a96deea1d6bc78578950347dcbec
Bad: b2d472701a703596889c3fd067fd8929aeffc4be
Build error:
--
warning: the feature `new_uninit` has been stable since 1.82.0
On Sat, 14 Dec 2024 at 02:09, Brian Norris wrote:
>
> If the header is included in a test without
> certain other headers, it produces compiler warnings like:
>
> In file included from [...]
> ../include/kunit/platform_device.h:15:57: warning: ‘struct completion’
> declared
syzbot has found a reproducer for the following issue on:
HEAD commit:a0e3919a2df2 Merge tag 'usb-6.13-rc3' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15a4c34458
kernel config: https://syzkaller.appspot.com/x/.config?x=b874549
If the header is included in a test without
certain other headers, it produces compiler warnings like:
In file included from [...]
../include/kunit/platform_device.h:15:57: warning: ‘struct completion’
declared inside parameter list will not be visible outside of this
definition or declaration
[Gentle Reminder]
On Mon, 26 Aug 2024 at 18:50, Naresh Kamboju wrote:
>
> The following kernel warning is noticed on all arch and all devices while
> running selftests: core: unshare_test on Linux next-20240823 and
> next-20240826.
>
> First seen on next-20240823.
>
ue, please add the following tag to the commit:
Reported-by: syzbot+bd5829ba3619f08e2...@syzkaller.appspotmail.com
R10: R11: 0246 R12: 0002
R13: R14: 7f2cedb45fa0 R15: 7ffcd711e1d8
[ cut here ]--------
WARNING: CPU: 0
---[ cut here ]
WARNING: CPU: 0 PID: 5337 at net/core/dev.c:11738
__dev_change_net_namespace+0x16ed/0x1820 net/core/dev.c:11738
Modules linked in:
CPU: 0 UID: 0 PID: 5337 Comm: syz.0.0 Not tainted
6.12.0-syzkaller-09073-g9f16d5e6f220 #0
Hardware name: QEMU Standard PC (Q35 + ICH9
On 2024-11-04 12:47:26 [+0100], Peter Zijlstra wrote:
> On Mon, Nov 04, 2024 at 12:45:06PM +0100, Peter Zijlstra wrote:
> > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > index 6310a180278b..ac9f6682bb2f 100644
> > --- a/mm/kasan/generic.c
> > +++ b/mm/kasan/generic.c
> > @@ -521,12 +521,
From: "Paul E. McKenney"
Currently, once an RCU CPU stall warning decides to dump the stalling
CPUs' stacks, the rcu_dump_cpu_stacks() function persists until it
has gone through the full list. Unfortunately, if the stalled grace
periods ends midway through, this function will be
On Mon, 4 Nov 2024 at 12:45, Peter Zijlstra wrote:
>
> On Mon, Nov 04, 2024 at 12:25:03PM +0100, Vlastimil Babka wrote:
> > On 11/4/24 12:11, Vlastimil Babka wrote:
>
> > >> __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4771
> > >> alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265
> > >
On Mon, Nov 04, 2024 at 12:25:03PM +0100, Vlastimil Babka wrote:
> On 11/4/24 12:11, Vlastimil Babka wrote:
> >> __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4771
> >> alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265
> >> stack_depot_save_flags+0x666/0x830 lib/stackdepot.c:627
> >>
On Mon, Nov 04, 2024 at 12:45:06PM +0100, Peter Zijlstra wrote:
> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> index 6310a180278b..ac9f6682bb2f 100644
> --- a/mm/kasan/generic.c
> +++ b/mm/kasan/generic.c
> @@ -521,12 +521,12 @@ size_t kasan_metadata_size(struct kmem_cache *cache,
> bool
On 11/1/24 13:04, Muhammad Usama Anjum wrote:
> On 11/1/24 4:15 PM, Mirsad Todorovac wrote:
>> Coccinelle gives WARNING recommending the use of ARRAY_SIZE() macro
>> definition
>> to improve the code readability:
>>
>> ./tools/testing/selftests/x86/syscall_nu
On 11/1/24 14:48, Peter Xu wrote:
> On Fri, Nov 01, 2024 at 12:15:25PM +0100, Mirsad Todorovac wrote:
>> Coccinelle gives WARNING recommending the use of ARRAY_SIZE() macro
>> definition
>> to improve the code readability:
>>
>> ./tools/testing/selftest
On Fri, Nov 01, 2024 at 12:15:25PM +0100, Mirsad Todorovac wrote:
> Coccinelle gives WARNING recommending the use of ARRAY_SIZE() macro definition
> to improve the code readability:
>
> ./tools/testing/selftests/mm/uffd-unit-tests.c:1484:32-33: WARNING: Use
> ARRAY_SIZE
&g
On 11/1/24 4:15 PM, Mirsad Todorovac wrote:
> Coccinelle gives WARNING recommending the use of ARRAY_SIZE() macro definition
> to improve the code readability:
>
> ./tools/testing/selftests/x86/syscall_numbering.c:316:35-36: WARNING: Use
> ARRAY_SIZE
>
> Fixes: 15c82d98
Coccinelle gives WARNING recommending the use of ARRAY_SIZE() macro definition
to improve the code readability:
./tools/testing/selftests/x86/syscall_numbering.c:316:35-36: WARNING: Use
ARRAY_SIZE
Fixes: 15c82d98a0f78 ("selftests/x86/syscall: Update and extend
syscall_numbering_64")
Coccinelle gives WARNING recommending the use of ARRAY_SIZE() macro definition
to improve the code readability:
./tools/testing/selftests/mm/uffd-unit-tests.c:1484:32-33: WARNING: Use
ARRAY_SIZE
./tools/testing/selftests/mm/uffd-unit-tests.c:1485:30-31: WARNING: Use
ARRAY_SIZE
Fixes
Le Wed, Oct 16, 2024 at 09:18:52AM -0700, Paul E. McKenney a écrit :
> Hello!
>
> This series contains RCU CPU stall-warning changes for v6.13:
>
> 1.Delete unused rcu_gp_might_be_stalled() function.
>
> 2. Stop stall warning from dumping stacks if grace period e
Currently, once an RCU CPU stall warning decides to dump the stalling
CPUs' stacks, the rcu_dump_cpu_stacks() function persists until it
has gone through the full list. Unfortunately, if the stalled grace
periods ends midway through, this function will be dumping stacks of
innocent-bystander
Hello!
This series contains RCU CPU stall-warning changes for v6.13:
1. Delete unused rcu_gp_might_be_stalled() function.
2. Stop stall warning from dumping stacks if grace period ends.
3. Finer-grained grace-period-end checks in rcu_dump_cpu_stacks().
Changes since v1:
o
On Tue, Oct 15, 2024 at 04:02:37PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 15, 2024 at 02:49:06PM -0400, Joel Fernandes wrote:
> > On Wed, Oct 09, 2024 at 11:05:02AM -0700, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > This series contains RCU
On Tue, Oct 15, 2024 at 02:49:06PM -0400, Joel Fernandes wrote:
> On Wed, Oct 09, 2024 at 11:05:02AM -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > This series contains RCU CPU stall-warning changes for v6.13:
> >
> > 1. Delete unused rcu_gp_might_be_stal
On Wed, Oct 09, 2024 at 11:05:02AM -0700, Paul E. McKenney wrote:
> Hello!
>
> This series contains RCU CPU stall-warning changes for v6.13:
>
> 1.Delete unused rcu_gp_might_be_stalled() function.
>
> 2. Stop stall warning from dumping stacks if grace period e
On Wed, Oct 09, 2024 at 11:05:08AM -0700, Paul E. McKenney wrote:
> Currently, once an RCU CPU stall warning decides to dump the stalling
> CPUs' stacks, the rcu_dump_cpu_stacks() function persists until it
> has gone through the full list. Unfortunately, if the stalled grace
Currently, once an RCU CPU stall warning decides to dump the stalling
CPUs' stacks, the rcu_dump_cpu_stacks() function persists until it
has gone through the full list. Unfortunately, if the stalled grace
periods ends midway through, this function will be dumping stacks of
innocent-bystander
Hello!
This series contains RCU CPU stall-warning changes for v6.13:
1. Delete unused rcu_gp_might_be_stalled() function.
2. Stop stall warning from dumping stacks if grace period ends.
3. Finer-grained grace-period-end checks in rcu_dump_cpu_stacks
On Sat, 31 Aug 2024 at 11:38, Hou Tao wrote:
>
> From: Hou Tao
>
> Hi,
>
> The patch set aims to fix the warning related to an abnormal size
> parameter of kmalloc() in virtiofs. Patch #1 fixes it by introducing
> use_pages_for_kvec_io option in fuse_conn and enabling
> After several tests, I found that the same PoC can cause multiple
> different crashes for some unknown reason. Thus, I suspect that the
> bug is capable of performing unintended memory writing without being
> caught by KASAN.
> I tested the PoC on the latest kernel, Linux 6.11 rc7 and it can stil
[C0] ? __pfx___run_timers+0x10/0x10
> > [ 657.469401][C0] ? __pfx_lock_acquire+0x10/0x10
> > [ 657.471986][C0] ? lock_acquire+0x1ad/0x550
> > [ 657.474472][C0] timer_expire_remote+0xfb/0x160
> > [ 657.477069][C0] ? __pfx_timer_expire_remote+0x10/0x10
&g
? __pfx_kthread+0x10/0x10
> [ 657.529240][C0] ret_from_fork+0x44/0x70
> [ 657.531687][C0] ? __pfx_kthread+0x10/0x10
> [ 657.534185][C0] ret_from_fork_asm+0x1a/0x30
> [ 657.536744][C0]
> [ 657.538752][C0] Modules linked in:
> [ 657.541038][C0] ---[
bot-assets/1aed2837c105/bzImage-8d8d276b.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c80d8dc0d9fa81a3c...@syzkaller.appspotmail.com
[ cut here ]
only secondary bus families can be translated
WARNING: CPU: 0 PID: 15821
disabled
is about list corruption BUG. So they are different and looks like
something is corrupted. So i would not trust that your report is about
kvfree_rcu_bulk() warning is related to a real issue with kvfree_rcu()
call.
A also run the reproducer on the 6.11.0-rc7 kernel. It still runs
without any panics yet.
Could you please test the latest kernel? For example 6.11.0-rc7?
--
Uladzislau Rezki
Hi Maintainer,
V4:
-Fix build warning when CONFIG_KALLSYMS is not enabled;
-Add Fixes tag;
I can't find add_sect_attrs and add_notes_attrs commit in linux.next git log,
and Petr Pavlu show /sys/module patch link when review,
so I label Fixes as below, If incorrect please notify me.
pspotmail.com
>
> R10: R11: 0293 R12:
> R13: 00000000 R14: R15:
>
> [ cut here ]
> WARNING: CPU: 3 PID: 14392 at net/core/dev.c:11431
> __dev_change_net_namespace+0x1048/
fc64b5c120 R15:
[ cut here ]--------
WARNING: CPU: 0 PID: 5214 at net/core/dev.c:11568
__dev_change_net_namespace+0x171a/0x1830 net/core/dev.c:11568
Modules linked in:
CPU: 0 UID: 0 PID: 5214 Comm: syz-executor241 Not tainted
6.11.0-rc6-syzkaller-00326-gd1f2d
t fixes stuff in there.
>
> The fact that the warning was only made visible in
> bdacf3e34945 ("net: Use nested-BH locking for napi_alloc_cache.")
> does not change the fact that it was already present before.
>
> Also, having bdacf3e34945 is not necessary for
On Wed, Sep 04, 2024 at 02:08:53AM -0700, Shivani Agarwal wrote:
> From: Breno Leitao
>
> [ Upstream commit f8321fa75102246d7415a6af441872f6637c93ab ]
>
> After the commit bdacf3e34945 ("net: Use nested-BH locking for
> napi_alloc_cache.") was merged, the follo
> sudo modprobe hci
> sudo modprobe hci_vhci
> sudo modprobe mac802154
> sudo modprobe ieee802154
> sudo modprobe ieee802154_socket
> sudo modprobe mac802154_hwsim
> sudo modprobe adf7242
> sudo modprobe atusb
> sudo modprobe at86rf230
> sudo modprobe fakelb
d even after that i am not able to get any "WARNING in kvfree_rcu_bulk".
urezki@pc638:~$ uname -a
Linux pc638 6.11.0-rc2+ #3827 SMP PREEMPT_DYNAMIC Wed Sep 4 19:37:22 CEST 2024
x86_64 GNU/Linux
urezki@pc638:~$
is it easy to reproduce? Am i missing something in my setup?
--
Uladzislau Rezki
First of all, thanks for the quick reply
> I get that you have this on kunit on ARCH=um, but that makes it
> neither
> a kunit nor a um patch :)
Well, yes I wasn't entirely sure how to put it, sure people from
UM/KUnit know what this is about, but I agree perhaps the patch title
can be a bit mi
On Wed, 2024-09-04 at 15:50 +0200, Gabriele Monaco wrote:
> While building for KUnit with default settings, the build is generating
> the following compilation warnings.
>
> ```
> $ make ARCH=um O=.kunit --jobs=16
> ../lib/iomap.c:156:5: warning: no previous prototype for
While building for KUnit with default settings, the build is generating
the following compilation warnings.
```
$ make ARCH=um O=.kunit --jobs=16
../lib/iomap.c:156:5: warning: no previous prototype for
‘ioread64_lo_hi’ [-Wmissing-prototypes]
156 | u64 ioread64_lo_hi(const void __iomem *addr
From: Breno Leitao
[ Upstream commit f8321fa75102246d7415a6af441872f6637c93ab ]
After the commit bdacf3e34945 ("net: Use nested-BH locking for
napi_alloc_cache.") was merged, the following warning began to appear:
WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
napi_skb
From: Breno Leitao
[ Upstream commit f8321fa75102246d7415a6af441872f6637c93ab ]
After the commit bdacf3e34945 ("net: Use nested-BH locking for
napi_alloc_cache.") was merged, the following warning began to appear:
WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
napi_skb
From: Breno Leitao
[ Upstream commit f8321fa75102246d7415a6af441872f6637c93ab ]
After the commit bdacf3e34945 ("net: Use nested-BH locking for
napi_alloc_cache.") was merged, the following warning began to appear:
WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
napi_skb
From: Breno Leitao
[ Upstream commit f8321fa75102246d7415a6af441872f6637c93ab ]
After the commit bdacf3e34945 ("net: Use nested-BH locking for
napi_alloc_cache.") was merged, the following warning began to appear:
WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
napi_skb
ou fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1df6ffa7a6274ae26...@syzkaller.appspotmail.com
R10: R11: 0246 R12: 0002
R13: R14: 7f95c6735f80 R15: 7ffd0db2c528
[ cut here ]--------
WA
et: Use nested-BH locking for
> > > napi_alloc_cache.") was merged, the following warning began to appear:
> > >
> > >WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
> > > napi_skb_cache_put+0x82/0x4b0
> > >
> > > __warn+0x1
On Sun Aug 25, 2024 at 11:06 AM EEST, Kai Huang wrote:
> Building the SGX code with W=1 generates below warning:
>
> arch/x86/kernel/cpu/sgx/main.c:741: warning: Function parameter or struct
> member 'low' not described in 'sgx_calc_section_metric'
>
72cf28b.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ce35de20ed6652f60...@syzkaller.appspotmail.com
[ cut here ]--------
WARNING: CPU: 0 PID: 5229 at kernel/trace/bpf_trace.c:1917 get_bpf_raw_tp_regs
kernel/trace/bpf_trace.c:19
Building the SGX code with W=1 generates below warning:
arch/x86/kernel/cpu/sgx/main.c:741: warning: Function parameter or struct
member 'low' not described in 'sgx_calc_section_metric'
arch/x86/kernel/cpu/sgx/main.c:741: warning: Function parameter or struct
member &#x
e.
>
> Stack dump:
>
> ----[ cut here ]
> WARNING: CPU: 1 PID: 14015 at kernel/events/uprobes.c:1107
> uprobe_unregister+0x66/0x80 kernel/events/uprobes.c:1107
> Modules linked in:
> CPU: 1 PID: 14015 Comm: syz.0.291 Not tainted 6.8.0 #1
> Hardware name:
On 8/14/24 3:46 PM, Hou Tao wrote:
> Hi,
>
> On 8/14/2024 2:34 PM, Jingbo Xu wrote:
>> Hi, Tao,
>>
>> On 4/26/24 10:39 PM, Hou Tao wrote:
>>> From: Hou Tao
>>>
>>> Hi,
>>>
>>> The patch set aims to fix the warning rela
Hi,
On 8/14/2024 2:34 PM, Jingbo Xu wrote:
> Hi, Tao,
>
> On 4/26/24 10:39 PM, Hou Tao wrote:
>> From: Hou Tao
>>
>> Hi,
>>
>> The patch set aims to fix the warning related to an abnormal size
>> parameter of kmalloc() in virtiofs. Patch #1 fixes it b
Hi, Tao,
On 4/26/24 10:39 PM, Hou Tao wrote:
> From: Hou Tao
>
> Hi,
>
> The patch set aims to fix the warning related to an abnormal size
> parameter of kmalloc() in virtiofs. Patch #1 fixes it by introducing
> use_pages_for_kvec_io option in fuse_conn and enabling it
could not readily reproduce on a current kernel. Please double check
against the latest kernel.
> Stack dump:
>
> [ cut here ]
> unexpected event refcount: 2; ptr=888019589820
> WARNING: CPU: 0 PID: 13593 at kernel/events/core.c:5254 free_event+0xa3/
=888019589820
WARNING: CPU: 0 PID: 13593 at kernel/events/core.c:5254 free_event+0xa3/0xc0
kernel/events/core.c:5254
Modules linked in:
CPU: 0 PID: 13593 Comm: syz.3.346 Not tainted 6.8.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:free_event+0xa3/0xc0 kernel
; IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+263726e59eab6b442...@syzkaller.appspotmail.com
>
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at mm/slub.c:4550
> slab_free_after_rcu_debug+0x18b/0x270 mm/slub.c:4550
See https://lore.kernel.org/all/zqyths-o85nqu...@elver.google.com/T/#u
[ cut here ]
WARNING: CPU: 0 PID: 1 at mm/slub.c:4550 slab_free_after_rcu_debug+0x18b/0x270
mm/slub.c:4550
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted
6.11.0-rc1-next-20240802-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute
Hello Michael,
On Sun, Jul 14, 2024 at 03:38:42AM -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 12, 2024 at 04:53:25AM -0700, Breno Leitao wrote:
> > After the commit bdacf3e34945 ("net: Use nested-BH locking for
> > napi_alloc_cache.") was merged, the followin
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Fri, 12 Jul 2024 04:53:25 -0700 you wrote:
> After the commit bdacf3e34945 ("net: Use nested-BH locking for
> napi_alloc_cache.") was merged, the following warning began to appear:
>
>
在 2024/7/12 下午7:53, Breno Leitao 写道:
After the commit bdacf3e34945 ("net: Use nested-BH locking for
napi_alloc_cache.") was merged, the following warning began to appear:
WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
napi_skb_cache_put+0x82/0x4b0
__warn+0
On Fri, Jul 12, 2024 at 7:54 PM Breno Leitao wrote:
>
> After the commit bdacf3e34945 ("net: Use nested-BH locking for
> napi_alloc_cache.") was merged, the following warning began to appear:
>
> WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
> n
On Fri, Jul 12, 2024 at 04:53:25AM -0700, Breno Leitao wrote:
> After the commit bdacf3e34945 ("net: Use nested-BH locking for
> napi_alloc_cache.") was merged, the following warning began to appear:
>
>WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
> napi
On Fri, 12 Jul 2024 07:58:49 -0700 Breno Leitao wrote:
> I didn't send to `net` since this WARNING is only "showing" in net-next,
> due to commit bdacf3e34945 ("net: Use nested-BH locking for
> napi_alloc_cache.") being only in net-next.
>
> But you have a
On Fri, 12 Jul 2024 04:53:25 -0700 Breno Leitao wrote:
> After the commit bdacf3e34945 ("net: Use nested-BH locking for
> napi_alloc_cache.") was merged, the following warning began to appear:
>
>WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
> napi
Hello Jakub,
On Fri, Jul 12, 2024 at 07:54:32AM -0700, Jakub Kicinski wrote:
> On Fri, 12 Jul 2024 04:53:25 -0700 Breno Leitao wrote:
> > Subject: [PATCH net-next] virtio_net: Fix napi_skb_cache_put warning
>
> [PATCH net] for fixes so that the bot knows what to test against
On Fri, 12 Jul 2024 04:53:25 -0700 Breno Leitao wrote:
> Subject: [PATCH net-next] virtio_net: Fix napi_skb_cache_put warning
[PATCH net] for fixes so that the bot knows what to test against :)
No need to repost (this time).
After the commit bdacf3e34945 ("net: Use nested-BH locking for
napi_alloc_cache.") was merged, the following warning began to appear:
WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451
napi_skb_cache_put+0x82/0x4b0
__warn+0x12f/0x340
napi_skb_cache_put+
On Sat, Jul 06, 2024 at 12:15:01AM -0300, Ágatha Isabelle Chris Moreira Guedes
wrote:
> Fix the absence of warning message and kernel tainting when initializing
> drivers from the `drivers/staging` subtree from initcalls (when
> configured as built-in).
>
> When such a driver is
Hello,
On Sat, Jul 06, 2024 at 12:15:01AM -0300, Ágatha Isabelle Chris Moreira Guedes
wrote:
> Fix the absence of warning message and kernel tainting when initializing
> drivers from the `drivers/staging` subtree from initcalls (when
> configured as built-in).
>
> When such a dri
Thanks!
Acked-by: Dan Carpenter
regards,
dan carpenter
Fix the absence of warning message and kernel tainting when initializing
drivers from the `drivers/staging` subtree from initcalls (when
configured as built-in).
When such a driver is built as module and the module is loaded, the
`load_module()` function taints the kernel to signal code of
On Thu, Jul 04, 2024 at 09:20:49PM -0300, Ágatha Isabelle Chris Moreira Guedes
wrote:
> +#ifdef CONFIG_STAGING
> +/**
> + * staging_init_taint() - We need to taint the kernel whenever staging code
> + * is initialized (from built-in drivers) or loaded (as modules) and issue
> +
ere `CONFIG_STAGING=n`
because:
> +/**
> + * staging_init_taint() - We need to taint the kernel whenever staging code
> + * is initialized (from built-in drivers) or loaded (as modules) and issue
> + * a warning the first time it happens.
> + */
> +void staging_taint(const char *code_id,
Fix the absence of warning message and kernel tainting when initializing
drivers from the `drivers/staging` subtree from initcalls (when
configured as built-in).
When such a driver is built as module and the module is loaded, the
`load_module()` function taints the kernel to signal code of
1 - 100 of 7453 matches
Mail list logo
