On Wed, 29 May 2024, Trond Myklebust wrote:
> On Tue, 2024-05-28 at 11:19 +1000, NeilBrown wrote:
> > On Tue, 28 May 2024, Trond Myklebust wrote:
> > > On Mon, 2024-05-27 at 13:04 +1000, NeilBrown wrote:
> > > >
> > > > dentry->d_fsdata
unblock_revalidate().
Reported-and-tested-by: Richard Kojedzinszky
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501
Fixes: 3c59366c207e ("NFS: don't unhash dentry during unlink/rename")
Signed-off-by: NeilBrown
---
fs/nfs/dir.c | 47 ---
On Tue, 28 May 2024, Trond Myklebust wrote:
> On Mon, 2024-05-27 at 13:04 +1000, NeilBrown wrote:
> >
> > dentry->d_fsdata is set to NFS_FSDATA_BLOCKED while unlinking or
> > renaming-over a file to ensure that no open succeeds while the NFS
> > oper
suggests that arm64 does need barriers some
times.
I don't have arm64 hardware to test on but I'm happy with your
test results.
Thanks,
NeilBrown
>
> Regards,
> Richard
>
>
> On May 27, 2024 4:02:32 AM GMT+02:00, NeilBrown wrote:
>
> On Sun, 26 May 2024, Richard Kojedz
unblock_revalidate().
Reported-and-tested-by: Richard Kojedzinszky
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501
Fixes: 3c59366c207e ("NFS: don't unhash dentry during unlink/rename")
Signed-off-by: NeilBrown
---
fs/nfs/dir.c | 44 +---
ve made some cosmetic improvements to the patch and will post it to
the NFS maintainers.
Thanks again,
NeilBrown
>
> Thanks,
> Richard
>
> 2024-05-24 07:29 időpontban Richard Kojedzinszky ezt írta:
> > Dear Neil,
> >
> > I've applied your patch, and since t
and a list of package
dependencies that I need to install (on Debian), I can give it a try.
Or you could try this patch. It might help, but I don't have high
hopes. It adds some memory barriers and fixes a bug which would cause a
problem if memory allocation failed (but memory allocation nev
,
and then fail the mount. That would happen if, for example, rpc.mountd
wasn't running.
So I think these failures are caused by some problem with restarting the
services and aren't actually testing the code at all.
Could you try again and make sure rpcbind and rpc.mountd are running on
the server before attempting the mount?
Thanks,
NeilBrown
in Debian (with the
>>>admin choosing) or is it an "xor"?
>>>
>
> I think there are two questions:
>
> a) can they both exist in different packages that conflict with each
> other? I'm guessing that will probably be yes.
>
> b) can they both be
On Wed, 24 Jul 2013 04:02:15 +0100 Ben Hutchings b...@decadent.org.uk wrote:
Neil, does the report below sound like the bug you fixed with:
commit 7bb23c4934059c64cbee2e41d5d24ce122285176
Author: NeilBrown ne...@suse.de
Date: Tue Jul 16 16:50:47 2013 +1000
md/raid10: fix two
the following versions: 3.8-rc5, 3.7.5, 3.4.28,
3.2.37, 3.0.61, 2.6.34.14 and 2.6.32.60.
Cheers,
Sebastian
Thanks!
I've added Cc: sta...@vger.kernel.org and will forward it to Linus shortly.
NeilBrown
signature.asc
Description: PGP signature
On Mon, 7 Jan 2013 13:34:05 +0100 (CET) bug556...@arcor.de wrote:
Hello,
thanks for responding.
NeilBrown:
The upstream bug tracker is
mailto:linux-r...@vger.kernel.org
Well ok, though a regular mailinglist makes it rather hard to get an overview
for non-devs,
and reporting
md do the extra buffering and splitting
that you suggest.
Maybe the best interim fix is to reject the added device is its limits are
too low.
NeilBrown
Note: This is reproducible in much more common scenarios as the
original reporter had (e.g. --add a USB (3.0 these days) drive
, instead of minutes
when running last kernel from Linus git tree, up to commit 9e85a6f.
For more information follow the thread on linux-r...@vger.kernel.org:
http://marc.info/?l=linux-raidm=134136614330049w=4
Following that link:
NeilBrown wrote:
On Mon, 2 Jul 2012 23:15:08 +0100 Jose
device to tell the layer above that something has
changed.
But these are both fairly intrusive which unclear performance/complexity
implications and no one has bothered.
NeilBrown
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
15 matches
Mail list logo
