> On May 2, 2018, at 10:30 AM, Peter Zijlstra wrote:
>
> On Wed, May 02, 2018 at 04:48:32PM +, Song Liu wrote:
>>> It's broken though, I've bet you've never actually ran this with lockdep
>>> enabled for example.
>>
>> I am not following here. I just run the new selftest with CONFIG_LOCKDE
On Wed, May 02, 2018 at 04:48:32PM +, Song Liu wrote:
> > It's broken though, I've bet you've never actually ran this with lockdep
> > enabled for example.
>
> I am not following here. I just run the new selftest with CONFIG_LOCKDEP on,
> and got no warning for this.
Weird, I would be expec
> On May 2, 2018, at 2:21 AM, Peter Zijlstra wrote:
>
> On Tue, May 01, 2018 at 05:02:19PM -0700, Song Liu wrote:
>> @@ -267,17 +285,27 @@ static void stack_map_get_build_id_offset(struct
>> bpf_stack_build_id *id_offs,
>> {
>> int i;
>> struct vm_area_struct *vma;
>> +bool in_nm
On Tue, May 01, 2018 at 05:02:19PM -0700, Song Liu wrote:
> @@ -267,17 +285,27 @@ static void stack_map_get_build_id_offset(struct
> bpf_stack_build_id *id_offs,
> {
> int i;
> struct vm_area_struct *vma;
> + bool in_nmi_ctx = in_nmi();
> + bool irq_work_busy = false;
> +
Hi Song,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url:
https://github.com/0day-ci/linux/commits/Song-Liu/bpf-enable-stackmap-with-build_id-in-nmi-context/20180502-081727
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Currently, we cannot parse build_id in nmi context because of
up_read(¤t->mm->mmap_sem), this makes stackmap with build_id
less useful. This patch enables parsing build_id in nmi by putting
the up_read() call in irq_work. To avoid memory allocation in nmi
context, we use per cpu variable for the ir
