Re: [RFC PATCH] locking/percpu-rwsem: use this_cpu_{inc|dec}() for read_count

On 17/09/2020 15:48, Matthew Wilcox wrote: On Thu, Sep 17, 2020 at 02:01:33PM +0200, Oleg Nesterov wrote: <> If we change bio_endio to invoke the ->bi_end_io callbacks in softirq context instead of hardirq context, we can change the pagecache to take BH-safe locks instead of IRQ-safe locks.

Re: [RFC PATCH] locking/percpu-rwsem: use this_cpu_{inc|dec}() for read_count

On 16/09/2020 15:32, Hou Tao wrote: <> However the performance degradation is huge under aarch64 (4 sockets, 24 core per sockets): nearly 60% lost. v4.19.111 no writer, reader cn | 24| 48| 72 | 96 the rate of down_read/up_read per second

Re: [PATCH 0/5] Enable per-file/directory DAX operations

On 22/10/2019 14:21, Boaz Harrosh wrote: > On 20/10/2019 18:59, ira.we...@intel.com wrote: <> >> At LSF/MM we discussed the difficulties of switching the mode of a file with >> active mappings / page cache. Rather than solve those races the decision was >> to >>

Re: [PATCH 1/5] fs/stat: Define DAX statx attribute

On 20/10/2019 18:59, ira.we...@intel.com wrote: > From: Ira Weiny > > In order for users to determine if a file is currently operating in DAX > mode (effective DAX). Define a statx attribute value and set that > attribute if the effective DAX flag is set. > > To go along with this we propose

Re: [PATCH 0/5] Enable per-file/directory DAX operations

On 20/10/2019 18:59, ira.we...@intel.com wrote: > From: Ira Weiny > > At LSF/MM'19 [1] [2] we discussed applications that overestimate memory > consumption due to their inability to detect whether the kernel will > instantiate page cache for a file, and cases where a global dax enable via a >

Re: pagecache locking

On 06/07/2019 02:31, Dave Chinner wrote: > > As long as the IO ranges to the same file *don't overlap*, it should > be perfectly safe to take separate range locks (in read or write > mode) on either side of the mmap_sem as non-overlapping range locks > can be nested and will not self-deadlock. >

Re: [PATCH] dax: Fix missed PMD wakeups

On 04/07/2019 16:58, Matthew Wilcox wrote: > On Thu, Jul 04, 2019 at 04:00:00PM +0300, Boaz Harrosh wrote: <> >> Matthew you must be kidding an ilog2 in binary is zero clocks >> (Return the highest bit or something like that) > > You might want to actually check the do

Re: [PATCH] dax: Fix missed PMD wakeups

On 04/07/2019 06:27, Matthew Wilcox wrote: > On Wed, Jul 03, 2019 at 02:28:41PM -0700, Dan Williams wrote: <> >>> +#ifdef CONFIG_XARRAY_MULTI >>> + unsigned int sibs = xas->xa_sibs; >>> + >>> + while (sibs) { >>> + order++; >>> + sibs /= 2; >>> + } >>

Re: [PATCH] mm: Support madvise_willneed override by Filesystems

On 03/07/2019 20:21, Jan Kara wrote: > On Wed 03-07-19 04:04:57, Boaz Harrosh wrote: >> On 19/06/2019 11:21, Jan Kara wrote: >> <> <> >> Hi Jan >> >> Funny I'm sitting on the same patch since LSF last. I need it too for other >> reaso

Re: [PATCH] filesystem-dax: Disable PMD support

On 03/07/2019 03:42, Dan Williams wrote: > On Tue, Jul 2, 2019 at 5:23 PM Boaz Harrosh wrote: <> > > Yes, but the trick is how to manage cases where someone waiting on one > type needs to be woken up by an event on the other. Exactly I'm totally with you on this. > So a

Re: pagecache locking

On 03/07/2019 04:07, Patrick Farrell wrote: > Recursively read locking is generally unsafe, that’s why lockdep > complains about it. The common RW lock primitives are queued in > their implementation, meaning this recursive read lock sequence: > P1 - read (gets lock) > P2 - write > P1 - read > >

[PATCH] mm: Support madvise_willneed override by Filesystems

za > Hi Jan Funny I'm sitting on the same patch since LSF last. I need it too for other reasons. I have not seen, have you pushed your patch yet? (Is based on old v4.20) ~ >From fddb38169e33d23060ddd444ba6f2319f76edc89 Mon Sep 17 00:00:00 2001 From: Boaz Harrosh Date: Thu, 16 M

