| Message ID | 1687955688-20809-3-git-send-email-quic_mojha@quicinc.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | [v4,01/21] docs: qcom: Add qualcomm minidump guide | expand |
On Wed, Jun 28, 2023 at 3:35 PM Mukesh Ojha <quic_mojha@quicinc.com> wrote: > > Module like minidump providing debugging support will need to > get the symbol information from the core kernel e.g to get > the linux_banner, kernel section addresses bss, data, ro etc. > > commit 0bd476e6c671 ("kallsyms: unexport kallsyms_lookup_name() Commit > and kallsyms_on_each_symbol()") unexports kallsyms_lookup_name > due to lack of in-tree user of the symbol. Now, that minidump > will one of its user, export it. users ... Is it a direct revert? Then make it visible by leaving pieces from `git revert`. ... > - If not, drop this stray change. > +EXPORT_SYMBOL_GPL(kallsyms_lookup_name);
On Wed, Jun 28, 2023 at 06:04:29PM +0530, Mukesh Ojha wrote: > Module like minidump providing debugging support will need to > get the symbol information from the core kernel e.g to get > the linux_banner, kernel section addresses bss, data, ro etc. > One might ask why we would need such a debug driver to be compiled as module? What would you do if we need to capture more kernel data structures later? Do you plan to continue use kallsyms_lookup_name() to query all the symbols? I have seen v3 discussion where you are asked to compile this driver as module but that time there was no reason why your driver needs to be compiled as statically, now you have a reason (linux_banner) for it. > commit 0bd476e6c671 ("kallsyms: unexport kallsyms_lookup_name() > and kallsyms_on_each_symbol()") unexports kallsyms_lookup_name > due to lack of in-tree user of the symbol. Now, that minidump > will one of its user, export it. > > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Thanks, Pavan
On 6/28/2023 6:54 PM, Andy Shevchenko wrote: > On Wed, Jun 28, 2023 at 3:35 PM Mukesh Ojha <quic_mojha@quicinc.com> wrote: >> >> Module like minidump providing debugging support will need to >> get the symbol information from the core kernel e.g to get >> the linux_banner, kernel section addresses bss, data, ro etc. >> >> commit 0bd476e6c671 ("kallsyms: unexport kallsyms_lookup_name() > > Commit > >> and kallsyms_on_each_symbol()") unexports kallsyms_lookup_name >> due to lack of in-tree user of the symbol. Now, that minidump >> will one of its user, export it. > > users > > ... > > Is it a direct revert? Then make it visible by leaving pieces from `git revert`. > No, it is not direct revert.. > ... > >> - > > If not, drop this stray change. ok - Mukesh > >> +EXPORT_SYMBOL_GPL(kallsyms_lookup_name); > >
On 6/28/2023 7:23 PM, Pavan Kondeti wrote: > On Wed, Jun 28, 2023 at 06:04:29PM +0530, Mukesh Ojha wrote: >> Module like minidump providing debugging support will need to >> get the symbol information from the core kernel e.g to get >> the linux_banner, kernel section addresses bss, data, ro etc. >> > One might ask why we would need such a debug driver to > be compiled as module? What would you do if we need to capture more > kernel data structures later? Do you plan to continue use > kallsyms_lookup_name() to query all the symbols? You are on point, i needed this driver to be static but i don't have any example at present to collect more than just _linux_banner_ from my existing set of patches.. Agree, it will be easier to make this driver as static instead of opening up the doors for modules to abuse via exporting kallsyms_lookup_name() and also it will be very slow for production kernel uses. > > I have seen v3 discussion where you are asked to compile this driver > as module but that time there was no reason why your driver needs to > be compiled as statically, now you have a reason (linux_banner) for > it. Yes, at present minidump driver will not be able to compile without exporting kallsyms_lookup_name() -Mukesh > >> commit 0bd476e6c671 ("kallsyms: unexport kallsyms_lookup_name() >> and kallsyms_on_each_symbol()") unexports kallsyms_lookup_name >> due to lack of in-tree user of the symbol. Now, that minidump >> will one of its user, export it. >> >> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > > Thanks, > Pavan
On Wed, Jun 28, 2023 at 08:52:57PM +0530, Mukesh Ojha wrote: > > > On 6/28/2023 7:23 PM, Pavan Kondeti wrote: > > On Wed, Jun 28, 2023 at 06:04:29PM +0530, Mukesh Ojha wrote: > > > Module like minidump providing debugging support will need to > > > get the symbol information from the core kernel e.g to get > > > the linux_banner, kernel section addresses bss, data, ro etc. > > > > > One might ask why we would need such a debug driver to > > be compiled as module? What would you do if we need to capture more > > kernel data structures later? Do you plan to continue use > > kallsyms_lookup_name() to query all the symbols? > > You are on point, i needed this driver to be static but i don't have > any example at present to collect more than just _linux_banner_ from > my existing set of patches.. > > Agree, it will be easier to make this driver as static instead of > opening up the doors for modules to abuse via exporting > kallsyms_lookup_name() and also it will be very slow for production > kernel uses. Right, I unexported that symbol deliberately in 0bd476e6c671 ("kallsyms: unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()") and I don't think we should add it back for this driver. Will
On Wed, Jun 28, 2023 at 04:32:47PM +0100, Will Deacon wrote: > On Wed, Jun 28, 2023 at 08:52:57PM +0530, Mukesh Ojha wrote: > > > > > > On 6/28/2023 7:23 PM, Pavan Kondeti wrote: > > > On Wed, Jun 28, 2023 at 06:04:29PM +0530, Mukesh Ojha wrote: > > > > Module like minidump providing debugging support will need to > > > > get the symbol information from the core kernel e.g to get > > > > the linux_banner, kernel section addresses bss, data, ro etc. > > > > > > > One might ask why we would need such a debug driver to > > > be compiled as module? What would you do if we need to capture more > > > kernel data structures later? Do you plan to continue use > > > kallsyms_lookup_name() to query all the symbols? > > > > You are on point, i needed this driver to be static but i don't have > > any example at present to collect more than just _linux_banner_ from > > my existing set of patches.. > > > > Agree, it will be easier to make this driver as static instead of > > opening up the doors for modules to abuse via exporting > > kallsyms_lookup_name() and also it will be very slow for production > > kernel uses. > > Right, I unexported that symbol deliberately in 0bd476e6c671 ("kallsyms: > unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()") and I > don't think we should add it back for this driver. I agree, it shouldn't be needed by any in-kernel module/driver. If you really want the name, look it up afterward in userspace :) thanks, greg k-h
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c index 77747391f49b..34a074f58736 100644 --- a/kernel/kallsyms.c +++ b/kernel/kallsyms.c @@ -283,7 +283,7 @@ unsigned long kallsyms_lookup_name(const char *name) return module_kallsyms_lookup_name(name); } - +EXPORT_SYMBOL_GPL(kallsyms_lookup_name); /* * Iterate over all symbols in vmlinux. For symbols from modules use * module_kallsyms_on_each_symbol instead.
Module like minidump providing debugging support will need to get the symbol information from the core kernel e.g to get the linux_banner, kernel section addresses bss, data, ro etc. commit 0bd476e6c671 ("kallsyms: unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()") unexports kallsyms_lookup_name due to lack of in-tree user of the symbol. Now, that minidump will one of its user, export it. Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> --- kernel/kallsyms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)