All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Sean Tranchetti <stranche@codeaurora.org>
Cc: pablo@netfilter.org, netfilter-devel@vger.kernel.org,
	fw@strlen.de, subashab@codeaurora.org
Subject: Re: [PATCH nf] x_tables: Properly close read section with read_seqcount_retry
Date: Sat, 14 Nov 2020 17:53:30 +0100	[thread overview]
Message-ID: <20201114165330.GM23619@breakpoint.cc> (raw)
In-Reply-To: <1605320516-17810-1-git-send-email-stranche@codeaurora.org>

Sean Tranchetti <stranche@codeaurora.org> wrote:
> xtables uses a modified version of a seqcount lock for synchronization
> between replacing private table information and the packet processing
> path (i.e. XX_do_table). The main modification is in the "write"
> semantics, where instead of adding 1 for each write, the write side will
> add 1 only if it finds no other writes ongoing, and adds 1 again (thereby
> clearing the LSB) when it finishes.
> 
> This allows the read side to avoid calling read_seqcount_begin() in a loop
> if a write is detected, since the value is guaranteed to only increment
> once all writes have completed. As such, it is only necessary to check if
> the initial value of the sequence count has changed to inform the reader
> that all writes are finished.
> 
> However, the current check for the changed value uses the wrong API;
> raw_seqcount_read() is protected by smp_rmb() in the same way as
> read_seqcount_begin(), making it appropriate for ENTERING read-side
> critical sections, but not exiting them. For that, read_seqcount_rety()
> must be used to ensure the proper barrier placement for synchronization
> with xt_write_recseq_end() (itself modeled after write_seqcount_end()).

[..]

> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index af22dbe..39f1f2b 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -1404,7 +1404,7 @@ xt_replace_table(struct xt_table *table,
>  			do {
>  				cond_resched();
>  				cpu_relax();
> -			} while (seq == raw_read_seqcount(s));
> +			} while (!read_seqcount_retry(s, seq));

I'm fine with this change but AFAIU this is just a cleanup since
this part isn't a read-sequence as no  'shared state' is accessed/read between
the seqcount begin and the do{}while. smb_rmb placement should not matter here.

Did I miss anything?

Thanks.


  reply	other threads:[~2020-11-14 16:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-14  2:21 [PATCH nf] x_tables: Properly close read section with read_seqcount_retry Sean Tranchetti
2020-11-14 16:53 ` Florian Westphal [this message]
2020-11-16  6:32   ` subashab
2020-11-16 14:18     ` Florian Westphal
2020-11-16 16:26       ` subashab
2020-11-16 17:04         ` Florian Westphal
2020-11-16 17:51           ` subashab
2020-11-16 18:20             ` Florian Westphal
2020-11-18 12:13               ` Will Deacon
2020-11-18 12:42                 ` Florian Westphal
2020-11-18 12:54                   ` Will Deacon
2020-11-18 13:14                     ` Florian Westphal
2020-11-18 20:39                       ` subashab
2020-11-18 21:10                         ` Florian Westphal
2020-11-20  5:53                           ` subashab
2020-11-20  6:31                             ` Florian Westphal
2020-11-20  9:44                             ` Peter Zijlstra
2020-11-20  9:53                               ` Peter Zijlstra
2020-11-20 10:20                                 ` Florian Westphal
2020-11-20 10:47                                   ` Peter Zijlstra
2020-11-21  1:27                                     ` subashab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201114165330.GM23619@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=stranche@codeaurora.org \
    --cc=subashab@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.