Re: pagecache locking

On 20/06/2019 01:37, Dave Chinner wrote: <> > > I'd prefer it doesn't get lifted to the VFS because I'm planning on > getting rid of it in XFS with range locks. i.e. the XFS_MMAPLOCK is > likely to go away in the near term because a range lock can be > taken on either side of the mmap_sem in the

Re: [PATCH] filesystem-dax: Disable PMD support

On 02/07/2019 18:37, Dan Williams wrote: <> > > I'd be inclined to do the brute force fix of not trying to get fancy > with separate PTE/PMD waitqueues and then follow on with a more clever > performance enhancement later. Thoughts about that? > Sir Dan I do not understand how separate

Re: remove exofs, the T10 OSD code and block/scsi bidi support V4

t myself, til now you guys > been doing this for me ;-)" > > Now the last time this caused a bit of a stir, but still no actual users, > not even for SG_IO passthrough commands. So here we go again, this time > including removing everything in the scsi and block layer suppor

Re: remove exofs, the T10 OSD code and block/scsi bidi support V3

On 20/12/18 09:26, Christoph Hellwig wrote: > On Wed, Dec 19, 2018 at 09:01:53PM -0500, Douglas Gilbert wrote: >>> 1) reduce the size of every kernel with block layer support, and >>> even more for every kernel with scsi support >> >> By proposing the removal of bidi support from the block

Re: remove exofs, the T10 OSD code and block/scsi bidi support V3

On 19/12/18 16:43, Christoph Hellwig wrote: > On Mon, Nov 26, 2018 at 07:11:10PM +0200, Boaz Harrosh wrote: >> On 11/11/18 15:32, Christoph Hellwig wrote: >>> The only real user of the T10 OSD protocol, the pNFS object layout >>> driver never went to the point of havin

Re: [PATCH 33/41] scsi: osd: osd_initiator: mark expected switch fall-throughs

On 28/11/18 06:32, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva ACK-by: Boaz Harrosh > --- > drivers/scsi/osd/osd_initiator.c | 3 ++- &g

Re: remove exofs, the T10 OSD code and block/scsi bidi support V3

On 11/11/18 15:32, Christoph Hellwig wrote: > The only real user of the T10 OSD protocol, the pNFS object layout > driver never went to the point of having shipping products, and we > removed it 1.5 years ago. Exofs is just a simple example without > real life users. > You have failed to say

Re: remove exofs, the T10 OSD code and block/scsi bidi support V3

On 11/11/18 15:32, Christoph Hellwig wrote: > The only real user of the T10 OSD protocol, the pNFS object layout > driver never went to the point of having shipping products, and we > removed it 1.5 years ago. Exofs is just a simple example without > real life users. > You have failed to say

Re: remove exofs and the T10 OSD code V2

On 31/10/18 23:10, Douglas Gilbert wrote: > On 2018-10-31 4:57 p.m., Boaz Harrosh wrote: >> On 30/10/18 09:45, Christoph Hellwig wrote: >>> On Mon, Oct 29, 2018 at 02:42:12PM -0600, Jens Axboe wrote: >>>> LGTM, for both: >>> >>> I also have this on

Re: remove exofs and the T10 OSD code V2

On 31/10/18 23:10, Douglas Gilbert wrote: > On 2018-10-31 4:57 p.m., Boaz Harrosh wrote: >> On 30/10/18 09:45, Christoph Hellwig wrote: >>> On Mon, Oct 29, 2018 at 02:42:12PM -0600, Jens Axboe wrote: >>>> LGTM, for both: >>> >>> I also have this on

Re: [RFC][PATCH v2 05/10] exofs: use common file type conversion

ile-time checks added by > Phillip Potter to make sure they remain the same as FT_x values > > v1: > - Initial implementation > > Signed-off-by: Phillip Potter Yes thank you, totally ACK-by: Boaz Harrosh > --- > fs/exofs/dir.c | 49 ++--

Re: [RFC][PATCH v2 05/10] exofs: use common file type conversion

ile-time checks added by > Phillip Potter to make sure they remain the same as FT_x values > > v1: > - Initial implementation > > Signed-off-by: Phillip Potter Yes thank you, totally ACK-by: Boaz Harrosh > --- > fs/exofs/dir.c | 49 ++--

Re: [PATCH] fs/exofs: Remove ignored __weak attribute

