On 2021-02-27 22:29, Warner Losh wrote:
> On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov wrote:
>
> > >
> > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add
> > > any security, except imaginary? The only purpose of it is to have a
> > > check-list item ticked green.
> >
>
On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov wrote:
> >
> > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add
> > any security, except imaginary? The only purpose of it is to have a
> > check-list item ticked green.
>
> I don't know if I should parse this as sarcasm (or any
>
> But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add
> any security, except imaginary? The only purpose of it is to have a
> check-list item ticked green.
I don't know if I should parse this as sarcasm (or any other form of
"humor") or is a serious statement? But this does
On Fri, Feb 26, 2021 at 08:32:26PM +0100, Gordon Bergling wrote:
> On Fri, Feb 26, 2021 at 08:57:55PM +0200, Konstantin Belousov wrote:
> > On Fri, Feb 26, 2021 at 07:34:03PM +0100, Gordon Bergling wrote:
> > > On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote:
> > > > As of 9a227a2fd642 (ma
Thanks. I adjusted the namecache. However, the nfs fix provided by
Rick should go in regardless.
On 2/27/21, Juraj Lutter wrote:
>
>
>> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote:
>>
>> Can you dump 'struct componentname *cnp'? This should do the trick:
>> f 12
>> p cnp
>>
>> Most notably I w
> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote:
>
> Can you dump 'struct componentname *cnp'? This should do the trick:
> f 12
> p cnp
>
> Most notably I want to know if the name to added is a literal dot.
>
Yes, it is a dot (the directory itself):
cn_nameptr = 0xfe0011428018 ".", cn_
You should be able to just use kgdb on the old kernel and the
crashdump you already collected, provided both are still around.
Alternatively boot with this without the fix:
diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c
index fef1e31d197b..c4d2990b155d 100644
--- a/sys/kern/vfs_cache.c
+
I am now running a patched kernel, without problems.
I can boot to unpatched one and see the output of these ddb commands.
otis
—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576
> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote:
>
> Can you dump 'struct componentname *cnp'? This shou
Can you dump 'struct componentname *cnp'? This should do the trick:
f 12
p cnp
Most notably I want to know if the name to added is a literal dot.
That case is handled if necessary, but the assert was added to start
making the interface stricter. If the name is a dot I'll be inclined
to remove the
I’ve got some LORs:
lock order reversal:
1st 0xf8008c4f4af0 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1071
2nd 0xf8008c51a930 zfs (zfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1083
lock order zfs -> nfs established at:
#0 0x80c7bb7d at witness_checkorder+0x46d
#1 0x
Hi,
thank you for the swift reaction. This patch fixed my problem.
otis
—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576
> On 27 Feb 2021, at 16:53, Rick Macklem wrote:
>
> I reproduced the problem and the attached trivial patch
> seems to fix it. Please test the patch if you can.
On 16/02/2021 22:38, Mateusz Guzik wrote:
> I think for future proofing it would be best if all vnodes going there
> had seqc marked, thus I think this should do the trick:
>
> diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
> b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_v
I reproduced the problem and the attached trivial patch
seems to fix it. Please test the patch if you can.
Mateusz, I assume the directory shouldn't try and add
a cache entry for itself?
I don't test NFSv3 much and I don't test "rdirplus"
much, so it slipped through the cracks.
Thanks for reporti
On Sat, Feb 27, 2021 at 7:10 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:
> > On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes <
> > freebsd-...@gndrsh.dnsmgr.net> wrote:
> >
> > > > My understanding is that KTLS works very well with OpenSSL for
> sending,
> > > but
> > > > not as w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The fourth BETA build of the 13.0-RELEASE release cycle is now available.
Installation images are available for:
o 13.0-BETA4 amd64 GENERIC
o 13.0-BETA4 i386 GENERIC
o 13.0-BETA4 powerpc GENERIC
o 13.0-BETA4 powerpc64 GENERIC64
o 13.0-BETA4 powerpc
And a kgdb backtrace:
(kgdb) bt
#0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0x804c7b2a in db_dump (dummy=, dummy2=,
dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575
#3 0x
Reliably reproducible:
VNASSERT failed: dvp != vp not true at /usr/src/sys/kern/vfs_cache.c:2269
(cache_enter_time)
0xf80079321e00: type VDIR
usecount 4, writecount 0, refcount 3 seqc users 0 mountedhere 0
hold count flags ()
flags (VV_ROOT|VV_VMSIZEVNLOCK)
v_object 0xf801
> On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
>
> > > My understanding is that KTLS works very well with OpenSSL for sending,
> > but
> > > not as well for receiving, because there's nothing like a recvfile
> > > syscall. However, it works great for
- poudriere data stored on NFS
- NFS server 12-STABLE
- NFS client (that panicked) 14-CURRENT
- Panic string:
condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269
(cache_enter_time)
backtrace:
Tracing pid 27294 tid 100893 td 0xfe00ea1a3500
kdb_enter() at kdb_enter+0x37/frame 0x
Great. Committed as c01da939b0998f8de068a23c9016c377e761255e. As you might
have guessed, I don't have a current cardbus system, though I need to bring
one up to finish the removal of PC Card support.
Warner
On Sat, Feb 27, 2021 at 1:13 AM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
>
That fixes the problem. Thanks for the quick response.
--
steve
On Sat, Feb 27, 2021 at 12:02:54AM -0700, Warner Losh wrote:
> What does https://reviews.freebsd.org/D28963 do for you?
>
> Warner
>
> On Fri, Feb 26, 2021 at 9:48 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
>
21 matches
Mail list logo