Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+03\/26\]\s+bpfilter\:\s+reject\s+kernel\s+addresses\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+03\/26\]\s+bpfilter\:\s+reject\s+kernel\s+addresses\s*$/: 4 ]

Total 4 documents matching your query.

1. RE: [PATCH 03/26] bpfilter: reject kernel addresses (score: 1): Author: David Laight <David.Laight@xxxxxxxxxx>; Date: Thu, 23 Jul 2020 14:56:33 +0000; Is this a different bit of bpf that that which used to directly intercept setsockopt() requests and pass them down from a kernel buffer? I can't held feeling that bpf is getting 'too big for its boot; /html/lvs-devel/2020-07/msg00124.html (15,867 bytes)
2. Re: [PATCH 03/26] bpfilter: reject kernel addresses (score: 1): Author: 'Christoph Hellwig' <hch@xxxxxx>; Date: Thu, 23 Jul 2020 16:44:55 +0200; I'm not saying that I approve of the design, but the current bpfilter design uses process_vm_readv to access the buffer, which obviously does not work with kernel buffers.; /html/lvs-devel/2020-07/msg00123.html (15,430 bytes)
3. RE: [PATCH 03/26] bpfilter: reject kernel addresses (score: 1): Author: David Laight <David.Laight@xxxxxxxxxx>; Date: Thu, 23 Jul 2020 14:42:11 +0000; What sort of operations is the bpf filter doing on the sockopt buffers? Any attempts to reject some requests can be thwarted by a second application thread modifying the buffer after the bpf filter h; /html/lvs-devel/2020-07/msg00122.html (15,304 bytes)
4. [PATCH 03/26] bpfilter: reject kernel addresses (score: 1): Author: Christoph Hellwig <hch@xxxxxx>; Date: Thu, 23 Jul 2020 08:08:45 +0200; The bpfilter user mode helper processes the optval address using process_vm_readv. Don't send it kernel addresses fed under set_fs(KERNEL_DS) as that won't work. Signed-off-by: Christoph Hellwig <hch; /html/lvs-devel/2020-07/msg00116.html (12,412 bytes)

Current List: 1 - 4
Page: [1]