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
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.
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
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
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
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
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
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.
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.
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:
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:
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
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
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
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
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
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
v1 was here:
https://lkml.org/lkml/2017/8/10/689
v1 -> v2:
Remove .can_queue field from the templates.
Rich.
v1 was here:
https://lkml.org/lkml/2017/8/10/689
v1 -> v2:
Remove .can_queue field from the templates.
Rich.
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
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
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
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 ++
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
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
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
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
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.
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.
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
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
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,
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,
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
> +++
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
> +++
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
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
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.
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.
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 +
>
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
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
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
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
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
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
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
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
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
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
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
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 <
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
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
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
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.
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.
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:
> > >
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:
> > >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[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
[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
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.
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
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
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
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
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
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
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
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 ++
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,
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
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
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 ++
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,
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
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
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,
>
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
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
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
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
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
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
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
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 - 100 of 213 matches
Mail list logo