On 1/29/24 16:46, Michael S. Tsirkin wrote:
On Fri, Jan 26, 2024 at 03:55:02PM -0800, Guenter Roeck wrote:
On 1/26/24 14:35, Nathan Chancellor wrote:
(slimming up the CC list, I don't think this is too relevant to the
wider stable community)
On Fri, Jan 26, 2024 at 01:01:15PM -0800, Guenter Ro
On Fri, Apr 09, 2021 at 08:36:07 +0200, Greg KH
> On Thu, Apr 08, 2021 at 07:11:48PM +, Jianmin Wang wrote:
> > while the new services need to invoke libkcapi in the container environment.
> >
> > We have verified that the problem doesn't exist on newer kernel version.
> > However, due to man
On Thu, Apr 08, 2021 at 07:11:48PM +, Jianmin Wang wrote:
> On Mon, Apr 05, 2021 at 16:14 UTC, Greg KH wrote:
> > On Mon, Apr 05, 2021 at 01:55:15PM +, Jianmin Wang wrote:
> > > There is same problem found in linux 4.19.y as upstream commit. The
> > > changes of crypto_user_* and cryptouse
On Mon, Apr 05, 2021 at 16:14 UTC, Greg KH wrote:
> On Mon, Apr 05, 2021 at 01:55:15PM +, Jianmin Wang wrote:
> > There is same problem found in linux 4.19.y as upstream commit. The
> > changes of crypto_user_* and cryptouser.h files from upstream patch are
> > merged into
> > crypto/crypto_
> On Wed, May 20, 2020 at 12:45:56PM -0400, st...@rowland.harvard.edu wrote:
> > On Wed, May 20, 2020 at 03:42:17PM +, Sverdlin, Alexander (Nokia -
> > DE/Ulm) wrote:
> > > Hello Dinghao,
> > >
> > > On Wed, 2020-05-20 at 21:29 +0800, Dinghao Liu wrote:
> > > > pm_runtime_get_sync() increment
Hi Alexander,
There are large amounts of cases that assume pm_runtime_get_sync()
will modify runtime PM usage counter on error. Fixing this in PM
subsystem will influence all callers of pm_runtime_get_sync() and
introduce new bugs. Therefore I think the better solution is to fix
misused cases ind
Hi Sergey,
>You shrink a 2 bytes offset down to a 1 byte offset, thus you enforce that
2 Byte offset is not shrinked to 1 byte, Its only 1 bit is reserved out of
16 bits of offset. So only 15 Bits can be used to store offset value.
>'page should be less than 32KB', which I'm sure will be confusin
On Tue, Aug 22, 2017 at 12:14 PM, Tudor Ambarus
wrote:
> Hi, Herbert,
>
> On 02/02/2017 03:57 PM, Herbert Xu wrote:
>>
>> Yes but RSA had an in-kernel user in the form of module signature
>> verification. We don't add algorithms to the kernel without
>> actual users. So this patch-set needs to c
Hi, Herbert,
On 02/02/2017 03:57 PM, Herbert Xu wrote:
Yes but RSA had an in-kernel user in the form of module signature
verification. We don't add algorithms to the kernel without
actual users. So this patch-set needs to come with an actual
in-kernel user of ECDSA.
ECDSA can be used by the
Please confirm receipt of my previous mail..When can i call you
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Karl Hiramoto wrote:
>
> The attached patch fixes my issue, but am not sure if it is correct or
> will cause problems else where.
This is what we'll do once generic chaining is available on all
architectures. Until then it's up to the driver to fix the SG
list up before passing it to DMA.
Che
Hallo.
Die Mailingliste [EMAIL PROTECTED] ist umgezogen,
da sie durch Spams verseucht wurde.
Siehe https://mlists.in-berlin.de/mailman/listinfo/linux-avmb1
The mailing list [EMAIL PROTECTED] was been moved,
we got too many spams.
Visit https://mlists.in-berlin.de/mailman/listinfo/linux-avmb1
Jivin The Hog lays it down ...
>
> I have read some docs about dm-crypt and the crypto-api. It seems that the
> crypto stuff is added to the kernel since 2.6.4. A possibility thus would be
> to use an older kernel that does not contain the crypto stuff. Will a 2.4
> kernel do, or does that also c
I have read some docs about dm-crypt and the crypto-api. It seems that the
crypto stuff is added to the kernel since 2.6.4. A possibility thus would be
to use an older kernel that does not contain the crypto stuff. Will a 2.4
kernel do, or does that also contain crypto algo's?
As I recall, the De
- Oorspronkelijk bericht -
From: Andy Gay <[EMAIL PROTECTED]>
> On Tue, 2006-05-23 at 19:18 +0200, The Hog wrote:
> > Hi,
> >
> > I have ben told that the Linux kernel contains cryptographic code in many
> > places. U.S. export restrictions forbid to export software that contains
> > cryp
On Tue, May 23, 2006 at 08:37:07PM +0200, The Hog ([EMAIL PROTECTED]) wrote:
> > > Would it be possible to build a kernel that does not contain cryptographic
> > > algorithms? I understand that several cryptographic options can be
> disabled
> > > through "make menuconfig". But, will that be enough
> > Would it be possible to build a kernel that does not contain cryptographic
> > algorithms? I understand that several cryptographic options can be
disabled
> > through "make menuconfig". But, will that be enough or are there crypto
> > routines in the kernel that cannot be removed?
>
> Disable
17 matches
Mail list logo
