Delivering SIGKILL to init
Prompted by some discussion elsewhere, I've been trying to send SIGKILL to init. If I ktrace kill(1), I can see "kill(1,9)" which returns 0 but the signal is never delivered. If I sent (eg) SIGXCPU then init dies and the kernel panics (as expected). I've looked through sys/kern/kern_* and can't see anywhere that special cases the delivery of SIGKILL to init. Can anyone please explain why SIGKILL doesn't kill init (at least on -stable). -- Peter Jeremy pgpGGJl4gQDvH.pgp Description: PGP signature
Re: jail2 patchset 12
thanks for point this :( i will rewrite old jail api as wrapper to new
API for avoid similar errors...
В Втр, 19.09.2006, в 00:50, John Baldwin пишет:
> On Sunday 17 September 2006 18:08, Alex Lyashkov wrote:
> > Thanks for you report. I really more test new jail2 API then old :(
> > Please apply this patch.
> >
> > # p4 diff -du kern_jail.c
> > //depot/projects/jail2/sys/kern/kern_jail.c#4 -
> > /root/jail2/sys/kern/kern_jail.c
> > @@ -316,6 +316,7 @@
> > if (error)
> > return (error);
> >
> > + mtx_lock(&allprison_mtx);
> > pr = prison_find(uap->jid);
> > if (pr == NULL) {
> > return (ESRCH);
>
> Does this leak the lock in the ESRCH case now?
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: numbers don't lie ...
On Thu, 14 Sep 2006, Oliver Fromme wrote: OF> Because buildworld is I/O-bound on systems with sufficiently OF> fast processors. OF> OF> Try putting the contents of /usr/src into a RAM disk and OF> repeat the benchmark. The numbers might look a little OF> different then. Of course, you should have sufficient RAM OF> in the machines -- If they're going to swap to the disks, OF> your benchmark won't be happy. OF> OF> I think putting /usr/obj onto a RAM disk is _not_ necessary OF> because of soft-updates, so the processes shouldn't block OF> on writes. My experiments show that if you have enough memory to host radmdrive for /usr/src you'd better leave it for caching - there were no statistically meaningful performance difference, at least on machines with 1G+ RAM. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.2/pxe blues, was Re: pxe boot size limit?
> it seems that pxeboot has a limit with respect to the kernel size, > which prevents the kernel to get loaded, the error printed is > slightly misleading. > > the solution is to make a kernel with loadable modules, instead of > compiled in. not entirely true :-( but changing kernel size has different results. kernel is 6.2-PRERELEASE. hosts are 64bits: 1 - amd Athlon dual core - nic is em 2 - intel Xeon dual core - nic is bc 3 - intel Pentium 4 K8 - nic is bge 1 & 3 are now booting, but 2 is panics with: /boot/kernel/kernel text=0x430118 data=0x79450+0x3ccf0 syms=[0x8+0x73278+0x8+0x62861] panic: free: guard1 fail @ 0x7c6fe from /r+d/6.2/src/lib/libstand/ufs.c:699 a slightly older kernel, and bigger, boots just fine. booting from local disk is also ok. so, what is causing pxeboot to fail? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: numbers don't lie ...
On Tue, Sep 19, 2006 at 04:11:12PM +0400, Dmitry Morozovsky wrote: > On Thu, 14 Sep 2006, Oliver Fromme wrote: > > OF> Because buildworld is I/O-bound on systems with sufficiently > OF> fast processors. > OF> > OF> Try putting the contents of /usr/src into a RAM disk and > OF> repeat the benchmark. The numbers might look a little > OF> different then. Of course, you should have sufficient RAM > OF> in the machines -- If they're going to swap to the disks, > OF> your benchmark won't be happy. > OF> > OF> I think putting /usr/obj onto a RAM disk is _not_ necessary > OF> because of soft-updates, so the processes shouldn't block > OF> on writes. > > My experiments show that if you have enough memory to host radmdrive for > /usr/src you'd better leave it for caching - there were no statistically > meaningful performance difference, at least on machines with 1G+ RAM. Really? My measurements show the opposite (on a system with 16GB of RAM). Kris pgpbrfr1gGCPw.pgp Description: PGP signature
Re: Delivering SIGKILL to init
On Tue, 2006-Sep-19 17:55:50 +1000, Peter Jeremy wrote: >Prompted by some discussion elsewhere, I've been trying to send >SIGKILL to init. If I ktrace kill(1), I can see "kill(1,9)" which >returns 0 but the signal is never delivered. If I sent (eg) SIGXCPU >then init dies and the kernel panics (as expected). I've looked >through sys/kern/kern_* and can't see anywhere that special cases >the delivery of SIGKILL to init. For anyone else interested: I was pointed to code in kern_sig.c:issignal() by a friend. The signal action handling switch (about line 2172 in -stable) ignores any signals marked SIG_DFL for "system" processes (those with a PID of 1 or less). Since SIGKILL is marked SIG_DFL (because it can't be changed), this means SIGKILL isn't delivered. SIGXCPU (and a variety of other signals) have a handler defined by init so they aren't SIG_DFL and therefore are delivered. -- Peter Jeremy pgpqhYltrBM2I.pgp Description: PGP signature
Symlinks on read-only FS
I've just noticed this, in ufs/ufs/ufs_vnops.c:ufs_access()
/*
* Disallow write attempts on read-only filesystems;
* unless the file is a socket, fifo, or a block or
* character device resident on the filesystem.
*/
if (mode & VWRITE) {
switch (vp->v_type) {
case VDIR:
case VLNK:
case VREG:
if (vp->v_mount->mnt_flag & MNT_RDONLY)
return (EROFS);
Is the inclusion of VLNK here correct? I would think that
only the target of the symlink should matter: if it happens
to point onto a writable FS, the fact that the symlink itself
is on a ROFS should not matter.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Symlinks on read-only FS
Perry Hutchison wrote: Is the inclusion of VLNK here correct? I would think that only the target of the symlink should matter: if it happens to point onto a writable FS, the fact that the symlink itself is on a ROFS should not matter. yes, it is correct. short symbolic links are stored in the inode itself, so if you modify a short link, you'll be modifying metadata, which is not allowed. it could be argued, that as long as the change is restricted to one inode, it could be tolerable, but moreover, if your short symbolic link is modified to be longer than fits in inode, a disk block will need to be allocated, which would involve a change to block map, which is certainly not desirable for read-only mounts. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlinks on read-only FS
> > Is the inclusion of VLNK here correct? I would think that > > only the target of the symlink should matter: if it happens > > to point onto a writable FS, the fact that the symlink itself > > is on a ROFS should not matter. > > yes, it is correct. > short symbolic links are stored in the inode itself, so if you > modify a short link, you'll be modifying metadata, which is > not allowed. it could be argued, that as long as the change is > restricted to one inode, it could be tolerable, but moreover, > if your short symbolic link is modified to be longer than fits > in inode, a disk block will need to be allocated, which would > involve a change to block map, which is certainly not desirable > for read-only mounts. So the sort of write access being validated here would be writing to the symlink itself (i.e. the definition)? I did not know that could be done. I had expected that the caller would eventually dereference the link, and write to its target. Certainly we wouldn't want to allow changing what the link itself contains if it is on a ROFS -- indeed this might not even be possible (e.g. if the FS is recorded on a CDROM). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Symlinks on read-only FS
Perry Hutchison wrote: So the sort of write access being validated here would be writing to the symlink itself (i.e. the definition)? symlinks are dereferenced during name lookup and are not affected by the write mount options of the filesystems they reside on. you can open a file for write by accessing a symlink pointing to it, even though the symlink itself may reside on a read-only filesystem. and you can disregard what i said in my previous post: there's no interface to change the symlink after it was created. actually, i'm not sure there is a real-world case in which this code would be invoked with VLNK. checking write permissions on a symlink? access(2)/eaccess(2) dereference symlinks. but if, for whatever reason, someone calls VOP_ACCESS on read-only UFS filesystem, checking if writing to symlink itself is ok, it will be denied. which makes sense. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
Re: numbers don't lie ...
Danny Braniss wrote: Im testing these 2 boxes, Sun X4100 and Dell-2950, and: SUN X4100: Dual Core AMD Opteron(tm) Processor 280 (2393.19-MHz K8-class CPU) one 70g sata disk DELL 2950: Intel(R) Xeon(TM) CPU 3.20GHz (3192.98-MHz K8-class CPU) 4 sata disks + raid0 they both run identical 6.1-STABLE. my 'cpu benchmark' shows the amd being much better than the intel. but, doing a make buildworld give interesting results: dell-2950 : make -j16 TARGET_ARCH=amd64 buildworld : 24m17.41s real 1h3m3.26s user 17m15.07s sys dell-2950 : make -j8 TARGET_ARCH=amd64 buildworld : 24m8.28s real 1h2m59.38s user 16m16.20s sys sunfire : make -j16 TARGET_ARCH=amd64 buildworld : 24m21.38s real 49m6.68s user 14m22.64s sys sunfire : make -j8 TARGET_ARCH=amd64 buildworld : 23m47.69s real 48m53.58s user 13m44.81s sys which probably says something about my 'cpu benchmark' :-( but why is the user time so much different between the boxes? Even though your asking about user time I would like to point out I have long prefered to see build world as by far a hard disk io benchmark over a CPU benchmark. After doing such benchmarks my self I have noticed my raid 1 SAS Dells with upto 40% less CPU power crush my Dell dual socket 3.6ghz raid 5 SAS servers in buildworld speed, this is purely because simple fact raid 5 is much slower on writes, CPU has far less to do with buildworld performance. Also a Dell 2950 on SATA seems to be a bit of a odd combination as I would believe most people get the SAS drives for a Dell 2950 and use the PERC5 / mfi SAS device crontroller. Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
