netdev - Re: [PATCH] bpf: fix size of copy_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Aug 2016 09:30:34 -0700
From:	William Tu <u9012063@...il.com>
To:	Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:	Daniel Borkmann <daniel@...earbox.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH] bpf: fix size of copy_to_user in percpu map.

>> And in my /sys/devices/system/cpu, I have cpu0 and cpu1,
>> kernel_max = 63
>> possible = 0-63
>> present = 0-1
>
> glibc is doing
> ls -d /sys/devices/system/cpu/cpu*
> http://osxr.org:8080/glibc/source/sysdeps/unix/sysv/linux/getsysstats.c?v=glibc-2.14#0180
> And /sys/devices/system/cpu/possible shows 0-63 while only two dirs 'cpu0' and 'cpu1'
> are there?!

yes, that's right.
I only have cpu0 and cpu1 directories, while 'possible' shows 0-63.

> If my understanding of cpu_dev_register_generic() in drivers/base/cpu.c
> is correct the number of 'cpu*' dirs should be equal to possible_cpu.
> Could you please debug why is that the case, because then it's probably
> a bug on the kernel side.

Thanks, I will do it.

> I think it's correct for glibc to rely on the number of 'cpu*' dirs.
> Did you boot with possible_cpus=64 command line arg by any chance?
>
No.

>> So sysconf simply reads these entries configured by kernel. Looking at
>> kernel code, "arch/x86/configs/x86_64_defconfig" sets
>> CONFIG_NR_CPUS=64, and later on set_cpu_possible() is called at
>> arch/x86/kernel/smpboot.c, which parses the ACPI multiprocessor table
>> and configured new value. Based on these observations, I think
>> different hypervisor may have different ways of emulating ACPI
>> processor table or BIOS implementation thus these values differ.
>
> What behavior do you see in ESX ?
> btw, rhel7 ships with nr_cpus=5120 and ubuntu default is 256,
> so this lack of acpi in vmware fusion will lead to possible_cpu=5120,
> a lot of pain in per-cpu allocator and linux VMs will not be happy.
> I think vmware has to be fixed first regardless of what we find
> out about 'cpu*' vs /sys/devices/system/cpu/possible
>

Thanks, I will debug it and update when I have more info.
Regards,
William