From: Shivank Garg <shivankg@amd.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: kernel test robot <lkp@intel.com>,
oe-kbuild-all@lists.linux.dev,
Linux Memory Management List <linux-mm@kvack.org>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [akpm-mm:mm-unstable 272/272] include/linux/stddef.h:8:14: error: called object is not a function or function pointer
Date: Fri, 2 May 2025 11:41:34 +0530 [thread overview]
Message-ID: <b7caee56-80b4-49e2-a140-16a0adaee209@amd.com> (raw)
In-Reply-To: <20250501155912.fc59c6e36c87c623501fe988@linux-foundation.org>
On 5/2/2025 4:29 AM, Andrew Morton wrote:
> On Thu, 1 May 2025 22:52:30 +0100 Matthew Wilcox <willy@infradead.org> wrote:
>
>> On Thu, May 01, 2025 at 02:13:04PM -0700, Andrew Morton wrote:
>>> Should this new JFS migration code be wrapped in #ifdef CONFIG_MIGRATION?
>>
>> Yes
>
> OK, thanks, I'll try this. Maybe there's a way to reduce the amount of
> ifdeffing. Warning, contains bonus whitespace tuneups!
>
> --- a/fs/jfs/jfs_metapage.c~jfs-implement-migrate_folio-for-jfs_metapage_aops-fix-2
> +++ a/fs/jfs/jfs_metapage.c
> @@ -152,8 +152,10 @@ static inline void dec_io(struct folio *
> handler(folio, anchor->status);
> }
>
> -static int __metapage_migrate_folio(struct address_space *mapping, struct folio *dst,
> - struct folio *src, enum migrate_mode mode)
> +#ifdef CONFIG_MIGRATION
> +static int __metapage_migrate_folio(struct address_space *mapping,
> + struct folio *dst, struct folio *src,
> + enum migrate_mode mode)
> {
> struct meta_anchor *src_anchor = src->private;
> struct metapage *mps[MPS_PER_PAGE] = {0};
> @@ -199,8 +201,10 @@ static int __metapage_migrate_folio(stru
>
> return MIGRATEPAGE_SUCCESS;
> }
> +#endif /* CONFIG_MIGRATION */
>
> #else
> +
> static inline struct metapage *folio_to_mp(struct folio *folio, int offset)
> {
> return folio->private;
> @@ -224,8 +228,10 @@ static inline void remove_metapage(struc
> #define inc_io(folio) do {} while(0)
> #define dec_io(folio, status, handler) handler(folio, status)
>
> -static int __metapage_migrate_folio(struct address_space *mapping, struct folio *dst,
> - struct folio *src, enum migrate_mode mode)
> +#ifdef CONFIG_MIGRATION
> +static int __metapage_migrate_folio(struct address_space *mapping,
> + struct folio *dst, struct folio *src,
> + enum migrate_mode mode)
> {
> struct metapage *mp;
> int page_offset;
> @@ -249,6 +255,7 @@ static int __metapage_migrate_folio(stru
>
> return MIGRATEPAGE_SUCCESS;
> }
> +#endif /* CONFIG_MIGRATION */
>
> #endif
>
> @@ -629,11 +636,13 @@ static bool metapage_release_folio(struc
> return ret;
> }
>
> +#ifdef CONFIG_MIGRATION
> /*
> * metapage_migrate_folio - Migration function for JFS metapages
> */
> -static int metapage_migrate_folio(struct address_space *mapping, struct folio *dst,
> - struct folio *src, enum migrate_mode mode)
> +static int metapage_migrate_folio(struct address_space *mapping,
> + struct folio *dst, struct folio *src,
> + enum migrate_mode mode)
> {
> int expected_count;
>
> @@ -646,6 +655,9 @@ static int metapage_migrate_folio(struct
> return -EAGAIN;
> return __metapage_migrate_folio(mapping, dst, src, mode);
> }
> +#else
> +#define metapage_migrate_folio NULL
> +#endif /* CONFIG_MIGRATION */
>
> static void metapage_invalidate_folio(struct folio *folio, size_t offset,
> size_t length)
> _
>
Hi Andrew,
Thank you for addressing the issues with my patch and fixing the errors.
I appreciate the cleanup and the CONFIG_MIGRATION wrapping.
Best regards,
Shivank
prev parent reply other threads:[~2025-05-02 6:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 21:02 kernel test robot
2025-05-01 21:13 ` Andrew Morton
2025-05-01 21:52 ` Matthew Wilcox
2025-05-01 22:59 ` Andrew Morton
2025-05-02 6:11 ` Shivank Garg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7caee56-80b4-49e2-a140-16a0adaee209@amd.com \
--to=shivankg@amd.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox