[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191108135631.GA22507@linux-8ccs>
Date: Fri, 8 Nov 2019 14:56:31 +0100
From: Jessica Yu <jeyu@...nel.org>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Andrea Arcangeli <aarcange@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Matthias Maennich <maennich@...gle.com>
Subject: Re: [PATCH 03/13] kvm: monolithic: fixup x86-32 build
+++ Paolo Bonzini [05/11/19 16:10 +0100]:
>On 05/11/19 15:56, Andrea Arcangeli wrote:
>>>> I think we should:
>>>>
>>>> 1) whitelist to shut off the warnings on demand
>>>
>>> Do you mean adding a whitelist to modpost? That would work, though I am
>>> not sure if the module maintainer (Jessica Yu) would accept that.
>>
>> Yes that's exactly what I meant.
>
>Ok, thanks. Jessica, the issue here is that we have two (mutually
>exclusive) modules providing the same interface to a third module.
>Andrea will check that, when the same symbol is exported by two modules,
>the second-loaded module correctly fails insmod.
Hi Paolo, thanks for getting me up to speed.
The module loader already rejects loading a module with
duplicate exported symbols.
> If that is okay, we will also need modpost not to warn for these
> symbols in sym_add_exported.
I think it's certainly doable in modpost, for example we could pass a
list of whitelisted symbols and have modpost read them in and not warn
if it encounters the whitelisted symbols more than once. Modpost will
also have to be modified to accomodate duplicate symbols. I'm not
sure how ugly this would be without seeing the actual patch. And I am
not sure what Masahiro (who takes care of all things kbuild-related)
thinks of this idea. But before implementing all this, is there
absolutely no way around having the duplicated exported symbols? (e.g.,
could the modules be configured/built in a mutally exclusive way? I'm
lacking the context from the rest of the thread, so not sure which are
the problematic modules.)
Thanks,
Jessica
Powered by blists - more mailing lists