^ > > Just remove the attribute because it hasn't been correct since the > initial addition of this file in commit b14f8ab28449 ("exofs: Kbuild, > Headers and osd utils"). > > Reported-by: Nick Desaulniers > Reviewed-by: Nick Desaulniers ACK-by: Boaz Ha

Re: [PATCH] fs/exofs: Remove ignored __weak attribute

^ > > Just remove the attribute because it hasn't been correct since the > initial addition of this file in commit b14f8ab28449 ("exofs: Kbuild, > Headers and osd utils"). > > Reported-by: Nick Desaulniers > Reviewed-by: Nick Desaulniers ACK-by: Boaz Ha

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 18/05/18 17:14, Christopher Lameter wrote: > On Tue, 15 May 2018, Boaz Harrosh wrote: > >>> I don't think page tables work the way you think they work. >>> >>> + err = vm_insert_pfn_prot(zt->vma, zt_addr, pfn, prot); >>> >>>

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 18/05/18 17:14, Christopher Lameter wrote: > On Tue, 15 May 2018, Boaz Harrosh wrote: > >>> I don't think page tables work the way you think they work. >>> >>> + err = vm_insert_pfn_prot(zt->vma, zt_addr, pfn, prot); >>> >>>

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 17:17, Peter Zijlstra wrote: <> >> >> So I would love some mm guy to explain where are those bits collected? > > Depends on the architecture, some architectures only ever set bits, > some, like x86, clear bits again. You want to look at switch_mm(). > > Basically x86 clears the bit

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 17:17, Peter Zijlstra wrote: <> >> >> So I would love some mm guy to explain where are those bits collected? > > Depends on the architecture, some architectures only ever set bits, > some, like x86, clear bits again. You want to look at switch_mm(). > > Basically x86 clears the bit

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 17:18, Matthew Wilcox wrote: > On Tue, May 15, 2018 at 05:10:57PM +0300, Boaz Harrosh wrote: >> I'm not a lawyer either but I think I'm doing OK. Because I am doing exactly >> like FUSE is doing. Only some 15 years later, with modern CPUs in mind. I do >> no

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 17:18, Matthew Wilcox wrote: > On Tue, May 15, 2018 at 05:10:57PM +0300, Boaz Harrosh wrote: >> I'm not a lawyer either but I think I'm doing OK. Because I am doing exactly >> like FUSE is doing. Only some 15 years later, with modern CPUs in mind. I do >> no

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 16:50, Matthew Wilcox wrote: > On Tue, May 15, 2018 at 04:29:22PM +0300, Boaz Harrosh wrote: >> On 15/05/18 15:03, Matthew Wilcox wrote: >>> You're getting dangerously close to admitting that the entire point >>> of this exercise is so that you c

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 16:50, Matthew Wilcox wrote: > On Tue, May 15, 2018 at 04:29:22PM +0300, Boaz Harrosh wrote: >> On 15/05/18 15:03, Matthew Wilcox wrote: >>> You're getting dangerously close to admitting that the entire point >>> of this exercise is so that you c

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 15:03, Matthew Wilcox wrote: > On Tue, May 15, 2018 at 02:41:41PM +0300, Boaz Harrosh wrote: >> That would be very hard. Because that program would: >> - need to be root >> - need to start and pretend it is zus Server with the all mount >> thread thing, re

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 15:03, Matthew Wilcox wrote: > On Tue, May 15, 2018 at 02:41:41PM +0300, Boaz Harrosh wrote: >> That would be very hard. Because that program would: >> - need to be root >> - need to start and pretend it is zus Server with the all mount >> thread thing, re

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 14:54, Boaz Harrosh wrote: > On 15/05/18 03:44, Matthew Wilcox wrote: >> On Mon, May 14, 2018 at 02:49:01PM -0700, Andrew Morton wrote: >>> On Mon, 14 May 2018 20:28:01 +0300 Boaz Harrosh <bo...@netapp.com> wrote: >>>> In this project we utilize a

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 14:54, Boaz Harrosh wrote: > On 15/05/18 03:44, Matthew Wilcox wrote: >> On Mon, May 14, 2018 at 02:49:01PM -0700, Andrew Morton wrote: >>> On Mon, 14 May 2018 20:28:01 +0300 Boaz Harrosh wrote: >>>> In this project we utilize a per-core server thread so

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 15:07, Mark Rutland wrote: > On Tue, May 15, 2018 at 01:43:23PM +0300, Boaz Harrosh wrote: >> On 15/05/18 03:41, Matthew Wilcox wrote: >>> On Mon, May 14, 2018 at 10:37:38PM +0300, Boaz Harrosh wrote: >>>> On 14/05/18 22:15, Matthew Wilcox wrote: >&

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 15:07, Mark Rutland wrote: > On Tue, May 15, 2018 at 01:43:23PM +0300, Boaz Harrosh wrote: >> On 15/05/18 03:41, Matthew Wilcox wrote: >>> On Mon, May 14, 2018 at 10:37:38PM +0300, Boaz Harrosh wrote: >>>> On 14/05/18 22:15, Matthew Wilcox wrote: >&

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 15:09, Peter Zijlstra wrote: > On Tue, May 15, 2018 at 02:41:41PM +0300, Boaz Harrosh wrote: >> On 15/05/18 14:11, Matthew Wilcox wrote: > >>> You're still thinking about this from the wrong perspective. If you >>> were writing a program to attack t

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 15:09, Peter Zijlstra wrote: > On Tue, May 15, 2018 at 02:41:41PM +0300, Boaz Harrosh wrote: >> On 15/05/18 14:11, Matthew Wilcox wrote: > >>> You're still thinking about this from the wrong perspective. If you >>> were writing a program to attack t

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 14:47, Peter Zijlstra wrote: > On Tue, May 15, 2018 at 01:43:23PM +0300, Boaz Harrosh wrote: >> Yes I know, but that is exactly the point of this flag. I know that this >> address is only ever accessed from a single core. Because it is an mmap (vma) >> of an O_T

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 14:47, Peter Zijlstra wrote: > On Tue, May 15, 2018 at 01:43:23PM +0300, Boaz Harrosh wrote: >> Yes I know, but that is exactly the point of this flag. I know that this >> address is only ever accessed from a single core. Because it is an mmap (vma) >> of an O_T

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 03:44, Matthew Wilcox wrote: > On Mon, May 14, 2018 at 02:49:01PM -0700, Andrew Morton wrote: >> On Mon, 14 May 2018 20:28:01 +0300 Boaz Harrosh <bo...@netapp.com> wrote: >>> In this project we utilize a per-core server thread so everything >>> is

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 03:44, Matthew Wilcox wrote: > On Mon, May 14, 2018 at 02:49:01PM -0700, Andrew Morton wrote: >> On Mon, 14 May 2018 20:28:01 +0300 Boaz Harrosh wrote: >>> In this project we utilize a per-core server thread so everything >>> is kept local. If we use the

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 14:11, Matthew Wilcox wrote: > On Tue, May 15, 2018 at 01:43:23PM +0300, Boaz Harrosh wrote: >> On 15/05/18 03:41, Matthew Wilcox wrote: >>> On Mon, May 14, 2018 at 10:37:38PM +0300, Boaz Harrosh wrote: >>>> On 14/05/18 22:15, Matthew Wilcox wrote: >&

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 14:11, Matthew Wilcox wrote: > On Tue, May 15, 2018 at 01:43:23PM +0300, Boaz Harrosh wrote: >> On 15/05/18 03:41, Matthew Wilcox wrote: >>> On Mon, May 14, 2018 at 10:37:38PM +0300, Boaz Harrosh wrote: >>>> On 14/05/18 22:15, Matthew Wilcox wrote: >&

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 10:08, Christoph Hellwig wrote: > On Mon, May 14, 2018 at 09:26:13PM +0300, Boaz Harrosh wrote: >> I am please pushing for this patch ahead of the push of ZUFS, because >> this is the only patch we need from otherwise an STD Kernel. >> >> We are partnering

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 10:08, Christoph Hellwig wrote: > On Mon, May 14, 2018 at 09:26:13PM +0300, Boaz Harrosh wrote: >> I am please pushing for this patch ahead of the push of ZUFS, because >> this is the only patch we need from otherwise an STD Kernel. >> >> We are partnering

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 03:41, Matthew Wilcox wrote: > On Mon, May 14, 2018 at 10:37:38PM +0300, Boaz Harrosh wrote: >> On 14/05/18 22:15, Matthew Wilcox wrote: >>> On Mon, May 14, 2018 at 08:28:01PM +0300, Boaz Harrosh wrote: >>>> On a call to mmap an mmap provider (like an FS)

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 15/05/18 03:41, Matthew Wilcox wrote: > On Mon, May 14, 2018 at 10:37:38PM +0300, Boaz Harrosh wrote: >> On 14/05/18 22:15, Matthew Wilcox wrote: >>> On Mon, May 14, 2018 at 08:28:01PM +0300, Boaz Harrosh wrote: >>>> On a call to mmap an mmap provider (like an FS)

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 14/05/18 22:15, Matthew Wilcox wrote: > On Mon, May 14, 2018 at 08:28:01PM +0300, Boaz Harrosh wrote: >> On a call to mmap an mmap provider (like an FS) can put >> this flag on vma->vm_flags. >> >> The VM_LOCAL_CPU flag tells the Kernel that the vma will be u

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 14/05/18 22:15, Matthew Wilcox wrote: > On Mon, May 14, 2018 at 08:28:01PM +0300, Boaz Harrosh wrote: >> On a call to mmap an mmap provider (like an FS) can put >> this flag on vma->vm_flags. >> >> The VM_LOCAL_CPU flag tells the Kernel that the vma will be u

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 14/05/18 20:28, Boaz Harrosh wrote: > > On a call to mmap an mmap provider (like an FS) can put > this flag on vma->vm_flags. > > The VM_LOCAL_CPU flag tells the Kernel that the vma will be used > from a single-core only, and therefore invalidation (flush_tlb) of > P

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 14/05/18 20:28, Boaz Harrosh wrote: > > On a call to mmap an mmap provider (like an FS) can put > this flag on vma->vm_flags. > > The VM_LOCAL_CPU flag tells the Kernel that the vma will be used > from a single-core only, and therefore invalidation (flush_tlb) of > P

