Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 14 Jun 2023 18:11:08 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        Wei-chin Tsai =?utf-8?B?KOiUoee2reaZiSk=?= 
        <Wei-chin.Tsai@mediatek.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Mel Lee =?utf-8?B?KOadjuWlh+mMmik=?= <Mel.Lee@mediatek.com>,
        "linux-mediatek@lists.infradead.org" 
        <linux-mediatek@lists.infradead.org>,
        wsd_upstream <wsd_upstream@mediatek.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
        Ivan Tseng =?utf-8?B?KOabvuW/l+i7kik=?= 
        <ivan.tseng@mediatek.com>
Subject: Re: [PATCH v2 2/3] memory: export symbols for memory related
 functions
Message-ID: <ZIn0rMjYESJHuzyg@casper.infradead.org>
References: <20230614032038.11699-1-Wei-chin.Tsai@mediatek.com>
 <20230614032038.11699-3-Wei-chin.Tsai@mediatek.com>
 <ZIlpWR6/uWwQUc6J@shell.armlinux.org.uk>
 <fef0006ced8d5e133a3bfbf4dc4353a86578b9cd.camel@mediatek.com>
 <cb7f49bc-8ed4-a916-44f4-39e360afce41@collabora.com>
 <ZInpF3aKMLFVQ3Vf@shell.armlinux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZInpF3aKMLFVQ3Vf@shell.armlinux.org.uk>
Precedence: bulk

On Wed, Jun 14, 2023 at 05:21:43PM +0100, Russell King (Oracle) wrote:
> What I'm trying to get at is that we have arch_vma_name in
> arch/arm/kernel/process.c and also a weak function in kernel/signal.c.
> 
> Both of these end up adding an entry into the __ksymtab_strings
> section and a ___ksymtab section for this symbol. So we end up with
> two entries in each.
> 
> Now, if the one from kernel/signal.c points at its own weak function,
> and that is found first, then that's the function that is going to be
> bound, not the function that's overriding it.
> 
> If, instead, the export in kernel/signal.c ends up pointing at the
> overriden function, then the export in arch/arm/kernel/process.c is
> entirely redundant.
> 
> So, you need to get to the bottom of this... and until you do I'm
> afraid I'll have to NAK this patch.

I think the patch should be NAKed indefinitely.  I had a quick look at
the user, and it seems like something is being done in the kernel that
should be done in userspace.