netdev - Re: [PATCH v5 04/17] octeontx2-pf: Initialize and config queues

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20200126.120059.1968749784775179465.davem@davemloft.net>
Date:   Sun, 26 Jan 2020 12:00:59 +0100 (CET)
From:   David Miller <davem@...emloft.net>
To:     sunil.kovvuri@...il.com
Cc:     netdev@...r.kernel.org, kubakici@...pl, mkubecek@...e.cz,
        maciej.fijalkowski@...el.com, sgoutham@...vell.com,
        gakula@...vell.com
Subject: Re: [PATCH v5 04/17] octeontx2-pf: Initialize and config queues

From: sunil.kovvuri@...il.com
Date: Fri, 24 Jan 2020 23:15:42 +0530

> @@ -184,6 +192,72 @@ static inline void otx2_mbox_unlock(struct mbox *mbox)
>  	mutex_unlock(&mbox->lock);
>  }
>  
> +/* With the absence of API for 128-bit IO memory access for arm64,
> + * implement required operations at place.
> + */
> +#if defined(CONFIG_ARM64)
> +static inline void otx2_write128(u64 lo, u64 hi, void __iomem *addr)
> +{
> +	__asm__ volatile("stp %x[x0], %x[x1], [%x[p1],#0]!"
> +			 ::[x0]"r"(lo), [x1]"r"(hi), [p1]"r"(addr));
> +}
> +
> +static inline u64 otx2_atomic64_add(u64 incr, u64 *ptr)
> +{
> +	u64 result;
> +
> +	__asm__ volatile(".cpu   generic+lse\n"
> +			 "ldadd %x[i], %x[r], [%[b]]"
> +			 : [r]"=r"(result), "+m"(*ptr)
> +			 : [i]"r"(incr), [b]"r"(ptr)
> +			 : "memory");
> +	return result;
> +}
> +
> +#else
> +#define otx2_write128(lo, hi, addr)
> +#define otx2_atomic64_add(incr, ptr)		({ *ptr = incr; })
> +#endif

So what exactly is going on here?  Are these true 128-bit writes
and atomic operations?  Why is it named atomic64 then?  Why can't
the normal atomic64 kernel interfaces be used?

Finally why is the #else case doing an assignment to *ptr rather
than an increment like "*ptr += incr;"?