Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

On Fri, Jun 30, 2017 at 02:13:39PM +0100, Will Deacon wrote: > On Fri, Jun 30, 2017 at 05:38:15AM -0700, Paul E. McKenney wrote: > > On Fri, Jun 30, 2017 at 10:19:29AM +0100, Will Deacon wrote: > > > On Thu, Jun 29, 2017 at 05:01:16PM -0700, Paul E. McKenney wrote: > > > > There is no agreed-upon

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Florian, Am 30.06.2017 um 21:55 schrieb Florian Westphal: >>> Why not use a hash of the address? >> >> Would also work. Or xor it with a random number. >> >> On the other hand, for user space it would be more useful when the conntrack >> id >> does not repeat that often. That's why I favor the

Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

On Fri, Jun 30, 2017 at 01:02:48PM -0700, Paul E. McKenney wrote: > On Fri, Jun 30, 2017 at 09:21:23PM +0200, Oleg Nesterov wrote: > > On 06/30, Paul E. McKenney wrote: > > > > > > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote: > > > > > > > > I do not think the overhead will be

Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

On Fri, Jun 30, 2017 at 03:50:33PM -0400, Alan Stern wrote: > On Fri, 30 Jun 2017, Oleg Nesterov wrote: > > > On 06/30, Paul E. McKenney wrote: > > > > > > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote: > > > > > > > > I do not think the overhead will be noticeable in this

Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

On Fri, Jun 30, 2017 at 09:21:23PM +0200, Oleg Nesterov wrote: > On 06/30, Paul E. McKenney wrote: > > > > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote: > > > > > > I do not think the overhead will be noticeable in this particular case. > > > > > > But I am not sure I understand

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Richard Weinberger wrote: > Florian, > > Am 30.06.2017 um 21:35 schrieb Florian Westphal: > > Richard Weinberger wrote: > >> Hi! > >> > >> I noticed that nf_conntrack leaks kernel addresses, it uses the memory > >> address > >> as identifier used for generating

Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

On Fri, 30 Jun 2017, Oleg Nesterov wrote: > On 06/30, Paul E. McKenney wrote: > > > > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote: > > > > > > I do not think the overhead will be noticeable in this particular case. > > > > > > But I am not sure I understand why do we want to

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Florian, Am 30.06.2017 um 21:35 schrieb Florian Westphal: > Richard Weinberger wrote: >> Hi! >> >> I noticed that nf_conntrack leaks kernel addresses, it uses the memory >> address >> as identifier used for generating conntrack and expect ids.. >> Since these ids are also

nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Hi! I noticed that nf_conntrack leaks kernel addresses, it uses the memory address as identifier used for generating conntrack and expect ids.. Since these ids are also visible to unprivileged users via network namespaces I suggest reverting these commits: commit

Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

On 06/30, Paul E. McKenney wrote: > > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote: > > > > I do not think the overhead will be noticeable in this particular case. > > > > But I am not sure I understand why do we want to unlock_wait. Yes I agree,

[RFC PATCH nf-next 3/3] netfilter: exthdr: early set support

This allows setting 2 and 4 byte quantities in the tcp option space. This allows native replacement for xt_TCPMSS in nf_tables. Todo: -TCPOPTSTRIP equivalent -possibly restrict write support so we can't generate invalid options (e.g., don't allow write to kind,len). Signed-off-by: Florian

Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

On Fri, Jun 30, 2017 at 09:16:07AM -0700, Paul E. McKenney wrote: > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote: > > On 06/30, Paul E. McKenney wrote: > > > > > > > > + raw_spin_lock_irq(>pi_lock); > > > > > + raw_spin_unlock_irq(>pi_lock); > > > > > > I

Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote: > On 06/30, Paul E. McKenney wrote: > > > > > > + raw_spin_lock_irq(>pi_lock); > > > > + raw_spin_unlock_irq(>pi_lock); > > > > I agree that the spin_unlock_wait() implementations would avoid the > >

Re: [PATCH v2] netfilter: nfnetlink: Improve input length sanitization in nfnetlink_rcv

On Thu, Jun 29, 2017 at 6:22 PM, Pablo Neira Ayuso wrote: > On Tue, Jun 27, 2017 at 07:05:27PM +0200, Pablo Neira Ayuso wrote: >> On Tue, Jun 27, 2017 at 05:58:25PM +0200, Pablo Neira Ayuso wrote: >> > On Wed, Jun 07, 2017 at 03:50:38PM +0200, Mateusz Jurczyk wrote: >> > >

Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

On Fri, Jun 30, 2017 at 05:38:15AM -0700, Paul E. McKenney wrote: > On Fri, Jun 30, 2017 at 10:19:29AM +0100, Will Deacon wrote: > > On Thu, Jun 29, 2017 at 05:01:16PM -0700, Paul E. McKenney wrote: > > > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > > > and it appears

Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

