Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Tue, Jun 6, 2023 at 5:48 AM Andreas Gruenbacher wrote: > > - Don't get stuck writing page onto itself under direct I/O. Btw, is there a test for this DIO case? We've had the deadlock issue on t page lock (or for inode locks or whatever) for normal IO when faulting in the same page that is

Re: [Cluster-devel] [GIT PULL] gfs2 fix for v6.3-rc4

On Thu, Mar 23, 2023 at 3:22 PM Andreas Grünbacher wrote: > > I've pushed the tag out now; should I resend the pull request? No, all good, I have the changes, Linus

Re: [Cluster-devel] [GIT PULL] gfs2 fix for v6.3-rc4

On Thu, Mar 23, 2023 at 11:45 AM Andreas Gruenbacher wrote: > > From: Linus Torvalds Wat? > git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git > gfs2-v6.3-rc3-fix -ENOSUCHTAG > for you to fetch changes up to 260595b439776c473cc248f0de63fe78d964d849: .. and

Re: [Cluster-devel] [GIT PULL] gfs2 writepage fix

On Sun, Jan 22, 2023 at 1:01 AM Andreas Gruenbacher wrote: > > gfs2 writepage fix > > - Fix a regression introduced by commit "gfs2: stop using > generic_writepages in gfs2_ail1_start_one". Hmm. I'm adding a few more people and linux-fsdevel to the reply, because we had a number of filesystems

Re: [Cluster-devel] [GIT PULL] dlm updates for 6.0

On Mon, Aug 1, 2022 at 8:56 AM David Teigland wrote: > > At risk of compounding your trouble, I could have added that you can use > the original merge and have me send the fixup. Well, I only had something like 4 other merges on top, none of them *that* complicated. And I hadn't pushed out, so

Re: [Cluster-devel] [GIT PULL] dlm updates for 6.0

On Mon, Aug 1, 2022 at 7:43 AM David Teigland wrote: > > (You can ignore the premature 5.20 pull request from some weeks ago.) Gaah. That was the first thing I pulled this morning because it was the earliest. And apparently you've rebased, so I can't even just pull on top. Gaah. Now I'll have

Re: [Cluster-devel] [RFC 0/2] refcount: attempt to avoid imbalance warnings

On Thu, Jun 30, 2022 at 6:59 AM Alexander Aring wrote: > > I send this patch series as RFC because it was necessary to do a kref > change after adding __cond_lock() to refcount_dec_and_lock() > functionality. Can you try something like this instead? This is two separate patches - one for

Re: [Cluster-devel] sparse warnings related to kref_put_lock() and refcount_dec_and_lock()

On Tue, Jun 28, 2022 at 1:58 AM Luc Van Oostenryck wrote: > > I would certainly not recommend this but ... > if it's OK to cheat and lie then you can do: > + bool refcount_dec_and_lock(refcount_t *r, spinlock_t *lock) > __acquires(lock); Actually, we have "__cond_lock()" in the kernel to

Re: [Cluster-devel] [GIT PULL] gfs2 fixes

On Fri, May 13, 2022 at 2:07 PM Andreas Gruenbacher wrote: > > Would you like to still pull these fixes for v5.18, or should we send them in > the next merge window? I've pulled them. Any filesystem corruption issue sounds scary enough that it doesn't sound very sane to delay fixes.

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Tue, May 3, 2022 at 2:35 PM Andreas Gruenbacher wrote: > > More testing still ongoing, but the following patch seems to fix the > data corruption. Fingers crossed. > + truncate_pagecache_range(inode, hstart, hend - 1); > + if (hstart < hend) > +

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Tue, May 3, 2022 at 9:41 AM Andreas Gruenbacher wrote: > > That's happening in iomap_file_buffered_write() and iomap_iter(): > > while ((ret = iomap_iter(, ops)) > 0) > iter.processed = iomap_write_iter(, i); > > Here, iomap_write_iter() returns how much progress it has

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Mon, May 2, 2022 at 11:31 AM Linus Torvalds wrote: > > NOTE! This patch is entirely untested. I also didn't actually yet go > look at what gfs2 does when 'bytes' and 'copied' are different. Oh, it's a lot of generic iomap_write_end() code, so I guess it's just as well that

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Thu, Apr 28, 2022 at 10:09 AM Linus Torvalds wrote: > > I'll look at that copy_page_to_iter_iovec() some more regardless, but > doing that "let's double-check it's not somethign else" would be good. Oh, and as I do that, it strikes me: What platform do you see the p

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Thu, Apr 28, 2022 at 6:27 AM Andreas Gruenbacher wrote: > > The data corruption we've been getting unfortunately didn't have to do > with lock contention (we already knew that); it still occurs. I'm > running out of ideas on what to try there. Hmm. I don't see the bug, but I do have a

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Wed, Apr 27, 2022 at 3:20 PM Linus Torvalds wrote: > > So I really think > > (a) you are mis-reading the standard by attributing too strong logic > to paperwork that is English prose and not so exact > > (b) documenting Linux as not doing what you are mis-reading it for

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Wed, Apr 27, 2022 at 2:26 PM Andreas Gruenbacher wrote: > > Well, POSIX explicitly mentions those atomicity expectations, e.g., > for read [1]: Yes. I'm aware. And my point is that we've never done _that_ kind of atomicity. It's also somewhat ambiguous what it actually means, since what it

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Wed, Apr 27, 2022 at 12:41 PM Andreas Gruenbacher wrote: > > I wonder if this could be documented in the read and write manual > pages. Or would that be asking too much? I don't think it would be asking too much, since it's basically just describing what Linux has always done in all the major

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Wed, Apr 27, 2022 at 5:29 AM Andreas Gruenbacher wrote: > > Regular (buffered) reads and writes are expected to be atomic with > respect to each other. Linux has actually never honored that completely broken POSIX requirement, although I think some filesystems (notably XFS) have tried. It's

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Tue, Apr 26, 2022 at 2:28 PM Andreas Gruenbacher wrote: > > Btrfs has a comment in that place that reads: > > /* No increment (+=) because iomap returns a cumulative value. */ What a truly horrid interface. But you are triggering repressed childhood memories: > That's so that we can

Re: [Cluster-devel] [GIT PULL] gfs2 fix

On Tue, Apr 26, 2022 at 7:54 AM Andreas Gruenbacher wrote: > > Also, note that we're fighting with a rare case of data corruption that > seems to have been introduced by commit 00bfe02f4796 ("gfs2: Fix mmap + > page fault deadlocks for buffered I/O"; merged in v5.16). The > corruption seems to

Re: [Cluster-devel] [GIT PULL] gfs2 fixes

On Fri, Feb 11, 2022 at 9:05 AM Andreas Gruenbacher wrote: > > * Revert debug commit that causes unexpected data corruption. Well, apparently not just unexpected, but unexplained too. That's a bit worrisome. It sounds like the corruption cause is still there, just hidden by the lack of

Re: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks

On Fri, Oct 29, 2021 at 10:50 AM Catalin Marinas wrote: > > First of all, a uaccess in interrupt should not force such signal as it > had nothing to do with the interrupted context. I guess we can do an > in_task() check in the fault handler. Yeah. It ends up being similar to the thread flag in

Re: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks

On Thu, Oct 28, 2021 at 2:21 PM Catalin Marinas wrote: > > They do look fairly similar but we should have the information in the > fault handler to distinguish: not a page fault (pte permission or p*d > translation), in_task(), user address, fixup handler. But I agree the > logic looks fragile.

Re: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks

On Wed, Oct 27, 2021 at 12:13 PM Catalin Marinas wrote: > > As an alternative, you mentioned earlier that a per-thread fault status > was not feasible on x86 due to races. Was this only for the hw poison > case? I think the uaccess is slightly different. It's not x86-specific, it's very generic.

Re: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks

On Tue, Oct 26, 2021 at 11:50 AM Linus Torvalds wrote: > > Because for _most_ cases of "copy_to/from_user()" and friends by far, > the only thing we look for is "zero for success". Gaah. Looking around, I almost immediately found some really

Re: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks

On Tue, Oct 26, 2021 at 11:24 AM Catalin Marinas wrote: > > While more intrusive, I'd rather change copy_page_from_iter_atomic() > etc. to take a pointer where to write back an error code. I absolutely hate this model. The thing is, going down that rat-hole, you'll find that you'll need to add

Re: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks

On Fri, Oct 22, 2021 at 8:06 AM Catalin Marinas wrote: > > Probing only the first byte(s) in fault_in() would be ideal, no need to > go through all filesystems and try to change the uaccess/probing order. Let's try that. Or rather: probing just the first page - since there are users like that

Re: [Cluster-devel] [RFC][arm64] possible infinite loop in btrfs search_ioctl()

On Thu, Oct 21, 2021 at 4:42 AM Andreas Gruenbacher wrote: > > But probing the entire memory range in fault domain granularity in the > page fault-in functions still doesn't actually make sense. Those > functions really only need to guarantee that we'll be able to make > progress eventually. From

Re: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks

On Wed, Oct 20, 2021 at 12:44 PM Catalin Marinas wrote: > > However, with MTE doing both get_user() every 16 bytes and > gup can get pretty expensive. So I really think that anything that is performance-critical had better only do the "fault_in_write()" code path in the cold error path where you

