From: Sean Tranchetti <stranche@codeaurora.org>
To: pablo@netfilter.org, netfilter-devel@vger.kernel.org, fw@strlen.de
Cc: subashab@codeaurora.org, Sean Tranchetti <stranche@codeaurora.org>
Subject: [PATCH nf] x_tables: Properly close read section with read_seqcount_retry
Date: Fri, 13 Nov 2020 18:21:56 -0800 [thread overview]
Message-ID: <1605320516-17810-1-git-send-email-stranche@codeaurora.org> (raw)
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()).
Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
---
net/netfilter/x_tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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));
}
}
--
2.7.4
next reply other threads:[~2020-11-14 2:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-14 2:21 Sean Tranchetti [this message]
2020-11-14 16:53 ` [PATCH nf] x_tables: Properly close read section with read_seqcount_retry Florian Westphal
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=1605320516-17810-1-git-send-email-stranche@codeaurora.org \
--to=stranche@codeaurora.org \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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.