On Tue, Aug 22, 2023 at 2:34 PM Chris Li <chrisl@xxxxxxxxxx> wrote: > > 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. No. It was a temp workaround. It was fixed on bpf local storage side later.
