Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpf: Minor fixes #3236

Closed
wants to merge 5 commits into from
Closed

Conversation

kernel-patches-bot
Copy link

Pull request for series with
subject: bpf: Minor fixes
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=655094

@kernel-patches-bot
Copy link
Author

Master branch: c5c7358
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=655094
version: 1

@kernel-patches-bot
Copy link
Author

Master branch: d17b557
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=655094
version: 1

@kernel-patches-bot
Copy link
Author

Master branch: f0cf642
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=655094
version: 1

@kernel-patches-bot
Copy link
Author

Master branch: b0cbd61
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=655094
version: 1

@kernel-patches-bot
Copy link
Author

Master branch: 6d30487
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=655094
version: 1

Kernel Patches Daemon and others added 3 commits June 30, 2022 13:58
GFP_ATOMIC doesn't cooperate well with memcg pressure so far, especially
if we allocate too much GFP_ATOMIC memory. For example, when we set the
memcg limit to limit a non-preallocated bpf memory, the GFP_ATOMIC can
easily break the memcg limit by force charge. So it is very dangerous to
use GFP_ATOMIC in non-preallocated case. One way to make it safe is to
remove __GFP_HIGH from GFP_ATOMIC, IOW, use (__GFP_ATOMIC |
__GFP_KSWAPD_RECLAIM) instead, then it will be limited if we allocate
too much memory.

We introduced BPF_F_NO_PREALLOC is because full map pre-allocation is
too memory expensive for some cases. That means removing __GFP_HIGH
doesn't break the rule of BPF_F_NO_PREALLOC, but has the same goal with
it-avoiding issues caused by too much memory. So let's remove it.

__GFP_KSWAPD_RECLAIM doesn't cooperate well with memcg pressure neither
currently. But the memcg code can be improved to make
__GFP_KSWAPD_RECLAIM work well under memcg pressure.

It also fixes a typo in the comment.

Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE and BPF_PROG_TYPE_TRACING are
trace type as well, which may also cause unexpected memory allocation if
we set BPF_F_NO_PREALLOC.
Let's also warn on both of them.

Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
@kernel-patches-bot
Copy link
Author

Master branch: 39e940d
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=655094
version: 1

It doesn't need to do the preempt check when migrate is disabled
after commit
74d862b ("sched: Make migrate_disable/enable() independent of RT").

Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
For example,
/sys/fs/bpf/maps.debug is a bpf link, when you run `bpftool map show` to
show it,
- before
  $ bpftool map show pinned /sys/fs/bpf/maps.debug
  Error: incorrect object type: unknown
- after
  $ bpftool map show pinned /sys/fs/bpf/maps.debug
  Error: incorrect object type: link

Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
@kernel-patches-bot
Copy link
Author

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=655094 irrelevant now. Closing PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants