On Tue, 13 Oct 2015, Robert Elz wrote:
After Paul's recent fixes, from what I can see, that is now true everywhere,
except in the one case in kern_exit.c where proc_lock is released
immediately before p_stat = SSTOP; It would probably be worthwhile to
reverse the order of those two operations
Date:Tue, 13 Oct 2015 02:27:47 +
From:Taylor R Campbell
Message-ID: <20151013022635.578f560...@jupiter.mumble.net>
| (a) The protocol is that under proc_lock but *not* p->p_lock, p_waited
| must be written before p_stat, and p_stat must be read before
| p_w
Date:Tue, 13 Oct 2015 02:27:47 +
From:Taylor R Campbell
Message-ID: <20151013022635.578f560...@jupiter.mumble.net>
| In this case, and generally[*], you need a membar_consumer matching
| the membar_producer in order for the latter to have any useful effect.
O
Date: Tue, 13 Oct 2015 08:42:55 +0700
From: Robert Elz
The code is (pre fix) ...
p->p_waited = 0;
membar_producer();
p->p_stat = SSTOP;
My assumption is that the objective was to ensure that no-one would
ever see p_stat ==
On Tue, 13 Oct 2015, Robert Elz wrote:
Paul's question really amounted to, I think, whether either the fact that
proc_lock will be held while p_waited is set to 0 would make a difference
(I can't see why that would really matter) or more likely, since the code
will become
p->p
Date:Mon, 12 Oct 2015 22:25:12 +
From:Taylor R Campbell
Message-ID: <2015101359.e6f9f60...@jupiter.mumble.net>
| It is not clear to me why it was needed in the first place,
The code is (pre fix) ...
p->p_waited = 0;
membar_p
On Mon, 12 Oct 2015, Taylor R Campbell wrote:
In kern/kern_exit.c at (original) line 231, there's a call to
membar_producer(), presumably to ensure that p->p_waited is globally
visible before updating p_.p_stat (which might cause someone to look
at p->p_waited).
Now that I'm planning
Date: Sun, 11 Oct 2015 09:45:04 +0800 (PHT)
From: Paul Goyette
In kern/kern_exit.c at (original) line 231, there's a call to
membar_producer(), presumably to ensure that p->p_waited is globally
visible before updating p_.p_stat (which might cause someone to look
at p->p_waited).
Date: Sat, 10 Oct 2015 14:31:41 -0500
From: Don Lee
On Oct 10, 2015, at 10:27 AM, Taylor R Campbell
wrote:
> proc_lock may be held by another thread even if the caller is
> guaranteed not to hold it. The other thread may furthermore be
> waiting on p->p_lock, in which case a
Hi all,
I have a build machine building pkgsrc where I see some very strange
issues. The individual chroots share a read-only null-mounted base
directory with a number of tmpfs instances on top for most of the
writeable parts. Symptoms of the some data corruption or race
conditions:
(1) checksum f
10 matches
Mail list logo
