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

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

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable
head:   cb1d236cb1038fa1bbae9913803f1c655b86d931
commit: 70dd375afcfe1839321ea8a65749404a99f0e773 [179/192] zswap: make shrinking memcg-aware
config: x86_64-randconfig-r112-20231129 (https://download.01.org/0day-ci/archive/20231129/202311292250.RUfWGNgx-lkp@intel.com/config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231129/202311292250.RUfWGNgx-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311292250.RUfWGNgx-lkp@intel.com/

All errors (new ones prefixed by >>):

   mm/zswap.c: In function 'mem_cgroup_from_entry':
   mm/zswap.c:298:24: error: implicit declaration of function 'obj_cgroup_memcg'; did you mean 'obj_cgroup_put'? [-Werror=implicit-function-declaration]
     return entry->objcg ? obj_cgroup_memcg(entry->objcg) : NULL;
                           ^~~~~~~~~~~~~~~~
                           obj_cgroup_put
   mm/zswap.c:298:55: warning: pointer/integer type mismatch in conditional expression
     return entry->objcg ? obj_cgroup_memcg(entry->objcg) : NULL;
                                                          ^
   mm/zswap.c: In function 'shrink_worker':
>> mm/zswap.c:825:17: error: dereferencing pointer to incomplete type 'struct mem_cgroup'
      css_get(&memcg->css);
                    ^~
   cc1: some warnings being treated as errors


vim +825 mm/zswap.c

   798	
   799	static void shrink_worker(struct work_struct *w)
   800	{
   801		struct zswap_pool *pool = container_of(w, typeof(*pool),
   802							shrink_work);
   803		struct mem_cgroup *memcg;
   804		int ret, failures = 0;
   805	
   806		/* global reclaim will select cgroup in a round-robin fashion. */
   807		do {
   808			spin_lock(&zswap_pools_lock);
   809			memcg = pool->next_shrink =
   810				mem_cgroup_iter_online(NULL, pool->next_shrink, NULL, true);
   811	
   812			/* full round trip */
   813			if (!memcg) {
   814				spin_unlock(&zswap_pools_lock);
   815				if (++failures == MAX_RECLAIM_RETRIES)
   816					break;
   817	
   818				goto resched;
   819			}
   820	
   821			/*
   822			 * Acquire an extra reference to the iterated memcg in case the
   823			 * original reference is dropped by the zswap offlining callback.
   824			 */
 > 825			css_get(&memcg->css);
   826			spin_unlock(&zswap_pools_lock);
   827	
   828			ret = shrink_memcg(memcg);
   829			mem_cgroup_put(memcg);
   830	
   831			if (ret == -EINVAL)
   832				break;
   833			if (ret && ++failures == MAX_RECLAIM_RETRIES)
   834				break;
   835	
   836	resched:
   837			cond_resched();
   838		} while (!zswap_can_accept());
   839	}
   840	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Andrew Morton]

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.

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

[Andrew Morton]

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.

So I'll restore this series with this hack:


 include/linux/memcontrol.h |    5 +++++
 mm/zswap.c                 |    3 +++
 2 files changed, 8 insertions(+)

--- a/include/linux/memcontrol.h~zswap-make-shrinking-memcg-aware-fix
+++ a/include/linux/memcontrol.h
@@ -1165,6 +1165,11 @@ unsigned long mem_cgroup_soft_limit_recl
 
 #define MEM_CGROUP_ID_SHIFT	0
 
+static inline struct mem_cgroup *obj_cgroup_memcg(struct obj_cgroup *objcg)
+{
+	return NULL;
+}
+
 static inline struct mem_cgroup *folio_memcg(struct folio *folio)
 {
 	return NULL;
--- a/mm/zswap.c~zswap-make-shrinking-memcg-aware-fix
+++ a/mm/zswap.c
@@ -32,6 +32,7 @@
 #include <linux/mm_types.h>
 #include <linux/page-flags.h>
 #include <linux/swapops.h>
+#include <linux/memcontrol.h>
 #include <linux/writeback.h>
 #include <linux/pagemap.h>
 #include <linux/workqueue.h>
@@ -822,7 +823,9 @@ static void shrink_worker(struct work_st
 		 * Acquire an extra reference to the iterated memcg in case the
 		 * original reference is dropped by the zswap offlining callback.
 		 */
+#ifdef CONFIG_MEMCG
 		css_get(&memcg->css);
+#endif
 		spin_unlock(&zswap_pools_lock);
 
 		ret = shrink_memcg(memcg);
_

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

[Yosry Ahmed]

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.

I hope this helps.

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

[Andrew Morton]

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.

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

[Yosry Ahmed]

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?

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

[Andrew Morton]

On Wed, 29 Nov 2023 14:31:12 -0800 Yosry Ahmed <yosryahmed@google.com> wrote:

> > 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?

Sure.  Normally basing on current -linus works out.

For best accuracy the base could be the preceding patch in mm-unstable
which in this case is "zram: use kmap_local_page()", but that level of
fiddling is rarely needed.

Alternatively, if the changes are small then sending me a shower of
small fixups against latest mm-unstable works.  I'll figure out how to
arrange things so everything lands nicely.

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

[Nhat Pham]

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?

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

[Yosry Ahmed]

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.

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

[Nhat Pham]

On Wed, Nov 29, 2023 at 4:13 PM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> 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.

Ohhh I totally misunderstood this email chain then. Woopsies. Ok cool will do.

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

[Nhat Pham]

Ok I just sent out v8. I've tried to build the kernel with 4
combinations of CONFIG_ZSWAP and CONFIG_MEMCG - hopefully there is no
further build error.

On Wed, Nov 29, 2023 at 4:18 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Wed, Nov 29, 2023 at 4:13 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > 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.
>
> Ohhh I totally misunderstood this email chain then. Woopsies. Ok cool will do.