Re: linux-next: build failure after merge of the bpf tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Stephen, hi John,

On 04/16/2018 04:30 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the bpf tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> kernel/bpf/core.o: In function `sock_map_release':
> core.c:(.text+0xd04): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> kernel/events/core.o: In function `sock_map_release':
> core.c:(.text+0x85cc): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> block/blk-core.o: In function `sock_map_release':
> blk-core.c:(.text+0x58e8): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> drivers/net/virtio_net.o: In function `sock_map_release':
> virtio_net.c:(.text+0x53ec): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> net/core/dev.o: In function `sock_map_release':
> dev.c:(.text+0x6c68): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> net/core/rtnetlink.o: In function `sock_map_release':
> rtnetlink.c:(.text+0x63e0): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> net/core/filter.o: In function `sock_map_release':
> filter.c:(.text+0x8c8c): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> net/core/sock_reuseport.o: In function `sock_map_release':
> sock_reuseport.c:(.text+0x398): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> net/bpf/test_run.o: In function `sock_map_release':
> test_run.c:(.text+0x3dc): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> net/packet/af_packet.o: In function `sock_map_release':
> af_packet.c:(.text+0x6958): multiple definition of `sock_map_release'
> kernel/sysctl.o:sysctl.c:(.text+0x1a50): first defined here
> 
> Caused by commit
> 
>   9b2e8bbc4e7a ("bpf: sockmap, map_release does not hold refcnt for pinned maps")
> 
> I applied the following patch for today:
> 
> From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
> Date: Mon, 16 Apr 2018 12:27:24 +1000
> Subject: [PATCH] fix for "bpf: sockmap, map_release does not hold refcnt for
>  pinned maps"
> 
> Signed-off-by: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
> ---
>  include/linux/bpf.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index f46561de5154..3b6c2b66f414 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -660,7 +660,7 @@ static inline int sock_map_prog(struct bpf_map *map,
>  	return -EOPNOTSUPP;
>  }
>  
> -void sock_map_release(struct bpf_map *map) {}
> +static inline void sock_map_release(struct bpf_map *map) {}
>  #endif
>  
>  /* verifier prototypes for helper functions called from eBPF programs */

Sigh, yeah, that's buggy. Thanks for catching it!

John, given bpf tree hasn't been pushed out, I'm considering to drop the
series from the bpf tree so we can have a clean respin of it with this fixed
initially and not as follow-up churn.

While you're at it, can you just make this a bpf callback, so we have the
'clear' handlers private in prog array and sockmap respectively? This would
also have avoided the bug in the first place.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux