Re: INFO: task hung in nbd_ioctl

On Thu, Oct 17, 2019 at 10:47:59AM -0500, Mike Christie wrote: > On 10/17/2019 09:03 AM, Richard W.M. Jones wrote: > > On Tue, Oct 01, 2019 at 04:19:25PM -0500, Mike Christie wrote: > >> Hey Josef and nbd list, > >> > >> I had a question about if there are an

Re: nbd, nbdkit, loopback mounts and memory management

On Mon, Feb 18, 2019 at 12:15:14AM +0100, Pavel Machek wrote: > But Shaun reported it happened somehow often for them, so he might > have a practical test case... better than my theories :-). Yes, certainly not saying this isn't a problem. I think the good news is the fix seems quite easy, ie.

Re: nbd, nbdkit, loopback mounts and memory management

So not to dispute that this could be a bug, but I couldn't cause a deadlock. I wonder if you can see something wrong with my method? *** Set up *** - kernel 5.0.0-0.rc3.git0.1.fc30.x86_64 - nbd-client 3.19-1.fc30 - nbdkit 1.11.5 (git commit ef9d1978ce28) Baremetal machine was booted with

Re: nbd, nbdkit, loopback mounts and memory management

On Fri, Feb 15, 2019 at 10:41:26PM +, Richard W.M. Jones wrote: > On Fri, Feb 15, 2019 at 08:19:54PM +0100, Pavel Machek wrote: > > Hi! > > > > I watched fosdem talk about > > nbdkit... https://www.youtube.com/watch?v=9E5A608xJG0 . Nice. But word > > of wa

Re: nbd, nbdkit, loopback mounts and memory management

On Fri, Feb 15, 2019 at 08:19:54PM +0100, Pavel Machek wrote: > Hi! > > I watched fosdem talk about > nbdkit... https://www.youtube.com/watch?v=9E5A608xJG0 . Nice. But word > of warning: I'm not sure using it read-write on localhost is safe. > > In particular, user application could create a lot

Re: [PATCH v2] libata: Drop SanDisk SD7UB3Q*G1001 NOLPM quirk

I agree with Hans's analysis above, so ACK from me. Rich. > BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207 > Cc: sta...@vger.kernel.org > Cc: Richard W.M. Jones > Cc: Lorenzo Dalrio > Reported-by: Lorenzo Dalrio > Signed-off-by: Hans de Goede > --- > Change

Re: [PATCH v2] libata: Drop SanDisk SD7UB3Q*G1001 NOLPM quirk

I agree with Hans's analysis above, so ACK from me. Rich. > BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207 > Cc: sta...@vger.kernel.org > Cc: Richard W.M. Jones > Cc: Lorenzo Dalrio > Reported-by: Lorenzo Dalrio > Signed-off-by: Hans de Goede > --- > Change

Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

On Fri, Aug 11, 2017 at 12:41:47AM +0300, Michael S. Tsirkin wrote: > On Thu, Aug 10, 2017 at 10:35:11PM +0100, Richard W.M. Jones wrote: > > On Fri, Aug 11, 2017 at 12:31:44AM +0300, Michael S. Tsirkin wrote: > > > Then we probably should fail probe if vq size is too small.

Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

On Fri, Aug 11, 2017 at 12:41:47AM +0300, Michael S. Tsirkin wrote: > On Thu, Aug 10, 2017 at 10:35:11PM +0100, Richard W.M. Jones wrote: > > On Fri, Aug 11, 2017 at 12:31:44AM +0300, Michael S. Tsirkin wrote: > > > Then we probably should fail probe if vq size is too small.

Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

On Fri, Aug 11, 2017 at 12:31:44AM +0300, Michael S. Tsirkin wrote: > Then we probably should fail probe if vq size is too small. What does this mean? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog:

Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

On Fri, Aug 11, 2017 at 12:31:44AM +0300, Michael S. Tsirkin wrote: > Then we probably should fail probe if vq size is too small. What does this mean? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog:

Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

On Fri, Aug 11, 2017 at 12:21:16AM +0300, Michael S. Tsirkin wrote: > On Thu, Aug 10, 2017 at 05:40:34PM +0100, Richard W.M. Jones wrote: > > If using indirect descriptors, you can make the total_sg as large as > > you want. > > That would be a spec violation though, even if

Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

