Re: r314708: panic: tdsendsignal: ksi on queue
On Fri, Mar 10, 2017 at 12:11:51AM +0100, Jilles Tjoelker wrote:
> This patch introduces a subtle correctness bug. A real SIGCHLD ksiginfo
> should always be the zombie's p_ksi; otherwise, the siginfo may be lost
> if there are too many signals pending for the target process or in the
> system. If the siginfo is lost and the reaper normally passes si_pid to
> waitpid() or similar (instead of passing WAIT_ANY or P_ALL), a zombie
> will remain until the reaper terminates.
>
> Conceptually the siginfo is sent to one process at a time only, so the
> bug is an artifact of the implementation. Perhaps the piece of code
> added in r309886 can be moved or the ksiginfo can be removed from the
> parent's queue.
>
> If such a fix is not possible, it may be better to send a bare SIGCHLD
> (si_code is SI_KERNEL or 0, depending on how many signals are pending)
> in this situation and document that reapers must use WAIT_ANY or P_ALL.
> (However, compared to the pre-r309886 situation they can still use
> SIGCHLD to get notified when to call waitpid() or similar.)
>
IMO it is acceptable for reaper to know and handle the case of lost
siginfo. But also it seems to be not too hard to guarantee the queueing
of the SIGCHLD for zombie re-parerning.
diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c
index c524fe5df37..1a1dcc3a4c7 100644
--- a/sys/kern/kern_exit.c
+++ b/sys/kern/kern_exit.c
@@ -189,6 +189,7 @@ exit1(struct thread *td, int rval, int signo)
{
struct proc *p, *nq, *q, *t;
struct thread *tdt;
+ ksiginfo_t *ksi, *ksi1;
mtx_assert(&Giant, MA_NOTOWNED);
KASSERT(rval == 0 || signo == 0, ("exit1 rv %d sig %d", rval, signo));
@@ -449,14 +450,23 @@ exit1(struct thread *td, int rval, int signo)
wakeup(q->p_reaper);
for (; q != NULL; q = nq) {
nq = LIST_NEXT(q, p_sibling);
+ ksi = ksiginfo_alloc(TRUE);
PROC_LOCK(q);
q->p_sigparent = SIGCHLD;
if (!(q->p_flag & P_TRACED)) {
proc_reparent(q, q->p_reaper);
if (q->p_state == PRS_ZOMBIE) {
+ if (q->p_ksi == NULL) {
+ ksi1 = NULL;
+ } else {
+ ksiginfo_copy(q->p_ksi, ksi);
+ ksi->ksi_flags |= KSI_INS;
+ ksi1 = ksi;
+ ksi = NULL;
+ }
PROC_LOCK(q->p_reaper);
- pksignal(q->p_reaper, SIGCHLD, q->p_ksi);
+ pksignal(q->p_reaper, SIGCHLD, ksi1);
PROC_UNLOCK(q->p_reaper);
}
} else {
@@ -489,6 +499,8 @@ exit1(struct thread *td, int rval, int signo)
kern_psignal(q, SIGKILL);
}
PROC_UNLOCK(q);
+ if (ksi != NULL)
+ ksiginfo_free(ksi);
}
/*
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: smp_rendezvous_action: Are atomics correctly used ?
Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a écrit : > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=annotat > > > > e#l1 > > > > 080> > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > Hello, > > > > > > > > > > I'm curently reading the code of the function smp_rendezvous_action, > > > > > in > > > > > kern/subr_smp.c file. In that function, i see that the variable > > > > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > te#l > > > > > 412 > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > te#l > > > > > 458 > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > te#l > > > > > 472 > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > You should provide either evidence or, at least, some reasoning > > > supporting > > > your claims. > > > > I curently have a software watchdog that triger and does a coredump. In > > the > > coredumps, I always see a CPU trying to write-lock a "rm lock". Every > > time, > > that CPU is spinning into the smp_rendezvous_action, in the first while > > loop) while the others are into the idle threads. > > > > The fact is that freeze is not clear and I start to search "exotic" causes > > to explain it. > > This sounds as the 'usual' deadlock, where some other thread owns rmlock in > read mode. I recommend you to follow the > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel > debug-deadlocks.html Just a last question, for my personnal knowledge. In ARM >= 6, for atomic acces, the code should (?) use LDREX and STREX for, I quote : "Use LDREX and STREX to implement interprocess communication in multiple-processor and shared-memory systems." (see here : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/Cihbghef.html But, in that while loop, it's a standard "LDR" that is used. Is it correct too, and why ? -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
Re: smp_rendezvous_action: Are atomics correctly used ?
On Fri, Mar 10, 2017 at 02:24:52PM +0100, Alexandre Martins wrote: > Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a ?crit : > > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=annotat > > > > > e#l1 > > > > > 080> > > > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > > Hello, > > > > > > > > > > > > I'm curently reading the code of the function smp_rendezvous_action, > > > > > > in > > > > > > kern/subr_smp.c file. In that function, i see that the variable > > > > > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > > te#l > > > > > > 412 > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > > te#l > > > > > > 458 > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > > te#l > > > > > > 472 > > > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > > > You should provide either evidence or, at least, some reasoning > > > > supporting > > > > your claims. > > > > > > I curently have a software watchdog that triger and does a coredump. In > > > the > > > coredumps, I always see a CPU trying to write-lock a "rm lock". Every > > > time, > > > that CPU is spinning into the smp_rendezvous_action, in the first while > > > loop) while the others are into the idle threads. > > > > > > The fact is that freeze is not clear and I start to search "exotic" causes > > > to explain it. > > > > This sounds as the 'usual' deadlock, where some other thread owns rmlock in > > read mode. I recommend you to follow the > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel > > debug-deadlocks.html > > Just a last question, for my personnal knowledge. > > In ARM >= 6, for atomic acces, the code should (?) use LDREX and STREX for, I > quote : "Use LDREX and STREX to implement interprocess communication in > multiple-processor and shared-memory systems." (see here : > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/Cihbghef.html > In my previous response to you, I explicitely defined what 'atomic' means when adjected to the term 'load'. The *EX instructions are used on ll/sc architectures to implement read/modify/write atomic operations, which are different from load (read) operations. > But, in that while loop, it's a standard "LDR" that is used. Is it correct > too, and why ? Which 'that while loop' ? while (atomic_load_acq_int(&smp_rv_waiters[3]) < ncpus) cpu_spinwait(); This one ? Because the semantic of the normal load + DMB barrier provides the expected semantic of atomic_load_acq(), as explained in atomic(9) and utilized by the author of the code. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: smp_rendezvous_action: Are atomics correctly used ?
Le vendredi 10 mars 2017, 15:57:16 Konstantin Belousov a écrit : > On Fri, Mar 10, 2017 at 02:24:52PM +0100, Alexandre Martins wrote: > > Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a ?crit : > > > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=ann > > > > > > otat > > > > > > e#l1 > > > > > > 080> > > > > > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > > > Hello, > > > > > > > > > > > > > > I'm curently reading the code of the function > > > > > > > smp_rendezvous_action, > > > > > > > in > > > > > > > kern/subr_smp.c file. In that function, i see that the variable > > > > > > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=an > > > > > > > nota > > > > > > > te#l > > > > > > > 412 > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=an > > > > > > > nota > > > > > > > te#l > > > > > > > 458 > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=an > > > > > > > nota > > > > > > > te#l > > > > > > > 472 > > > > > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > > > > > You should provide either evidence or, at least, some reasoning > > > > > supporting > > > > > your claims. > > > > > > > > I curently have a software watchdog that triger and does a coredump. > > > > In > > > > the > > > > coredumps, I always see a CPU trying to write-lock a "rm lock". Every > > > > time, > > > > that CPU is spinning into the smp_rendezvous_action, in the first > > > > while > > > > loop) while the others are into the idle threads. > > > > > > > > The fact is that freeze is not clear and I start to search "exotic" > > > > causes > > > > to explain it. > > > > > > This sounds as the 'usual' deadlock, where some other thread owns rmlock > > > in > > > read mode. I recommend you to follow the > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke > > > rnel debug-deadlocks.html > > > > Just a last question, for my personnal knowledge. > > > > In ARM >= 6, for atomic acces, the code should (?) use LDREX and STREX > > for, I quote : "Use LDREX and STREX to implement interprocess > > communication in multiple-processor and shared-memory systems." (see here > > : > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/Cihbg > > hef.html > In my previous response to you, I explicitely defined what 'atomic' > means when adjected to the term 'load'. The *EX instructions are used on > ll/sc architectures to implement read/modify/write atomic operations, > which are different from load (read) operations. Ok ! Because we just want to read the value, there is no need to use the *EX version. *EX is intended to be use when a modification will be done thereafter. > > > But, in that while loop, it's a standard "LDR" that is used. Is it correct > > too, and why ? > > Which 'that while loop' ? > while (atomic_load_acq_int(&smp_rv_waiters[3]) < ncpus) > cpu_spinwait(); > This one ? No, I point the one at line 412, 458 and 472: 412: while (smp_rv_waiters[0] < smp_rv_ncpus) cpu_spinwait(); 458: while (smp_rv_waiters[1] < smp_rv_ncpus) cpu_spinwait(); 472: while (smp_rv_waiters[2] < smp_rv_ncpus) cpu_spinwait(); > > Because the semantic of the normal load + DMB barrier provides the expected > semantic of atomic_load_acq(), as explained in atomic(9) and utilized by > the author of the code. So, the writer must use LDREX/STREX to modify the value and use dmb to make visible to other CPU the write. The readers can read simply the value without the barrier because cache coherancy protcol will update the value automaticaly. I think I finally got it ! Thank you so much ! Best regards, -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
Re: smp_rendezvous_action: Are atomics correctly used ?
On Fri, Mar 10, 2017 at 03:30:21PM +0100, Alexandre Martins wrote: > Le vendredi 10 mars 2017, 15:57:16 Konstantin Belousov a ?crit : > > On Fri, Mar 10, 2017 at 02:24:52PM +0100, Alexandre Martins wrote: > > > Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a ?crit : > > > > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > > > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=ann > > > > > > > otat > > > > > > > e#l1 > > > > > > > 080> > > > > > > > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > > > > Hello, > > > > > > > > > > > > > > > > I'm curently reading the code of the function > > > > > > > > smp_rendezvous_action, > > > > > > > > in > > > > > > > > kern/subr_smp.c file. In that function, i see that the variable > > > > > > > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=an > > > > > > > > nota > > > > > > > > te#l > > > > > > > > 412 > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=an > > > > > > > > nota > > > > > > > > te#l > > > > > > > > 458 > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=an > > > > > > > > nota > > > > > > > > te#l > > > > > > > > 472 > > > > > > > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > > > > > > > You should provide either evidence or, at least, some reasoning > > > > > > supporting > > > > > > your claims. > > > > > > > > > > I curently have a software watchdog that triger and does a coredump. > > > > > In > > > > > the > > > > > coredumps, I always see a CPU trying to write-lock a "rm lock". Every > > > > > time, > > > > > that CPU is spinning into the smp_rendezvous_action, in the first > > > > > while > > > > > loop) while the others are into the idle threads. > > > > > > > > > > The fact is that freeze is not clear and I start to search "exotic" > > > > > causes > > > > > to explain it. > > > > > > > > This sounds as the 'usual' deadlock, where some other thread owns rmlock > > > > in > > > > read mode. I recommend you to follow the > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke > > > > rnel debug-deadlocks.html > > > > > > Just a last question, for my personnal knowledge. > > > > > > In ARM >= 6, for atomic acces, the code should (?) use LDREX and STREX > > > for, I quote : "Use LDREX and STREX to implement interprocess > > > communication in multiple-processor and shared-memory systems." (see here > > > : > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/Cihbg > > > hef.html > > In my previous response to you, I explicitely defined what 'atomic' > > means when adjected to the term 'load'. The *EX instructions are used on > > ll/sc architectures to implement read/modify/write atomic operations, > > which are different from load (read) operations. > > Ok ! Because we just want to read the value, there is no need to use the *EX > version. *EX is intended to be use when a modification will be done > thereafter. > > > > > > But, in that while loop, it's a standard "LDR" that is used. Is it correct > > > too, and why ? > > > > Which 'that while loop' ? > > while (atomic_load_acq_int(&smp_rv_waiters[3]) < ncpus) > > cpu_spinwait(); > > This one ? > > No, I point the one at line 412, 458 and 472: > > 412: while (smp_rv_waiters[0] < smp_rv_ncpus) > cpu_spinwait(); > > 458: while (smp_rv_waiters[1] < smp_rv_ncpus) > cpu_spinwait(); > > 472: while (smp_rv_waiters[2] < smp_rv_ncpus) > cpu_spinwait(); > > > > > Because the semantic of the normal load + DMB barrier provides the expected > > semantic of atomic_load_acq(), as explained in atomic(9) and utilized by > > the author of the code. > > So, the writer must use LDREX/STREX to modify the value and use dmb to make > visible to other CPU the write. No, this is false statement on all/many counts. ll/sc is only needed for atomic modification, not for a write. If you need to assign a given value to the variable, STR instruction does just that. LDREX/STREX provide a way to ensure that a modification done atomically. E.g., if your intent is to add 1 to the word in memory, you need to ensure that the memory is not modified, when writing out the modified read value. Next, DMB does not 'make visible' the modification. DMB separates externally visible effects of executed instructions before and after it. >From the whole guarantees provided by this separation, atomic_load_acq() only needs the effect of not allowing later memory accesses to occur earlier than the DMB instruction was executed (t
Re: start-up failure at SVN r314889
It works, thank you! On Thu, Mar 9, 2017 at 5:58 AM, Michael Butler wrote: > Per Hans .. this should fix it: > > r314953 | hselasky | 2017-03-09 04:17:43 -0500 (Thu, 09 Mar 2017) | 9 lines > Changed paths: >M /head/sys/compat/linuxkpi/common/src/linux_work.c > > Don't create any threads before SI_SUB_INIT_IF in the LinuxKPI. Else > kthread_add() will assert it is called too soon. This fixes a startup > issue when COMPAT_LINUXKPI is in enabled the kernel configuration > file. > > imb > > > > On 3/8/17 6:02 PM, Michael Butler wrote: >> >> The difference between a kernel that boots and another that won't is .. >> >> imb@toshi:/home/imb> diff -cw /sys/amd64/conf/TOSHI~ /sys/amd64/conf/TOSHI >> *** /sys/amd64/conf/TOSHI~ Wed Mar 8 10:05:09 2017 >> --- /sys/amd64/conf/TOSHI Wed Mar 8 17:33:25 2017 >> *** >> *** 373,379 >># Enable Linux ABI emulation >>#options COMPAT_LINUX32 >># Enable Linux KPI >> ! #options COMPAT_LINUXKPI >> >># Enable the linux-like proc filesystem support (requires COMPAT_LINUX >># and PSEUDOFS) >> --- 373,379 >># Enable Linux ABI emulation >>#options COMPAT_LINUX32 >># Enable Linux KPI >> ! options COMPAT_LINUXKPI >> >># Enable the linux-like proc filesystem support (requires COMPAT_LINUX >># and PSEUDOFS) >> >> Seems to point at something in SVN r314843 :-( >> >> imb >> >> >> On 03/08/17 17:10, Eric Camachat wrote: >>> >>> I have the same issue on Dell Precision M4800. >>> >>> On Wed, Mar 8, 2017 at 6:26 AM, David Wolfskill >>> wrote: On Wed, Mar 08, 2017 at 07:55:44AM -0500, Michael Butler wrote: > > My laptop usually starts like this .. > > FreeBSD 12.0-CURRENT #21 r314812M: Mon Mar 6 19:34:51 EST 2017 > i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI > amd64 > FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM > 4.0.0) > ... > > This morning, I get this :-( > > FreeBSD 12.0-CURRENT #27 r314889M: Tue Mar 7 19:55:25 EST 2017 > i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI > FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM > 4.0.0) > VT(vga): resolution 640x480 > panic: kthread_add called too soon > [ .. ] > > Any thoughts? > "uname -vp" output from my last several (successful) build/smoke-tests for head: FreeBSD 12.0-CURRENT #274 r314653M/314653:1200023: Sat Mar 4 06:46:18 PST 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 FreeBSD 12.0-CURRENT #275 r314700M/314700:1200023: Sun Mar 5 07:45:20 PST 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 FreeBSD 12.0-CURRENT #276 r314770M/314770:1200023: Mon Mar 6 05:45:44 PST 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 FreeBSD 12.0-CURRENT #277 r314842M/314842:1200023: Tue Mar 7 05:55:58 PST 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 FreeBSD 12.0-CURRENT #278 r314906M/314906:1200024: Wed Mar 8 06:05:49 PST 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 Sorry it's not more help. Peace, david -- David H. Wolfskill da...@catwhisker.org How could one possibly "respect" a misogynist, racist, bullying con-man??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. >>> >>> >>> >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- ☀Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: smp_rendezvous_action: Are atomics correctly used ?
Le vendredi 10 mars 2017, 16:46:26 Konstantin Belousov a écrit : > On Fri, Mar 10, 2017 at 03:30:21PM +0100, Alexandre Martins wrote: > > Le vendredi 10 mars 2017, 15:57:16 Konstantin Belousov a ?crit : > > > On Fri, Mar 10, 2017 at 02:24:52PM +0100, Alexandre Martins wrote: > > > > Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a ?crit : > > > > > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > > > > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > > > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > > > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view > > > > > > > > =ann > > > > > > > > otat > > > > > > > > e#l1 > > > > > > > > 080> > > > > > > > > > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > I'm curently reading the code of the function > > > > > > > > > smp_rendezvous_action, > > > > > > > > > in > > > > > > > > > kern/subr_smp.c file. In that function, i see that the > > > > > > > > > variable > > > > > > > > > smp_rv_waiters is read in some while() loop in a non-atomic > > > > > > > > > way. > > > > > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?vie > > > > > > > > > w=an > > > > > > > > > nota > > > > > > > > > te#l > > > > > > > > > 412 > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?vie > > > > > > > > > w=an > > > > > > > > > nota > > > > > > > > > te#l > > > > > > > > > 458 > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?vie > > > > > > > > > w=an > > > > > > > > > nota > > > > > > > > > te#l > > > > > > > > > 472 > > > > > > > > > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > > > > > > > > > You should provide either evidence or, at least, some reasoning > > > > > > > supporting > > > > > > > your claims. > > > > > > > > > > > > I curently have a software watchdog that triger and does a > > > > > > coredump. > > > > > > In > > > > > > the > > > > > > coredumps, I always see a CPU trying to write-lock a "rm lock". > > > > > > Every > > > > > > time, > > > > > > that CPU is spinning into the smp_rendezvous_action, in the first > > > > > > while > > > > > > loop) while the others are into the idle threads. > > > > > > > > > > > > The fact is that freeze is not clear and I start to search > > > > > > "exotic" > > > > > > causes > > > > > > to explain it. > > > > > > > > > > This sounds as the 'usual' deadlock, where some other thread owns > > > > > rmlock > > > > > in > > > > > read mode. I recommend you to follow the > > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handboo > > > > > k/ke > > > > > rnel debug-deadlocks.html > > > > > > > > Just a last question, for my personnal knowledge. > > > > > > > > In ARM >= 6, for atomic acces, the code should (?) use LDREX and STREX > > > > for, I quote : "Use LDREX and STREX to implement interprocess > > > > communication in multiple-processor and shared-memory systems." (see > > > > here > > > > > > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/C > > > > ihbg > > > > hef.html > > > > > > In my previous response to you, I explicitely defined what 'atomic' > > > means when adjected to the term 'load'. The *EX instructions are used on > > > ll/sc architectures to implement read/modify/write atomic operations, > > > which are different from load (read) operations. > > > > Ok ! Because we just want to read the value, there is no need to use the > > *EX version. *EX is intended to be use when a modification will be done > > thereafter.> > > > > But, in that while loop, it's a standard "LDR" that is used. Is it > > > > correct > > > > too, and why ? > > > > > > Which 'that while loop' ? > > > > > > while (atomic_load_acq_int(&smp_rv_waiters[3]) < ncpus) > > > > > > cpu_spinwait(); > > > > > > This one ? > > > > No, I point the one at line 412, 458 and 472: > > > > 412: while (smp_rv_waiters[0] < smp_rv_ncpus) > > > > cpu_spinwait(); > > > > 458: while (smp_rv_waiters[1] < smp_rv_ncpus) > > > > cpu_spinwait(); > > > > 472: while (smp_rv_waiters[2] < smp_rv_ncpus) > > > > cpu_spinwait(); > > > > > > Because the semantic of the normal load + DMB barrier provides the > > > expected > > > semantic of atomic_load_acq(), as explained in atomic(9) and utilized by > > > the author of the code. > > > > So, the writer must use LDREX/STREX to modify the value and use dmb to > > make > > visible to other CPU the write. > > No, this is false statement on all/many counts. ll/sc is only needed for > atomic modification, not for a write. If you need to assign a given value > to the variable, STR instruction does just that. LDREX/STREX provide a > way to ensure that a m
Re: smp_rendezvous_action: Are atomics correctly used ?
On Fri, Mar 10, 2017 at 04:23:02PM +0100, Alexandre Martins wrote: > Le vendredi 10 mars 2017, 16:46:26 Konstantin Belousov a ?crit : > > On Fri, Mar 10, 2017 at 03:30:21PM +0100, Alexandre Martins wrote: > > > Le vendredi 10 mars 2017, 15:57:16 Konstantin Belousov a ?crit : > > > > On Fri, Mar 10, 2017 at 02:24:52PM +0100, Alexandre Martins wrote: > > > > > Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a ?crit : > > > > > > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > > > > > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > > > > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins > wrote: > > > > > > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view > > > > > > > > > =ann > > > > > > > > > otat > > > > > > > > > e#l1 > > > > > > > > > 080> > > > > > > > > > > > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > I'm curently reading the code of the function > > > > > > > > > > smp_rendezvous_action, > > > > > > > > > > in > > > > > > > > > > kern/subr_smp.c file. In that function, i see that the > > > > > > > > > > variable > > > > > > > > > > smp_rv_waiters is read in some while() loop in a non-atomic > > > > > > > > > > way. > > > > > > > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?vie > > > > > > > > > > w=an > > > > > > > > > > nota > > > > > > > > > > te#l > > > > > > > > > > 412 > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?vie > > > > > > > > > > w=an > > > > > > > > > > nota > > > > > > > > > > te#l > > > > > > > > > > 458 > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?vie > > > > > > > > > > w=an > > > > > > > > > > nota > > > > > > > > > > te#l > > > > > > > > > > 472 > > > > > > > > > > > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > > > > > > > > > > > You should provide either evidence or, at least, some reasoning > > > > > > > > supporting > > > > > > > > your claims. > > > > > > > > > > > > > > I curently have a software watchdog that triger and does a > > > > > > > coredump. > > > > > > > In > > > > > > > the > > > > > > > coredumps, I always see a CPU trying to write-lock a "rm lock". > > > > > > > Every > > > > > > > time, > > > > > > > that CPU is spinning into the smp_rendezvous_action, in the first > > > > > > > while > > > > > > > loop) while the others are into the idle threads. > > > > > > > > > > > > > > The fact is that freeze is not clear and I start to search > > > > > > > "exotic" > > > > > > > causes > > > > > > > to explain it. > > > > > > > > > > > > This sounds as the 'usual' deadlock, where some other thread owns > > > > > > rmlock > > > > > > in > > > > > > read mode. I recommend you to follow the > > > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handboo > > > > > > k/ke > > > > > > rnel debug-deadlocks.html > > > > > > > > > > Just a last question, for my personnal knowledge. > > > > > > > > > > In ARM >= 6, for atomic acces, the code should (?) use LDREX and STREX > > > > > for, I quote : "Use LDREX and STREX to implement interprocess > > > > > communication in multiple-processor and shared-memory systems." (see > > > > > here > > > > > > > > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/C > > > > > ihbg > > > > > hef.html > > > > > > > > In my previous response to you, I explicitely defined what 'atomic' > > > > means when adjected to the term 'load'. The *EX instructions are used on > > > > ll/sc architectures to implement read/modify/write atomic operations, > > > > which are different from load (read) operations. > > > > > > Ok ! Because we just want to read the value, there is no need to use the > > > *EX version. *EX is intended to be use when a modification will be done > > > thereafter.> > > > > > But, in that while loop, it's a standard "LDR" that is used. Is it > > > > > correct > > > > > too, and why ? > > > > > > > > Which 'that while loop' ? > > > > > > > > while (atomic_load_acq_int(&smp_rv_waiters[3]) < ncpus) > > > > > > > > cpu_spinwait(); > > > > > > > > This one ? > > > > > > No, I point the one at line 412, 458 and 472: > > > > > > 412: while (smp_rv_waiters[0] < smp_rv_ncpus) > > > > > > cpu_spinwait(); > > > > > > 458: while (smp_rv_waiters[1] < smp_rv_ncpus) > > > > > > cpu_spinwait(); > > > > > > 472: while (smp_rv_waiters[2] < smp_rv_ncpus) > > > > > > cpu_spinwait(); > > > > > > > > Because the semantic of the normal load + DMB barrier provides the > > > > expected > > > > semantic of atomic_load_acq(), as explained in atomic(9) and utilized by > > > > the author of the code. > > > > > > So, the writer must use LDREX/STREX
Re: input/output error @boot
On Thu, 9 Mar 2017 06:00:23 + Dexuan Cui wrote > Hi Roberto, > Thanks for sending me your memmap and this is a temporary workaround > patch for you: > https://github.com/dcui/freebsd/commit/0edd1db55fbbb56352d6024250e4ae7dd8ad31 > e3.patch > > I put the memmap info here for people who're interested: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c26 > > We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) . > loader.efi just writes into this range by force -- this is unsafe anyway! > > To fix this correctly & thoroughly, IMO we need a relocatable kernel, but > that would require a lot of complicated long term work: > https://reviews.freebsd.org/D9686?id=25414#inline-56969 > > For now, I suggest we should only apply the idea "reduce the size of the > staging area if necessary" to VM running on Hyper-V, we should restore the > old behavior on physical machines since that has been working for people > for a long period of time, though it's potentially unsafe. > > I think in the loader we can use CPUID to tell if we're running on Hyper-V or > not. Indeed that will provide *capability*. But I'm don't think that can tell you that it is currently *enabled* || *in use*. The CPU I experienced the (u)efi issue on has the capability, but I've turned it off, as it's more hindrance for performance, for the server' intended use. IOW I think just probing for *capability* isn't going to be enough. --Chris > > Thanks, > -- Dexuan > > > -Original Message- > > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- > > curr...@freebsd.org] On Behalf Of Dexuan Cui > > Sent: Thursday, March 9, 2017 10:44 > > To: Roberto Rodriguez Jr > > Cc: FreeBSD Current > > Subject: RE: input/output error @boot > > > > Hmm, Alex did report 314891 worked. > > > > Can you please post the full boot log of the loader? > > Especially, when you see the “OK” prompt, can you please run the “memmap” > > command like this link ... > > > > You can take a photo of the screen and send it to me, if it’s too big. > > > > Thanks, > > -- Dexuan > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: MANPATH not handled correctly
On Sun, Jan 08, 2017 at 11:26:33AM -0800, Steve Kargl wrote: > MANPATH is not handled correctly. According to the documentation > in apropos(1) and whatis(1): > > MANPATH The standard search path used by man(1) may be changed by > specifying a path in the MANPATH environment variable. Invalid > paths, or paths without manual databases, are ignored. > Overridden by -M. If MANPATH begins with a colon, it is > appended to the default list; if it ends with a colon, it is > prepended to the default list; or if it contains two adjacent > colons, the standard search path is inserted between the > colons. If none of these conditions are met, it overrides the > standard search path. > > I have a manpage named mkpic in $HOME/man/man1. I also have the FreeBSD > installed manpages, e.g., /usr/share/man/man1/cat.1.gz. If I have > 'setenv MANPATH :$HOME/man' in my .cshrc file, then the following occurs: > > % setenv | grep MANPATH > MANPATH=:/home/kargl/man > % apropos mkpic > (Warning: MANPATH environment variable set) > mkpic(1) - construct a contour image in MIFF image format > % apropos cat > (Warning: MANPATH environment variable set) > matrix(3) - Array and matrix allocation for FFT library > > So, the above description of MANPATH is incorrect as :/home/kargl/man > should have been appended to the default MANPATH. > > Interestingly, manpath(1) seems to described what actually happens > (long lines wrapped): > > % unsetenv MANPATH > % manpath > /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\ >/usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\ >/usr/local/share/xpdf/man > % setenv MANPATH :$HOME/sman > % manpath > (Warning: MANPATH environment variable set) > :/home/kargl/man > > The expected result according apropos(1) and whatis(1) for last command is > > % manpath > /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\ >/usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\ >/usr/local/share/xpdf/man:/home/kargl/man Sorry it took time, but it is now fixed. the issue was we have kept our man(1) when importing mandoc and I have not noticed that mandoc had that feature. I implemented it in our man(1) While here I removed the painful warning Best regards, Bapt signature.asc Description: PGP signature
Re: MANPATH not handled correctly
On Sat, Mar 11, 2017 at 07:34:40AM +0100, Baptiste Daroussin wrote: > On Sun, Jan 08, 2017 at 11:26:33AM -0800, Steve Kargl wrote: > > MANPATH is not handled correctly. According to the documentation > > in apropos(1) and whatis(1): > > (snip) > > Sorry it took time, but it is now fixed. the issue was we have kept our man(1) > when importing mandoc and I have not noticed that mandoc had that feature. > > I implemented it in our man(1) > > While here I removed the painful warning > Thank you! Thank you! Thank you! -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
