On 24/05/23 03:57PM, Miklos Szeredi wrote:
> [trimming CC list]
>
> On Thu, 23 May 2024 at 04:49, John Groves wrote:
>
> > - memmap=! will reserve a pretend pmem device at
> >
> > - memmap=$ will reserve a pretend dax device at
> >
>
> Doesn't get me a /dev/dax or /dev/pmem
>
> Complete qe
On Fri, May 24, 2024 at 09:55:48AM +0200, Miklos Szeredi wrote:
> On Fri, 24 May 2024 at 02:47, John Groves wrote:
>
> > Apologies, but I'm short on time at the moment - going into a long holiday
> > weekend in the US with family plans. I should be focused again by middle of
> > next week.
>
> N
On Fri, 24 May 2024 at 02:47, John Groves wrote:
> Apologies, but I'm short on time at the moment - going into a long holiday
> weekend in the US with family plans. I should be focused again by middle of
> next week.
NP.
Obviously I'll need to test it before anything is merged, other than
that
On 24/05/23 03:57PM, Miklos Szeredi wrote:
> [trimming CC list]
>
> On Thu, 23 May 2024 at 04:49, John Groves wrote:
>
> > - memmap=! will reserve a pretend pmem device at
> >
> > - memmap=$ will reserve a pretend dax device at
> >
>
> Doesn't get me a /dev/dax or /dev/pmem
>
> Complete qe
[trimming CC list]
On Thu, 23 May 2024 at 04:49, John Groves wrote:
> - memmap=! will reserve a pretend pmem device at
>
> - memmap=$ will reserve a pretend dax device at
Doesn't get me a /dev/dax or /dev/pmem
Complete qemu command line:
qemu-kvm -s -serial none -parallel none -kernel
/hom
On Wed, Mar 10, 2021 at 04:29:51PM +, Al Viro wrote:
> On Tue, Mar 09, 2021 at 04:53:42PM +0100, Christoph Hellwig wrote:
> > Just use the generic anon_inode file system.
>
> Umm... The only problem I see here is the lifetime rules for
> that module, and that's not
On Wed, Mar 10, 2021 at 04:32:34PM +, Al Viro wrote:
> On Tue, Mar 09, 2021 at 04:53:43PM +0100, Christoph Hellwig wrote:
> > Just use the generic anon_inode file system.
>
> Are you changing the lifetime rules for that module?
The core drm module is pinned by the actual drive
On Tue, Mar 09, 2021 at 04:53:43PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
Are you changing the lifetime rules for that module?
On Tue, Mar 09, 2021 at 04:53:42PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
Umm... The only problem I see here is the lifetime rules for
that module, and that's not something introduced in this patchset.
Said that, looks like the logics around that
On Tue, Mar 09, 2021 at 04:53:48PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Minchan Kim
On Tue, Mar 09, 2021 at 04:53:42PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
>
> Signed-off-by: Christoph Hellwig
> arch/powerpc/platforms/pseries/cmm.c | 27 ++-
> 1 file changed, 2 insertions(+), 25 deletions(-)
&g
On 09.03.21 16:53, Christoph Hellwig wrote:
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
drivers/virtio/virtio_balloon.c | 30 +++---
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b
On 09.03.21 16:53, Christoph Hellwig wrote:
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
drivers/misc/vmw_balloon.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc
On 09.03.21 16:53, Christoph Hellwig wrote:
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/cmm.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/pseries
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
mm/z3fold.c | 38 ++
1 file changed, 2 insertions(+), 36 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index e7cd9298b221f5..e0749a3d8987de 100644
--- a/mm/z3fold.c
+++ b
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
mm/zsmalloc.c | 48 +++-
1 file changed, 3 insertions(+), 45 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index a6449a2ad861de..a7d2f471935447 100644
--- a
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
kernel/resource.c | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 0fd091a3f2fc66..12560553c26796 100644
--- a/kernel
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
drivers/misc/vmw_balloon.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index 5d057a05ddbee8..be4be32f858253
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
drivers/virtio/virtio_balloon.c | 30 +++---
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_drv.c | 64 ++-
1 file changed, 3 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 87e7214a8e3565
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/cmm.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/cmm.c
b/arch/powerpc/platforms/pseries/cmm.c
Enable UBI file system support.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/configs/qcom_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 07737cbe557f..51eeefd264d3 100644
--- a/arch/arm/configs
e
was valid. And then secondly, by checking s_log_block_size directly.
The first check is not reliable, and can trigger an UBSAN warning if
s_log_block_size on a maliciously corrupted superblock is greater than
22. This is harmless, since the second test will correctly reject the
maliciously
ocksize
was valid. And then secondly, by checking s_log_block_size directly.
The first check is not reliable, and can trigger an UBSAN warning if
s_log_block_size on a maliciously corrupted superblock is greater than
22. This is harmless, since the second test will correctly reject the
maliciously
the
glops function causes the file system to be frozen. This is intended. However,
GFS2's mount and unmount processes also hold the freeze glock to prevent other
processes, perhaps on different cluster nodes, from mounting the frozen file
system in read-write mode.
Before this patch, there
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
From: Bob Peterson
[ Upstream commit c5c68724696e7d2f8db58a5fce3673208d35c485 ]
Before this patch, gfs2_fitrim was not properly checking for a "live" file
system. If the file system had something to trim and the file system
was read-only (or spectator) it would start the trim, b
On 10/20/20 5:51 PM, Fenghua Yu wrote:
check_resctrlfs_support() checks if the platform supports resctrl file
system or not by looking for resctrl in /proc/filesystems and returns a
boolean value. The main function of resctrl test suite calls
check_resctrlfs_support() but forgets to check for
check_resctrlfs_support() checks if the platform supports resctrl file
system or not by looking for resctrl in /proc/filesystems and returns a
boolean value. The main function of resctrl test suite calls
check_resctrlfs_support() but forgets to check for it's return value. This
means that re
On Sat, 8 Aug 2020 09:59:34 -0600 David Ahern wrote:
> On 8/7/20 8:06 PM, Andrew Lunn wrote:
> > So i personally don't think netdev statistics is a good idea, i doubt
> > it scales.
>
> +1
+1
Please stop using networking as the example for this.
We don't want file interfaces for stats, and we
On 07.08.20 18:23, Al Viro wrote:
Hi,
>> This is a concept from Plan9. The main purpose is allowing applications
>> "dialing" some connection, do initial handshakes (eg. authentication)
>> and then publish the connection to other applications, that now can now
>> make use of the already dialed co
On Fri 2020-08-07 14:29:09, Jonathan Adams wrote:
> [resending to widen the CC lists per rdun...@infradead.org's suggestion
> original posting to lkml here: https://lkml.org/lkml/2020/8/5/1009]
>
> To try to restart the discussion of kernel statistics started by the
> statsfs patchsets (https://lk
On 8/7/20 8:06 PM, Andrew Lunn wrote:
> So i personally don't think netdev statistics is a good idea, i doubt
> it scales.
+1
> net/dev/stats/tx_bytes/annotations
> DESCRIPTION net\ device\ transmited\ bytes\ count
> CUMULATIVE
> net/dev/stats/tx_bytes/fields
> interface value
> str int
> net/dev/stats/tx_bytes/values
> lo 4394430608
> eth0 33353183843
> eth1 16228847091
This is a rather small system. Have
[resending to widen the CC lists per rdun...@infradead.org's suggestion
original posting to lkml here: https://lkml.org/lkml/2020/8/5/1009]
To try to restart the discussion of kernel statistics started by the
statsfs patchsets (https://lkml.org/lkml/2020/5/26/332), I wanted
to share the following
On 8/5/20 5:14 PM, Jonathan Adams wrote:
> To try to restart the discussion of kernel statistics started by the
> statsfs patchsets (https://lkml.org/lkml/2020/5/26/332), I wanted
> to share the following set of patches which are Google's 'metricfs'
> implementation and some example uses. Google h
On Fri, Aug 07, 2020 at 01:09:30PM +0200, Enrico Weigelt, metux IT consult
wrote:
> Hello folks,
>
>
> here's the first version of my "srvfs" implementation - a synthentic
> filesystem which allows a process to "publish" an open file descriptor
> i
Hello folks,
here's the first version of my "srvfs" implementation - a synthentic
filesystem which allows a process to "publish" an open file descriptor
into the file system, so other processes can continue from there, with
whatever state the fd is already in.
This is
To try to restart the discussion of kernel statistics started by the
statsfs patchsets (https://lkml.org/lkml/2020/5/26/332), I wanted
to share the following set of patches which are Google's 'metricfs'
implementation and some example uses. Google has been using metricfs
internally since 2012 as a
On Mon, Aug 03, 2020 at 10:56:23AM -0400, Qian Cai wrote:
> On Tue, Jul 28, 2020 at 06:33:53PM +0200, Christoph Hellwig wrote:
> > Hi Al and Linus,
> >
> > currently a lot of the file system calls in the early in code (and the
> > devtmpfs kthread) rely on the implic
On Tue, Jul 28, 2020 at 06:33:53PM +0200, Christoph Hellwig wrote:
> Hi Al and Linus,
>
> currently a lot of the file system calls in the early in code (and the
> devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot.
> This is one of the few last remaining places
On Fri, Jul 31, 2020 at 03:14:24AM +0100, Al Viro wrote:
> Christoph Hellwig (28):
> [snip]
> initramfs: switch initramfs unpacking to struct file based APIs
> initramfs: switch initramfs unpacking to struct file based APIs
> [snip]
>
> It's not a bisect hazard, of course, but if you d
On Thu, Jul 30, 2020 at 08:25:24AM +0200, Christoph Hellwig wrote:
> On Wed, Jul 29, 2020 at 08:51:17PM +0100, Al Viro wrote:
> > On Tue, Jul 28, 2020 at 06:33:53PM +0200, Christoph Hellwig wrote:
> > > Hi Al and Linus,
> > >
> > > currently a lot of the fi
On Wed, Jul 29, 2020 at 08:51:17PM +0100, Al Viro wrote:
> On Tue, Jul 28, 2020 at 06:33:53PM +0200, Christoph Hellwig wrote:
> > Hi Al and Linus,
> >
> > currently a lot of the file system calls in the early in code (and the
> > devtmpfs kthread) rely on the implic
On Tue, Jul 28, 2020 at 06:33:53PM +0200, Christoph Hellwig wrote:
> Hi Al and Linus,
>
> currently a lot of the file system calls in the early in code (and the
> devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot.
> This is one of the few last remaining places
Hi Al and Linus,
currently a lot of the file system calls in the early in code (and the
devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot.
This is one of the few last remaining places we need to deal with to kill
off set_fs entirely, so this series adds new helpers that take
On Sun, Jul 26, 2020 at 06:26:27PM +0200, Christoph Hellwig wrote:
> On Sun, Jul 26, 2020 at 06:24:26PM +0200, Christoph Hellwig wrote:
> > Btw, care to take a look at
> >
> > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/kernel_readwrite
> >
> > it has been in linux-next for 2
On Sun, Jul 26, 2020 at 06:24:26PM +0200, Christoph Hellwig wrote:
> Btw, care to take a look at
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/kernel_readwrite
>
> it has been in linux-next for 2 1/2 weeks, and the only interesting
> thing found was that btrfs didn't wire u
; >
> > > > Hi Al and Linus,
> > > >
> > > > currently a lot of the file system calls in the early in code (and the
> > > > devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot.
> > > > This is one of the few last remaining pla
On Sun, Jul 26, 2020 at 05:52:04PM +0200, Christoph Hellwig wrote:
> On Sun, Jul 26, 2020 at 08:49:28AM -0700, Linus Torvalds wrote:
> > On Sun, Jul 26, 2020 at 12:14 AM Christoph Hellwig wrote:
> > >
> > > Hi Al and Linus,
> > >
> > > currently a lot
On Sun, Jul 26, 2020 at 08:49:28AM -0700, Linus Torvalds wrote:
> On Sun, Jul 26, 2020 at 12:14 AM Christoph Hellwig wrote:
> >
> > Hi Al and Linus,
> >
> > currently a lot of the file system calls in the early in code (and the
> > devtmpfs kthread) rely on the
On Sun, Jul 26, 2020 at 12:14 AM Christoph Hellwig wrote:
>
> Hi Al and Linus,
>
> currently a lot of the file system calls in the early in code (and the
> devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot.
> This is one of the few last remaining places we ne
Hi Al and Linus,
currently a lot of the file system calls in the early in code (and the
devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot.
This is one of the few last remaining places we need to deal with to kill
off set_fs entirely, so this series adds new helpers that take
Hi Al and Linus,
currently a lot of the file system calls in the early in code (and the
devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot.
This is one of the few last remaining places we need to deal with to kill
off set_fs entirely, so this series adds new helpers that take
Hi Al,
currently a lot of the file system calls in the early in code (and the
devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot.
This is one of the few last remaining places we need to deal with to kill
off set_fs entirely, so this series adds new helpers that take kernel
On Wed, 8 Jul 2020 16:58:04 +0200
"Alexander A. Klimov" wrote:
> Documentation/filesystems/9p.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/9p.rst
> b/Documentation/filesystems/9p.rst
> index 2995279ddc24..7b5964bc8865 100644
> --- a/Do
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
On 28/05/20 00:21, David Ahern wrote:
> On 5/27/20 3:07 PM, Paolo Bonzini wrote:
>> I see what you meant now. statsfs can also be used to enumerate objects
>> if one is so inclined (with the prototype in patch 7, for example, each
>> network interface becomes a directory).
>
> there are many use
On 5/27/20 3:07 PM, Paolo Bonzini wrote:
> I see what you meant now. statsfs can also be used to enumerate objects
> if one is so inclined (with the prototype in patch 7, for example, each
> network interface becomes a directory).
there are many use cases that have 100's to 1000's have network de
On 27/05/20 23:27, Jakub Kicinski wrote:
> On Wed, 27 May 2020 23:07:53 +0200 Paolo Bonzini wrote:
>>> Again, I have little KVM knowledge, but BPF also uses a fd-based API,
>>> and carries stats over the same syscall interface.
>>
>> Can BPF stats (for BPF scripts created by whatever process is r
On Wed, 27 May 2020 23:07:53 +0200 Paolo Bonzini wrote:
> > Again, I have little KVM knowledge, but BPF also uses a fd-based API,
> > and carries stats over the same syscall interface.
>
> Can BPF stats (for BPF scripts created by whatever process is running in
> the system) be collected by an e
he right
> place for statistics (for example it is affected by lockdown)
>
> In this patch series I introduce statsfs, a synthetic ram-based virtual
> filesystem that takes care of gathering and displaying statistics for the
> Linux kernel subsystems.
>
> The file system is mounte
On 27/05/20 22:23, Jakub Kicinski wrote:
> On Wed, 27 May 2020 15:14:41 +0200 Emanuele Giuseppe Esposito wrote:
>> Regarding the config, as I said the idea is to gather multiple
>> subsystems' statistics, therefore there wouldn't be a single
>> configuration method like in netlink.
>> For example
On Wed, 27 May 2020 15:14:41 +0200 Emanuele Giuseppe Esposito wrote:
> Regarding the config, as I said the idea is to gather multiple
> subsystems' statistics, therefore there wouldn't be a single
> configuration method like in netlink.
> For example in kvm there are file descriptors for configur
On 27/05/20 15:33, Andrew Lunn wrote:
>> I don't really know a lot about the networking subsystem, and as it was
>> pointed out in another email on patch 7 by Andrew, networking needs to
>> atomically gather and display statistics in order to make them consistent,
>> and currently this is not suppo
> I don't really know a lot about the networking subsystem, and as it was
> pointed out in another email on patch 7 by Andrew, networking needs to
> atomically gather and display statistics in order to make them consistent,
> and currently this is not supported by stats_fs but could be added in
> f
The file system is mounted on /sys/kernel/stats and would be already used
by kvm. Statsfs was initially introduced by Paolo Bonzini [1].
What's the direct motivation for this work? Moving KVM stats out of
debugfs?
There's many reasons: one of these is not using debugfs for
t; place for statistics (for example it is affected by lockdown)
>
> In this patch series I introduce statsfs, a synthetic ram-based virtual
> filesystem that takes care of gathering and displaying statistics for the
> Linux kernel subsystems.
>
> The file system is mounte
virtual
filesystem that takes care of gathering and displaying statistics for the
Linux kernel subsystems.
The file system is mounted on /sys/kernel/stats and would be already used
by kvm. Statsfs was initially introduced by Paolo Bonzini [1].
Statsfs offers a generic and stable API, allowing any kind
On Wed, 13 May 2020, Patrick Donnelly wrote:
> However, it seems odd that this depends on the owner of the directory.
> i.e. this protection only seems to be enforced if the sticky directory
> is owned by root. That's expected?
According to the documentation[0] this appears to be intentional:
pr
On Wed, May 13, 2020 at 9:11 AM Al Viro wrote:
>
> On Wed, May 13, 2020 at 08:00:28AM -0700, Patrick Donnelly wrote:
> > In newer kernels (at least 5.6), it appears root is not able to write
> > to files owned by other users in a sticky directory:
>
> Yes. Controlled by /proc/sys/fs/protected_reg
On Wed, May 13, 2020 at 08:00:28AM -0700, Patrick Donnelly wrote:
> In newer kernels (at least 5.6), it appears root is not able to write
> to files owned by other users in a sticky directory:
Yes. Controlled by /proc/sys/fs/protected_regular, which systemd crowd
has decided to enable in commit 2
In newer kernels (at least 5.6), it appears root is not able to write
to files owned by other users in a sticky directory:
$ uname -r
5.6.11-arch1-1
$ stat -f /tmp
File: "/tmp"
ID: 0Namelen: 255 Type: tmpfs
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 200516
On 4/25/20 1:56 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> except for the DASD case under discussion the last users of ioctl_by_bdev
> are the file system drivers that want to query CDROM information using
> ioctls. This series switches them to use function calls directly i
Hi Jens,
can you pick up this series?
Except for the DASD case under discussion the last users of ioctl_by_bdev
are the file system drivers that want to query CDROM information using
ioctls. This series switches them to use function calls directly into
the CDROM midlayer instead, which implies
Jens,
can you pick this up for the for-5.8/block tree? We're about ready
to kill ioctl_by_bdev after this series.
On Sun, Oct 20, 2019 at 10:51:56AM -0700, Andi Kleen wrote:
SNIP
> @@ -92,8 +93,12 @@ static int pmu_format(const char *name, struct list_head
> *format)
> snprintf(path, PATH_MAX,
>"%s" EVENT_SOURCE_DEVICE_PATH "%s/format", sysfs, name);
>
> - if (stat(path, &st) < 0
From: Andi Kleen
pmu.c does a lot of redundant /sys accesses while parsing aliases
and probing for PMUs. On large systems with a lot of PMUs this
can get expensive (>2s):
% time seconds usecs/call callserrors syscall
-- --- --- - - ---
From: Andi Kleen
pmu.c does a lot of redundant /sys accesses while parsing aliases
and probing for PMUs. On large systems with a lot of PMUs this
can get expensive (>2s):
% time seconds usecs/call callserrors syscall
-- --- --- - - ---
On Thu, Sep 12, 2019 at 3:07 PM Miklos Szeredi wrote:
> Is this a regression from 9p?
Let me answer myself: 9p seems to behave similarly: after
suspend/resume it hangs.
So added -EOPNOTSUPP + pr_warn() to the freeze function and verified
that this fixes the bad behavior.
Thanks,
Miklos
On Thu, Sep 12, 2019 at 2:54 PM Stefan Hajnoczi wrote:
>
> On Thu, Sep 12, 2019 at 10:14:11AM +0200, Miklos Szeredi wrote:
> > On Wed, Sep 11, 2019 at 5:54 PM Stefan Hajnoczi wrote:
> > >
> > > On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote:
> > > > I've folded the series from Viv
On Thu, Sep 12, 2019 at 10:14:11AM +0200, Miklos Szeredi wrote:
> On Wed, Sep 11, 2019 at 5:54 PM Stefan Hajnoczi wrote:
> >
> > On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote:
> > > I've folded the series from Vivek and fixed a couple of TODO comments
> > > myself. AFAICS two iss
On Wed, Sep 11, 2019 at 5:54 PM Stefan Hajnoczi wrote:
>
> On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote:
> > I've folded the series from Vivek and fixed a couple of TODO comments
> > myself. AFAICS two issues remain that need to be resolved in the short
> > term, one way or the
On Wed, Sep 11, 2019 at 4:53 PM Vivek Goyal wrote:
>
> On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote:
> > Git tree for this version is available here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v5
> >
> > Only post patches that actually add vi
On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote:
> I've folded the series from Vivek and fixed a couple of TODO comments
> myself. AFAICS two issues remain that need to be resolved in the short
> term, one way or the other: freeze/restore and full virtqueue.
I have researched freez
On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote:
> Git tree for this version is available here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v5
>
> Only post patches that actually add virtiofs (virtiofs-v5-base..virtiofs-v5).
>
> I've folded the ser
On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote:
> Git tree for this version is available here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v5
>
> Only post patches that actually add virtiofs (virtiofs-v5-base..virtiofs-v5).
>
> I've folded the ser
Git tree for this version is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v5
Only post patches that actually add virtiofs (virtiofs-v5-base..virtiofs-v5).
I've folded the series from Vivek and fixed a couple of TODO comments
myself. AFAICS two issues
On Tue, Sep 03, 2019 at 11:17:35AM +0200, Miklos Szeredi wrote:
> On Tue, Sep 3, 2019 at 10:31 AM Michael S. Tsirkin wrote:
> > > > fs/fuse/Kconfig | 11 +
> > > > fs/fuse/Makefile|1 +
> > > > fs/fuse/control.c |4 +-
> > > > fs/fuse/cuse.c
On Tue, Sep 03, 2019 at 10:18:51AM -0400, Vivek Goyal wrote:
> On Tue, Sep 03, 2019 at 10:12:16AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Sep 03, 2019 at 10:07:52AM -0400, Vivek Goyal wrote:
> > > On Tue, Sep 03, 2019 at 04:31:38AM -0400, Michael S. Tsirkin wrote:
> > >
> > > [..]
> > > > +
1 - 100 of 1196 matches
Mail list logo
