netdev - Re: [PATCH wpan-next 2/2] 6lowpan: nhc: drop EEXIST limitation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3b7a9363-1fea-d4a3-360d-a2e60b1038c7@datenfreihafen.org>
Date:   Thu, 16 Jun 2022 09:57:07 +0200
From:   Stefan Schmidt <stefan@...enfreihafen.org>
To:     Alexander Aring <aahringo@...hat.com>
Cc:     linux-wpan@...r.kernel.org, linux-bluetooth@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH wpan-next 2/2] 6lowpan: nhc: drop EEXIST limitation


Hello Alex.

On 13.06.22 05:29, Alexander Aring wrote:
> In nhc we have compression() and uncompression(). Currently we have a
> limitation that we return -EEXIST when it's the nhc is already
> registered according the nexthdr. But on receiving handling and the
> nhcid we can indeed support both at the same time. 

The sentence above is not really clear to me. Do you want to say that on 
rx we can support more than one nhcid? I am a bit confused why you write 
both here. Where does the limit to two come from?

We remove the current
> static array implementation and replace it by a dynamic list handling to
> get rid of this limitation.
> 
> Signed-off-by: Alexander Aring <aahringo@...hat.com>
> ---
>   net/6lowpan/nhc.c | 69 ++++++++++++++++++++++++++++++-----------------
>   1 file changed, 44 insertions(+), 25 deletions(-)
> 
> diff --git a/net/6lowpan/nhc.c b/net/6lowpan/nhc.c
> index 7b374595328d..3d7c50139142 100644
> --- a/net/6lowpan/nhc.c
> +++ b/net/6lowpan/nhc.c
> @@ -12,13 +12,30 @@
>   
>   #include "nhc.h"
>   
> -static const struct lowpan_nhc *lowpan_nexthdr_nhcs[NEXTHDR_MAX + 1];
> +struct lowpan_nhc_entry {
> +	const struct lowpan_nhc *nhc;
> +	struct list_head list;
> +};
> +
>   static DEFINE_SPINLOCK(lowpan_nhc_lock);
> +static LIST_HEAD(lowpan_nexthdr_nhcs);
> +
> +const struct lowpan_nhc *lowpan_nhc_by_nexthdr(u8 nexthdr)
> +{
> +	const struct lowpan_nhc_entry *e;
> +
> +	list_for_each_entry(e, &lowpan_nexthdr_nhcs, list) {
> +		if (e->nhc->nexthdr == nexthdr &&
> +		    e->nhc->compress)
> +			return e->nhc;

We will always go with the first one we find? Do I miss something or 
does that mean the one registered as seond and above will never be taken 
into acount?

regards
Stefan Schmidt