On Fri, Jun 30, 2017 at 01:04:45PM +0200, Oleg Nesterov wrote: > On 06/29, Paul E. McKenney wrote: > > > > --- a/kernel/task_work.c > > +++ b/kernel/task_work.c > > @@ -109,7 +109,8 @@ void task_work_run(void) > > * the first entry == work, cmpxchg(task_works) should > >

Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

On Fri, Jun 30, 2017 at 10:19:29AM +0100, Will Deacon wrote: > On Thu, Jun 29, 2017 at 05:01:16PM -0700, Paul E. McKenney wrote: > > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > > and it appears that all callers could do just as well with a lock/unlock > > pair. This

Re: [PATCH RFC 03/26] sched: Replace spin_unlock_wait() with lock/unlock pair

On Fri, Jun 30, 2017 at 12:31:50PM +0200, Arnd Bergmann wrote: > On Fri, Jun 30, 2017 at 2:01 AM, Paul E. McKenney > wrote: > > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > > and it appears that all callers could do just as well with a

[ANNOUNCE] Netfilter (+folks) userday in Faro, Portugal (Monday, July 3th)

Hi! We're releasing today the planning for our Netfilter (and folks) userday in Faro, Portugal. This is the pre-event that traditionally come before the Netfilter developer Workshop. This is the planning: 9h: Welcoming (Pablo Neira) 9h15: Suricata and its interaction with Netfilter (Eric

RE: [PATCH 25/29] netfilter, kbuild: use canonical method to specify objs.

From: Pablo Neira Ayuso > Sent: 29 June 2017 23:53 > Should use ":=" instead of "+=". ... > diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile > index c9b78e7b342f..913380919301 100644 > --- a/net/netfilter/Makefile > +++ b/net/netfilter/Makefile > @@ -70,10 +70,9 @@

Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

On 06/29, Paul E. McKenney wrote: > > --- a/kernel/task_work.c > +++ b/kernel/task_work.c > @@ -109,7 +109,8 @@ void task_work_run(void) >* the first entry == work, cmpxchg(task_works) should >* fail, but it can play with *work and other entries. >*/

Re: [PATCH nft 2/3] include: Remove __init macro definition.

On Fri, Jun 30, 2017 at 02:57:12PM +0530, Varsha Rao wrote: > Add nft_init function, which calls _init functions in main.c file. > Remove __init macro definition as libnftables library will be created > soon. Rename realm_table_init() function to avoid ambiguity as > realm_table_rt_init() and

Re: [PATCH nft 1/3] include: Remove datatype_register().

On Fri, Jun 30, 2017 at 02:56:19PM +0530, Varsha Rao wrote: > Remove datatype_register() function and its calling __init functions. > Add arguments of datatype_register() function to datatype array. Applied, thanks Varsha. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH RFC 03/26] sched: Replace spin_unlock_wait() with lock/unlock pair

On Fri, Jun 30, 2017 at 2:01 AM, Paul E. McKenney wrote: > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > and it appears that all callers could do just as well with a lock/unlock > pair. This commit therefore replaces the spin_unlock_wait()

[PATCH nft 3/3] include: Remove __exit macro definition.

Add nft_exit function, which calls _exit functions in main.c file. Remove __exit macro definition as libnftables library will be created soon. Rename realm_table_exit() function to avoid ambiguity as realm_table_rt_exit() and realm_table_meta_exit() in rt.c and meta.c files. Signed-off-by: Varsha

[PATCH nft 2/3] include: Remove __init macro definition.

Add nft_init function, which calls _init functions in main.c file. Remove __init macro definition as libnftables library will be created soon. Rename realm_table_init() function to avoid ambiguity as realm_table_rt_init() and realm_table_meta_init() in rt.c and meta.c files. Signed-off-by: Varsha

[PATCH nft 1/3] include: Remove datatype_register().

Remove datatype_register() function and its calling __init functions. Add arguments of datatype_register() function to datatype array. Signed-off-by: Varsha Rao --- include/ct.h | 3 +++ include/datatype.h | 1 - include/exthdr.h | 1 + include/fib.h | 2

[PATCH nft 0/3] include: Remove datatype_register(), __init and __exit macros.

This patchset removes datatype_register() function, __init and __exit macro definitions. Varsha Rao (3): include: Remove datatype_register(). include: Remove __init macro definition. include: Remove __exit macro definition. include/ct.h | 3 +++ include/datatype.h | 1 -

Re: [PATCH RFC 12/26] arm64: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 05:01:20PM -0700, Paul E. McKenney wrote: > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > and it appears that all callers could do just as well with a lock/unlock > pair. This commit therefore removes the underlying arch-specific >

Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

On Thu, Jun 29, 2017 at 05:01:16PM -0700, Paul E. McKenney wrote: > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > and it appears that all callers could do just as well with a lock/unlock > pair. This commit therefore removes spin_unlock_wait() and related > definitions