[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZaD0L7nkFeTwv_g5@pc636>
Date: Fri, 12 Jan 2024 09:11:27 +0100
From: Uladzislau Rezki <urezki@...il.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: "Uladzislau Rezki (Sony)" <urezki@...il.com>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, Baoquan He <bhe@...hat.com>,
Lorenzo Stoakes <lstoakes@...il.com>,
Matthew Wilcox <willy@...radead.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Dave Chinner <david@...morbit.com>,
Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH 1/1] mm: vmalloc: Fix a warning in the
crash_save_vmcoreinfo_init()
> On Thu, Jan 11, 2024 at 08:23:29PM +0100, Uladzislau Rezki (Sony) wrote:
> > #endif
> > VMCOREINFO_SYMBOL(_stext);
> > - vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", (unsigned long) VMALLOC_START);
>
> Well, the right fix is of course to make sure VMALLOC_START has a
> consistent type, else we need to plaster this crud all over.
> unsigned long seems like the right type for it, so at least m68k should
> be fixed to confirm to that by adding a UL postfix to the definition.
>
I agree with you. I wanted to focus on fixing that particular place
because i wanted to avoid other(on this step), possible side effects
or drawbacks if i went with patching the arch/m68k/* files.
But, in general arch/m68k/* has to be fixed.
--
Uladzislau Rezki
Powered by blists - more mailing lists