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, 14 Nov 2016 09:49:49 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     davem@...emloft.net, bblanco@...mgrid.com, tariqt@...lanox.com,
        zhiyisun@...il.com, ranas@...lanox.com, netdev@...r.kernel.org
Subject: Re: [PATCH net 2/3] bpf, mlx5: fix various refcount/prog issues in
 mlx5e_xdp_set

On 11/14/2016 03:49 AM, Alexei Starovoitov wrote:
> On Mon, Nov 14, 2016 at 01:43:41AM +0100, Daniel Borkmann wrote:
[...]
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index 751e806..a0fca9f 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -682,6 +682,17 @@ struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i)
>>   }
>>   EXPORT_SYMBOL_GPL(bpf_prog_add);
>>
>> +void bpf_prog_sub(struct bpf_prog *prog, int i)
>> +{
>> +	/* Only to be used for undoing previous bpf_prog_add() in some
>> +	 * error path. We still know that another entity in our call
>> +	 * path holds a reference to the program, thus atomic_sub() can
>> +	 * be safely used in such cases!
>> +	 */
>> +	WARN_ON(atomic_sub_return(i, &prog->aux->refcnt) == 0);
>> +}
>> +EXPORT_SYMBOL_GPL(bpf_prog_sub);
>
> the patches look good. I'm only worried about net/net-next merge
> conflict here. (I would have to deal with it as well).
> So instead of copying the above helper can we apply net-next's
> 'bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path'
> patch to net without mlx4_xdp_set hunk and then apply
> the rest of this patch?
> Even better is to send this patch 2/3 to net-next?
> yes, it's an issue, but very small one. There is no security
> concern here, so I would prefer to avoid merge conflict.
> Did you do a test merge of net/net-next by any chance?

Yes, I did a test merge and git resolved the above just fine w/o
any conflicts. I have no strong opinion whether net or net-next.
If preferred, I can just resend this series in the evening against
net-next instead, perhaps that's a bit better.

Thanks,
Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