Re: Add SUM sysctl
> > --Kj7319i9nmIyA2yE > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sat, Apr 16, 2011 at 04:46:53PM -0600, Warren Block wrote: > >On Sat, 16 Apr 2011, dieter...@engineer.com wrote: > > > >>Suggestion 2: The kernel may not have an official flag for single > >>vs multi user mode but you can fake it. Try something like > >>"pgrep syslogd". If syslogd is running assume multiuser mode. If > >>syslogd is not running assume single user mode. > > > >Another option: kern.hostid is set nonzero pretty early in the rc > >scripts. > > Same as getty(8). That also will not be running in SU and in most cases > is a clear indication that nothing else is running unless you have a > remote only machine without a console in which you have purposely > disabled getty(8). > > --=20 > > Regards, > J. Hellenthal > WWJD when something gets too complicated, it's usualy helpful to look for other ways out: the /(root) + /usr + kernel-debuging + src is less than 1GB, so what I do (when diskless is not an option), I have a 2 partitions, both bootable, and so i ALWAYS update the non active one, then 1- I always have a working / in case the update screwed something 2- I can update without problems. my $.02 danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
on 16/04/2011 14:46 Andriy Gapon said the following: > > Guys, > > I am trying to debug this chromium issue: > http://trillian.chruetertee.ch/chromium/ticket/13 > Not sure SOCK_SEQPACKET mentioned in the ticket is an actual culprit, the > problem that interests me is that pthread_cond_wait() returns EPERM where it > shouldn't. That happens on stable/8. > > I compared ktrace of chromium on stable/8 and head. Startup traces are very > similar until execution gets to one particular place. At that place stable/8 > chromium executes pthread_cond_wait - I see _umtx_op(UMTX_OP_CV_WAIT) and > that's > where EPERM is returned. On the other hand it seems that head chromium > executes > something different at exactly the same place, perhaps sem_wait - I see > _umtx_op(UMTX_OP_WAIT_UINT_PRIVATE). So this is puzzle #1 for me why > chromimum > build or run-time chooses a different thing to call/use at that place. OK, this was simple. This is because of the new userland condvar implementation in head. The call is the same pthread_cond_wait, just the different implementation in libthr. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
on 16/04/2011 14:46 Andriy Gapon said the following: > The second puzzle is the EPERM return value itself, on stable/8. > From what I seem chromium does a bunch of forks before it gets to the place of > interest. My debugging shows that those forks are "single-threaded" (i.e. > code > in thr_fork.c is not called). And then in a process/thread that makes that > pthread_cond_wait call I see that libthr and kernel have different opinions > about what current TID is. Userland part uses what is actually a kernel TID > of > its parent thread (the one that called fork). And given how the work is > divided > between userland and kernel in libthr, that mismatch leads to serious > consequences. > > So my question is why libthr doesn't see its actual TID. Maybe some > initialization code is not invoked. BTW, chromium is linked to both libc and > libthr (per ldd). But it seems that there are no pthread calls up the fork > chain until that pthread_cond_wait call. The second problem seems to be caused by chrome binary being linked to libc and libthr in "incorrect order", libc comes before libthr in ldd output. My debugging shows that fork is resolved from libc, not from libthr. Not sure what to blame here: - build toolchain for putting libc before libthr - rtld for not preferring libthr over libc - libc/libthr for being split into two pieces in the current way -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
On Sun, 17 Apr 2011, Andriy Gapon wrote: on 16/04/2011 14:46 Andriy Gapon said the following: The second puzzle is the EPERM return value itself, on stable/8. From what I seem chromium does a bunch of forks before it gets to the place of interest. My debugging shows that those forks are "single-threaded" (i.e. code in thr_fork.c is not called). And then in a process/thread that makes that pthread_cond_wait call I see that libthr and kernel have different opinions about what current TID is. Userland part uses what is actually a kernel TID of its parent thread (the one that called fork). And given how the work is divided between userland and kernel in libthr, that mismatch leads to serious consequences. So my question is why libthr doesn't see its actual TID. Maybe some initialization code is not invoked. BTW, chromium is linked to both libc and libthr (per ldd). But it seems that there are no pthread calls up the fork chain until that pthread_cond_wait call. The second problem seems to be caused by chrome binary being linked to libc and libthr in "incorrect order", libc comes before libthr in ldd output. My debugging shows that fork is resolved from libc, not from libthr. Not sure what to blame here: - build toolchain for putting libc before libthr - rtld for not preferring libthr over libc - libc/libthr for being split into two pieces in the current way - The build procedure for chromium. libc/[libc_r, libpthread, libthr] have always behaved that way since the libc/libc_r split. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
on 17/04/2011 18:21 Daniel Eischen said the following: > On Sun, 17 Apr 2011, Andriy Gapon wrote: > >> on 16/04/2011 14:46 Andriy Gapon said the following: >>> The second puzzle is the EPERM return value itself, on stable/8. >>> From what I seem chromium does a bunch of forks before it gets to the place >>> of >>> interest. My debugging shows that those forks are "single-threaded" (i.e. >>> code >>> in thr_fork.c is not called). And then in a process/thread that makes that >>> pthread_cond_wait call I see that libthr and kernel have different opinions >>> about what current TID is. Userland part uses what is actually a kernel >>> TID of >>> its parent thread (the one that called fork). And given how the work is >>> divided >>> between userland and kernel in libthr, that mismatch leads to serious >>> consequences. >>> >>> So my question is why libthr doesn't see its actual TID. Maybe some >>> initialization code is not invoked. BTW, chromium is linked to both libc >>> and >>> libthr (per ldd). But it seems that there are no pthread calls up the fork >>> chain until that pthread_cond_wait call. >> >> The second problem seems to be caused by chrome binary being linked to libc >> and >> libthr in "incorrect order", libc comes before libthr in ldd output. My >> debugging shows that fork is resolved from libc, not from libthr. >> Not sure what to blame here: >> - build toolchain for putting libc before libthr >> - rtld for not preferring libthr over libc >> - libc/libthr for being split into two pieces in the current way > > - The build procedure for chromium. > > libc/[libc_r, libpthread, libthr] have always behaved that > way since the libc/libc_r split. Well, I wouldn't blame it so expressly: -pthread is the first option on the linkage command line, there is -lc there also. I would expect that that would do the right thing, but it doesn't. And that's a PITA for porting. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
On Sun, 17 Apr 2011, Andriy Gapon wrote: on 17/04/2011 18:21 Daniel Eischen said the following: On Sun, 17 Apr 2011, Andriy Gapon wrote: on 16/04/2011 14:46 Andriy Gapon said the following: The second puzzle is the EPERM return value itself, on stable/8. From what I seem chromium does a bunch of forks before it gets to the place of interest. My debugging shows that those forks are "single-threaded" (i.e. code in thr_fork.c is not called). And then in a process/thread that makes that pthread_cond_wait call I see that libthr and kernel have different opinions about what current TID is. Userland part uses what is actually a kernel TID of its parent thread (the one that called fork). And given how the work is divided between userland and kernel in libthr, that mismatch leads to serious consequences. So my question is why libthr doesn't see its actual TID. Maybe some initialization code is not invoked. BTW, chromium is linked to both libc and libthr (per ldd). But it seems that there are no pthread calls up the fork chain until that pthread_cond_wait call. The second problem seems to be caused by chrome binary being linked to libc and libthr in "incorrect order", libc comes before libthr in ldd output. My debugging shows that fork is resolved from libc, not from libthr. Not sure what to blame here: - build toolchain for putting libc before libthr - rtld for not preferring libthr over libc - libc/libthr for being split into two pieces in the current way - The build procedure for chromium. libc/[libc_r, libpthread, libthr] have always behaved that way since the libc/libc_r split. Well, I wouldn't blame it so expressly: -pthread is the first option on the linkage command line, there is -lc there also. I would expect that that would do the right thing, but it doesn't. And that's a PITA for porting. ports have been doing the right thing for years; I think they probably just remove the explicit -lc because -lc is implied. I'm not saying that you couldn't change the linker to ignore -lc, but we've gotten (so far) without it. I recall it was a little bit of work to get some ports to behave correctly, but it was very managable. But perhaps @ports has a different view of history ;-) -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
SMP question w.r.t. reading kernel variables
Hi,
I should know the answer to this, but... When reading a global kernel
variable, where its modifications are protected by a mutex, is it
necessary to get the mutex lock to just read its value?
For example:
Aif ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0)
return (EPERM);
versus
BMNT_ILOCK(mp);
if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) {
MNT_IUNLOCK(mp);
return (EPERM);
}
MNT_IUNLOCK(mp);
My hunch is that B is necessary if you need an up-to-date value
for the variable (mp->mnt_kern_flag in this case).
Is that correct?
Thanks in advance for help with this, rick
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: SMP question w.r.t. reading kernel variables
2011/4/17 Rick Macklem :
> Hi,
>
> I should know the answer to this, but... When reading a global kernel
> variable, where its modifications are protected by a mutex, is it
> necessary to get the mutex lock to just read its value?
>
> For example:
> A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0)
> return (EPERM);
> versus
> B MNT_ILOCK(mp);
> if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) {
> MNT_IUNLOCK(mp);
> return (EPERM);
> }
> MNT_IUNLOCK(mp);
>
> My hunch is that B is necessary if you need an up-to-date value
> for the variable (mp->mnt_kern_flag in this case).
>
> Is that correct?
>
> Thanks in advance for help with this, rick
In general, FreeBSD kernel assumes that read and writes of the word
boundry and of the int types are always atomic.
Considering this, if a kernel variable is of int type or word boundry
size you don't strictly need a lock there.
Anyway, locking also bring some side effect, like usage of memory and
compiler barriers... while it is true that bounded read/writes should
be seq points, it is not too obvious to predict if the barrier is
necessary or not, is implied or not in every architecture we support.
Said that, for a matter of consistency and of better semantic, I
prefer to also lock "simple" read/writes when the objects are
explicitly equipped to do that.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: SMP question w.r.t. reading kernel variables
On Sun, Apr 17, 2011 at 03:49:48PM -0400, Rick Macklem wrote:
> Hi,
>
> I should know the answer to this, but... When reading a global kernel
> variable, where its modifications are protected by a mutex, is it
> necessary to get the mutex lock to just read its value?
>
> For example:
> Aif ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0)
> return (EPERM);
> versus
> BMNT_ILOCK(mp);
> if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) {
> MNT_IUNLOCK(mp);
> return (EPERM);
> }
> MNT_IUNLOCK(mp);
>
> My hunch is that B is necessary if you need an up-to-date value
> for the variable (mp->mnt_kern_flag in this case).
>
> Is that correct?
mnt_kern_flag read is atomic on all architectures.
If, as I suspect, the fragment is for the VFS_UNMOUNT() fs method,
then VFS guarantees the stability of mnt_kern_flag, by blocking
other attempts to unmount until current one is finished.
If not, then either you do not need the lock, or provided snipped
which takes a lock is unsufficient, since you are dropping the lock
but continue the action that depends on the flag not being set.
pgp3IYsjmCOsB.pgp
Description: PGP signature
Re: SMP question w.r.t. reading kernel variables
> On Sun, Apr 17, 2011 at 03:49:48PM -0400, Rick Macklem wrote:
> > Hi,
> >
> > I should know the answer to this, but... When reading a global
> > kernel
> > variable, where its modifications are protected by a mutex, is it
> > necessary to get the mutex lock to just read its value?
> >
> > For example:
> > A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0)
> > return (EPERM);
> > versus
> > B MNT_ILOCK(mp);
> > if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) {
> > MNT_IUNLOCK(mp);
> > return (EPERM);
> > }
> > MNT_IUNLOCK(mp);
> >
> > My hunch is that B is necessary if you need an up-to-date value
> > for the variable (mp->mnt_kern_flag in this case).
> >
> > Is that correct?
>
> mnt_kern_flag read is atomic on all architectures.
> If, as I suspect, the fragment is for the VFS_UNMOUNT() fs method,
> then VFS guarantees the stability of mnt_kern_flag, by blocking
> other attempts to unmount until current one is finished.
> If not, then either you do not need the lock, or provided snipped
> which takes a lock is unsufficient, since you are dropping the lock
> but continue the action that depends on the flag not being set.
Sounds like A should be ok then. The tests matter when dounmount()
calls VFS_SYNC() and VFS_UNMOUNT(), pretty much as you guessed. To
be honest, most of it will be the thread doing the dounmount() call,
although other threads fall through VOP_INACTIVE() while they are
terminating in VFS_UNMOUNT() and these need to do the test, too.
{ I just don't know much about the SMP stuff, so I don't know when
a cache on another core might still have a stale copy of a value.
I've heard the term "memory barrier", but don't really know what it
means.:-)
Thanks, rick
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
On Sun, 17 Apr 2011 17:39:43 +0300 Andriy Gapon wrote: > on 16/04/2011 14:46 Andriy Gapon said the following: > > The second puzzle is the EPERM return value itself, on stable/8. > > From what I seem chromium does a bunch of forks before it gets to > > the place of interest. My debugging shows that those forks are > > "single-threaded" (i.e. code in thr_fork.c is not called). And > > then in a process/thread that makes that pthread_cond_wait call I > > see that libthr and kernel have different opinions about what > > current TID is. Userland part uses what is actually a kernel TID > > of its parent thread (the one that called fork). And given how the > > work is divided between userland and kernel in libthr, that > > mismatch leads to serious consequences. > > > > So my question is why libthr doesn't see its actual TID. Maybe some > > initialization code is not invoked. BTW, chromium is linked to > > both libc and libthr (per ldd). But it seems that there are no > > pthread calls up the fork chain until that pthread_cond_wait call. > > The second problem seems to be caused by chrome binary being linked > to libc and libthr in "incorrect order", libc comes before libthr in > ldd output. My debugging shows that fork is resolved from libc, not > from libthr. Not sure what to blame here: > - build toolchain for putting libc before libthr > - rtld for not preferring libthr over libc > - libc/libthr for being split into two pieces in the current way Why rtld would make any special allowances for libthr?! It does exactly what it is told to do, just as it should. -- Alexander Kabaev signature.asc Description: PGP signature
Re: puzzled: fork +libthr
On Sun, 17 Apr 2011 18:56:52 +0300
Andriy Gapon wrote:
> on 17/04/2011 18:21 Daniel Eischen said the following:
> > On Sun, 17 Apr 2011, Andriy Gapon wrote:
> >
> >> on 16/04/2011 14:46 Andriy Gapon said the following:
> >>> The second puzzle is the EPERM return value itself, on stable/8.
> >>> From what I seem chromium does a bunch of forks before it gets to
> >>> the place of interest. My debugging shows that those forks are
> >>> "single-threaded" (i.e. code in thr_fork.c is not called). And
> >>> then in a process/thread that makes that pthread_cond_wait call I
> >>> see that libthr and kernel have different opinions about what
> >>> current TID is. Userland part uses what is actually a kernel TID
> >>> of its parent thread (the one that called fork). And given how
> >>> the work is divided between userland and kernel in libthr, that
> >>> mismatch leads to serious consequences.
> >>>
> >>> So my question is why libthr doesn't see its actual TID. Maybe
> >>> some initialization code is not invoked. BTW, chromium is linked
> >>> to both libc and libthr (per ldd). But it seems that there are
> >>> no pthread calls up the fork chain until that pthread_cond_wait
> >>> call.
> >>
> >> The second problem seems to be caused by chrome binary being
> >> linked to libc and libthr in "incorrect order", libc comes before
> >> libthr in ldd output. My debugging shows that fork is resolved
> >> from libc, not from libthr. Not sure what to blame here:
> >> - build toolchain for putting libc before libthr
> >> - rtld for not preferring libthr over libc
> >> - libc/libthr for being split into two pieces in the current way
> >
> > - The build procedure for chromium.
> >
> > libc/[libc_r, libpthread, libthr] have always behaved that
> > way since the libc/libc_r split.
>
> Well, I wouldn't blame it so expressly: -pthread is the first option
> on the linkage command line, there is -lc there also. I would expect
> that that would do the right thing, but it doesn't. And that's a
> PITA for porting.
>
I would blame it, and expressly at that. -pthread is a shortcut for
{-lpthread -lc} instead of just {-lc} in the place where implied libc
is provided by the compiler driver and has no magic properties you want
it it to have. If chromium build infrastructure circumvents that, it is
only said build infrastructure to blame.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: Add SUM sysctl
On Sun, 17 Apr 2011 15:11:03 +0300 Daniel Braniss wrote: > when something gets too complicated, it's usualy helpful to look for other > ways > out: > the /(root) + /usr + kernel-debuging + src is less than 1GB, so what I > do (when diskless is not an option), I have a 2 partitions, both bootable, > and so i ALWAYS update the non active one, then > 1- I always have a working / in case the update screwed something > 2- I can update without problems. A number of people have mentioned this, but none have pointed out that with a ZFS system, you don't even have to keep a spare partition around to do this. Cryx provided this script (http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE/manageBE) which makes updating a FreeBSD system as simple any Unix system I've seen. http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
on 18/04/2011 03:54 Alexander Kabaev said the following:
>
> I would blame it, and expressly at that. -pthread is a shortcut for
> {-lpthread -lc} instead of just {-lc} in the place where implied libc
> is provided by the compiler driver and has no magic properties you want
> it it to have. If chromium build infrastructure circumvents that, it is
> only said build infrastructure to blame.
OK, I see, thank you.
Still inconvenient.
As in: if we know for a fact that "gcc ... -pthread -lc" results in a broken
binary, then IMO we should do something about that.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