Re: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks

On Wed, Oct 20, 2021 at 6:37 AM Catalin Marinas wrote: > > The atomic "add zero" trick isn't that simple for MTE since the arm64 > atomic or exclusive instructions run with kernel privileges and > therefore with the kernel tag checking mode. Are there any instructions that are useful for

Re: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks

On Tue, Oct 19, 2021 at 3:42 AM Andreas Gruenbacher wrote: > > From my point of view, the following questions remain: > > * I hope these patches will be merged for v5.16, but what process >should I follow for that? The patch queue contains mm and iomap >changes, so a pull request from

Re: [Cluster-devel] [RFC][arm64] possible infinite loop in btrfs search_ioctl()

On Tue, Oct 12, 2021 at 10:27 AM Catalin Marinas wrote: > > Apart from fault_in_pages_*(), there's also fault_in_user_writeable() > called from the futex code which uses the GUP mechanism as the write > would be destructive. It looks like it could potentially trigger the > same infinite loop on

Re: [Cluster-devel] [RFC][arm64] possible infinite loop in btrfs search_ioctl()

On Mon, Oct 11, 2021 at 2:08 PM Catalin Marinas wrote: > > +#ifdef CONFIG_ARM64_MTE > +#define FAULT_GRANULE_SIZE (16) > +#define FAULT_GRANULE_MASK (~(FAULT_GRANULE_SIZE-1)) [...] > If this looks in the right direction, I'll do some proper patches > tomorrow. Looks fine to me. It's

Re: [Cluster-devel] [RFC][arm64] possible infinite loop in btrfs search_ioctl()

On Mon, Oct 11, 2021 at 10:38 AM Catalin Marinas wrote: > > I cleaned up this patch [1] but I realised it still doesn't solve it. > The arm64 __copy_to_user_inatomic(), while ensuring progress if called > in a loop, it does not guarantee precise copy to the fault position. That should be ok.,

Re: [Cluster-devel] [PATCH v7 16/19] iomap: Add done_before argument to iomap_dio_rw

On Thu, Sep 9, 2021 at 4:31 AM Christoph Hellwig wrote: > > What about just passing done_before as an argument to > iomap_dio_complete? gfs2 would have to switch to __iomap_dio_rw + > iomap_dio_complete instead of iomap_dio_rw for that, and it obviously > won't work for async completions, but you

Re: [Cluster-devel] [PATCH v7 17/19] gup: Introduce FOLL_NOFAULT flag to disable page faults

On Thu, Sep 9, 2021 at 4:36 AM Christoph Hellwig wrote: > > On Fri, Aug 27, 2021 at 06:49:24PM +0200, Andreas Gruenbacher wrote: > > Introduce a new FOLL_NOFAULT flag that causes get_user_pages to return > > -EFAULT when it would otherwise trigger a page fault. This is roughly > > similar to

Re: [Cluster-devel] [PATCH v7 00/19] gfs2: Fix mmap + page fault deadlocks

On Fri, Sep 3, 2021 at 11:28 AM Al Viro wrote: > > FWIW, my objections regarding the calling conventions are still there. So I'm happy to further change the calling conventions, but by now _that_ part is most definitely a "not this merge window". The need for that ternary state is still there.

Re: [Cluster-devel] [PATCH v7 00/19] gfs2: Fix mmap + page fault deadlocks

On Wed, Sep 1, 2021 at 12:53 PM Andreas Gruenbacher wrote: > > So there's a minor merge conflict between Christoph's iomap_iter > conversion and this patch queue now, and I should probably clarify the > description of "iomap: Add done_before argument to iomap_dio_rw" that > Darrick ran into. Then

Re: [Cluster-devel] [PATCH v7 04/19] iov_iter: Turn iov_iter_fault_in_readable into fault_in_iov_iter_readable

On Fri, Aug 27, 2021 at 1:56 PM Kari Argillander wrote: > > At least this patch will break ntfs3 which is in next. It has been there > just couple weeks so I understand. I added Konstantin and ntfs3 list so > that we know what is going on. Can you please info if and when do we > need rebase. No

Re: [Cluster-devel] [PATCH v7 16/19] iomap: Add done_before argument to iomap_dio_rw

On Fri, Aug 27, 2021 at 2:32 PM Darrick J. Wong wrote: > > No, because you totally ignored the second question: > > If the directio operation succeeds even partially and the PARTIAL flag > is set, won't that push the iov iter ahead by however many bytes > completed? > > We already finished the IO

Re: [Cluster-devel] [PATCH v7 05/19] iov_iter: Introduce fault_in_iov_iter_writeable

