Hi Alexei, On Tue, Aug 22, 2023 at 11:57 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Tue, Aug 22, 2023 at 10:48 AM Chris Li <chrisl@xxxxxxxxxx> 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?" > > Where did this concern come from? > Since when BPF can modify arbitrary state? > > But I wasn't cc-ed on the original patch, so not sure what it attempts to do. > Maybe concern is valid. Sorry I did not CC you on the original patch submission. I should. Here is the link for the 1/2 patch, which has the step to reproduce. https://lore.kernel.org/linux-mm/20230817-free_pcppages_bulk-v1-1-c14574a9f80c@xxxxxxxxxx/ It is using an older version of the BPF program. That spinlock allocation was fixed in commit c66a36af7ba3a628. Chris > > > 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. > > panic and warns because of bpf prog?! > bpf infra takes all the precaution to make sure that bpf progs > can never cause such damage. > > > > > How about the second (clean up) patch or Keming's clean up version? I can modify > > it to take out the pcp->count if the verdict is just not supporting > > BPF changing internal > > state at all. I do wish to get rid of the pindex_min and pindex_max. > > > > Thanks > > > > Chris >
