> This is PR 39918
Oh no, I hit a known bug! Sorry for wasting everybody's time. I was hoping to
find an unknown problem.
> You could test this hypothesis by explicitly writing
> `if (fp->f_count != 0) panic("...")' there.
I preferred to apply the fix with a printf() in front.
Thanks a lot for
> Date: Mon, 13 Aug 2018 14:19:42 +
> From: Taylor R Campbell
>
> If you are running with DIAGNOSTIC off, then KASSERT(fp->f_count != 0)
> in unp_gc in netbsd-6 will never panic; instead it may attempt to
> regain a reference too late to a socket file that another thread is in
> the process
> Date: Mon, 13 Aug 2018 12:05:10 +
> From: Taylor R Campbell
>
> > Date: Sun, 12 Aug 2018 20:59:07 +0200
> > From: Edgar Fuß
> >
> > OK, I hit my new panic in soput(). The call chain is
> > breakpoint<-vpanic<-printf_nolog<-soqinsque<-soclose<-soo_close<-closef<-fd_close<-syscall.
>
>
> Date: Sun, 12 Aug 2018 20:59:07 +0200
> From: Edgar Fuß
>
> OK, I hit my new panic in soput(). The call chain is
> breakpoint<-vpanic<-printf_nolog<-soqinsque<-soclose<-soo_close<-closef<-fd_close<-syscall.
That's weird. soclose doesn't call soqinsque.
I don't have a hypothesis for how the
> The unp_gc thread assumes that holding a reference to the associated
> struct file, by incrementing f_count, prevents the socket from being
> freed. Certainly that prevents closef from calling fo_close, which
> for a socket is soo_close, which calls soclose, which calls sofree,
> which calls
> Are you sure it _only_ happens in the do/while and _never_ in the
> preceding if?
No, I'm not sure.
> In any case, it's just a diagnostic, not a protocol for a robust
> software system to rely on. If it doesn't work, can try another one.
OK, I hit my new panic in soput(). The call chain is
Date:Fri, 10 Aug 2018 19:17:55 -0400 (EDT)
From:Mouse
Message-ID: <201808102317.taa24...@stone.rodents-montreal.org>
| However, whether it means "nyah nyah, I'm not telling you this" or
| "don't worry, this won't be on the exam"
Not either I would think - the
>> | Ancient BSD tradition is not to explain these things :-(
>> Older than that. Don't you remember
>> you are not expected to understand this
>> (or wording very similar) in ancient 4th/5th edition unix.
> The explanation for that comment I've read somewhere was that it
> really meant
> Are you sure it _only_ happens in the do/while and _never_ in the
> preceding if?
Well, the three times I looked at the backtrace carefully, yes (I have photos).
The next two or three times, I'm not completely sure.
> In any case, it's just a diagnostic, not a protocol for a robust
> software
On Sat, Aug 11, 2018 at 00:46:26 +0700, Robert Elz wrote:
> Date:Fri, 10 Aug 2018 08:03:55 -0400
> From:Greg Troxel
> Message-ID:
>
> | Ancient BSD tradition is not to explain these things :-(
>
> Older than that. Don't you remember
> you are not
> Date: Fri, 10 Aug 2018 19:48:40 +0200
> From: Edgar Fuß
>
> > Yes -- isn't that the symptom you're seeing, or did I miss something?
> It's the mutex_oncpu in the while condition that crashes, not the on in the
> if condition above the do.
Are you sure it _only_ happens in the do/while and
> Yes -- isn't that the symptom you're seeing, or did I miss something?
It's the mutex_oncpu in the while condition that crashes, not the on in the
if condition above the do.
> It doesn't really matter since (a) only one thread ever sets the
> variable, (b) there are no invariants around it, and
Date:Fri, 10 Aug 2018 08:03:55 -0400
From:Greg Troxel
Message-ID:
| Ancient BSD tradition is not to explain these things :-(
Older than that. Don't you remember
you are not expected to understand this
(or wording very similar) in ancient 4th/5th edition
> Date: Fri, 10 Aug 2018 19:05:28 +0200
> From: Edgar Fuß
>
> > More likely is that the socket is prematurely freed before unp_gc
> > grabs it at all.
> But then the mutex_oncpu() in the if above the do...while would panic, no?
Yes -- isn't that the symptom you're seeing, or did I miss
> More likely is that the socket is prematurely freed before unp_gc
> grabs it at all.
But then the mutex_oncpu() in the if above the do...while would panic, no?
> You could do something like create a global variable that stores the
> socket pointer that unp_gc is currently working on, shortly
> Date: Fri, 10 Aug 2018 17:51:11 +0200
> From: Edgar Fuß
>
> I'm currently running an 8.0_STABLE kernel on the machine (with 6.1_STABLE
> userland) and no panics so far. This smay be
> -- luck
> -- different timing that doesn't trigger the race
> -- a bug fixed since 6.1
>
> If someone
Thank you both for the detailed explanations and audits!
I'm currently running an 8.0_STABLE kernel on the machine (with 6.1_STABLE
userland) and no panics so far. This smay be
-- luck
-- different timing that doesn't trigger the race
-- a bug fixed since 6.1
If someone remembers a bug in this
> Date: Fri, 10 Aug 2018 08:03:55 -0400
> From: Greg Troxel
>
> Edgar Fuà writes:
>
> > Is there a general scheme/rule/proposal how to prevent a mutex that someone
> > is trying to mutex_enter() from being teared down by someone else calling
> > mutex_destroy() on it during that?
>
> Not
Edgar Fuß writes:
> I know very little about locking so that's probably a stupid question, but:
Don't worry - locking is probably the hardest thing to get right.
> Is there a general scheme/rule/proposal how to prevent a mutex that someone
> is trying to mutex_enter() from being teared down
I know very little about locking so that's probably a stupid question, but:
Is there a general scheme/rule/proposal how to prevent a mutex that someone
is trying to mutex_enter() from being teared down by someone else calling
mutex_destroy() on it during that?
Specifically, I'm trying to
20 matches
Mail list logo
