diff mbox series

netfilter: conditionally use ct and ctinfo

Message ID 20220305180853.696640-1-trix@redhat.com (mailing list archive)
State Awaiting Upstream
Delegated to: Netdev Maintainers
Headers show
Series netfilter: conditionally use ct and ctinfo | expand

Checks

Context Check Description
netdev/tree_selection success Guessed tree name to be net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/subject_prefix warning Target tree name not specified in the subject
netdev/cover_letter success Single patches do not need cover letters
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/cc_maintainers success CCed 8 of 8 maintainers
netdev/build_clang success Errors and warnings before: 0 this patch: 0
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 11 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Tom Rix March 5, 2022, 6:08 p.m. UTC 
From: Tom Rix <trix@redhat.com>

The setting ct and ctinfo are controlled by
CONF_NF_CONNTRACK.  So their use should also
be controlled.

Signed-off-by: Tom Rix <trix@redhat.com>
---
 net/netfilter/nfnetlink_log.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Florian Westphal March 7, 2022, 12:46 p.m. UTC | #1 
trix@redhat.com <trix@redhat.com> wrote:
> From: Tom Rix <trix@redhat.com>
> 
> The setting ct and ctinfo are controlled by
> CONF_NF_CONNTRACK.  So their use should also
> be controlled.

Any reason for this change?

We try to avoid ifdef where possible, unless it avoids a compiler
warning/build/linker issue.

This doesn't change generated code for me (NF_CONNTRACK=n) either.
Tom Rix March 7, 2022, 1:39 p.m. UTC | #2 
On 3/7/22 4:46 AM, Florian Westphal wrote:
> trix@redhat.com <trix@redhat.com> wrote:
>> From: Tom Rix <trix@redhat.com>
>>
>> The setting ct and ctinfo are controlled by
>> CONF_NF_CONNTRACK.  So their use should also
>> be controlled.
> Any reason for this change?

Define and use are connected. Doing something to one without doing 
something to the other doesn't make sense.

Could removing the CONF_NF_CONNTRACK be done for the define side ?

Tom

> We try to avoid ifdef where possible, unless it avoids a compiler
> warning/build/linker issue.
>
> This doesn't change generated code for me (NF_CONNTRACK=n) either.
>
Florian Westphal March 7, 2022, 9:54 p.m. UTC | #3 
Tom Rix <trix@redhat.com> wrote:
> 
> On 3/7/22 4:46 AM, Florian Westphal wrote:
> > trix@redhat.com <trix@redhat.com> wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > The setting ct and ctinfo are controlled by
> > > CONF_NF_CONNTRACK.  So their use should also
> > > be controlled.
> > Any reason for this change?
> 
> Define and use are connected. Doing something to one without doing something
> to the other doesn't make sense.

We often rely on compiler to remove branches that always evaluate to
false, just like in this case.

> Could removing the CONF_NF_CONNTRACK be done for the define side ?

Doubt it.  Looking at git history it avoids build breakage.
diff mbox series

Patch

diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
index d97eb280cb2e8..141e0ebf4bc23 100644
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -629,9 +629,11 @@  __build_packet_message(struct nfnl_log_net *log,
 			 htonl(atomic_inc_return(&log->global_seq))))
 		goto nla_put_failure;
 
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
 	if (ct && nfnl_ct->build(inst->skb, ct, ctinfo,
 				 NFULA_CT, NFULA_CT_INFO) < 0)
 		goto nla_put_failure;
+#endif
 
 	if ((pf == NFPROTO_NETDEV || pf == NFPROTO_BRIDGE) &&
 	    nfulnl_put_bridge(inst, skb) < 0)