Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Subject: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
Date: Fri, 13 Dec 2024 10:57:52 -0800
Cc: Sebastian Sewior <bigeasy@xxxxxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, Matthew Wilcox <willy@xxxxxxxxxxxxx>, bpf <bpf@xxxxxxxxxxxxxxx>, Andrii Nakryiko <andrii@xxxxxxxxxx>, Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Vlastimil Babka <vbabka@xxxxxxx>, Hou Tao <houtao1@xxxxxxxxxx>, Johannes Weiner <hannes@xxxxxxxxxxx>, shakeel.butt@xxxxxxxxx, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Tejun Heo <tj@xxxxxxxxxx>, linux-mm <linux-mm@xxxxxxxxx>, Kernel Team <kernel-team@xxxxxx>
In-reply-to: <CAADnVQ+R3ABHX2sdiTqjgZDgn0==cA3gryx9h_uDktU6P2s2aw@mail.gmail.com>

On Fri, Dec 13, 2024 at 10:44 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> If hard-irq acquired rt_mutex B (spin_lock or spin_trylock doesn't
> change the above analysis),

attempting to spin_lock from irq is obviously not safe. scratch that part.

References:
- [PATCH bpf-next v2 0/6] bpf, mm: Introduce __GFP_TRYLOCK
  - From: Alexei Starovoitov
- [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Alexei Starovoitov
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Matthew Wilcox
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Michal Hocko
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Alexei Starovoitov
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Sebastian Sewior
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Michal Hocko
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Sebastian Sewior
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Steven Rostedt
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Sebastian Sewior
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Steven Rostedt
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Alexei Starovoitov

Prev by Date: Re: [PATCH bpf-next v5 4/5] bpf: Make fs kfuncs available for SYSCALL and TRACING program types
Next by Date: Re: LSF/MM/BPF: 2025: Call for Proposals
Previous by thread: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
Next by thread: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
Index(es):
- Date
- Thread

[Index of Archives] [Linux Samsung SoC] [Linux Rockchip SoC] [Linux Actions SoC] [Linux for Synopsys ARC Processors] [Linux NFS] [Linux NILFS] [Linux USB Devel] [Video for Linux] [Linux Audio Users] [Yosemite News] [Linux Kernel] [Linux SCSI]