Hi Vincent,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
commit: 10f4c9b9a33b7df000f74fa0d896351fb1a61e6a x86/asm: Fix build of UML with KASAN
date: 6 months ago
config: um-randconfig-r111-20240305 (https://download.01.org/0day-ci/archive/20240305/[email protected]/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240305/[email protected]/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All errors (new ones prefixed by >>):
/usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_write':
>> pcap-dbus.o:(.text+0x244ff): undefined reference to `dbus_message_demarshal'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24515): undefined reference to `dbus_connection_send'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x2451e): undefined reference to `dbus_connection_flush'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24526): undefined reference to `dbus_message_unref'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24574): undefined reference to `dbus_error_free'
/usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_read':
>> pcap-dbus.o:(.text+0x245c0): undefined reference to `dbus_connection_pop_message'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x245e2): undefined reference to `dbus_connection_pop_message'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x245f8): undefined reference to `dbus_connection_read_write'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24662): undefined reference to `dbus_message_is_signal'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x2467e): undefined reference to `dbus_message_marshal'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x246e6): undefined reference to `dbus_free'
/usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_cleanup':
>> pcap-dbus.o:(.text+0x2474c): undefined reference to `dbus_connection_unref'
/usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_activate':
>> pcap-dbus.o:(.text+0x247f6): undefined reference to `dbus_connection_open'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x2480e): undefined reference to `dbus_bus_register'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x248fc): undefined reference to `dbus_bus_add_match'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24904): undefined reference to `dbus_error_is_set'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x2494b): undefined reference to `dbus_bus_get'
/usr/bin/ld: pcap-dbus.o:(.text+0x2497c): undefined reference to `dbus_error_free'
/usr/bin/ld: pcap-dbus.o:(.text+0x2498d): undefined reference to `dbus_bus_add_match'
/usr/bin/ld: pcap-dbus.o:(.text+0x24995): undefined reference to `dbus_error_is_set'
/usr/bin/ld: pcap-dbus.o:(.text+0x249ce): undefined reference to `dbus_error_free'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x249da): undefined reference to `dbus_connection_unref'
/usr/bin/ld: pcap-dbus.o:(.text+0x24a06): undefined reference to `dbus_bus_get'
/usr/bin/ld: pcap-dbus.o:(.text+0x24a42): undefined reference to `dbus_error_free'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24a55): undefined reference to `dbus_connection_set_max_received_size'
/usr/bin/ld: pcap-dbus.o:(.text+0x24a66): undefined reference to `dbus_connection_unref'
/usr/bin/ld: pcap-dbus.o:(.text+0x24adc): undefined reference to `dbus_error_free'
/usr/bin/ld: pcap-dbus.o:(.text+0x24b1a): undefined reference to `dbus_error_free'
collect2: error: ld returned 1 exit status
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Tue, Mar 05, 2024 at 23:11 +0800 kernel test robot <[email protected]> wrote:
> Hi Vincent,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
> commit: 10f4c9b9a33b7df000f74fa0d896351fb1a61e6a x86/asm: Fix build of UML with KASAN
> date: 6 months ago
> config: um-randconfig-r111-20240305 (https://download.01.org/0day-ci/archive/20240305/[email protected]/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240305/[email protected]/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <[email protected]>
> | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>
> All errors (new ones prefixed by >>):
>
> /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_write':
>>> pcap-dbus.o:(.text+0x244ff): undefined reference to `dbus_message_demarshal'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24515): undefined reference to `dbus_connection_send'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2451e): undefined reference to `dbus_connection_flush'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24526): undefined reference to `dbus_message_unref'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24574): undefined reference to `dbus_error_free'
> /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_read':
>>> pcap-dbus.o:(.text+0x245c0): undefined reference to `dbus_connection_pop_message'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x245e2): undefined reference to `dbus_connection_pop_message'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x245f8): undefined reference to `dbus_connection_read_write'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24662): undefined reference to `dbus_message_is_signal'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2467e): undefined reference to `dbus_message_marshal'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x246e6): undefined reference to `dbus_free'
> /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_cleanup':
>>> pcap-dbus.o:(.text+0x2474c): undefined reference to `dbus_connection_unref'
> /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_activate':
>>> pcap-dbus.o:(.text+0x247f6): undefined reference to `dbus_connection_open'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2480e): undefined reference to `dbus_bus_register'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x248fc): undefined reference to `dbus_bus_add_match'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24904): undefined reference to `dbus_error_is_set'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2494b): undefined reference to `dbus_bus_get'
> /usr/bin/ld: pcap-dbus.o:(.text+0x2497c): undefined reference to `dbus_error_free'
> /usr/bin/ld: pcap-dbus.o:(.text+0x2498d): undefined reference to `dbus_bus_add_match'
> /usr/bin/ld: pcap-dbus.o:(.text+0x24995): undefined reference to `dbus_error_is_set'
> /usr/bin/ld: pcap-dbus.o:(.text+0x249ce): undefined reference to `dbus_error_free'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x249da): undefined reference to `dbus_connection_unref'
> /usr/bin/ld: pcap-dbus.o:(.text+0x24a06): undefined reference to `dbus_bus_get'
> /usr/bin/ld: pcap-dbus.o:(.text+0x24a42): undefined reference to `dbus_error_free'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24a55): undefined reference to `dbus_connection_set_max_received_size'
> /usr/bin/ld: pcap-dbus.o:(.text+0x24a66): undefined reference to `dbus_connection_unref'
> /usr/bin/ld: pcap-dbus.o:(.text+0x24adc): undefined reference to `dbus_error_free'
> /usr/bin/ld: pcap-dbus.o:(.text+0x24b1a): undefined reference to `dbus_error_free'
> collect2: error: ld returned 1 exit status
Hi Ingo!
This error seems to be unrelated to the reported commit 10f4c9b9a33b
("x86/asm: Fix build of UML with KASAN"). The root cause seems to be the
option `CONFIG_UML_NET_PCAP` (which is deprecated, as stated in
`arch/um/drivers/Kconfig`), which tries to build `pcap.o`.
In the Makefile, one can find
LDFLAGS_pcap.o = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libpcap.a)
and at the top the very old comment
# pcap is broken in 2.5 because kbuild doesn't allow pcap.a to be linked
# in to pcap.o
`libpcap` is indeed the one referencing these symbols (that can be found
in `libdbus-1` and `libsystemd`). I'm guessing we should just ignore
this report, right? (Can it even be disabled somehow?)
Thank you
Waqar Hameed
P.S
Vincent has left the company and has therefore been removed from
the CC list.
D.S
On Thu, 2024-03-07 at 09:54 +0000, Anton Ivanov wrote:
>
> PCAP is not feasible to incorporate into the build system at present.
> It has grown all kinds of warts over the years and brings a lot of dependencies.
> IMHO we should remove it from the tree. It has reached a point where it cannot
> be built on a modern system.
I suppose it might be possible to call pcap-config? But agree that it
doesn't seem really worth investing in.
> The users who need the same functionality can produce a bpf filter using tcpdump
> and load it as "firmware" into the vector/raw driver.
>
> I am working on a pure python bpf compiler which takes the same syntax as PCAP.
> It is showing signs of life and it can do some of the simpler use cases. Once
> that is ready, it should be possible to use that instead of pcap/tcpdump.
How's that required to be formatted and loaded? tcpdump itself can also
dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
so probably not useful). Perhaps we could even automatically call
'tcpdump' at runtime?
johannes
On 06/03/2024 16:14, Waqar Hameed wrote:
> On Tue, Mar 05, 2024 at 23:11 +0800 kernel test robot <[email protected]> wrote:
>
>> Hi Vincent,
>>
>> FYI, the error/warning still remains.
>>
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> head: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
>> commit: 10f4c9b9a33b7df000f74fa0d896351fb1a61e6a x86/asm: Fix build of UML with KASAN
>> date: 6 months ago
>> config: um-randconfig-r111-20240305 (https://download.01.org/0day-ci/archive/20240305/[email protected]/config)
>> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240305/[email protected]/reproduce)
>>
>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> the same patch/commit), kindly add following tags
>> | Reported-by: kernel test robot <[email protected]>
>> | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>>
>> All errors (new ones prefixed by >>):
>>
>> /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_write':
>>>> pcap-dbus.o:(.text+0x244ff): undefined reference to `dbus_message_demarshal'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24515): undefined reference to `dbus_connection_send'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2451e): undefined reference to `dbus_connection_flush'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24526): undefined reference to `dbus_message_unref'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24574): undefined reference to `dbus_error_free'
>> /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_read':
>>>> pcap-dbus.o:(.text+0x245c0): undefined reference to `dbus_connection_pop_message'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x245e2): undefined reference to `dbus_connection_pop_message'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x245f8): undefined reference to `dbus_connection_read_write'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24662): undefined reference to `dbus_message_is_signal'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2467e): undefined reference to `dbus_message_marshal'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x246e6): undefined reference to `dbus_free'
>> /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_cleanup':
>>>> pcap-dbus.o:(.text+0x2474c): undefined reference to `dbus_connection_unref'
>> /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_activate':
>>>> pcap-dbus.o:(.text+0x247f6): undefined reference to `dbus_connection_open'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2480e): undefined reference to `dbus_bus_register'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x248fc): undefined reference to `dbus_bus_add_match'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24904): undefined reference to `dbus_error_is_set'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2494b): undefined reference to `dbus_bus_get'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x2497c): undefined reference to `dbus_error_free'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x2498d): undefined reference to `dbus_bus_add_match'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24995): undefined reference to `dbus_error_is_set'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x249ce): undefined reference to `dbus_error_free'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x249da): undefined reference to `dbus_connection_unref'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24a06): undefined reference to `dbus_bus_get'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24a42): undefined reference to `dbus_error_free'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24a55): undefined reference to `dbus_connection_set_max_received_size'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24a66): undefined reference to `dbus_connection_unref'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24adc): undefined reference to `dbus_error_free'
>> /usr/bin/ld: pcap-dbus.o:(.text+0x24b1a): undefined reference to `dbus_error_free'
>> collect2: error: ld returned 1 exit status
>
> Hi Ingo!
>
> This error seems to be unrelated to the reported commit 10f4c9b9a33b
> ("x86/asm: Fix build of UML with KASAN"). The root cause seems to be the
> option `CONFIG_UML_NET_PCAP` (which is deprecated, as stated in
> `arch/um/drivers/Kconfig`), which tries to build `pcap.o`.
>
> In the Makefile, one can find
>
> LDFLAGS_pcap.o = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libpcap.a)
>
> and at the top the very old comment
>
> # pcap is broken in 2.5 because kbuild doesn't allow pcap.a to be linked
> # in to pcap.o
>
> `libpcap` is indeed the one referencing these symbols (that can be found
> in `libdbus-1` and `libsystemd`). I'm guessing we should just ignore
> this report, right? (Can it even be disabled somehow?)
>
> Thank you
> Waqar Hameed
>
> P.S
> Vincent has left the company and has therefore been removed from
> the CC list.
> D.S
>
PCAP is not feasible to incorporate into the build system at present.
It has grown all kinds of warts over the years and brings a lot of dependencies.
IMHO we should remove it from the tree. It has reached a point where it cannot
be built on a modern system.
The users who need the same functionality can produce a bpf filter using tcpdump
and load it as "firmware" into the vector/raw driver.
I am working on a pure python bpf compiler which takes the same syntax as PCAP.
It is showing signs of life and it can do some of the simpler use cases. Once
that is ready, it should be possible to use that instead of pcap/tcpdump.
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
On 07/03/2024 10:03, Johannes Berg wrote:
> On Thu, 2024-03-07 at 09:54 +0000, Anton Ivanov wrote:
>>
>> PCAP is not feasible to incorporate into the build system at present.
>> It has grown all kinds of warts over the years and brings a lot of dependencies.
>> IMHO we should remove it from the tree. It has reached a point where it cannot
>> be built on a modern system.
>
> I suppose it might be possible to call pcap-config? But agree that it
> doesn't seem really worth investing in.
>
>> The users who need the same functionality can produce a bpf filter using tcpdump
>> and load it as "firmware" into the vector/raw driver.
>>
>> I am working on a pure python bpf compiler which takes the same syntax as PCAP.
>> It is showing signs of life and it can do some of the simpler use cases. Once
>> that is ready, it should be possible to use that instead of pcap/tcpdump.
>
> How's that required to be formatted and loaded? tcpdump itself can also
> dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
> so probably not useful). Perhaps we could even automatically call
> 'tcpdump' at runtime?
That is one option.
As far as common use cases are concerned, at present you can:
tcpdump -ddd, convert it to raw binary (3 liner in a language of choice) and pass that to vecX as a bpffile=
It may be worth it to make vecX also take the -ddd format directly by adding "format" options to bpffile.
I'd rather do that instead of invoking tcpdump out of a device open. The -ddd notation (+/- a comma here and there) is
standard - it is also used by iptables, etc. It can used by other code generators as well.
>
> johannes
>
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
On Thu, 2024-03-07 at 10:27 +0000, Anton Ivanov wrote:
> >
> > How's that required to be formatted and loaded? tcpdump itself can also
> > dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
> > so probably not useful). Perhaps we could even automatically call
> > 'tcpdump' at runtime?
>
> That is one option.
>
> As far as common use cases are concerned, at present you can:
>
> tcpdump -ddd, convert it to raw binary (3 liner in a language of choice) and pass that to vecX as a bpffile=
>
> It may be worth it to make vecX also take the -ddd format directly by adding "format" options to bpffile.
>
> I'd rather do that instead of invoking tcpdump out of a device open. The -ddd notation (+/- a comma here and there) is
> standard - it is also used by iptables, etc. It can used by other code generators as well.
Yeah, that makes sense, this is all kind of special configuration
anyway, and given that it's been broken forever ...
I actually doubt anyone would scream if we just removed it, so maybe
just remove it and if they do scream, point to the above, including said
3-liner in the response?
johannes
On 07/03/2024 10:29, Johannes Berg wrote:
> On Thu, 2024-03-07 at 10:27 +0000, Anton Ivanov wrote:
>>>
>>> How's that required to be formatted and loaded? tcpdump itself can also
>>> dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
>>> so probably not useful). Perhaps we could even automatically call
>>> 'tcpdump' at runtime?
>>
>> That is one option.
>>
>> As far as common use cases are concerned, at present you can:
>>
>> tcpdump -ddd, convert it to raw binary (3 liner in a language of choice) and pass that to vecX as a bpffile=
>>
>> It may be worth it to make vecX also take the -ddd format directly by adding "format" options to bpffile.
>>
>> I'd rather do that instead of invoking tcpdump out of a device open. The -ddd notation (+/- a comma here and there) is
>> standard - it is also used by iptables, etc. It can used by other code generators as well.
>
> Yeah, that makes sense, this is all kind of special configuration
> anyway, and given that it's been broken forever ...
>
> I actually doubt anyone would scream if we just removed it, so maybe
> just remove it and if they do scream, point to the above, including said
> 3-liner in the response?
Let's make it so.
>
> johannes
>
>
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
On Thu, Mar 07, 2024 at 10:49 +0000 Anton Ivanov <[email protected]> wrote:
> On 07/03/2024 10:29, Johannes Berg wrote:
[...]
>> Yeah, that makes sense, this is all kind of special configuration
>> anyway, and given that it's been broken forever ...
>> I actually doubt anyone would scream if we just removed it, so maybe
>> just remove it and if they do scream, point to the above, including said
>> 3-liner in the response?
>
> Let's make it so.
I'm guessing Johannes (or Anton) will create the patch for removing it
and no further action is needed from my side.
Thank you for your swift responses!