[PATCH] mm: Add new vma flag VM_LOCAL_CPU

ale and the threads are interfering with each other. This is because flush-tlb is scheduled on all (other) CPUs. NOTE: This vma (VM_LOCAL_CPU) is never used during a page_fault. It is always used in a synchronous way from a thread pinned to a single core. Signed-off-by: Boaz Harrosh <bo...@netapp.com> ---

[PATCH] mm: Add new vma flag VM_LOCAL_CPU

ale and the threads are interfering with each other. This is because flush-tlb is scheduled on all (other) CPUs. NOTE: This vma (VM_LOCAL_CPU) is never used during a page_fault. It is always used in a synchronous way from a thread pinned to a single core. Signed-off-by: Boaz Harrosh --- arch/x86/mm/tlb.c |

Re: [PATCH] scsi: libosd: Remove VLA usage

id 80 character column limit. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > ACK-BY: Boaz Harrosh <o...@electrozaur.com> > Signed-off-by: Kees Cook <keesc...@chromium.org> > --- > drivers/scsi/osd/osd

Re: [PATCH] scsi: libosd: Remove VLA usage

id 80 character column limit. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > ACK-BY: Boaz Harrosh > Signed-off-by: Kees Cook > --- > drivers/scsi/osd/osd_initiator.c | 16 > 1 file changed, 8

