Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

On Thu, 22 Jun 2017 14:24:58 -0600 Logan Gunthorpe <log...@deltatee.com> wrote: > On 6/22/2017 2:14 PM, Alan Cox wrote: > > If a platform doesn't support 64bit I/O operations from the CPU then you > > either need to use some kind of platform/architecture specific int

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

On Thu, 22 Jun 2017 10:48:13 -0600 Logan Gunthorpe wrote: > Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y > and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not > universally available, it makes them unusable for driver developers. > This

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

On Thu, 22 Jun 2017 10:48:14 -0600 Logan Gunthorpe wrote: > Alpha implements its own io operation and doesn't use the > common library. Thus to make ioread64 and iowrite64 globally > available we need to add implementations for alpha. > > For this, we simply use calls that

Re: Wrong system clock vs X.509 date specifiers

On Tue, 25 Sep 2012 16:09:54 +0100 David Howells dhowe...@redhat.com wrote: The X.509 certificate has a pair of times in it that delineate the valid period of the cert, and I'm checking that the system clock is within the bounds they define before permitting you to use the cert. I've been

Re: Wrong system clock vs X.509 date specifiers

On Tue, 25 Sep 2012 16:35:20 +0100 David Howells dhowe...@redhat.com wrote: Alan Cox a...@lxorguk.ukuu.org.uk wrote: Generate a certificate that is valid from a few minutes before the wallclock time. It's a certificate policy question not a kernel hackery one. That doesn't seem

Re: [PATCH 14/16] X.509: Add an ASN.1 decoder

On Tue, 18 Sep 2012 18:34:12 +0100 David Howells dhowe...@redhat.com wrote: Alan Cox a...@lxorguk.ukuu.org.uk wrote: Why do this in the kernel.That appears to be completely insane. A number of reasons: (1) The UEFI signature/key database may contain ASN.1 X.509 certificates

Re: [PATCH 14/16] X.509: Add an ASN.1 decoder

On Fri, 14 Sep 2012 00:50:05 +0100 David Howells dhowe...@redhat.com wrote: Add an ASN.1 BER/DER/CER decoder. This uses the bytecode from the ASN.1 compiler in the previous patch to inform it as to what to expect to find in the encoded byte stream. The output from the compiler also tells

Re: [PATCH] Use kzfree in crypto API context initialization and key/iv handling

On Mon, 1 Jun 2009 14:48:37 +1000 Herbert Xu herb...@gondor.apana.org.au wrote: On Sun, May 31, 2009 at 09:46:23PM -0700, David Miller wrote: I don't even want to think about what this does to IPSEC rule creation rates, that that matters heavily for cell phone networks where hundreds of

Re: [patch 5/5] Apply the PG_sensitive flag to the CryptoAPI subsystem

Also, there's no discussion about long-lived threads keeping sensitive information in there kernel stack indefinitely. kernel stack clearing isn't hard to do, just do it on every syscall exit and in the infinite loop for kernel threads. Actually that is probably not as important. In most

Re: Runaway loop with the current git.

apparently not triggering, since it could be that Debian's initrd might cause some other uncaught recursion loop if we don't drive this problem determination to root cause. Agreed - and there are all sorts of obscure and wonderful other ways to trip this up which need the detector (AF_UNIX

Re: Runaway loop with the current git.

Even when this works around it, the problem that the kernel triggers module loading on /dev/console access stays and needs to be fixed instead. It isn't a problem. It is trying to have hotplug load a suitable driver. This is what is supposed to happen. Alan -- To unsubscribe from this list:

Re: Runaway loop with the current git.

It isn't a problem. It is trying to have hotplug load a suitable driver. This is what is supposed to happen. No, it's not. 5:1 is _in_ the kernel, and must not be tried to be loaded by the kernel. We need to make /dev/console access return -ENODEV if not available, not try to load a

Re: Runaway loop with the current git.

Wrong. First at least because tty/console stuff is built in. Are you two people or just two names and email addresses for the same ? /dev/console is a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI. But we alredy got, that you

Re: Runaway loop with the current git.

Heh, init is not allowed to write something to the console or any other tty? init is not run as the helper of a modprobe. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: Runaway loop with the current git.

/dev/console is a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI. So wrong. If no driver is associated, like early, in that case, we must return -ENODEV, instead of calling modprobe in a loop. It's a built-in device, and it's

Re: Runaway loop with the current git.

Alan, let's make some progress on this fingerpointing. If Herbert's patch fixes the crypto loading problem, it will find its way upstream for the current tree, and in the merge window Kay's patch may be applied and widely tested. Thoughts? I have no intention of applying Kay's patch because

Re: Runaway loop with the current git.

On Sun, 7 Dec 2008 20:54:38 +0300 Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Sun, Dec 07, 2008 at 05:52:45PM +, Alan Cox ([EMAIL PROTECTED]) wrote: Alan, let's make some progress on this fingerpointing. If Herbert's patch fixes the crypto loading problem, it will find its way

Re: Runaway loop with the current git.

The loop is detected and terminated. No. Please back up what you are trying to talk about. Let me introduce you to.. drum roll.. the source code. Its a useful resource, why don't you use it for once. max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);