On Fri, Aug 27, 2021 at 12:23 PM Al Viro wrote: > > Could you show the cases where "partial copy, so it's OK" behaviour would > break anything? Absolutely. For example, i t would cause an infinite loop in restore_fpregs_from_user() if the "buf" argument is a situation where the first page is

Re: [Cluster-devel] [PATCH v7 05/19] iov_iter: Introduce fault_in_iov_iter_writeable

On Fri, Aug 27, 2021 at 11:52 AM Al Viro wrote: > > Again, the calling conventions are wrong. Make it success/failure or > 0/-EFAULT. And it's inconsistent for iovec and non-iovec cases as it is. Al, the 0/-EFAULT thing DOES NOT WORK. The whole "success vs failure" model is broken. Because

Re: [Cluster-devel] [PATCH v7 04/19] iov_iter: Turn iov_iter_fault_in_readable into fault_in_iov_iter_readable

On Fri, Aug 27, 2021 at 11:53 AM Al Viro wrote: > > I really disagree with these calling conventions. "Number not faulted in" > is bloody useless It's what we already have for copy_to/from_user(), so it's actually consistent with that. And it avoids changing all the existing tests where people

Re: [Cluster-devel] [PATCH v7 00/19] gfs2: Fix mmap + page fault deadlocks

On Fri, Aug 27, 2021 at 9:49 AM Andreas Gruenbacher wrote: > > here's another update on top of v5.14-rc7. Changes: > > * Some of the patch descriptions have been improved. > > * Patch "gfs2: Eliminate ip->i_gh" has been moved further to the front. > > At this point, I'm not aware of anything

Re: [Cluster-devel] [PATCH v5 00/12] gfs2: Fix mmap + page fault deadlocks

On Thu, Aug 19, 2021 at 12:41 PM Andreas Gruenbacher wrote: > > Hmm, what if GUP is made to skip VM_IO vmas without adding anything to > the pages array? That would match fault_in_iov_iter_writeable, which > is modeled after __mm_populate and which skips VM_IO and VM_PFNMAP > vmas. I don't

Re: [Cluster-devel] [PATCH v5 00/12] gfs2: Fix mmap + page fault deadlocks

[ Sorry for the delay, I was on the road and this fell through the cracks ] On Mon, Aug 16, 2021 at 12:14 PM Andreas Gruenbacher wrote: > > On Tue, Aug 3, 2021 at 9:45 PM Linus Torvalds > wrote: > > > > Hmm. Have you tried to figure out why that "still returns 0&qu

Re: [Cluster-devel] [PATCH v5 00/12] gfs2: Fix mmap + page fault deadlocks

On Tue, Aug 3, 2021 at 12:18 PM Andreas Gruenbacher wrote: > > > With this patch queue, fstest generic/208 (aio-dio-invalidate-failure.c) > endlessly spins in gfs2_file_direct_write. It looks as if there's a bug > in get_user_pages_fast when called with FOLL_FAST_ONLY: > > (1) The test case

Re: [Cluster-devel] [PATCH v5 03/12] Turn fault_in_pages_{readable, writeable} into fault_in_{readable, writeable}

On Tue, Aug 3, 2021 at 12:18 PM Andreas Gruenbacher wrote: > > Turn fault_in_pages_{readable,writeable} into versions that return the number > of bytes faulted in instead of returning a non-zero value when any of the > requested pages couldn't be faulted in. Ugh. This ends up making most users

Re: [Cluster-devel] [PATCH v4 1/8] iov_iter: Introduce iov_iter_fault_in_writeable helper

On Tue, Jul 27, 2021 at 4:14 AM Andreas Gruenbacher wrote: > > On Tue, Jul 27, 2021 at 11:30 AM David Laight wrote: > > > > Is it actually worth doing any more than ensuring the first byte > > of the buffer is paged in before entering the block that has > > to disable page faults? > > We

Re: [Cluster-devel] [PATCH v3 1/7] iov_iter: Introduce fault_in_iov_iter helper

On Mon, Jul 26, 2021 at 9:33 AM Jan Kara wrote: > > On Fri 23-07-21 22:58:34, Andreas Gruenbacher wrote: > > + gup_flags = FOLL_TOUCH | FOLL_POPULATE; > > I don't think FOLL_POPULATE makes sense here. It makes sense only with > FOLL_MLOCK and determines whether mlock(2) should fault in

Re: [Cluster-devel] [PATCH v4 1/8] iov_iter: Introduce iov_iter_fault_in_writeable helper