Re: [PATCH 02/11 linux-next] exofs: use magic.h

On 05/21/2017 06:40 PM, Fabian Frederick wrote: > Filesystems generally use SUPER_MAGIC values from magic.h > instead of a local definition. > Is fine by me to move to magic.h but ... > Signed-off-by: Fabian Frederick > --- > fs/exofs/common.h | 6 +- >

Re: [PATCH 02/11 linux-next] exofs: use magic.h

On 05/21/2017 06:40 PM, Fabian Frederick wrote: > Filesystems generally use SUPER_MAGIC values from magic.h > instead of a local definition. > Is fine by me to move to magic.h but ... > Signed-off-by: Fabian Frederick > --- > fs/exofs/common.h | 6 +- > include/uapi/linux/magic.h

Re: [PATCH, RFC] MAINTAINERS: update OSD entries

-by: Christoph Hellwig <h...@lst.de> >> --- >> MAINTAINERS | 4 >> 1 file changed, 4 deletions(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 1bb06c5f7716..28dd83a1d9e2 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -

Re: [PATCH, RFC] MAINTAINERS: update OSD entries

ff-by: Christoph Hellwig >> --- >> MAINTAINERS | 4 >> 1 file changed, 4 deletions(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 1bb06c5f7716..28dd83a1d9e2 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -9418,10 +9418,6 @@

Re: [PATCH] ore: fix spelling mistake: "Multples" -> "multiples"

On 04/22/2017 03:48 PM, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com> > > trivial fix to spelling mistake in ORE_ERR message and make word all > lower case. > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Thanks ACK-by: Boaz

Re: [PATCH] ore: fix spelling mistake: "Multples" -> "multiples"

On 04/22/2017 03:48 PM, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in ORE_ERR message and make word all > lower case. > > Signed-off-by: Colin Ian King Thanks ACK-by: Boaz Harrosh > --- > fs/exofs/ore.c | 2 +- > 1 file changed,

Re: [PATCH 3/4] nfs: remove the objlayout driver

On 04/21/2017 05:00 PM, Trond Myklebust wrote: > Maintenance is not development. It’s about doing all the followup > _after_ the feature is declared to be developed. That’s been missing > for quite some time in the case of the OSD pNFS code, which is why > I’m not even bothering to consider

Re: [PATCH 3/4] nfs: remove the objlayout driver

On 04/21/2017 05:00 PM, Trond Myklebust wrote: > Maintenance is not development. It’s about doing all the followup > _after_ the feature is declared to be developed. That’s been missing > for quite some time in the case of the OSD pNFS code, which is why > I’m not even bothering to consider

Re: [PATCH 3/4] nfs: remove the objlayout driver

On 04/20/2017 11:18 PM, Trond Myklebust wrote: <> > > OK. I'm applying this patch for the 4.12 merge window. That is understandable this code was not tested for a long while > If, as Boaz > suggests, there is still an interest in exofs, then I suggest we put > that to the test by moving it

Re: [PATCH 3/4] nfs: remove the objlayout driver

On 04/20/2017 11:18 PM, Trond Myklebust wrote: <> > > OK. I'm applying this patch for the 4.12 merge window. That is understandable this code was not tested for a long while > If, as Boaz > suggests, there is still an interest in exofs, then I suggest we put > that to the test by moving it

Re: linux-next: manual merge of the scsi-mkp tree with the char-misc tree

On 04/07/2017 10:50 PM, Bart Van Assche wrote: > On Fri, 2017-04-07 at 13:29 -0600, Logan Gunthorpe wrote: >> On 07/04/17 09:49 AM, Bart Van Assche wrote: >>> Sorry that I had not yet noticed Logan's patch series. Should my two >>> patches that conflict with Logan's patch series be dropped and

Re: linux-next: manual merge of the scsi-mkp tree with the char-misc tree

On 04/07/2017 10:50 PM, Bart Van Assche wrote: > On Fri, 2017-04-07 at 13:29 -0600, Logan Gunthorpe wrote: >> On 07/04/17 09:49 AM, Bart Van Assche wrote: >>> Sorry that I had not yet noticed Logan's patch series. Should my two >>> patches that conflict with Logan's patch series be dropped and

Re: [PATCH 1/4] block: remove the osdblk driver

On 04/12/2017 07:01 PM, Christoph Hellwig wrote: > This was just a proof of concept user for the SCSI OSD library, and > never had any real users. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Yes please remove this driver ACK-by Boaz Harrosh <o...@electrozaur.com>

Re: [PATCH 1/4] block: remove the osdblk driver

On 04/12/2017 07:01 PM, Christoph Hellwig wrote: > This was just a proof of concept user for the SCSI OSD library, and > never had any real users. > > Signed-off-by: Christoph Hellwig Yes please remove this driver ACK-by Boaz Harrosh > --- > drivers/block/Kconfig | 16 -

Re: RFC: drop the T10 OSD code and its users

On 04/12/2017 07:01 PM, Christoph Hellwig wrote: Hi Sir Christoph > The only real user of the T10 OSD protocol, the pNFS object layout > driver never went to the point of having shipping products, and the > other two users (osdblk and exofs) were simple example of it's usage. > I understand

Re: RFC: drop the T10 OSD code and its users

On 04/12/2017 07:01 PM, Christoph Hellwig wrote: Hi Sir Christoph > The only real user of the T10 OSD protocol, the pNFS object layout > driver never went to the point of having shipping products, and the > other two users (osdblk and exofs) were simple example of it's usage. > I understand

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On 03/30/2017 09:35 PM, Jeff Layton wrote: <> > Yeah, I imagine we'd need a on-disk change for this unless there's > something already present that we could use in place of a crash counter. > Perhaps we can use s_mtime and/or s_wtime in some way, I'm not sure what is a parallel for that in xfs.

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On 03/30/2017 09:35 PM, Jeff Layton wrote: <> > Yeah, I imagine we'd need a on-disk change for this unless there's > something already present that we could use in place of a crash counter. > Perhaps we can use s_mtime and/or s_wtime in some way, I'm not sure what is a parallel for that in xfs.

Re: RFC: reject unknown open flags

On 03/30/2017 09:45 PM, Linus Torvalds wrote: > On Thu, Mar 30, 2017 at 11:26 AM, Christoph Hellwig wrote: >> >> That would be nice, but still won't work as we blindly copy f_flags >> into F_GETFL, not even masking our internal FMODE_ bits. > > Ok, *that* is just silly of us, and we

Re: RFC: reject unknown open flags

On 03/30/2017 09:45 PM, Linus Torvalds wrote: > On Thu, Mar 30, 2017 at 11:26 AM, Christoph Hellwig wrote: >> >> That would be nice, but still won't work as we blindly copy f_flags >> into F_GETFL, not even masking our internal FMODE_ bits. > > Ok, *that* is just silly of us, and we could try to

Re: [PATCH] scsi: osd_uld: remove an unneeded NULL check

en...@oracle.com> > Thanks sure! ACK-by Boaz Harrosh <o...@electrozaur.com> > diff --git a/drivers/scsi/osd/osd_uld.c b/drivers/scsi/osd/osd_uld.c > index 4101c3178411..8b9941a5687a 100644 > --- a/drivers/scsi/osd/osd_uld.c > +++ b/drivers/scsi/osd/osd_uld.c > @@ -50

Re: [PATCH] scsi: osd_uld: remove an unneeded NULL check

On 03/23/2017 12:41 PM, Dan Carpenter wrote: > We don't call the remove() function unless probe() succeeds so "oud" > can't be NULL here. Plus, if it were NULL, we dereference it on the > next line so it would crash anyway. > > Signed-off-by: Dan Carpenter > Than

Re: [Lsf-pc] [LSF/MM TOPIC] do we really need PG_error at all?

On 02/28/2017 03:11 AM, Jeff Layton wrote: <> > > I'll probably have questions about the read side as well, but for now it > looks like it's mostly used in an ad-hoc way to communicate errors > across subsystems (block to fs layer, for instance). If memory does not fail me it used to be checked

Re: [Lsf-pc] [LSF/MM TOPIC] do we really need PG_error at all?

On 02/28/2017 03:11 AM, Jeff Layton wrote: <> > > I'll probably have questions about the read side as well, but for now it > looks like it's mostly used in an ad-hoc way to communicate errors > across subsystems (block to fs layer, for instance). If memory does not fail me it used to be checked

Re: [PATCH v1 45/54] exofs: convert to bio_for_each_segment_all_sp()

On 12/27/2016 06:04 PM, Ming Lei wrote: > Signed-off-by: Ming Lei <tom.leim...@gmail.com> Cool ACK-by: Boaz Harrosh <o...@electrozaur.com> > --- > fs/exofs/ore.c | 3 ++- > fs/exofs/ore_raid.c | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) > >

Re: [PATCH v1 45/54] exofs: convert to bio_for_each_segment_all_sp()

On 12/27/2016 06:04 PM, Ming Lei wrote: > Signed-off-by: Ming Lei Cool ACK-by: Boaz Harrosh > --- > fs/exofs/ore.c | 3 ++- > fs/exofs/ore_raid.c | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/fs/exofs/ore.c b/fs/exofs/ore.c

Re: [PATCH v2 1/3] introduce memcpy_nocache()

On 10/28/2016 04:54 AM, Boylston, Brian wrote: > Boaz Harrosh wrote on 2016-10-26: >> On 10/26/2016 06:50 PM, Brian Boylston wrote: >>> Introduce memcpy_nocache() as a memcpy() that avoids the processor cache >>> if possible. Without arch-specific support, this

Re: [PATCH v2 1/3] introduce memcpy_nocache()

On 10/28/2016 04:54 AM, Boylston, Brian wrote: > Boaz Harrosh wrote on 2016-10-26: >> On 10/26/2016 06:50 PM, Brian Boylston wrote: >>> Introduce memcpy_nocache() as a memcpy() that avoids the processor cache >>> if possible. Without arch-specific support, this

Re: [PATCH v2 3/3] x86: remove unneeded flush in arch_copy_from_iter_pmem()

On 10/26/2016 06:50 PM, Brian Boylston wrote: > copy_from_iter_nocache() now uses nocache copies for all types of iovecs > on x86, so the flush in arch_copy_from_iter_pmem() is no longer needed. > > Cc: Ross Zwisler > Cc: Thomas Gleixner > Cc:

Re: [PATCH v2 3/3] x86: remove unneeded flush in arch_copy_from_iter_pmem()

On 10/26/2016 06:50 PM, Brian Boylston wrote: > copy_from_iter_nocache() now uses nocache copies for all types of iovecs > on x86, so the flush in arch_copy_from_iter_pmem() is no longer needed. > > Cc: Ross Zwisler > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: > Cc:

Re: [PATCH v2 1/3] introduce memcpy_nocache()

On 10/26/2016 06:50 PM, Brian Boylston wrote: > Introduce memcpy_nocache() as a memcpy() that avoids the processor cache > if possible. Without arch-specific support, this defaults to just > memcpy(). For now, include arch-specific support for x86. > > Cc: Ross Zwisler

Re: [PATCH v2 1/3] introduce memcpy_nocache()

On 10/26/2016 06:50 PM, Brian Boylston wrote: > Introduce memcpy_nocache() as a memcpy() that avoids the processor cache > if possible. Without arch-specific support, this defaults to just > memcpy(). For now, include arch-specific support for x86. > > Cc: Ross Zwisler > Cc: Thomas Gleixner >

Re: [PATCH 4/7] fs: make remaining filesystems use .rename2

On 08/23/2016 07:24 PM, Boaz Harrosh wrote: > On 08/23/2016 05:05 PM, Miklos Szeredi wrote: >> This is trivial to do: >> >> - add flags argument to foo_rename() >> - check if flags is zero >> - assign foo_rename() to .rename2 instead of .rename >> >>

Re: [PATCH 4/7] fs: make remaining filesystems use .rename2

On 08/23/2016 07:24 PM, Boaz Harrosh wrote: > On 08/23/2016 05:05 PM, Miklos Szeredi wrote: >> This is trivial to do: >> >> - add flags argument to foo_rename() >> - check if flags is zero >> - assign foo_rename() to .rename2 instead of .rename >> >>

Re: [PATCH 4/7] fs: make remaining filesystems use .rename2

owells <dhowe...@redhat.com> > Cc: Ilya Dryomov <idryo...@gmail.com> > Cc: Jan Harkes <jahar...@cs.cmu.edu> > Cc: Tyler Hicks <tyhi...@canonical.com> > Cc: Boaz Harrosh <o...@electrozaur.com> Hi exofs is not a distributed file system in the nfs-client sense.

Re: [PATCH 4/7] fs: make remaining filesystems use .rename2

, ceph, coda, ecryptfs, exofs, kernfs, lustre, ncpfs, nfs, ocfs2, > orangefs. > > After this, we can get rid of the duplicate interfaces for rename. > > Signed-off-by: Miklos Szeredi > Cc: Eric Van Hensbergen > Cc: David Howells > Cc: Ilya Dryomov > Cc: Jan Harkes &g

Re: DAX can not work on virtual nvdimm device

On 08/19/2016 09:30 PM, Ross Zwisler wrote: > On Fri, Aug 19, 2016 at 07:59:29AM -0700, Dan Williams wrote: >> On Fri, Aug 19, 2016 at 4:19 AM, Xiao Guangrong >> wrote: >>> >>> Hi Dan, >>> >>> Recently, Redhat reported that nvml test suite failed on QEMU/KVM, >>>

Re: DAX can not work on virtual nvdimm device

On 08/19/2016 09:30 PM, Ross Zwisler wrote: > On Fri, Aug 19, 2016 at 07:59:29AM -0700, Dan Williams wrote: >> On Fri, Aug 19, 2016 at 4:19 AM, Xiao Guangrong >> wrote: >>> >>> Hi Dan, >>> >>> Recently, Redhat reported that nvml test suite failed on QEMU/KVM, >>> more detailed info please refer

Re: [PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

this patch for a while in the lab and it does solve the problem above with no maleffects so: Tested-by: Boaz Harrosh <b...@plexistor.com> > Signed-off-by: Yigal Korman <yi...@plexistor.com> > --- > arch/x86/kernel/e820.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-

Re: [PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

this patch for a while in the lab and it does solve the problem above with no maleffects so: Tested-by: Boaz Harrosh > Signed-off-by: Yigal Korman > --- > arch/x86/kernel/e820.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/e820.c b/ar

  1   2   3   4   5   6   7   8   9   10   >