[PATCH v4 4/4] tests: add check for decoding of netfilter subsystem
Dmitry V. Levin
ldv at altlinux.org
Sun Mar 11 02:02:02 UTC 2018
On Sun, Mar 11, 2018 at 09:43:53AM +0800, Chen Jingpiao wrote:
> On 03/11 03:48, Dmitry V. Levin wrote:
[...]
> > In other words, NFNL_SUBSYS_COUNT provided by kernel headers is unreliable
> > and shouldn't be used, I think it has to be removed from
> > xlat/nl_netfilter_subsys_ids.in as well.
>
> I can not find an existing way to remove the condition from xlat/*.h.
> xlat/gen.sh only have print_xlat and cond_xlat to generate xlat array.
> Should I add a directive?
Well, you can simply write
#undef NFNL_SUBSYS_COUNT
#define NFNL_SUBSYS_COUNT 12
NFNL_SUBSYS_COUNT
but NFNL_SUBSYS_COUNT is not a symbol with some constant value: it changes
with time, so what's the use of printing it in symbolic form?
> ps:
> Is the same problem exist in other counter symbols in xlat/*.in?
> (I do the research, not found.)
I haven't investigated it. We might have more issues of this nature,
but if we do, then they are not covered by tests.
> > For netlink_netfilter.c purposes I'd recommend to use something like
> > (subsys_id > nl_netfilter_subsys_ids[ARRAY_SIZE(nl_netfilter_subsys_ids)
> - 1].val)
> > instead of subsys_id >= NFNL_SUBSYS_COUNT).
>
> If I have removed kernel header's NFNL_SUBSYS_COUNT value from
> xlat/nl_netfilter_subsys_ids.in.
> Why can't we use subsys_id >= NFNL_SUBSYS_COUNT?
I wonder whether it's a good idea to check against NFNL_SUBSYS_COUNT?
Wouldn't it be more future-proof to invoke decode_nlattr for any
subsys_id?
--
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20180311/773c1b41/attachment.bin>
More information about the Strace-devel
mailing list