Skip to content

FIPS-9 Add missing code that is included in the RPM but not represented in the kernel src trees - #66

Merged
PlaidCat merged 1 commit into
fips-9-certified/5.14.0-284.30.1from
{jmaple}_sync_code_with_release_fips-9-certified
Jan 22, 2025
Merged

FIPS-9 Add missing code that is included in the RPM but not represented in the kernel src trees#66
PlaidCat merged 1 commit into
fips-9-certified/5.14.0-284.30.1from
{jmaple}_sync_code_with_release_fips-9-certified

Conversation

@PlaidCat

@PlaidCatPlaidCat commented Jan 15, 2025

Copy link
Copy Markdown
Collaborator

This exists in the current delivery spec but is not in the kernel and this work has long since been done, I do not see a public version of the dist-git so that will be communicated internally

This is just reading it to the certified and will rebase fips-9-compliant off this commit.

net-memcg: avoid stalls when under memory pressure
jira LE-1603
bugfix: cgroupv2 cannot dowload file larger than RAM limit commit-author Jakub Kicinski <kuba@kernel.org>
commit 720ca52bcef225b967a339e0fffb6d0c7e962240
As Shakeel explains the commit under Fixes had the unintended side-effect of no longer pre-loading the cached memory allowance. Even tho we previously dropped the first packet received when over memory limit - the consecutive ones would get thru by using the cache. The charging was happening in batches of 128kB, so we'd let in 128kB (truesize) worth of packets per one drop.
After the change we no longer force charge, there will be no cache filling side effects. This causes significant drops and connection stalls for workloads which use a lot of page cache, since we can't reclaim page cache under GFP_NOWAIT.
Some of the latency can be recovered by improving SACK reneg handling but nowhere near enough to get back to the pre-5.15 performance (the application I'm experimenting with still sees 5-10x worst latency).
Apply the suggested workaround of using GFP_ATOMIC. We will now be more permissive than previously as we'll drop _no_ packets in softirq when under pressure. But I can't think of any good and simple way to address that within networking.
Link: https://lore.kernel.org/all/20221012163300.795e7b86@kernel.org/
Suggested-by: Shakeel Butt <shakeelb@google.com>
Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
Acked-by: Shakeel Butt <shakeelb@google.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Link: https://lore.kernel.org/r/20221021160304.1362511-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 720ca52bcef225b967a339e0fffb6d0c7e962240)
Signed-off-by: Jonathan Maple <jmaple@ciq.com>

@PlaidCat
net-memcg: avoid stalls when under memory pressure
d11bd6c
jira LE-1603
bugfix: cgroupv2 cannot dowload file larger than RAM limit
commit-author Jakub Kicinski <kuba@kernel.org>
commit 720ca52
As Shakeel explains the commit under Fixes had the unintended
side-effect of no longer pre-loading the cached memory allowance.
Even tho we previously dropped the first packet received when
over memory limit - the consecutive ones would get thru by using
the cache. The charging was happening in batches of 128kB, so
we'd let in 128kB (truesize) worth of packets per one drop.
After the change we no longer force charge, there will be no
cache filling side effects. This causes significant drops and
connection stalls for workloads which use a lot of page cache,
since we can't reclaim page cache under GFP_NOWAIT.
Some of the latency can be recovered by improving SACK reneg
handling but nowhere near enough to get back to the pre-5.15
performance (the application I'm experimenting with still
sees 5-10x worst latency).
Apply the suggested workaround of using GFP_ATOMIC. We will now
be more permissive than previously as we'll drop _no_ packets
in softirq when under pressure. But I can't think of any good
and simple way to address that within networking.
Link: https://lore.kernel.org/all/20221012163300.795e7b86@kernel.org/
Suggested-by: Shakeel Butt <shakeelb@google.com>
Fixes: 4b1327b ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
Acked-by: Shakeel Butt <shakeelb@google.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Link: https://lore.kernel.org/r/20221021160304.1362511-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 720ca52)
Signed-off-by: Jonathan Maple <jmaple@ciq.com>
@PlaidCatPlaidCat self-assigned this Jan 15, 2025
gvrose8192
gvrose8192 approved these changes Jan 15, 2025
View reviewed changes

@gvrose8192gvrose8192 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely need this one. Thanks!

@PlaidCat

PlaidCat commented Jan 15, 2025

Copy link
Copy Markdown
CollaboratorAuthor

Definitely need this one. Thanks!

YEah Its in the RPM but not in our branch ... don't want to loose this and its probably worth bringing to 9.2 in general

@PlaidCat
PlaidCat merged commit 4a5975c into fips-9-certified/5.14.0-284.30.1Jan 22, 2025
@PlaidCat
PlaidCat deleted the {jmaple}_sync_code_with_release_fips-9-certified branch January 22, 2025 22:33
github-actionsBot pushed a commit that referenced this pull request Apr 26, 2025
Rafael Aquini
mm/hugetlb: fix kernel NULL pointer dereference when migrating hugetl…
f2b7303
…b folio
JIRA: https://issues.redhat.com/browse/RHEL-84184
NOTE: this patch can also be found (by kerneloscope) on a dead parent branch
in upstream mainline tree as:
commit 1390a33
Conflicts:
* include/linux/page-flags.h: RHEL-only hunk is required here to avoid breaking
the build for kernel variants that disable CONFIG_TRANSPARENT_HUGEPAGE but
keep CONFIG_HUGETLBFS enabled (-rt). This is because RHEL-9 misses upstream
v6.10 commit 85edc15 ("mm: remove folio_prep_large_rmappable()") along
with its accompanying series which are irrelevant for this backport work;
This patch is a backport of the following upstream commit:
commit f708f69
Author: Miaohe Lin <linmiaohe@huawei.com>
Date: Tue Jul 9 20:04:33 2024 +0800
mm/hugetlb: fix kernel NULL pointer dereference when migrating hugetlb folio
A kernel crash was observed when migrating hugetlb folio:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 0 P4D 0
Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 3435 Comm: bash Not tainted 6.10.0-rc6-00450-g8578ca01f21f #66
RIP: 0010:__folio_undo_large_rmappable+0x70/0xb0
RSP: 0018:ffffb165c98a7b38 EFLAGS: 00000097
RAX: fffffbbc44528090 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffffa30e000a2800 RSI: 0000000000000246 RDI: ffffa3153ffffcc0
RBP: fffffbbc44528000 R08: 0000000000002371 R09: ffffffffbe4e5868
R10: 0000000000000001 R11: 0000000000000001 R12: ffffa3153ffffcc0
R13: fffffbbc44468000 R14: 0000000000000001 R15: 0000000000000001
FS: 00007f5b3a716740(0000) GS:ffffa3151fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000010959a000 CR4: 00000000000006f0
Call Trace:
<TASK>
__folio_migrate_mapping+0x59e/0x950
__migrate_folio.constprop.0+0x5f/0x120
move_to_new_folio+0xfd/0x250
migrate_pages+0x383/0xd70
soft_offline_page+0x2ab/0x7f0
soft_offline_page_store+0x52/0x90
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x380/0x540
ksys_write+0x64/0xe0
do_syscall_64+0xb9/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5b3a514887
RSP: 002b:00007ffe138fce68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f5b3a514887
RDX: 000000000000000c RSI: 0000556ab809ee10 RDI: 0000000000000001
RBP: 0000556ab809ee10 R08: 00007f5b3a5d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007f5b3a61b780 R14: 00007f5b3a617600 R15: 00007f5b3a616a00
It's because hugetlb folio is passed to __folio_undo_large_rmappable()
unexpectedly. large_rmappable flag is imperceptibly set to hugetlb folio
since commit f6a8dd9 ("hugetlb: convert alloc_buddy_hugetlb_folio to
use a folio"). Then commit be9581e ("mm: fix crashes from deferred
split racing folio migration") makes folio_migrate_mapping() call
folio_undo_large_rmappable() triggering the bug. Fix this issue by
clearing large_rmappable flag for hugetlb folios. They don't need that
flag set anyway.
Link: https://lkml.kernel.org/r/20240709120433.4136700-1-linmiaohe@huawei.com
Fixes: f6a8dd9 ("hugetlb: convert alloc_buddy_hugetlb_folio to use a folio")
Fixes: be9581e ("mm: fix crashes from deferred split racing folio migration")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Rafael Aquini <raquini@redhat.com>
PlaidCat added a commit that referenced this pull request Jun 18, 2025
@PlaidCat
mm/hugetlb: fix kernel NULL pointer dereference when migrating hugetl…
3ed86f2
…b folio
jira LE-3262
Rebuild_History Non-Buildable kernel-5.14.0-570.22.1.el9_6
commit-author Miaohe Lin <linmiaohe@huawei.com>
commit f708f69
A kernel crash was observed when migrating hugetlb folio:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 0 P4D 0
Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 3435 Comm: bash Not tainted 6.10.0-rc6-00450-g8578ca01f21f #66
RIP: 0010:__folio_undo_large_rmappable+0x70/0xb0
RSP: 0018:ffffb165c98a7b38 EFLAGS: 00000097
RAX: fffffbbc44528090 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffffa30e000a2800 RSI: 0000000000000246 RDI: ffffa3153ffffcc0
RBP: fffffbbc44528000 R08: 0000000000002371 R09: ffffffffbe4e5868
R10: 0000000000000001 R11: 0000000000000001 R12: ffffa3153ffffcc0
R13: fffffbbc44468000 R14: 0000000000000001 R15: 0000000000000001
FS: 00007f5b3a716740(0000) GS:ffffa3151fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000010959a000 CR4: 00000000000006f0
Call Trace:
<TASK>
__folio_migrate_mapping+0x59e/0x950
__migrate_folio.constprop.0+0x5f/0x120
move_to_new_folio+0xfd/0x250
migrate_pages+0x383/0xd70
soft_offline_page+0x2ab/0x7f0
soft_offline_page_store+0x52/0x90
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x380/0x540
ksys_write+0x64/0xe0
do_syscall_64+0xb9/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5b3a514887
RSP: 002b:00007ffe138fce68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f5b3a514887
RDX: 000000000000000c RSI: 0000556ab809ee10 RDI: 0000000000000001
RBP: 0000556ab809ee10 R08: 00007f5b3a5d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007f5b3a61b780 R14: 00007f5b3a617600 R15: 00007f5b3a616a00
It's because hugetlb folio is passed to __folio_undo_large_rmappable()
unexpectedly. large_rmappable flag is imperceptibly set to hugetlb folio
since commit f6a8dd9 ("hugetlb: convert alloc_buddy_hugetlb_folio to
use a folio"). Then commit be9581e ("mm: fix crashes from deferred
split racing folio migration") makes folio_migrate_mapping() call
folio_undo_large_rmappable() triggering the bug. Fix this issue by
clearing large_rmappable flag for hugetlb folios. They don't need that
flag set anyway.
Link: https://lkml.kernel.org/r/20240709120433.4136700-1-linmiaohe@huawei.com
Fixes: f6a8dd9 ("hugetlb: convert alloc_buddy_hugetlb_folio to use a folio")
Fixes: be9581e ("mm: fix crashes from deferred split racing folio migration")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit f708f69)
Signed-off-by: Jonathan Maple <jmaple@ciq.com>
github-actionsBot pushed a commit that referenced this pull request Sep 30, 2025
@metze-samba@smfrench
smb: client: make use of smbdirect_socket.statistics
ddfcb06
This will allow us to use common functions soon.
Note this generates the following warnings from
scripts/checkpatch.pl --quiet:
WARNING: quoted string split across lines
#59: FILE: fs/smb/client/cifs_debug.c:481:
+ seq_printf(m, "\nDebug count_get_receive_buffer: %llu "
+ "count_put_receive_buffer: %llu count_send_empty: %llu",
WARNING: quoted string split across lines
#66: FILE: fs/smb/client/cifs_debug.c:486:
seq_printf(m, "\nRead Queue "
+ "count_enqueue_reassembly_queue: %llu "
WARNING: quoted string split across lines
#67: FILE: fs/smb/client/cifs_debug.c:487:
+ "count_enqueue_reassembly_queue: %llu "
+ "count_dequeue_reassembly_queue: %llu "
total: 0 errors, 3 warnings, 83 lines checked
scripts/checkpatch.pl: FAILED
But I left them in there, because it matches the code
arround it...
Cc: Steve French <smfrench@gmail.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Long Li <longli@microsoft.com>
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
github-actionsBot pushed a commit that referenced this pull request Jan 20, 2026
@pcacjr
smb: client: make use of smbdirect_socket.statistics
3c27e52
JIRA: https://issues.redhat.com/browse/RHEL-116054
commit ddfcb06
Author: Stefan Metzmacher <metze@samba.org>
Date: Tue Aug 19 13:54:35 2025 +0200
smb: client: make use of smbdirect_socket.statistics
This will allow us to use common functions soon.
Note this generates the following warnings from
scripts/checkpatch.pl --quiet:
WARNING: quoted string split across lines
#59: FILE: fs/smb/client/cifs_debug.c:481:
+ seq_printf(m, "\nDebug count_get_receive_buffer: %llu "
+ "count_put_receive_buffer: %llu count_send_empty: %llu",
WARNING: quoted string split across lines
#66: FILE: fs/smb/client/cifs_debug.c:486:
seq_printf(m, "\nRead Queue "
+ "count_enqueue_reassembly_queue: %llu "
WARNING: quoted string split across lines
#67: FILE: fs/smb/client/cifs_debug.c:487:
+ "count_enqueue_reassembly_queue: %llu "
+ "count_dequeue_reassembly_queue: %llu "
total: 0 errors, 3 warnings, 83 lines checked
scripts/checkpatch.pl: FAILED
But I left them in there, because it matches the code
arround it...
Cc: Steve French <smfrench@gmail.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Long Li <longli@microsoft.com>
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Paulo Alcantara <paalcant@redhat.com>
github-actionsBot pushed a commit to bmastbergen/kernel-src-tree that referenced this pull request Feb 6, 2026
@pcacjr
smb: client: make use of smbdirect_socket.statistics
f649e4a
JIRA: https://issues.redhat.com/browse/RHEL-116058
Conflicts:
- Context difference due to missing upstream commit
3d78fe7, which is related
to netfslib and unsupported in RHEL 9.8.
commit ddfcb06
Author: Stefan Metzmacher <metze@samba.org>
Date: Tue Aug 19 13:54:35 2025 +0200
smb: client: make use of smbdirect_socket.statistics
This will allow us to use common functions soon.
Note this generates the following warnings from
scripts/checkpatch.pl --quiet:
WARNING: quoted string split across lines
ctrliq#59: FILE: fs/smb/client/cifs_debug.c:481:
+ seq_printf(m, "\nDebug count_get_receive_buffer: %llu "
+ "count_put_receive_buffer: %llu count_send_empty: %llu",
WARNING: quoted string split across lines
ctrliq#66: FILE: fs/smb/client/cifs_debug.c:486:
seq_printf(m, "\nRead Queue "
+ "count_enqueue_reassembly_queue: %llu "
WARNING: quoted string split across lines
ctrliq#67: FILE: fs/smb/client/cifs_debug.c:487:
+ "count_enqueue_reassembly_queue: %llu "
+ "count_dequeue_reassembly_queue: %llu "
total: 0 errors, 3 warnings, 83 lines checked
scripts/checkpatch.pl: FAILED
But I left them in there, because it matches the code
arround it...
Cc: Steve French <smfrench@gmail.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Long Li <longli@microsoft.com>
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Paulo Alcantara <paalcant@redhat.com>
github-actionsBot pushed a commit that referenced this pull request Aug 21, 2026
Zizhi Wo@axboe
null_blk: register configfs subsystem after creating default devices
c9d293d
In null_init(), configfs_register_subsystem() currently runs before
register_blkdev(), so when null_blk is built as a module, a racing mkdir()
+ poweron from userspace can reach null_add_dev() while null_major is still
0. __add_disk() then hits WARN_ON(disk->minors) (major=0 with minors!=0)
and fails:
[root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at __add_disk+0x8a7/0xde0,
[ 2366.523552] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib
[ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full)
......
[ 2366.547251] Call Trace:
[ 2366.547575] <TASK>
[ 2366.547831] ? _raw_spin_lock+0x84/0xe0
[ 2366.548260] add_disk_fwnode+0x114/0x560
[ 2366.548739] null_add_dev+0x102d/0x1b80 [null_blk]
[ 2366.549310] ? __pfx_null_add_dev+0x10/0x10 [null_blk]
[ 2366.549906] ? mutex_lock+0xde/0x1c0
[ 2366.550361] ? __pfx_mutex_lock+0x10/0x10
[ 2366.550827] nullb_device_power_store+0x1e7/0x280 [null_blk]
[ 2366.551499] ? __pfx_nullb_device_power_store+0x10/0x10 [null_blk]
[ 2366.552177] ? __kmalloc_cache_noprof+0x1f5/0x470
[ 2366.552748] ? configfs_write_iter+0x35c/0x4e0
[ 2366.553242] configfs_write_iter+0x286/0x4e0
[ 2366.553787] vfs_write+0x52d/0xd00
[ 2366.554169] ? __pfx_vfs_write+0x10/0x10
[ 2366.554679] ? __pfx___css_rstat_updated+0x10/0x10
[ 2366.555196] ? fdget_pos+0x1cf/0x4c0
[ 2366.555649] ksys_write+0xfc/0x1d0
......
Additionally, the err_dev path destroys all devices on nullb_list while
configfs is still registered. If a racing mkdir() + poweron puts a user
device on the list, null_destroy_dev()->null_free_dev() kfrees the user
device's nullb_device but /sys/kernel/config/nullb/<name> is still
reachable. Any userspace access to the item will trigger a UAF.
For simplicity, move configfs_register_subsystem() to the end to solve
the problems above.
Fixes: 3bf2bd2 ("nullb: add configfs interface")
Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
Link: https://patch.msgid.link/20260725022509.714271-3-wozizhi@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@bmastbergenbmastbergenbmastbergen approved these changes
@jason-rodrijason-rodriAwaiting requested review from jason-rodri
+1 more reviewer
@gvrose8192gvrose8192gvrose8192 approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@PlaidCatPlaidCat

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@PlaidCat@gvrose8192@bmastbergen