I will bump revision for stable/8 when merging, but I do not see much
reason to bump on HEAD right now.
Many thanks.
Uhm I think we can survive without a bump in HEAD. For now we will
need to keep our backward-compatibility patch anyway, and when the
bump happens on stable/8 our sysctl compar
Below is the patch I intend to commit after you retest it.
I applied it against our 8.2 based package,
altered our "clone" to use this new
interface and run eglibc testsuite. No regression.
Our runtime detection of this new interface will be based
on "sysctl kern.osreldate".
some rewording
Seems this interface be acceptable ?
Looks good to me.
The proposed code changes are in the attached patch.
Proposed wording of addition into RFORK(2):
DESCRIPTION:
RFTSIGZMB If set, the kernel will return selected signal number instead
of SIGCHILD upon thread exit for
Should the bit slice be 7 or 8 bits ?
I propose to go 8 bits, and add the check to be future-proof.
It seems that we already parse GNU/kFreeBSD brandnote. I think this
could be used to distinguish between old behaviour, that is currently
used by your libc, and proposed new interface, if __Fr
I would instead use a new flag to specify a signal sent on the child
death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is
set, the bit slice is used as signal number, 0 means do not send any
signal.
Please note that the signal should be checked for validity, it must be
<= _SIG_MAX
The 1st patch satisfies this. I agree that SIGCHLD part
is not easily readable.
The SIGCHLD part is ugly. This is why I am asking about possible ways
to overcome this.
We need a way to specify "no signal".
It can be "new flag" or "ugly SIGCHLD".
new flag:
pros: cleaner design
cons: one bit
RFLINUXPTH was used by the linuxthreads port, that was popular in the
time of FreeBSD 4.x and may be 5.x to run mysql. I will object against
this breakage.
Do I understand correctly that API/ABI backward compatibility with
previous FreeBSD releases w.r.t RFLINUXPTH is needed ?
The 1st patch s
Can you, please, describe the reasoning behind the
+ if (sig == SIGCHLD) sig = 0;
line ?
The main reason is backward compatibility.
The original FreeBSD code allows only to select between
SIGUSR1 or SIGCHLD signals.
The our extension changes meaning of RFLINUXTHPN to select sign
This patch made by Petr Salinger improves compatibility with
LinuxThreads in rfork() syscall. The Linux clone() implementation
allows specifying the signal sent to parent when child terminates
(instead of SIGCHLD).
As the threading implementation in Debian GNU/kFreeBSD is
LinuxThreads-based, we
Bellow is leaking recipe tested under GNU/kFreeBSD.
I would expect it leaks vnodes also under plain FreeBSD.
I confirm it is reproducible on plain FreeBSD. Looks like a security
issue, as a normal user can create a local DoS in a few dozen of
seconds.
I already posted the following patch in p
What have to be logged ?
Please look at ddb command "show files", implemented in kern/kern_descrip.c,
lines 3284-3305 on HEAD. Instead of doing full dump, you can manually
inspect the output. Or, you can write some code that would search the
suspicious vnodes among the vnodes referenced from the
I used the attached diff, with hackish snooping
on allocated/freed memory for vnodes. When the vp pointer have been
logged as active1/active2, it is (much) later shown with
dead_vnodeops in DUMP_VP().
Is there a lot of such /dev/ttyp* vnodes ? This indeed might be
suspicious. See below for descri
On Wed, 7 Apr 2010, Kostik Belousov wrote:
On Tue, Apr 06, 2010 at 10:01:56PM +0200, Petr Salinger wrote:
Can you try to get a backtrace at the points you have shown me ?
All are similar to this, with ptyp5/ptyp6/ptyp7 name changes.
a vnode 0xff0058978000: tag devfs, type VCHR
I would expect that sum of mnt_nvnodelistsize should be vfs.numvnodes.
The sum is at about 3400, but the vfs.numvnodes is at about 38000.
Is my expectation correct ?
Not quite, reclaimed vnode is removed from mp list.
Are they in some other list ?
Can you check
that vmstat -z | grep VNODE out
BTW, the 7.3 seems be unaffected by this.
Confirmed, the whole build of gcc-4.3 ends with
kern.maxvnodes: 10
kern.minvnodes: 25000
vfs.freevnodes: 22070
vfs.wantfreevnodes: 25000
vfs.numvnodes: 39907
debug.vnlru_nowhere: 0
while for 8.0 kernel even 12 in vfs.numvnodes does not suffic
Another possible workaround, if you do not need path resolutions in /proc
or lsof(1), is to set sysctl vfs.vlru_allow_cache_src=1.
I will test this.
Does not help.
kern.maxvnodes: 10
kern.minvnodes: 25000
vfs.vlru_allow_cache_src: 1
vfs.freevnodes: 199
vfs.wantfreevnodes: 25000
vfs.numvno
You can either increase kern.maxvnodes, the default value is very
conservative on amd64, where a lot of KVA is available. On the other
hand, increase of the value on i386 could easily cause KVA exhaustion.
The increase helps, the system become responsive. In fact I previously
suspected schedule
Hi,
I have the same problem as in
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-August/029227.html
During "make check" of gcc-4.3 the vfs.numvnodes goes up,
after reaching default limit 10 the machine is stuck.
kern.maxvnodes: 10
kern.sigqueue.alloc_fail: 0
kern.sigqueue.overf
18 matches
Mail list logo
