Re: [akpm-mm:mm-unstable 179/192] mm/zswap.c:825:17: error: dereferencing pointer to incomplete type 'struct mem_cgroup'

[Yosry Ahmed <yosryahmed@google.com>]

On Wed, Nov 29, 2023 at 4:02 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Wed, Nov 29, 2023 at 2:31 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > On Wed, Nov 29, 2023 at 2:29 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > On Wed, 29 Nov 2023 14:18:15 -0800 Yosry Ahmed <yosryahmed@google.com> wrote:
> > >
> > > > On Wed, Nov 29, 2023 at 1:53 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > >
> > > > > On Wed, 29 Nov 2023 13:43:13 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > >
> > > > > > On Wed, 29 Nov 2023 23:42:11 +0800 kernel test robot <lkp@intel.com> wrote:
> > > > > >
> > > > > > > >> mm/zswap.c:825:17: error: dereferencing pointer to incomplete type 'struct mem_cgroup'
> > > > > > >       css_get(&memcg->css);
> > > > > > >                     ^~
> > > > > >
> > > > > > OK, thanks, patchset needs work for CONFIG_MEMCG=n.  I'll drop this version.
> > > > >
> > > > > Well that's annoying - the "mm: memcg: subtree stats flushing and
> > > > > thresholds" series had lots of dependencies on this series.
> > > >
> > > > FWIW, the "mm: memcg: subtree stats flushing and thresholds" series
> > > > has no actual dependency on the zswap series. The conflicts come from
> > > > patch 2, which moves some code in mm/memcontrol.c, which happens to be
> > > > touched by the zswap series. The first 2 patches of the stats series
> > > > are just refactoring with no functional changes, so if those two can
> > > > remain in mm-unstable, independent of the remaining of the series or
> > > > the zswap series, then either Nhat or I could easily rebased our
> > > > patches on top of them, and you can easily move the series in & out of
> > > > mm-unstable without conflicts.
> > > >
> > > > Another thing is, the only difference between v3 & v4 of the "mm:
> > > > memcg: subtree stats flushing and thresholds" series is the rebase on
> > > > top of the zswap series. So if you want, you can take both series out,
> > > > and add in v3 of the stats series instead of v4. If you need to remove
> > > > the stast series again in the future, you can leave the first two
> > > > patches to avoid conflicts with the zswap series.
> > > >
> > >
> > > Ok, thanks.  I prefer not to make what is in mm.git too different from
> > > what was sent.
> > >
> > > I've left everything in place:
> > >
> > > list_lru-allows-explicit-memcg-and-numa-node-selection.patch
> > > memcontrol-add-a-new-function-to-traverse-online-only-memcg-hierarchy.patch
> > > zswap-make-shrinking-memcg-aware.patch
> > > zswap-make-shrinking-memcg-aware-fix.patch
> > > mm-memcg-add-per-memcg-zswap-writeback-stat.patch
> > > selftests-cgroup-update-per-memcg-zswap-writeback-selftest.patch
> > > zswap-shrinks-zswap-pool-based-on-memory-pressure.patch
> > > #
> > > ...
> > > #
> > > mm-memcg-change-flush_next_time-to-flush_last_time.patch
> > > mm-memcg-move-vmstats-structs-definition-above-flushing-code.patch
> > > mm-memcg-make-stats-flushing-threshold-per-memcg.patch
> > > mm-workingset-move-the-stats-flush-into-workingset_test_recent.patch
> > > mm-memcg-restore-subtree-stats-flushing.patch
> > >
> > > in the hope that a new version of the first series ("workload-specific
> > > and memory pressure-driven zswap writeback") can be dropped in place of
> > > the old version.
> > >
> >
> > I see. So Nhat needs to *not* rebase his patches on top of the current
> > mm-unstable, right?
>
> FWIW, I'll have to re-send a v8 to fix the kernel test robots/build
> issues that I've missed and incorporate the comments/suggestions from
> Michal and Johannes. IIUC, your series is ready right? Then we can
> have your v3 in mm-unstable first, then I can rebase my patch's v8 on
> top of that (fixing any merge conflicts along the way), then send out
> the whole thing again.
>
> Does this sound good?

Andrew said he expects a new version to be dropped in place of the old
version, and my v4 is already in mm-unstable on top of your series. So
I guess you should send v8 against Linus's tree (or mm-unstable at the
same base as your v7), and Andrew will replace v7 with v8 in place.