linux-kernel - Re: [PATCH rfc 0/6] Scheduler BPF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YedFIIK+a7AbsfPt@carbon.dhcp.thefacebook.com>
Date:   Tue, 18 Jan 2022 14:54:24 -0800
From:   Roman Gushchin <guro@...com>
To:     Huichun Feng <foxhoundsk.tw@...il.com>
CC:     <bpf@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <mgorman@...hsingularity.net>, <mingo@...hat.com>,
        <peterz@...radead.org>
Subject: Re: [PATCH rfc 0/6] Scheduler BPF

On Sat, Jan 15, 2022 at 04:29:24PM +0800, Huichun Feng wrote:
> Hi Roman and the list,

Hello Huichun!

> 
> I have a naive question regarding BPF hook for sched.
> 
> Given that BPF can also be attached to tracepoint, why do we add a BPF prog
> type specific to sched?

Tracing programs can have return values as well, see kretprobes.

> 
> The reason I can come up with is that sched BPF can have retval to drive the
> scheduling decision in static branch, whereas tracepoint is not able to do this.
> Is it mainly because of this or anything else?

Well, you are right that right now there is no strict necessity to
introduce a new prog type (aside from static branch mechanism you
mentioned), however I believe it's useful in a long run. Sched
programs might be able to use a different set of helpers, maybe there
will be some additional restrictions, etc. It's an RFC version of the
patchset and any ideas, suggestions and critic are highly welcome!

Thanks!