From herbert at gondor.apana.org.au  Sun Oct  1 00:30:50 2023
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Sun, 1 Oct 2023 15:30:50 +0800
Subject: arc-elf32-ld: net/xfrm/xfrm_algo.o:(.rodata+0x24): undefined
 reference to `crypto_has_aead'
In-Reply-To: <ZRbPBdu0ZJ86juff@hog>
References: <CA+G9fYu2DKDxOEFTeJhH-r_JD8gR1gS8e4YsSrW3rfGegHR4Sg@mail.gmail.com>
 <ZRbPBdu0ZJ86juff@hog>
Message-ID: <ZRkgKnpgW0tfZgTc@gondor.apana.org.au>

On Fri, Sep 29, 2023 at 03:20:05PM +0200, Sabrina Dubroca wrote:
>
> I guess the problem is that CONFIG_XFRM_ALGO doesn't select
> CONFIG_CRYPTO_AEAD (or _AEAD2?), just CRYPTO_HASH and CRYPTO_SKCIPHER.
> 
> Herbert, does that seem reasonable?

Sorry Sabrina, this patch is already in my queue but I forgot to
push it out.  I'll get onto it now.

Thanks,
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From kamil.lasek at citycodes.pl  Wed Oct  4 00:45:38 2023
From: kamil.lasek at citycodes.pl (Kamil Lasek)
Date: Wed,  4 Oct 2023 07:45:38 GMT
Subject: =?UTF-8?Q?Rozszerzenie_Programu_M=C3=B3j_Pr=C4=85d_5.0?=
Message-ID: <20231004084500-0.1.7v.j15j.0.7n6h96n6gh@citycodes.pl>

Szanowni Pa?stwo!

W ramach nowej edycji programu M?j Pr?d mog? otrzyma? Pa?stwo dofinansowanie na zakup i monta? fotowoltaiki i/lub magazynu energii. Maksymalna kwota dofinansowania wynosi 58 tys. z?. 

Jako firma wyspecjalizowana w tym zakresie zajmiemy si? Pa?stwa wnioskiem o dofinansowanie oraz instalacj? i serwisem dopasowanych do Pa?stwa budynku paneli s?onecznych.

B?d? wdzi?czny za informacj? czy s? Pa?stwo zainteresowani.


Pozdrawiam,
Kamil Lasek


From kamil.lasek at citycodes.pl  Tue Oct 24 01:10:35 2023
From: kamil.lasek at citycodes.pl (Kamil Lasek)
Date: Tue, 24 Oct 2023 08:10:35 GMT
Subject: Wycena paneli fotowoltaicznych
Message-ID: <20231024084500-0.1.8a.l89x.0.u4mithdbnh@citycodes.pl>

Dzie? dobry,

dostrzegam mo?liwo?? wsp??pracy z Pa?stwa firm?.

?wiadczymy kompleksow? obs?ug? inwestycji w fotowoltaik?, kt?ra obni?a koszty energii elektrycznej.

Czy s? Pa?stwo zainteresowani weryfikacj? wst?pnych propozycji?


Pozdrawiam,
Kamil Lasek


From wuqiang.matt at bytedance.com  Sat Oct 28 09:40:17 2023
From: wuqiang.matt at bytedance.com (wuqiang.matt)
Date: Sun, 29 Oct 2023 00:40:17 +0800
Subject: [PATCH 3/3] locking/atomic: openrisc: use
 generic_cmpxchg[64]_local for arch_cmpxchg[64]_local
In-Reply-To: <20231028214918.e32265f1dd2ef26fd9d2d1c2@kernel.org>
References: <20231026073932.702197-1-wuqiang.matt@bytedance.com>
 <1e3aba7d-89ac-4b62-840e-992527115a70@app.fastmail.com>
 <66f5645c-f9f5-4c53-9503-a1f8470a9bee@bytedance.com>
 <20231028214918.e32265f1dd2ef26fd9d2d1c2@kernel.org>
Message-ID: <99f9c3d4-0c9e-4542-9511-796f719c36e3@bytedance.com>

On 2023/10/28 20:49, Masami Hiramatsu (Google) wrote:
> Hi Wuqiang,
> 
> On Thu, 26 Oct 2023 19:05:51 +0800
> "wuqiang.matt" <wuqiang.matt at bytedance.com> wrote:
> 
>> On 2023/10/26 16:46, Arnd Bergmann wrote:
>>> On Thu, Oct 26, 2023, at 09:39, wuqiang.matt wrote:
>>>> arch_cmpxchg[64]_local() are not defined for openrisc. So implement
>>>> them with generci_cmpxchg[64]_local, advised by Masami Hiramatsu.
>>>>
>>>> Closes:
>>>> https://lore.kernel.org/linux-trace-kernel/169824660459.24340.14614817132696360531.stgit at devnote2
>>>> Closes:
>>>> https://lore.kernel.org/oe-kbuild-all/202310241310.Ir5uukOG-lkp at intel.com
>>>>
>>>> Signed-off-by: wuqiang.matt <wuqiang.matt at bytedance.com>
>>>
>>> I think on architectures that have actual atomics, you
>>> generally want to define this to be the same as arch_cmpxchg()
>>> rather than the generic version.
>>>
>>> It depends on the relative cost of doing one atomic compared
>>> to an irq-disable/enable pair, but everyone else went with
>>> the former if they could. The exceptions are armv4/armv5,
>>> sparc32 and parisc, which don't have a generic cmpxchg()
>>> or similar operation.
>>
>> Sure, better native than the generic. I'll try to collect more
>> insights before next move.
> 
> So I will temporally remove the last change (use arch_cmpxchg_local
> in objpool) until these series are rewritten with arch native code,
> so that the next release will not break the kernel build.

Ok, it's fine to me. Thank you.


> But this must be fixed because arch_cmpxchg_local() is required
> for each arch anyway.

Yes. I'm working on the new update for arc/openrisc/hexagon. It would
be better resolve this issue first, then consider the objpool update
of using arch_cmpxchg_local.

>>
>>> You could do the thing that sparc64 and xtensa do, which
>>> use the native cmpxchg for supported word sizes but the
>>> generic version for 1- and 2-byte swaps, but that has its
>>> own set of problems if you end up doing operations on both
>>> the entire word and a sub-unit of the same thing.
>>
>> Thank you for pointing out this. I'll do some research on these
>> implementations.
> 
> arc also has the LL-SC instruction but depends on the core feature,
> so I think we can use it.

Right. The arc processor does have the CONFIG_ARC_HAS_LLSC option, but
I doubt the correctness of arch_cmpxchg_relaxed and arch_cmpxchg:

arch_cmpxchg_relaxed:
...
         switch(sizeof((_p_))) {
         case 4:
....

arch_cmpxchg:
...
	BUILD_BUG_ON(sizeof(_p_) != 4);		
...

_p is the address pointer, so I'm thinking it's a typo but I couldn't
yet confirm. There is not much about arc processors in the web :(


> Thank you,
> 
>>
>>>       Arnd
>>
>> Regards,
>> wuqiang
>>
> 
> 



From mhiramat at kernel.org  Sat Oct 28 20:26:41 2023
From: mhiramat at kernel.org (Masami Hiramatsu (Google))
Date: Sun, 29 Oct 2023 12:26:41 +0900
Subject: [PATCH 3/3] locking/atomic: openrisc: use
 generic_cmpxchg[64]_local for arch_cmpxchg[64]_local
In-Reply-To: <99f9c3d4-0c9e-4542-9511-796f719c36e3@bytedance.com>
References: <20231026073932.702197-1-wuqiang.matt@bytedance.com>
	<1e3aba7d-89ac-4b62-840e-992527115a70@app.fastmail.com>
	<66f5645c-f9f5-4c53-9503-a1f8470a9bee@bytedance.com>
	<20231028214918.e32265f1dd2ef26fd9d2d1c2@kernel.org>
	<99f9c3d4-0c9e-4542-9511-796f719c36e3@bytedance.com>
Message-ID: <20231029122641.a8c90d5e6bdfa6e7175bbe97@kernel.org>

On Sun, 29 Oct 2023 00:40:17 +0800
"wuqiang.matt" <wuqiang.matt at bytedance.com> wrote:

> On 2023/10/28 20:49, Masami Hiramatsu (Google) wrote:
> > Hi Wuqiang,
> > 
> > On Thu, 26 Oct 2023 19:05:51 +0800
> > "wuqiang.matt" <wuqiang.matt at bytedance.com> wrote:
> > 
> >> On 2023/10/26 16:46, Arnd Bergmann wrote:
> >>> On Thu, Oct 26, 2023, at 09:39, wuqiang.matt wrote:
> >>>> arch_cmpxchg[64]_local() are not defined for openrisc. So implement
> >>>> them with generci_cmpxchg[64]_local, advised by Masami Hiramatsu.
> >>>>
> >>>> Closes:
> >>>> https://lore.kernel.org/linux-trace-kernel/169824660459.24340.14614817132696360531.stgit at devnote2
> >>>> Closes:
> >>>> https://lore.kernel.org/oe-kbuild-all/202310241310.Ir5uukOG-lkp at intel.com
> >>>>
> >>>> Signed-off-by: wuqiang.matt <wuqiang.matt at bytedance.com>
> >>>
> >>> I think on architectures that have actual atomics, you
> >>> generally want to define this to be the same as arch_cmpxchg()
> >>> rather than the generic version.
> >>>
> >>> It depends on the relative cost of doing one atomic compared
> >>> to an irq-disable/enable pair, but everyone else went with
> >>> the former if they could. The exceptions are armv4/armv5,
> >>> sparc32 and parisc, which don't have a generic cmpxchg()
> >>> or similar operation.
> >>
> >> Sure, better native than the generic. I'll try to collect more
> >> insights before next move.
> > 
> > So I will temporally remove the last change (use arch_cmpxchg_local
> > in objpool) until these series are rewritten with arch native code,
> > so that the next release will not break the kernel build.
> 
> Ok, it's fine to me. Thank you.
> 
> 
> > But this must be fixed because arch_cmpxchg_local() is required
> > for each arch anyway.
> 
> Yes. I'm working on the new update for arc/openrisc/hexagon. It would
> be better resolve this issue first, then consider the objpool update
> of using arch_cmpxchg_local.
> 
> >>
> >>> You could do the thing that sparc64 and xtensa do, which
> >>> use the native cmpxchg for supported word sizes but the
> >>> generic version for 1- and 2-byte swaps, but that has its
> >>> own set of problems if you end up doing operations on both
> >>> the entire word and a sub-unit of the same thing.
> >>
> >> Thank you for pointing out this. I'll do some research on these
> >> implementations.
> > 
> > arc also has the LL-SC instruction but depends on the core feature,
> > so I think we can use it.
> 
> Right. The arc processor does have the CONFIG_ARC_HAS_LLSC option, but
> I doubt the correctness of arch_cmpxchg_relaxed and arch_cmpxchg:
> 
> arch_cmpxchg_relaxed:
> ...
>          switch(sizeof((_p_))) {
>          case 4:
> ....
> 
> arch_cmpxchg:
> ...
> 	BUILD_BUG_ON(sizeof(_p_) != 4);		
> ...
> 
> _p is the address pointer, so I'm thinking it's a typo but I couldn't
> yet confirm. There is not much about arc processors in the web :(

Hmm, indeed. This seems like a bug but it depends on the 'llock  %0, [%1]'
can take a 32bit address or 32bit data register. Usually it should
check the size of data, but need to check with ISA manual.

Vineet, can you check this suspicious bug?

Thank you,

> 
> 
> > Thank you,
> > 
> >>
> >>>       Arnd
> >>
> >> Regards,
> >> wuqiang
> >>
> > 
> > 
> 


-- 
Masami Hiramatsu (Google) <mhiramat at kernel.org>


From vgupta at kernel.org  Sun Oct 29 19:22:59 2023
From: vgupta at kernel.org (Vineet Gupta)
Date: Sun, 29 Oct 2023 19:22:59 -0700
Subject: [PATCH 3/3] locking/atomic: openrisc: use
 generic_cmpxchg[64]_local for arch_cmpxchg[64]_local
In-Reply-To: <20231029122641.a8c90d5e6bdfa6e7175bbe97@kernel.org>
References: <20231026073932.702197-1-wuqiang.matt@bytedance.com>
 <1e3aba7d-89ac-4b62-840e-992527115a70@app.fastmail.com>
 <66f5645c-f9f5-4c53-9503-a1f8470a9bee@bytedance.com>
 <20231028214918.e32265f1dd2ef26fd9d2d1c2@kernel.org>
 <99f9c3d4-0c9e-4542-9511-796f719c36e3@bytedance.com>
 <20231029122641.a8c90d5e6bdfa6e7175bbe97@kernel.org>
Message-ID: <391884b5-12b3-4377-bd44-9ae69a4a13df@kernel.org>



On 10/28/23 20:26, Masami Hiramatsu (Google) wrote:
> On Sun, 29 Oct 2023 00:40:17 +0800
> "wuqiang.matt" <wuqiang.matt at bytedance.com> wrote:
>
>> On 2023/10/28 20:49, Masami Hiramatsu (Google) wrote:
>>> Hi Wuqiang,
>>>
>>> On Thu, 26 Oct 2023 19:05:51 +0800
>>> "wuqiang.matt" <wuqiang.matt at bytedance.com> wrote:
>>>
>>>> On 2023/10/26 16:46, Arnd Bergmann wrote:
>>>>> On Thu, Oct 26, 2023, at 09:39, wuqiang.matt wrote:
>>>>>> arch_cmpxchg[64]_local() are not defined for openrisc. So implement
>>>>>> them with generci_cmpxchg[64]_local, advised by Masami Hiramatsu.
>>>>>>
>>>>>> Closes:
>>>>>> https://lore.kernel.org/linux-trace-kernel/169824660459.24340.14614817132696360531.stgit at devnote2
>>>>>> Closes:
>>>>>> https://lore.kernel.org/oe-kbuild-all/202310241310.Ir5uukOG-lkp at intel.com
>>>>>>
>>>>>> Signed-off-by: wuqiang.matt <wuqiang.matt at bytedance.com>
>>>>> I think on architectures that have actual atomics, you
>>>>> generally want to define this to be the same as arch_cmpxchg()
>>>>> rather than the generic version.
>>>>>
>>>>> It depends on the relative cost of doing one atomic compared
>>>>> to an irq-disable/enable pair, but everyone else went with
>>>>> the former if they could. The exceptions are armv4/armv5,
>>>>> sparc32 and parisc, which don't have a generic cmpxchg()
>>>>> or similar operation.
>>>> Sure, better native than the generic. I'll try to collect more
>>>> insights before next move.
>>> So I will temporally remove the last change (use arch_cmpxchg_local
>>> in objpool) until these series are rewritten with arch native code,
>>> so that the next release will not break the kernel build.
>> Ok, it's fine to me. Thank you.
>>
>>
>>> But this must be fixed because arch_cmpxchg_local() is required
>>> for each arch anyway.
>> Yes. I'm working on the new update for arc/openrisc/hexagon. It would
>> be better resolve this issue first, then consider the objpool update
>> of using arch_cmpxchg_local.
>>
>>>>> You could do the thing that sparc64 and xtensa do, which
>>>>> use the native cmpxchg for supported word sizes but the
>>>>> generic version for 1- and 2-byte swaps, but that has its
>>>>> own set of problems if you end up doing operations on both
>>>>> the entire word and a sub-unit of the same thing.
>>>> Thank you for pointing out this. I'll do some research on these
>>>> implementations.
>>> arc also has the LL-SC instruction but depends on the core feature,
>>> so I think we can use it.
>> Right. The arc processor does have the CONFIG_ARC_HAS_LLSC option, but
>> I doubt the correctness of arch_cmpxchg_relaxed and arch_cmpxchg:
>>
>> arch_cmpxchg_relaxed:
>> ...
>>           switch(sizeof((_p_))) {
>>           case 4:
>> ....
>>
>> arch_cmpxchg:
>> ...
>> 	BUILD_BUG_ON(sizeof(_p_) != 4);		
>> ...
>>
>> _p is the address pointer, so I'm thinking it's a typo but I couldn't
>> yet confirm. There is not much about arc processors in the web :(
> Hmm, indeed. This seems like a bug but it depends on the 'llock  %0, [%1]'
> can take a 32bit address or 32bit data register. Usually it should
> check the size of data, but need to check with ISA manual.
>
> Vineet, can you check this suspicious bug?

ARCv2 is a 32-bit ISA and LLOCK/SCOND work on 32-bit data.
So the pointers will be 32-bit anyways. Is the issue that 
pointer/cmpxchg operation could be on a smaller data type ?

-Vineet


From wuqiang.matt at bytedance.com  Sun Oct 29 20:41:41 2023
From: wuqiang.matt at bytedance.com (wuqiang.matt)
Date: Mon, 30 Oct 2023 11:41:41 +0800
Subject: [PATCH 3/3] locking/atomic: openrisc: use
 generic_cmpxchg[64]_local for arch_cmpxchg[64]_local
In-Reply-To: <391884b5-12b3-4377-bd44-9ae69a4a13df@kernel.org>
References: <20231026073932.702197-1-wuqiang.matt@bytedance.com>
 <1e3aba7d-89ac-4b62-840e-992527115a70@app.fastmail.com>
 <66f5645c-f9f5-4c53-9503-a1f8470a9bee@bytedance.com>
 <20231028214918.e32265f1dd2ef26fd9d2d1c2@kernel.org>
 <99f9c3d4-0c9e-4542-9511-796f719c36e3@bytedance.com>
 <20231029122641.a8c90d5e6bdfa6e7175bbe97@kernel.org>
 <391884b5-12b3-4377-bd44-9ae69a4a13df@kernel.org>
Message-ID: <7836be7b-ed41-4e0f-8983-9603bd6fcde0@bytedance.com>

On 2023/10/30 10:22, Vineet Gupta wrote:
> 
> 
> On 10/28/23 20:26, Masami Hiramatsu (Google) wrote:
>> On Sun, 29 Oct 2023 00:40:17 +0800
>> "wuqiang.matt" <wuqiang.matt at bytedance.com> wrote:
>>
>>> On 2023/10/28 20:49, Masami Hiramatsu (Google) wrote:
>>>> Hi Wuqiang,
>>>>
>>>> On Thu, 26 Oct 2023 19:05:51 +0800
>>>> "wuqiang.matt" <wuqiang.matt at bytedance.com> wrote:
>>>>
>>>>> On 2023/10/26 16:46, Arnd Bergmann wrote:
>>>>>> On Thu, Oct 26, 2023, at 09:39, wuqiang.matt wrote:
>>>>>>> arch_cmpxchg[64]_local() are not defined for openrisc. So implement
>>>>>>> them with generci_cmpxchg[64]_local, advised by Masami Hiramatsu.
>>>>>>>
>>>>>>> Closes:
>>>>>>> https://lore.kernel.org/linux-trace-kernel/169824660459.24340.14614817132696360531.stgit at devnote2
>>>>>>> Closes:
>>>>>>> https://lore.kernel.org/oe-kbuild-all/202310241310.Ir5uukOG-lkp at intel.com
>>>>>>>
>>>>>>> Signed-off-by: wuqiang.matt <wuqiang.matt at bytedance.com>
>>>>>> I think on architectures that have actual atomics, you
>>>>>> generally want to define this to be the same as arch_cmpxchg()
>>>>>> rather than the generic version.
>>>>>>
>>>>>> It depends on the relative cost of doing one atomic compared
>>>>>> to an irq-disable/enable pair, but everyone else went with
>>>>>> the former if they could. The exceptions are armv4/armv5,
>>>>>> sparc32 and parisc, which don't have a generic cmpxchg()
>>>>>> or similar operation.
>>>>> Sure, better native than the generic. I'll try to collect more
>>>>> insights before next move.
>>>> So I will temporally remove the last change (use arch_cmpxchg_local
>>>> in objpool) until these series are rewritten with arch native code,
>>>> so that the next release will not break the kernel build.
>>> Ok, it's fine to me. Thank you.
>>>
>>>
>>>> But this must be fixed because arch_cmpxchg_local() is required
>>>> for each arch anyway.
>>> Yes. I'm working on the new update for arc/openrisc/hexagon. It would
>>> be better resolve this issue first, then consider the objpool update
>>> of using arch_cmpxchg_local.
>>>
>>>>>> You could do the thing that sparc64 and xtensa do, which
>>>>>> use the native cmpxchg for supported word sizes but the
>>>>>> generic version for 1- and 2-byte swaps, but that has its
>>>>>> own set of problems if you end up doing operations on both
>>>>>> the entire word and a sub-unit of the same thing.
>>>>> Thank you for pointing out this. I'll do some research on these
>>>>> implementations.
>>>> arc also has the LL-SC instruction but depends on the core feature,
>>>> so I think we can use it.
>>> Right. The arc processor does have the CONFIG_ARC_HAS_LLSC option, but
>>> I doubt the correctness of arch_cmpxchg_relaxed and arch_cmpxchg:
>>>
>>> arch_cmpxchg_relaxed:
>>> ...
>>> ????????? switch(sizeof((_p_))) {
>>> ????????? case 4:
>>> ....
>>>
>>> arch_cmpxchg:
>>> ...
>>> ????BUILD_BUG_ON(sizeof(_p_) != 4);
>>> ...
>>>
>>> _p is the address pointer, so I'm thinking it's a typo but I couldn't
>>> yet confirm. There is not much about arc processors in the web :(
>> Hmm, indeed. This seems like a bug but it depends on the 'llock? %0, [%1]'
>> can take a 32bit address or 32bit data register. Usually it should
>> check the size of data, but need to check with ISA manual.
>>
>> Vineet, can you check this suspicious bug?
> 
> ARCv2 is a 32-bit ISA and LLOCK/SCOND work on 32-bit data.
> So the pointers will be 32-bit anyways. Is the issue that pointer/cmpxchg 
> operation could be on a smaller data type ?

For ARCv2 with CONFIG_ARC_HAS_LLSC, better add the data size checking and
only permit 32bit data size. Even for 32-bit system, data should can be
64bit 'long long'.

And In the case that CONFIG_ARC_HAS_LLSC is undefined, in arch_cmpxchg: the
pointer size checking is unnecessary, since it's using spinlock internally:

https://elixir.bootlin.com/linux/v6.6-rc7/source/arch/arc/include/asm/cmpxchg.h#L60: 

	BUILD_BUG_ON(sizeof(_p_) != 4);					\
									\
	/*								\
	 * spin lock/unlock provide the needed smp_mb() before/after	\
	 */								\
	atomic_ops_lock(__flags);					\
	_prev_ = *_p_;							\
	if (_prev_ == _o_)						\
		*_p_ = _n_;						\
	atomic_ops_unlock(__flags);

Another question about the naming: arch_cmpxchg_relaxed() implemented if
CONFIG_ARC_HAS_LLSC is configured and arch_cmpxchg() defined for the rest.
Are there any reasons for difference names ?

As I checked, Synopsys has released 64bit ARC processors (HS66/HS68), but
I don't know the status of Linux kernel support.

> -Vineet

Regards,
wuqiang