On Sat, Jul 24, 2021 at 1:26 PM Al Viro wrote: > > On Sat, Jul 24, 2021 at 12:52:34PM -0700, Linus Torvalds wrote: > > > So I think the code needs to return 0 if _any_ fault was successful. > > s/any/the first/... Yes, but as long as we do them in order, and stop when it fa

Re: [Cluster-devel] [PATCH v4 1/8] iov_iter: Introduce iov_iter_fault_in_writeable helper

On Sat, Jul 24, 2021 at 12:35 PM Andreas Gruenbacher wrote: > > +int iov_iter_fault_in_writeable(const struct iov_iter *i, size_t bytes) > +{ ... > + if (fault_in_user_pages(start, len, true) != len) > + return -EFAULT; Looking at this once

Re: [Cluster-devel] [PATCH v3 1/7] iov_iter: Introduce fault_in_iov_iter helper

On Fri, Jul 23, 2021 at 1:58 PM Andreas Gruenbacher wrote: > > Introduce a new fault_in_iov_iter helper for manually faulting in an iterator. > Other than fault_in_pages_writeable(), this function is non-destructive. Again, as I pointed out in the previous version, "Other than" is not sensible

Re: [Cluster-devel] [PATCH v2 0/6] gfs2: Fix mmap + page fault deadlocks

On Sun, Jul 18, 2021 at 3:39 PM Andreas Gruenbacher wrote: > > here's an update to the gfs2 mmap + page faults fix that implements > Linus's suggestion of disabling page faults while we're holding the > inode glock. Apart from some wording/naming issues, I think this looks a _lot_ better, and

Re: [Cluster-devel] [PATCH v2 5/6] iov_iter: Introduce ITER_FLAG_FAST_ONLY flag

On Sun, Jul 18, 2021 at 3:40 PM Andreas Gruenbacher wrote: > > Introduce a new ITER_FLAG_FAST_ONLY flag I think the code is fine, but I think it might be best to call this "ITER_FLAG_NOIO" or something like that. The "FAST_ONLY" name makes sense in the context of "get_user_pages_fast()" where

Re: [Cluster-devel] [PATCH v2 1/6] iov_iter: Introduce fault_in_iov_iter helper

On Sun, Jul 18, 2021 at 3:39 PM Andreas Gruenbacher wrote: > > Introduce a new fault_in_iov_iter helper for manually faulting in an iterator. > Other than fault_in_pages_writeable(), this function is non-destructive. You mean "Unlike" rather than "Other than" (also in the comment of the patch).

Re: [Cluster-devel] [PATCH] gfs2: Fix mmap + page fault deadlocks

On Thu, Jul 1, 2021 at 5:20 PM Andreas Gruenbacher wrote: > > On Thu, Jul 1, 2021 at 11:41 PM Linus Torvalds > wrote: > > Also, I have to say that I think the direct-IO code is fundamentally > > mis-designed. Why it is doing the page lookup _during_ the IO is a > >

Re: [Cluster-devel] [PATCH] gfs2: Fix mmap + page fault deadlocks

On Thu, Jul 1, 2021 at 5:30 PM Linus Torvalds wrote: > > > Of course, if you ask for more data than the file has, that's another > thing, but who really does that with direct-IO? And if they do, why > should we care about their silly behavior? Now, if the issue is that people d

Re: [Cluster-devel] [PATCH] gfs2: Fix mmap + page fault deadlocks

On Thu, Jul 1, 2021 at 2:41 PM Linus Torvalds wrote: > > So what the direct-IO code _should_ do is to turn an ITER_IOVEC into a > ITER_KVEC by doing the page lookup ahead of time Actually, an ITER_BVEC, not ITER_KVEC. It wants a page array, not a kernel pointer array. But I ho

Re: [Cluster-devel] [PATCH] gfs2: Fix mmap + page fault deadlocks

On Thu, Jul 1, 2021 at 1:43 PM Andreas Gruenbacher wrote: > > here's another attempt at fixing the mmap + page fault deadlocks we're > seeing on gfs2. Still not ideal because get_user_pages_fast ignores the > current->pagefault_disabled flag Of course get_user_pages_fast() ignores the

Re: [Cluster-devel] [RFC 5/9] iov_iter: Add iov_iter_fault_in_writeable()

On Sat, Jun 12, 2021 at 2:47 PM Al Viro wrote: > > O_DIRECT case is a PITA - there we use GUP and there's no way > to tell GUP that in the current situation we do *NOT* want to hit > ->fault()/->page_mkwrite()/etc. pagefault_disable() won't be even > noticed there... Well, we could

Re: [Cluster-devel] [RFC 5/9] iov_iter: Add iov_iter_fault_in_writeable()

On Sat, Jun 12, 2021 at 2:12 PM Al Viro wrote: > > Actually, is there any good way to make sure that write fault is triggered > _without_ modification of the data? On x86 lock xadd (of 0, that is) would > probably do it and some of the other architectures could probably get away > with using

Re: [Cluster-devel] [RFC 4/9] gfs2: Fix mmap + page fault deadlocks (part 1)

On Mon, May 31, 2021 at 7:01 AM Andreas Gruenbacher wrote: > > Fix that by recognizing the self-recursion case. Hmm. I get the feeling that the self-recursion case should never have been allowed to happen in the first place. IOW, is there some reason why you can't make the user accesses always

Re: [Cluster-devel] [RFC 9/9] gfs2: Fix mmap + page fault deadlocks (part 2)

On Mon, May 31, 2021 at 7:02 AM Andreas Gruenbacher wrote: > > @@ -807,13 +824,20 @@ static ssize_t gfs2_file_direct_read(struct kiocb > *iocb, struct iov_iter *to, > [...] > ret = iomap_dio_rw(iocb, to, _iomap_ops, NULL, 0); > gfs2_glock_dq(gh); > + if

Re: [Cluster-devel] [RFC 0/9] gfs2: handle page faults during read and write

Sorry, I'm on a boat right now, with only a cellphone. Which is why this html mess email, and quick reply. Due to the html, this may get a bounce from the mailing list, and only make it to the personal email recipients. Feel free to quote more just in case others didn't get my original email

Re: [Cluster-devel] [GIT PULL] gfs2 fixes for v5.13-rc5

[ Adding fsdevel, because this is not limited to gfs2 ] On Mon, May 31, 2021 at 12:56 AM Andreas Gruenbacher wrote: > > Andreas Gruenbacher (2): > gfs2: Fix mmap locking for write faults This is bogus. I've pulled it, but this is just wrong. A write fault on a mmap IS NOT A WRITE to the

Re: [Cluster-devel] GFS2 changes for the 5.7 merge window

On Tue, Mar 31, 2020 at 9:41 AM Bob Peterson wrote: > > Could you please pull the following changes for gfs2? So I've pulled it, but I note that you didn't get the automated notification of that like almost everybody else does. The reason seems to be pretty simple: the pr-tracker-bot looks for

Re: [Cluster-devel] [GIT PULL] iomap: small cleanups for 5.5

On Tue, Dec 3, 2019 at 8:09 AM Darrick J. Wong wrote: > Please pull this series containing some more new iomap code for 5.5. > There's not much this time -- just removing some local variables that > don't need to exist in the iomap directio code. Hmm. The tag message (which was also in the email

Re: [Cluster-devel] [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read

On Wed, Nov 27, 2019 at 7:42 AM Steven Whitehouse wrote: > > I'll leave the finer details to Andreas here, since it is his patch, and > hopefully we can figure out a good path forward. As mentioned, I don't _hate_ that patch (ok, I seem to have typoed it and said that I don't "gate" it ;), so if

Re: [Cluster-devel] [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read

On Mon, Nov 25, 2019 at 2:53 AM Steven Whitehouse wrote: > > Linus, is that roughly what you were thinking of? So the concept looks ok, but I don't really like the new flags as they seem to be gfs2-specific rather than generic. That said, I don't _gate_ them either, since they aren't in any

Re: [Cluster-devel] [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read

On Wed, Oct 30, 2019 at 11:35 AM Steven Whitehouse wrote: > > NFS may be ok here, but it will break GFS2. There may be others too... > OCFS2 is likely one. Not sure about CIFS either. Does it really matter > that we might occasionally allocate a page and then free it again? Why are gfs2 and cifs

Re: [Cluster-devel] [GIT PULL] gfs2 changes

On Sat, Sep 21, 2019 at 9:51 AM Andreas Gruenbacher wrote: > > please consider pulling the following changes for gfs2. Merged. But I notice that you're not getting any pr-tracker replies. I'd suggest you cc lkml to get the automatic notification in case you care, Linus

Re: [GIT PULL] iomap: new code for 5.4

On Thu, Sep 19, 2019 at 10:07 AM Christoph Hellwig wrote: > > I personally surived with it, but really hated writing the open coded > list_for_each_entry + list_del or while list_first_entry_or_null + > ┐ist_del when I could have a nice primitive for it. I finally decided > to just add that

Re: [GIT PULL] iomap: new code for 5.4

On Thu, Sep 19, 2019 at 10:03 AM Linus Torvalds wrote: > > So inside of xfs, that "pop ioend from the list" model really may make > perfect sense, and you could just do > > static inline struct xfs_ioend *xfs_pop_ioend(struct list_head *head) Note that as usual, my

Re: [Cluster-devel] [GIT PULL] iomap: new code for 5.4

On Wed, Sep 18, 2019 at 8:45 PM Darrick J. Wong wrote: > > I propose the following (assuming Linus isn't cranky enough to refuse > the entire iomap patchpile forever): Since I don't think the code was _wrong_, it was just that I didn't want to introduce a new pattern for something we already

Re: [Cluster-devel] [GIT PULL] iomap: new code for 5.4

On Wed, Sep 18, 2019 at 6:31 PM Linus Torvalds wrote: > > Why would anybody use that odd "list_pop()" thing in a loop, when what > it really seems to just want is that bog-standard > "list_for_each_entry_safe()" Side note: I do agree that the list_for_each_

Re: [GIT PULL] iomap: new code for 5.4

On Tue, Sep 17, 2019 at 8:21 AM Darrick J. Wong wrote: > > Please pull this series containing all the new iomap code for 5.4. So looking at the non-iomap parts of it, I react to the new "list_pop() code. In particular, this: struct list_head *pos = READ_ONCE(list->next); is crazy to

Re: [Cluster-devel] [PATCH] gfs2: Fix error path kobject memory leak

On Mon, May 13, 2019 at 3:37 PM Andreas Gruenbacher wrote: > > Sorry, I should have been more explicit. Would you mind taking this > patch, please? If it's more convenient or more appropriate, I'll send > a pull request instead. Done. However,I'd like to point out that when I see patches from

Re: [PATCH] gfs2: Fix error path kobject memory leak

Andreas, did you intend for me to take this as a patch from the email, or will I get a pull request with this later? Linus

Re: [Cluster-devel] GFS2: Pull Request

On Wed, May 8, 2019 at 1:58 PM Jonathan Corbet wrote: > > I think this certainly belongs in the maintainer manual, but probably not > in pull-requests.rst. There are a lot of things about repository > management that seem to trip up even experienced maintainers; pre-pull > merges is just one of

Re: [Cluster-devel] GFS2: Pull Request

On Wed, May 8, 2019 at 1:17 PM Andreas Gruenbacher wrote: > > Would it make sense to describe how to deal with merge conflicts in > Documentation/maintainer/pull-requests.rst to stop people from getting > this wrong over and over again? Probably. I do think it got written up at some point (lwn

Re: [Cluster-devel] GFS2: Pull Request

On Wed, May 8, 2019 at 10:55 AM Linus Torvalds wrote: > > See what I'm saying? You would ask me to pull the un-merged state, but > then say "I noticed a few merge conflicts when I did my test merge, > and this is what I did" kind of aside. Side note: this is more important

Re: [Cluster-devel] GFS2: Pull Request

On Wed, May 8, 2019 at 4:49 AM Andreas Gruenbacher wrote: > > There was a conflict with commit 2b070cfe582b ("block: remove the i > argument to bio_for_each_segment_all") on Jens's block layer changes > which you've already merged. I've resolved that by merging those block > layer changes; please

Re: [Cluster-devel] [PATCH] gfs2: Revert "Fix loop in gfs2_rbm_find"

On Thu, Jan 31, 2019 at 11:12 AM Andreas Gruenbacher wrote: > > That patch just hasn't seen enough testing to make me comfortable > sending it yet. Ok, I'll just apply the revert. Thanks, Linus

Re: [Cluster-devel] [PATCH] gfs2: Revert "Fix loop in gfs2_rbm_find"

On Wed, Jan 30, 2019 at 12:30 PM Andreas Gruenbacher wrote: > > This reverts commit 2d29f6b96d8f80322ed2dd895bca590491c38d34. > > It turns out that the fix can lead to a ~20 percent performance regression > in initial writes to the page cache according to iozone. Let's revert this > for now to

Re: [Cluster-devel] [GIT PULL] gfs2: 4.20 fixes

On Thu, Nov 15, 2018 at 2:44 PM Andreas Gruenbacher wrote: > > Ok, I've changed the merge commit as follows now: > > Merge tag 'v4.20-rc1' > > Pull in the gfs2 fixes that went into v4.19-rc8: > > gfs2: Fix iomap buffered write support for journaled files > gfs2: Fix iomap

Re: [Cluster-devel] [GIT PULL] gfs2: 4.20 fixes

On Thu, Nov 15, 2018 at 12:20 PM Andreas Gruenbacher wrote: > > I guess rebasing the for-next branch onto something more recent to > avoid the back-merge in the first place will be best, resulting in a > cleaner history. Rebases aren't really any better at all. If you have a real *reason* for a

Re: [Cluster-devel] [GIT PULL] gfs2: 4.20 fixes

On Thu, Nov 15, 2018 at 6:00 AM Andreas Gruenbacher wrote: > > could you please pull the following gfs2 fixes for 4.20? No. I'm not pulling this useless commit message: "Merge tag 'v4.20-rc1'" with absolutely _zero_ explanation for why that merge was done. Guys, stop doing this. Because I

Re: [Cluster-devel] GFS2: Pull request (merge window)

On Tue, Oct 23, 2018 at 8:26 PM Bob Peterson wrote: > > Please consider pulling the following changes for the GFS2 file system. Pulled. Just FYI - I end up editing your notes to look a bit more like most other people send them. No need to change anything, I just thought I'd mention it.

Re: [Cluster-devel] GFS2: Pull request (merge window)

On Fri, May 5, 2017 at 1:28 PM, Bob Peterson wrote: > > I asked around, but nobody could tell me what went wrong. Strangely, > this command: > > git log --oneline --right-only origin/master...FETCH_HEAD --stat > > doesn't show this, but this one does: > > git diff --stat

Re: [Cluster-devel] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Thu, Jun 9, 2016 at 1:38 PM, Deepa Dinamani wrote: > > 1. There are a few link, rename functions which assign times like this: > > - inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME; > + inode->i_ctime = dir->i_ctime = dir->i_mtime = >

Re: [Cluster-devel] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Wed, Jun 8, 2016 at 10:04 PM, Deepa Dinamani wrote: > CURRENT_TIME macro is not appropriate for filesystems as it > doesn't use the right granularity for filesystem timestamps. > Use current_fs_time() instead. Again - using the inode instead fo the syuperblock in tghis

Re: [Cluster-devel] GFS2: Pull request (merge window)

On Tue, Apr 14, 2015 at 10:47 AM, Bob Peterson rpete...@redhat.com wrote: There's another that adds me as a GFS2 co-maintainer [...] So generally, when I start getting pull requests from different people, I'd like to see a previous separate heads-up or confirmation from the previous person just

Re: [Cluster-devel] GFS2: Pull request (merge window)

On Tue, Apr 14, 2015 at 10:47 AM, Bob Peterson rpete...@redhat.com wrote: 12 files changed, 184 insertions(+), 95 deletions(-) Oh, and this was incorrect. You had apparently limited the statistics to the fs/gfs2 directory, and thus missed the changes to the MAINTAINERS file. Don't do that -

Re: [Cluster-devel] GFS2: Pull request (fixes)

On Mon, Aug 19, 2013 at 2:26 AM, Steven Whitehouse swhit...@redhat.com wrote: Oops, forgot to sign this when I sent it first, so here is a signed copy of it. Please sign the git tag instead of the email. There are no sane tools to check email signatures etc, but git signed tags not only check

Re: [Cluster-devel] [patch for-3.8] fs, dlm: fix build error when EXPERIMENTAL is disabled

On Tue, Feb 12, 2013 at 1:50 AM, Steven Whitehouse swhit...@redhat.com wrote: That doesn't seem right to me... DLM has not been experimental for a long time now. Why not just select CRC32 in addition to IP_SCTP ? Hmm. IP_SCTP already does a select libcrc32c. So why doesn't that end up working?

Re: [Cluster-devel] GFS2: Pull request (merge window)

On Fri, Aug 3, 2012 at 3:18 AM, Steven Whitehouse swhit...@redhat.com wrote: I've been writing summaries when I send out the pre-pull patch posting so I could just copy paste from that if it thats the kind of thing that you are after? https://lkml.org/lkml/2012/7/23/59 Yup, exactly

Re: [Cluster-devel] GFS2: Pull request (merge window)

[ For some reason this didn't go out, and was in my drafts folder. Better late than never, I guess ] On Mon, Jul 23, 2012 at 7:59 AM, Steven Whitehouse swhit...@redhat.com wrote: Please consider pulling the following patches. There have been no changes since they were posted for review, It

Re: [Cluster-devel] GFS2: Use kmalloc when possible for -readdir()

On Wed, Jul 28, 2010 at 4:15 AM, Steven Whitehouse swhit...@redhat.com wrote: We may be able to eliminate vmalloc entirely at some stage, but this is easy to do right away. Quite frankly, I'd much rather see this abstracted out a bit. Why not just do a void *memalloc(unsigned int size) {

[Cluster-devel] Re: [PATCH] SLOW_WORK: Move slow_work's proc file to debugfs

On Tue, 1 Dec 2009, Ingo Molnar wrote: Nice - thanks for doing this so quickly! It might sound like nitpicking but /proc ABIs tend to be a lot harder to get rid of than debugfs interfaces. Ok, I applied it, so we'll not switch interfaces (even if they are just for debugging) across

  1   2   >