On Fri, Aug 11, 2017 at 12:21:16AM +0300, Michael S. Tsirkin wrote: > On Thu, Aug 10, 2017 at 05:40:34PM +0100, Richard W.M. Jones wrote: > > If using indirect descriptors, you can make the total_sg as large as > > you want. > > That would be a spec violation though, even if

[PATCH v2 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

If using indirect descriptors, you can make the total_sg as large as you want. If not, BUG is too serious because the function later returns -ENOSPC. Thanks Paolo Bonzini, Christoph Hellwig. Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> Reviewed-by: Paolo Bonzini <pbonz...@r

[PATCH v2 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

If using indirect descriptors, you can make the total_sg as large as you want. If not, BUG is too serious because the function later returns -ENOSPC. Thanks Paolo Bonzini, Christoph Hellwig. Signed-off-by: Richard W.M. Jones Reviewed-by: Paolo Bonzini --- drivers/virtio/virtio_ring.c | 5

[PATCH v2 2/2] virtio: virtio_scsi: Set can_queue to the length of the virtqueue.

ch command in the queue takes 1 virtqueue entry, so the number of commands which can be queued is equal to the length of the virtqueue. Note I intend to send a patch to qemu to allow the virtqueue size to be configured from the qemu command line. Thanks Paolo Bonzini, Christoph Hellwig. Signed-off-by: R

[PATCH v2 2/2] virtio: virtio_scsi: Set can_queue to the length of the virtqueue.

ch command in the queue takes 1 virtqueue entry, so the number of commands which can be queued is equal to the length of the virtqueue. Note I intend to send a patch to qemu to allow the virtqueue size to be configured from the qemu command line. Thanks Paolo Bonzini, Christoph Hellwig. Signed-off-by: R

[PATCH v2 0/2] virtio_scsi: Set can_queue based on size of virtqueue.

v1 was here: https://lkml.org/lkml/2017/8/10/689 v1 -> v2: Remove .can_queue field from the templates. Rich.

[PATCH v2 0/2] virtio_scsi: Set can_queue based on size of virtqueue.

v1 was here: https://lkml.org/lkml/2017/8/10/689 v1 -> v2: Remove .can_queue field from the templates. Rich.

[PATCH 2/2] virtio: virtio_scsi: Set can_queue to the length of the virtqueue.

ch command in the queue takes 1 virtqueue entry, so the number of commands which can be queued is equal to the length of the virtqueue. Note I intend to send a patch to qemu to allow the virtqueue size to be configured from the qemu command line. Thanks Paolo Bonzini, Christoph Hellwig. Signed-off-by: R

[PATCH 2/2] virtio: virtio_scsi: Set can_queue to the length of the virtqueue.

ch command in the queue takes 1 virtqueue entry, so the number of commands which can be queued is equal to the length of the virtqueue. Note I intend to send a patch to qemu to allow the virtqueue size to be configured from the qemu command line. Thanks Paolo Bonzini, Christoph Hellwig. Signed-off-by: R

[PATCH 0/2] virtio_scsi: Set can_queue based on size of virtqueue.

Earlier discussion: https://lkml.org/lkml/2017/8/4/601 "Increased memory usage with scsi-mq" Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1478201

[PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

If using indirect descriptors, you can make the total_sg as large as you want. If not, BUG is too serious because the function later returns -ENOSPC. Thanks Paolo Bonzini, Christoph Hellwig. Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> --- drivers/virtio/virtio_ring.c | 5 ++

[PATCH 0/2] virtio_scsi: Set can_queue based on size of virtqueue.

Earlier discussion: https://lkml.org/lkml/2017/8/4/601 "Increased memory usage with scsi-mq" Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1478201

[PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

If using indirect descriptors, you can make the total_sg as large as you want. If not, BUG is too serious because the function later returns -ENOSPC. Thanks Paolo Bonzini, Christoph Hellwig. Signed-off-by: Richard W.M. Jones --- drivers/virtio/virtio_ring.c | 5 +++-- 1 file changed, 3

Re: Increased memory usage with scsi-mq

OK this is looking a bit better now. With scsi-mq enabled: 175 disks virtqueue_size=64: 318 disks * virtqueue_size=16: 775 disks * With scsi-mq disabled: 1755 disks * = new results I also ran the whole libguestfs test suite with

Re: Increased memory usage with scsi-mq

OK this is looking a bit better now. With scsi-mq enabled: 175 disks virtqueue_size=64: 318 disks * virtqueue_size=16: 775 disks * With scsi-mq disabled: 1755 disks * = new results I also ran the whole libguestfs test suite with

Re: Increased memory usage with scsi-mq

On Thu, Aug 10, 2017 at 02:53:58PM +0200, Paolo Bonzini wrote: > can_queue and cmd_per_lun are different. can_queue should be set to the > value of vq->vring.num where vq is the command virtqueue (the first one > is okay if there's >1). > > If you want to change it, you'll have to do so in QEMU.

Re: Increased memory usage with scsi-mq

On Thu, Aug 10, 2017 at 02:53:58PM +0200, Paolo Bonzini wrote: > can_queue and cmd_per_lun are different. can_queue should be set to the > value of vq->vring.num where vq is the command virtqueue (the first one > is okay if there's >1). > > If you want to change it, you'll have to do so in QEMU.

Re: Increased memory usage with scsi-mq

23e49846189b2f55f3f02b70a290d4be237ed5 Mon Sep 17 00:00:00 2001 From: "Richard W.M. Jones" <rjo...@redhat.com> Date: Thu, 10 Aug 2017 12:21:47 +0100 Subject: [PATCH] scsi: virtio_scsi: Set can_queue based on cmd_per_lun passed by hypervisor. Signed-off-by: Richard W.M. Jones

Re: Increased memory usage with scsi-mq

23e49846189b2f55f3f02b70a290d4be237ed5 Mon Sep 17 00:00:00 2001 From: "Richard W.M. Jones" Date: Thu, 10 Aug 2017 12:21:47 +0100 Subject: [PATCH] scsi: virtio_scsi: Set can_queue based on cmd_per_lun passed by hypervisor. Signed-off-by: Richard W.M. Jones --- drivers/scsi/virtio

Re: Increased memory usage with scsi-mq

On Mon, Aug 07, 2017 at 02:11:39PM +0200, Paolo Bonzini wrote: > You could also add a module parameter to the driver, and set it to 64 on > the kernel command line (there is an example in > drivers/scsi/vmw_pvscsi.c of how to do it). [Proviso: I've not tested the performance of difference values,

Re: Increased memory usage with scsi-mq

On Mon, Aug 07, 2017 at 02:11:39PM +0200, Paolo Bonzini wrote: > You could also add a module parameter to the driver, and set it to 64 on > the kernel command line (there is an example in > drivers/scsi/vmw_pvscsi.c of how to do it). [Proviso: I've not tested the performance of difference values,

Re: Increased memory usage with scsi-mq

On Sat, Aug 05, 2017 at 03:39:54PM +0200, Christoph Hellwig wrote: > For now can you apply this testing patch to the guest kernel? > > diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c > index 9be211d68b15..0cbe2c882e1c 100644 > --- a/drivers/scsi/virtio_scsi.c > +++

Re: Increased memory usage with scsi-mq

On Sat, Aug 05, 2017 at 03:39:54PM +0200, Christoph Hellwig wrote: > For now can you apply this testing patch to the guest kernel? > > diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c > index 9be211d68b15..0cbe2c882e1c 100644 > --- a/drivers/scsi/virtio_scsi.c > +++

Re: Increased memory usage with scsi-mq

On Sat, Aug 05, 2017 at 10:44:36AM +0200, Christoph Hellwig wrote: > On Fri, Aug 04, 2017 at 10:00:47PM +0100, Richard W.M. Jones wrote: > > I read your slides about scsi-mq and it seems like a significant > > benefit to large machines, but could the out of the box defaults b

Re: Increased memory usage with scsi-mq

On Sat, Aug 05, 2017 at 10:44:36AM +0200, Christoph Hellwig wrote: > On Fri, Aug 04, 2017 at 10:00:47PM +0100, Richard W.M. Jones wrote: > > I read your slides about scsi-mq and it seems like a significant > > benefit to large machines, but could the out of the box defaults b

Increased memory usage with scsi-mq

https://bugzilla.redhat.com/show_bug.cgi?id=1478201 We have a libguestfs test which adds 256 virtio-scsi disks to a qemu virtual machine. The VM has 500 MB of RAM, 1 vCPU and no swap. This test has been failing for a little while. It runs out of memory during SCSI enumeration in early boot.

Increased memory usage with scsi-mq

https://bugzilla.redhat.com/show_bug.cgi?id=1478201 We have a libguestfs test which adds 256 virtio-scsi disks to a qemu virtual machine. The VM has 500 MB of RAM, 1 vCPU and no swap. This test has been failing for a little while. It runs out of memory during SCSI enumeration in early boot.

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

six_names > > Signed-off-by: Jason Wang <jasow...@redhat.com> I tested this, and it does appear to fix the crashes in vp_modern_find_vqs. Therefore: Tested-by: Richard W.M. Jones <rjo...@redhat.com> Thanks, Rich. > drivers/virtio/virtio_pci_common.c | 9 + >

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

ff-by: Jason Wang I tested this, and it does appear to fix the crashes in vp_modern_find_vqs. Therefore: Tested-by: Richard W.M. Jones Thanks, Rich. > drivers/virtio/virtio_pci_common.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/driver

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:56:22PM +0100, Christoph Hellwig wrote: > Does the patch from Jason in the > > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > > thread fix the issue for you? In brief, yes it does. I followed up on that

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:56:22PM +0100, Christoph Hellwig wrote: > Does the patch from Jason in the > > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > > thread fix the issue for you? In brief, yes it does. I followed up on that

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:56:22PM +0100, Christoph Hellwig wrote: > Does the patch from Jason in the > > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > > thread fix the issue for you? I didn't see this thread before. I'll check

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:56:22PM +0100, Christoph Hellwig wrote: > Does the patch from Jason in the > > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > > thread fix the issue for you? I didn't see this thread before. I'll check

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

inux 4.11-rc/mainline in a Fedora 26 guest under a CentOS7 host > (CPU: Intel(R) Pentium(R) CPU G3220) using KVM. Sometimes when the guest > actually booted the network did not work. To get some impressions of the > crashes I got see this gallery: > https://plus.google.com/+ThorstenLeemhuis/p

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

inux 4.11-rc/mainline in a Fedora 26 guest under a CentOS7 host > (CPU: Intel(R) Pentium(R) CPU G3220) using KVM. Sometimes when the guest > actually booted the network did not work. To get some impressions of the > crashes I got see this gallery: > https://plus.google.com/+ThorstenLeemhuis/p

Re: [PATCH RESEND] hwrng: core - don't pass stack allocated buffer to rng->read()

On Fri, Oct 21, 2016 at 02:04:27PM -0700, Andy Lutomirski wrote: > https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=6d4952d9d9d4dc2bb9c0255d95a09405a1e958f7 I have tested this one, and it also fixes the bug I was seeing. Thanks Laszlo as well for his fix, and

Re: [PATCH RESEND] hwrng: core - don't pass stack allocated buffer to rng->read()

On Fri, Oct 21, 2016 at 02:04:27PM -0700, Andy Lutomirski wrote: > https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=6d4952d9d9d4dc2bb9c0255d95a09405a1e958f7 I have tested this one, and it also fixes the bug I was seeing. Thanks Laszlo as well for his fix, and

Re: Warning from free_init_pages with large initrd

On Tue, Sep 27, 2016 at 11:20:06AM +0100, Sitsofe Wheeler wrote: > (See http://www.gossamer-threads.com/lists/linux/kernel/2534175 for > the history of this thread ) > > On 26 September 2016 at 20:00, Randy Dunlap wrote: > > > > but the warning in free_init_pages() is

Re: Warning from free_init_pages with large initrd

On Tue, Sep 27, 2016 at 11:20:06AM +0100, Sitsofe Wheeler wrote: > (See http://www.gossamer-threads.com/lists/linux/kernel/2534175 for > the history of this thread ) > > On 26 September 2016 at 20:00, Randy Dunlap wrote: > > > > but the warning in free_init_pages() is about alignment, not

[PATCH v3] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Running self-tests for a short-lived KVM VM takes 28ms on my laptop. This commit adds a flag 'cryptomgr.notests' which allows them to be disabled. However if fips=1 as well, we ignore this flag as FIPS mode mandates that the self-tests are run. Signed-off-by: Richard W.M. Jones <

[PATCH v3] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Running self-tests for a short-lived KVM VM takes 28ms on my laptop. This commit adds a flag 'cryptomgr.notests' which allows them to be disabled. However if fips=1 as well, we ignore this flag as FIPS mode mandates that the self-tests are run. Signed-off-by: Richard W.M. Jones

[PATCH v3] crypto: Add a flag allowing the self-tests to be disabled at runtime.

v2 -> v3: - Ignore the flag if FIPS mode is enabled. v1 -> v2: - Use printk_once. Because the serial console is so slow, printing the message multiple times actually consumed about 6ms extra later on during the boot. - - - I'm trying to reduce the time taken in the kernel in

[PATCH v3] crypto: Add a flag allowing the self-tests to be disabled at runtime.

v2 -> v3: - Ignore the flag if FIPS mode is enabled. v1 -> v2: - Use printk_once. Because the serial console is so slow, printing the message multiple times actually consumed about 6ms extra later on during the boot. - - - I'm trying to reduce the time taken in the kernel in

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote: > You are trying to take a generalized kernel and somehow "know" about the > hardware ahead of time it is going to run on. That seems like two > conflicting requirements, don't you agree? We would have the 8250 serial port in any kernel.

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote: > You are trying to take a generalized kernel and somehow "know" about the > hardware ahead of time it is going to run on. That seems like two > conflicting requirements, don't you agree? We would have the 8250 serial port in any kernel.

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote: > On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: > > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > > > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote: > > >

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote: > On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: > > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > > > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote: > > >

Re: [PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

On Fri, Apr 29, 2016 at 12:59:57PM +0200, Stephan Mueller wrote: > Am Freitag, 29. April 2016, 11:07:43 schrieb Richard W.M. Jones: > > Hi Richard, [...] > > + if (notests) { > > What about if (!fips_enabled && notests) ? > > I am not sure whether the ker

Re: [PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

On Fri, Apr 29, 2016 at 12:59:57PM +0200, Stephan Mueller wrote: > Am Freitag, 29. April 2016, 11:07:43 schrieb Richard W.M. Jones: > > Hi Richard, [...] > > + if (notests) { > > What about if (!fips_enabled && notests) ? > > I am not sure whether the ker

[PATCH v2] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Running self-tests for a short-lived KVM VM takes 28ms on my laptop. This commit adds a flag 'cryptomgr.notests' which allows them to be disabled. Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> --- Documentation/kernel-parameters.txt | 3 +++ crypto/testmgr.c

[PATCH v2] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Running self-tests for a short-lived KVM VM takes 28ms on my laptop. This commit adds a flag 'cryptomgr.notests' which allows them to be disabled. Signed-off-by: Richard W.M. Jones --- Documentation/kernel-parameters.txt | 3 +++ crypto/testmgr.c| 9 + 2 files

[PATCH v2] crypto: Add a flag allowing the self-tests to be disabled at runtime.

v1 -> v2: - Use printk_once. Because the serial console is so slow, printing the message multiple times consumed about 6ms extra later on in the boot. Printing it only once is both neater and avoids this extra overhead. Rich. - - - I'm trying to reduce the time taken in the kernel in

[PATCH v2] crypto: Add a flag allowing the self-tests to be disabled at runtime.

v1 -> v2: - Use printk_once. Because the serial console is so slow, printing the message multiple times consumed about 6ms extra later on in the boot. Printing it only once is both neater and avoids this extra overhead. Rich. - - - I'm trying to reduce the time taken in the kernel in

[PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Running self-tests for a short-lived KVM VM takes 28ms on my laptop. This commit adds a flag 'cryptomgr.notests' which allows them to be disabled. Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> --- Documentation/kernel-parameters.txt | 3 +++ crypto/testmgr.c

[PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Running self-tests for a short-lived KVM VM takes 28ms on my laptop. This commit adds a flag 'cryptomgr.notests' which allows them to be disabled. Signed-off-by: Richard W.M. Jones --- Documentation/kernel-parameters.txt | 3 +++ crypto/testmgr.c| 9 + 2 files

[PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

I'm trying to reduce the time taken in the kernel in initcalls, with my aim being to reduce the current ~700ms spent in initcalls before userspace, down to something like 100ms. All times on my Broadwell-U laptop, under virtualization. The purpose of this is to be able to launch VMs around

[PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

I'm trying to reduce the time taken in the kernel in initcalls, with my aim being to reduce the current ~700ms spent in initcalls before userspace, down to something like 100ms. All times on my Broadwell-U laptop, under virtualization. The purpose of this is to be able to launch VMs around

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote: > > Currently autoconf spends 25ms (on my laptop) testing if the UART > > exported to it by KVM is an 8250 without FIFO and/or with strange > > quirk

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote: > > Currently autoconf spends 25ms (on my laptop) testing if the UART > > exported to it by KVM is an 8250 without FIFO and/or with strange > > quirk

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote: > 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones <rjo...@redhat.com>: > > [This is an opinionated patch, mainly for discussion.] > > > > I'm trying to reduce the time taken in the kernel in initcalls, with

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote: > 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones : > > [This is an opinionated patch, mainly for discussion.] > > > > I'm trying to reduce the time taken in the kernel in initcalls, with > > my aim being t

[PATCH] 8250: Hypervisors always export working 16550A UARTs.

[This is an opinionated patch, mainly for discussion.] I'm trying to reduce the time taken in the kernel in initcalls, with my aim being to reduce the current ~700ms spent in initcalls before userspace, down to something like 100ms. All times on my Broadwell-U laptop, under virtualization. The

[PATCH] 8250: Hypervisors always export working 16550A UARTs.

[This is an opinionated patch, mainly for discussion.] I'm trying to reduce the time taken in the kernel in initcalls, with my aim being to reduce the current ~700ms spent in initcalls before userspace, down to something like 100ms. All times on my Broadwell-U laptop, under virtualization. The

[PATCH] 8250: Hypervisors always export working 16550A UARTs.

Currently autoconf spends 25ms (on my laptop) testing if the UART exported to it by KVM is an 8250 without FIFO and/or with strange quirks, which it obviously isn't. Assume it is exported to us by a hypervisor, it's a normal, working 16550A. Signed-off-by: Richard W.M. Jones <rjo...@redhat.

[PATCH] 8250: Hypervisors always export working 16550A UARTs.

Currently autoconf spends 25ms (on my laptop) testing if the UART exported to it by KVM is an 8250 without FIFO and/or with strange quirks, which it obviously isn't. Assume it is exported to us by a hypervisor, it's a normal, working 16550A. Signed-off-by: Richard W.M. Jones --- drivers/tty

Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

On Sun, Apr 17, 2016 at 06:57:36PM -0700, Josh Triplett wrote: > O_NOUMASK seems potentially useful to support implementation of umask > entirely in userspace, which also addresses thread-safety. A program > could read its process umask out at startup, handle umask entirely in > userspace

Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

On Sun, Apr 17, 2016 at 06:57:36PM -0700, Josh Triplett wrote: > O_NOUMASK seems potentially useful to support implementation of umask > entirely in userspace, which also addresses thread-safety. A program > could read its process umask out at startup, handle umask entirely in > userspace

Re: [PATCH v2] procfs: expose umask in /proc//status

On Fri, Apr 15, 2016 at 03:13:10PM +0200, Michal Hocko wrote: > On Thu 14-04-16 12:08:15, Richard W.M. Jones wrote: > > It's not possible to read the process umask without also modifying it, > > which is what umask(2) does. A library cannot read umask safely, > > especiall

Re: [PATCH v2] procfs: expose umask in /proc//status

On Fri, Apr 15, 2016 at 03:13:10PM +0200, Michal Hocko wrote: > On Thu 14-04-16 12:08:15, Richard W.M. Jones wrote: > > It's not possible to read the process umask without also modifying it, > > which is what umask(2) does. A library cannot read umask safely, > > especiall

[PATCH v2] procfs: expose umask in /proc//status

v1 -> v2: - Change printf format to %#04o. - Retest and update examples accordingly. -- It's not possible to read the process umask without also modifying it, which is what umask(2) does. A library cannot read umask safely, especially if the main program might be multithreaded. Add

[PATCH v2] procfs: expose umask in /proc//status

v1 -> v2: - Change printf format to %#04o. - Retest and update examples accordingly. -- It's not possible to read the process umask without also modifying it, which is what umask(2) does. A library cannot read umask safely, especially if the main program might be multithreaded. Add

[PATCH v2] procfs: expose umask in /proc//status

ask (umask) in octal. It is only shown for tasks which have task->fs. This patch is adapted from one originally written by Pierre Carrier. Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> --- Documentation/filesystems/proc.txt | 1 + fs/proc/array.c| 20 ++

[PATCH v2] procfs: expose umask in /proc//status

ask (umask) in octal. It is only shown for tasks which have task->fs. This patch is adapted from one originally written by Pierre Carrier. Signed-off-by: Richard W.M. Jones --- Documentation/filesystems/proc.txt | 1 + fs/proc/array.c| 20 +++- 2 files changed,

Re: [PATCH] procfs: expose umask in /proc//status (formerly umask2, formerly getumask)

On Thu, Apr 14, 2016 at 10:34:48AM +0100, Richard W.M. Jones wrote: > It's not possible to read the process umask without also modifying it, > which is what umask(2) does. A library cannot read umask safely, > especially if the main program might be multithreaded. > > Add a

Re: [PATCH] procfs: expose umask in /proc//status (formerly umask2, formerly getumask)

On Thu, Apr 14, 2016 at 10:34:48AM +0100, Richard W.M. Jones wrote: > It's not possible to read the process umask without also modifying it, > which is what umask(2) does. A library cannot read umask safely, > especially if the main program might be multithreaded. > > Add a

[PATCH] procfs: expose umask in /proc//status

ask (umask) in octal. It is only shown for tasks which have task->fs. This patch is adapted from one originally written by Pierre Carrier. Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> --- Documentation/filesystems/proc.txt | 1 + fs/proc/array.c| 20 ++

[PATCH] procfs: expose umask in /proc//status

ask (umask) in octal. It is only shown for tasks which have task->fs. This patch is adapted from one originally written by Pierre Carrier. Signed-off-by: Richard W.M. Jones --- Documentation/filesystems/proc.txt | 1 + fs/proc/array.c| 20 +++- 2 files changed,

[PATCH] procfs: expose umask in /proc//status (formerly umask2, formerly getumask)

It's not possible to read the process umask without also modifying it, which is what umask(2) does. A library cannot read umask safely, especially if the main program might be multithreaded. Add a new status line ("Umask") in /proc//status. It contains the file mode creation mask (umask) in

[PATCH] procfs: expose umask in /proc//status (formerly umask2, formerly getumask)

It's not possible to read the process umask without also modifying it, which is what umask(2) does. A library cannot read umask safely, especially if the main program might be multithreaded. Add a new status line ("Umask") in /proc//status. It contains the file mode creation mask (umask) in

Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

On Thu, Apr 14, 2016 at 09:09:38AM +1000, Stephen Rothwell wrote: > Hi Richard, > > On Wed, 13 Apr 2016 20:05:33 +0100 "Richard W.M. Jones" <rjo...@redhat.com> > wrote: > > > > It's not possible to read the process umask without also modifying it, >

Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

On Thu, Apr 14, 2016 at 09:09:38AM +1000, Stephen Rothwell wrote: > Hi Richard, > > On Wed, 13 Apr 2016 20:05:33 +0100 "Richard W.M. Jones" > wrote: > > > > It's not possible to read the process umask without also modifying it, > > which is what uma

Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

On Wed, Apr 13, 2016 at 10:45:05PM +0200, Florian Weimer wrote: > * H. Peter Anvin: > > > I have to say I'm skeptic to the need for umask2() as opposed to > > getumask(). > > I find the extension with a set-the-thread umask somewhat unlikely. > How would a potential per-thread umask interact

Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

On Wed, Apr 13, 2016 at 10:45:05PM +0200, Florian Weimer wrote: > * H. Peter Anvin: > > > I have to say I'm skeptic to the need for umask2() as opposed to > > getumask(). > > I find the extension with a set-the-thread umask somewhat unlikely. > How would a potential per-thread umask interact

umask2 man page (was: Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask])

UMASK(2) Linux Programmer's Manual UMASK(2) NAME umask, umask2 - get and set file mode creation mask SYNOPSIS #include #include mode_t umask(mode_t mask); #define _GNU_SOURCE #include #include

umask2 man page (was: Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask])

UMASK(2) Linux Programmer's Manual UMASK(2) NAME umask, umask2 - get and set file mode creation mask SYNOPSIS #include #include mode_t umask(mode_t mask); #define _GNU_SOURCE #include #include

Re: [PATCH v3 0/2] vfs: Define new syscall getumask.

On Wed, Apr 13, 2016 at 11:52:53AM -0700, Davidlohr Bueso wrote: > ENOMANPAGE Where do man pages go? In the man-pages project? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com

[PATCH v4 3/3] vfs: selftests: Add test for umask2 system call.

Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> --- tools/testing/selftests/Makefile | 1 + tools/testing/selftests/fs/.gitignore | 1 + tools/testing/selftests/fs/Makefile | 9 tools/testing/selftests/fs/umask2-tests.c | 77

Re: [PATCH v3 0/2] vfs: Define new syscall getumask.

On Wed, Apr 13, 2016 at 11:52:53AM -0700, Davidlohr Bueso wrote: > ENOMANPAGE Where do man pages go? In the man-pages project? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com

  1   2   3   >