On Tue, Aug 22, 2023 at 10:48:42AM -0700, Chris Li wrote: > Hi Mel, > > Adding Alexei to the discussion. > > On Mon, Aug 21, 2023 at 3:32 AM Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, Aug 17, 2023 at 11:05:22PM -0700, Chris Li wrote: > > > In this patch series I want to safeguard > > > the free_pcppage_bulk against change in the > > > pcp->count outside of this function. e.g. > > > by BPF program inject on the function tracepoint. > > > > > > I break up the patches into two seperate patches > > > for the safeguard and clean up. > > > > > > Hopefully that is easier to review. > > > > > > Signed-off-by: Chris Li <chrisl@xxxxxxxxxx> > > > > This sounds like a maintenance nightmare if internal state can be arbitrary > > modified by a BPF program and still expected to work properly in all cases. > > Every review would have to take into account "what if a BPF script modifies > > state behind our back?" > > Thanks for the feedback. > > I agree that it is hard to support if we allow BPF to change any internal > stage as a rule. That is why it is a RFC. Would you consider it case > by case basis? > The kernel panic is bad, the first patch is actually very small. I can > also change it > to generate warnings if we detect the inconsistent state. We wouldn't allow C code that hooks spinlocks (eg lockdep) to allocate memory. I don't understand why BPF code should allocate memory either.
