Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-hackers-digest V5 #725

0 views

Skip to first unread message

owner-freebsd-...@freebsd.org

unread,

Feb 20, 2003, 2:38:37 PM2/20/03

freebsd-hackers-digest Thursday, February 20 2003 Volume 05 : Number 725

In this issue:
Re: Ok, IPC jailed.
Re: IPFW changes.
Re: debugging a repeating panic that does not produce a dump
Re: debugging a repeating panic that does not produce a dump
scan_ffs for UFS2
Re: scan_ffs for UFS2
Re: bleh. Re: ufs_rename panic
modern (usb) webcam support?
RE: Hi!Dear FreeBSD!
Re: bleh. Re: ufs_rename panic
Re: bleh. Re: ufs_rename panic
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Re: scan_ffs for UFS2
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Re: Per-jail CPU limits?
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Re: debugging a repeating panic that does not produce a dump
Re: debugging a repeating panic that does not produce a dump
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Wireless PCI card
Re: Multi-level jailing.
Re: Wireless PCI card
Re: Multi-level jailing.
interrupt handler not getting called

----------------------------------------------------------------------

Date: Wed, 19 Feb 2003 13:54:38 -0500
From: Alexander Kabaev <ak...@gte.com>
Subject: Re: Ok, IPC jailed.

On Wed, 19 Feb 2003 19:45:52 +0100
Pawel Jakub Dawidek <ni...@garage.freebsd.pl> wrote:

> On Wed, Feb 19, 2003 at 07:43:19PM +0100, Pawel Jakub Dawidek wrote:
> +> Patches are attached.
>
> Now!:)
>
Please resubmit your patch as PR to ensure it will not get lost.
- --
Alexander Kabaev

------------------------------

Date: Wed, 19 Feb 2003 13:02:34 -0600
From: David Syphers <dsyp...@uchicago.edu>
Subject: Re: IPFW changes.

On Wednesday 19 February 2003 10:20 am, IAccounts wrote:
> 1: What is the best FBSD list for finding out who (if anyone) is also
> working on IPFW and what new features are planned, and;

The IPFW list could help (freebs...@freebsd.org). To see who is working on
it, look at the commit logs (e.g.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ipfw.c). Luigi Rizzo does
a lot of the work with it.

> 2: Where can the source files for IPFW be found on a clean install? I do
> have IPFW source files on my Thinkpad, but only in the compile directory.
> (Indicating that they appeared only AFTER I compiled my own custom
> kernel).

If you installed a source tree in the standard place (/usr/src), look in
/usr/src/sbin/ipfw.

- -David

- --
http://www.seektruth.org

Astronomy and Astrophysics Center
The University of Chicago

------------------------------

Date: Wed, 19 Feb 2003 20:30:28 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: debugging a repeating panic that does not produce a dump

Mike Tancsa <mi...@sentex.net> writes:
> Fatal trap 12: page fault while in kernel mode
> mp_lock = 00000002; cpuid = 0; lapic.id = 01000000
> fault virtual address = 0xc6efa8e8

Hmm, different fault address this time.

> (kgdb) up 6
> #6 0xc0174830 in makedev (x=28, y=160) at /usr/src/sys/kern/kern_conf.c:207

These numbers look perfectly valid (cuaia0). The only explanation I
can think of is some kind of race, or some kind of corruption.
Hopefully somebody more clued than myself will be able to figure it
out.

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Wed, 19 Feb 2003 14:43:19 -0500
From: Mike Tancsa <mi...@sentex.net>
Subject: Re: debugging a repeating panic that does not produce a dump

It only happens when periodic runs, but it on occasion skips a day. Eg.
yesterday it did not do it. It only started happening post Jan28th. I can
brutalize the server with repeated buildworlds (-j2 through 8) and it is
always successful. Its only on periodic that it dies and find is always
the process running. Its only with SMP as well on this 'oldish' machine

---Mike

At 08:30 PM 19/02/2003 +0100, Dag-Erling Smorgrav wrote:
>Mike Tancsa <mi...@sentex.net> writes:
> > Fatal trap 12: page fault while in kernel mode
> > mp_lock = 00000002; cpuid = 0; lapic.id = 01000000
> > fault virtual address = 0xc6efa8e8
>
>Hmm, different fault address this time.
>
> > (kgdb) up 6
> > #6 0xc0174830 in makedev (x=28, y=160) at
> /usr/src/sys/kern/kern_conf.c:207
>
>These numbers look perfectly valid (cuaia0). The only explanation I
>can think of is some kind of race, or some kind of corruption.
>Hopefully somebody more clued than myself will be able to figure it
>out.
>
>DES
>--
>Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Wed, 19 Feb 2003 22:20:12 +0100
From: Michael Ranner <mra...@inode.at>
Subject: scan_ffs for UFS2

- --Boundary-00=_MU/U+5seNB+VrtY
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello!

I am trying to learn scan_ffs (original from OpenBSD, ported to FreeBSD
by Robert Watson) about UFS2 on 5-CURRENT, but it will not find the
Superblock and I dont understand exactly both for loops, especially
that 512 byte increment.

Scan_ffs is a system tool from OpenBSD to recover erased disklabels
from your hard drive.

Thanks for your input.

- --
/\/\ichael Ranner

mra...@jawa.at - mra...@bitonline.cc - webm...@mariazell.at
- ----------------------------------------------------------------------
JAWA Management Software GmbH - http://www.jawa.at/
Liebenauer Hauptstrasse 2oo - A-8041 Graz
Tel +43 316 403274 21 - Fax +43 316 403274 10
- ----------------------------------------------------------------------
Mariazell Online - http://www.mariazell.at/
- ----------------------------------------------------------------------

- -----BEGIN GEEK CODE BLOCK-----
GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS++++$ P++>+++$ L-(+)$ E---
W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+>++ PE(-) Y+ PGP(-)
t+ 5+ X+++(++++) R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y?
- ------END GEEK CODE BLOCK------

- --Boundary-00=_MU/U+5seNB+VrtY
Content-Type: text/x-csrc;
charset="us-ascii";
name="scan_ffs.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="scan_ffs.c"

/* $OpenBSD: scan_ffs.c,v 1.8 2002/07/03 22:32:33 deraadt Exp $ */

/*
* Copyright (c) 1998 Niklas Hallqvist, Tobias Weingartner
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by Tobias Weingartner.
* 4. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

#include <sys/types.h>
#include <sys/param.h>
#include <sys/fcntl.h>
#ifdef __FreeBSD__
#include <ufs/ufs/dinode.h>
#endif
#include <ufs/ffs/fs.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <err.h>
#if 0
#include <util.h>
#endif

#ifdef __FreeBSD__
#define SBSIZE SBLOCKSIZE
#endif
#define SBCOUNT 64 /* XXX - Should be configurable */

/* Flags to control ourselves... */
#define FLAG_VERBOSE 1
#define FLAG_SMART 2
#define FLAG_LABELS 4

int
ufsscan(int fd, daddr_t beg, daddr_t end, int flags)
{
static char lastmount[MAXMNTLEN];
static u_int8_t buf[SBSIZE * SBCOUNT];
struct fs *sb;
daddr_t blk, lastblk;
int n;

lastblk = -1;
memset(lastmount, 0, MAXMNTLEN);

for (blk = beg; blk <= ((end<0)?blk:end); blk += (SBCOUNT*SBSIZE/512)){
memset(buf, 0, SBSIZE * SBCOUNT);
if (lseek(fd, (off_t)blk * 512, SEEK_SET) < 0)
err(1, "lseek");
if (read(fd, buf, SBSIZE * SBCOUNT) < 0)
err(1, "read");

for (n = 0; n < (SBSIZE * SBCOUNT); n += 512){
sb = (struct fs*)(&buf[n]);
if ((sb->fs_magic == FS_UFS1_MAGIC) ||
(sb->fs_magic == FS_UFS2_MAGIC)) {
if (flags & FLAG_VERBOSE)
printf("block %d id %x,%x size %d\n",
blk + (n/512), sb->fs_id[0],
sb->fs_id[1], sb->fs_size);

if (((blk+(n/512)) - lastblk) == (SBSIZE/512)) {
if (flags & FLAG_LABELS ) {
#ifdef __FreeBSD__
printf("X: %lld %lld 4.2BSD %ld %ld %ld # %s\n",
#else
printf("X: %d %d 4.2BSD %d %d %d # %s\n",
#endif
(daddr_t)((off_t)sb->fs_size *
sb->fs_fsize / 512),
blk+(n/512)-(2*SBSIZE/512),
sb->fs_fsize, sb->fs_bsize,
sb->fs_old_cpg, lastmount);
} else {
#ifdef __FreeBSD__
printf("ufs1 at %lld size %lld mount %s time %s\n",
#else
printf("ffs1 at %d size %lld mount %s time %s\n",
#endif
blk+(n/512)-(2*SBSIZE/512),
(long long)(off_t)sb->fs_size *
sb->fs_fsize,
lastmount, ctime((time_t *)&sb->fs_time));
}

if (flags & FLAG_SMART) {
off_t size = (off_t)sb->fs_size *
sb->fs_fsize;

if ((n + size) < (SBSIZE * SBCOUNT))
n += size;
else {
blk += (size/512 -
(SBCOUNT*SBCOUNT));
break;
}
}
}

/* Update last potential FS SBs seen */
lastblk = blk + (n/512);
memcpy(lastmount, sb->fs_fsmnt, MAXMNTLEN);
}
}
}
return(0);
}

void
usage(int code)
{
extern char *__progname;

fprintf(stderr, "usage: %s [-lsv] [-b begin] [-e end] device\n",
__progname);
exit(code);
}

int
main(int argc, char *argv[])
{
#ifdef __FreeBSD__
char *name;
#endif
int ch, fd, flags = 0;
daddr_t beg = 0, end = -1;

while ((ch = getopt(argc, argv, "lsvb:e:")) != -1)
switch(ch) {
case 'b':
beg = atoi(optarg);
break;
case 'e':
end = atoi(optarg);
break;
case 'v':
flags |= FLAG_VERBOSE;
break;
case 's':
flags |= FLAG_SMART;
break;
case 'l':
flags |= FLAG_LABELS;
break;
default:
usage(1);
/* NOTREACHED */
}
argc -= optind;
argv += optind;

if (argc != 1)
usage(1);

#ifdef __FreeBSD__
if (argv[0][0] != '/') {
if (asprintf(&name, "/dev/%s", argv[0]) == -1)
err(1, "%s", argv[1]);
} else
name = argv[0];
fd = open(name, O_RDONLY);
#else
fd = opendev(argv[0], O_RDONLY, OPENDEV_PART, NULL);
#endif
if (fd < 0)
err(1, "%s", argv[1]);
#ifdef __FreeBSD__
if (name != argv[0])
free(name);
#endif

return (ufsscan(fd, beg, end, flags));
}

- --Boundary-00=_MU/U+5seNB+VrtY--

------------------------------

Date: Wed, 19 Feb 2003 23:53:30 +0100
From: Michael Ranner <mra...@inode.at>
Subject: Re: scan_ffs for UFS2

- --Boundary-00=_qrAV+wBiKCp/hcI
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Am Mittwoch, 19. Februar 2003 22:20 schrieb Michael Ranner:
> Hello!
>
> I am trying to learn scan_ffs (original from OpenBSD, ported to FreeBSD
> by Robert Watson) about UFS2 on 5-CURRENT, but it will not find the
> Superblock and I dont understand exactly both for loops, especially
> that 512 byte increment.
>

Ok, now scan_ffs can detect a UFS2 filesystem, but scan_ffs does
not calculate the correct offset for the disklabel. Further I do
not unterstand the "smart" feature of scan_ffs fully at the moment.

Where to I find CPG in an UFS2 superblock? How can I detect, if
scan_ffs should display fs_old_cpg or the new cpg value. Which
fields hold the new cpg value in the superblock?

Regards,

- --
/\/\ichael Ranner

- --Boundary-00=_qrAV+wBiKCp/hcI
Content-Type: text/x-csrc;
charset="iso-8859-1";
name="scan_ffs.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="scan_ffs.c"

/* $OpenBSD: scan_ffs.c,v 1.8 2002/07/03 22:32:33 deraadt Exp $ */

#ifdef __FreeBSD__
#define SBSIZE SBLOCKSIZE
#endif
#define SBCOUNT 64 /* XXX - Should be configurable */

/* Flags to control ourselves... */
#define FLAG_VERBOSE 1
#define FLAG_SMART 2
#define FLAG_LABELS 4

int
ufsscan(int fd, daddr_t beg, daddr_t end, int flags)
{
static char lastmount[MAXMNTLEN];
static u_int8_t buf[SBSIZE * SBCOUNT];
struct fs *sb;
daddr_t blk, lastblk;
int n;
#ifdef __FreeBSD__
int ufs;
#endif

lastblk = -1;
memset(lastmount, 0, MAXMNTLEN);

for (n = 0; n < (SBSIZE * SBCOUNT); n += 512){
#ifdef __FreeBSD__
ufs = 0;
#endif
sb = (struct fs*)(&buf[n]);

#ifdef __FreeBSD__
if (sb->fs_magic == FS_UFS1_MAGIC)
ufs = 1;
if (sb->fs_magic == FS_UFS2_MAGIC)
ufs = 2;

if (ufs > 0) {
#else
if (sb->fs_magic == FS_MAGIC)
#endif
if (flags & FLAG_VERBOSE)
printf("block %d id %x,%x size %d\n",
blk + (n/512), sb->fs_id[0],
sb->fs_id[1], sb->fs_size);

#ifdef __FreeBSD__
if (((blk+(n/512)) - lastblk) == (SBSIZE*ufs/512)) {
#else
if (((blk+(n/512)) - lastblk) == (SBSIZE/512)) {
#endif
if (flags & FLAG_LABELS ) {
#ifdef __FreeBSD__
printf("X: %lld %lld 4.2BSD %ld %ld %ld # %s\n",
#else
printf("X: %d %d 4.2BSD %d %d %d # %s\n",
#endif
(daddr_t)((off_t)sb->fs_size *
sb->fs_fsize / 512),
blk+(n/512)-(2*SBSIZE/512),
sb->fs_fsize, sb->fs_bsize,
#ifdef __FreeBSD__
sb->fs_old_cpg, lastmount);
} else {
printf("ufs%d at %lld size %lld mount %s time %s\n",
ufs,
#else
sb->fs_cpg, lastmount);
} else {
printf("ffs at %d size %lld mount %s time %s\n",
#endif
blk+(n/512)-(2*SBSIZE/512),
(long long)(off_t)sb->fs_size *
sb->fs_fsize,
lastmount, ctime((time_t *)&sb->fs_time));
}

if (flags & FLAG_SMART) {
off_t size = (off_t)sb->fs_size *
sb->fs_fsize;

if ((n + size) < (SBSIZE * SBCOUNT))
n += size;
else {
blk += (size/512 -
(SBCOUNT*SBCOUNT));
break;
}
}
}

/* Update last potential FS SBs seen */
lastblk = blk + (n/512);
memcpy(lastmount, sb->fs_fsmnt, MAXMNTLEN);
}
}
}
return(0);
}

void
usage(int code)
{
extern char *__progname;

fprintf(stderr, "usage: %s [-lsv] [-b begin] [-e end] device\n",
__progname);
exit(code);
}

int
main(int argc, char *argv[])
{
#ifdef __FreeBSD__
char *name;
#endif
int ch, fd, flags = 0;
daddr_t beg = 0, end = -1;

if (argc != 1)
usage(1);

return (ufsscan(fd, beg, end, flags));
}

- --Boundary-00=_qrAV+wBiKCp/hcI--

------------------------------

Date: Wed, 19 Feb 2003 15:10:09 -0800
From: Yevgeniy Aleynikov <eug...@infospace.com>
Subject: Re: bleh. Re: ufs_rename panic

Just reminder that this problem is local kernel panic DoS (which can do
filesystem corruption) with very simple trigger code and it still exists.

And it's been almost 2 years since i wrote about it.

Workaround (commenting out panic call) doesnt fix the problem.
Server still crashes (not so often though) from virtual memory failures
like this:

panic: vm_fault: fault on nofault entry, addr: d0912000
mp_lock = 01000002; cpuid = 1; lapic.id = 00000000
boot() called on cpu#1

(kgdb) bt
#0 0xc0175662 in dumpsys ()
#1 0xc017542c in boot ()
#2 0xc0175894 in poweroff_wait ()
#3 0xc01e7c18 in vm_fault ()
#4 0xc0219d32 in trap_pfault ()
#5 0xc021990b in trap ()
#6 0xc01e008a in ufs_dirrewrite ()
#7 0xc01e31a4 in ufs_rename ()
#8 0xc01e4645 in ufs_vnoperate ()
#9 0xc01a9121 in rename ()
#10 0xc021a44d in syscall2 ()
#11 0xc02077cb in Xint0x80_syscall ()

How can i help to resolve this problem ASAP?

Thanks!

Matt Dillon wrote:
> Well, I've gone through hell trying to fix the rename()/rmdir()/remove()
> races and failed utterly. There are far more race conditions then even
> my last posting indicated, and there are *severe* problems fixing NFS
> to deal with even Ian's suggestion... it turns out that NFS's nfs_namei()
> permanently adjusts the mbuf while processing the path name, making
> restarts impossible.
>
> The only solution is to implement namei cache path locking and formalize
> the 'nameidata' structure, which means ripping up a lot of code because
> nearly the entire code base currently plays with the contents of
> 'nameidata' willy-nilly. Nothing else will work. It's not something
> that I can consider doing now.
>
> In the mean time I am going to remove the panic()'s in question. This
> means that in ufs_rename() the machine will silently ignore the race
> (not do the rename) instead of panic. It's all that can be done for
> the moment. It solve the security/attack issue. We'll have to attack
> the races as a separate issue. The patch to remove the panics is utterly
> trivial and I will commit it after I test it.
>
> -Matt
>
>
>

Discover what you can do.TM

------------------------------

Date: Thu, 20 Feb 2003 11:16:21 +1100 (EST)
From: jacob rhoden <jrh...@unimelb.edu.au>
Subject: modern (usb) webcam support?

My searches for information on webcam have not found much, except for some
sites which say FreeBSD does not support USB web cameras.

Is anyone currently working on support for this? Does anyone have any
ideas about where one could go to get information about where to start
if one was to start writing a driver?

(I am about to buy a webcam for use in windows, it would be nice if I
could choose a webcam which someone is either writing a driver for
or knows where i coudl get information on them so that I could
try and write one).

Any info appreciated!

- jacob

_______________________________________________________
Jacob Rhoden Phone: +61 3 9844 6102
ITS Division Email: jrh...@unimelb.edu.au
Melbourne University Mobile: +61 403 788 386

------------------------------

Date: Thu, 20 Feb 2003 08:01:39 +1000 (est)
From: Andrew MacIntyre <and...@bullseye.apana.org.au>
Subject: RE: Hi!Dear FreeBSD!

On Wed, 19 Feb 2003, Paul Robinson wrote:

> Seriosuly Terry, I can't tell if you were joking or not, but nobody is going
> to play with opengis stuff, just because it would be a "neat" way of showing
> where user groups are. :-)

No, but there are active OSS GIS packages - GRASS comes to mind, and I
think UMN's MapServer is also OSS.

- --
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: and...@bullseye.apana.org.au | Snail: PO Box 370
and...@pcug.org.au | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia

------------------------------

Date: Wed, 19 Feb 2003 17:01:35 -0800
From: Kirk McKusick <mcku...@beastie.mckusick.com>
Subject: Re: bleh. Re: ufs_rename panic

The potentially slow, but utterly effective way to fix this race
is to only allow one rename at a time per filesystem. It is
implemented by adding a flag in the mount structure and using
it to serialize calls to rename. When only one rename can happen
at a time, the race cannot occur.

If this proves to be too much of a slow down, it would be possible
to only serialize directory renames. As these are (presumably) much
rarer the slow down would be less noticable.

Kirk McKusick

=-=-=-=-=-=

Date: Wed, 19 Feb 2003 15:10:09 -0800
From: Yevgeniy Aleynikov <eug...@infospace.com>
To: Matt Dillon <dil...@earth.backplane.com>
CC: Kirk McKusick <mcku...@mckusick.com>, Ian Dowse <ied...@maths.tcd.ie>,
pe...@FreeBSD.ORG, ac...@FreeBSD.ORG, Ken Pizzini <ke...@infospace.com>,
hac...@FreeBSD.ORG, security...@FreeBSD.ORG, nec...@FreeBSD.ORG,
jed...@FreeBSD.ORG, rwa...@FreeBSD.ORG, i...@FreeBSD.ORG,
securi...@FreeBSD.ORG, w...@FreeBSD.ORG, gu...@FreeBSD.ORG
Subject: Re: bleh. Re: ufs_rename panic
X-ASK-Info: Confirmed by User

Just reminder that this problem is local kernel panic DoS (which can do
filesystem corruption) with very simple trigger code and it still exists.

And it's been almost 2 years since i wrote about it.

Workaround (commenting out panic call) doesnt fix the problem.
Server still crashes (not so often though) from virtual memory failures
like this:

panic: vm_fault: fault on nofault entry, addr: d0912000
mp_lock = 01000002; cpuid = 1; lapic.id = 00000000
boot() called on cpu#1

How can i help to resolve this problem ASAP?

Thanks!

Discover what you can do.TM

------------------------------

Date: Wed, 19 Feb 2003 19:21:09 -0600 (CST)
From: Mark Hittinger <bu...@pu.net>
Subject: Re: bleh. Re: ufs_rename panic

> McKusick wrote:
> The potentially slow, but utterly effective way to fix this race
> is to only allow one rename at a time per filesystem.

Can we serialize unprivileged renames per mount as an alternate work around?

Later

Mark Hittinger
bu...@pu.net

------------------------------

Date: Wed, 19 Feb 2003 18:04:59 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop

Vaclav Haisman wrote:
> > man 2 abort
> >
> > -- Terry
>
> logout ~/tmp>man 2 abort
> No entry for abort in section 2 of the manual
>
> Besides, this doesn't explain anything. I see I haven't asked any question in
> my previous post. So, why does FreeBSD behave different?

Because POSIX mandates that it do so?

man 3 signal tells us:

The handled signal is unblocked when the function returns and the process
continues from where it left off when the signal occurred. Unlike previ-
ous signal facilities, the handler func() remains installed after a sig-
nal has been delivered.

If you want this to not happen, you should explicitly uninstall the
handler, or you should call abort(3) (or _exit(2), if you don't want
to leave a core dump).

- -- Terry

------------------------------

Date: Wed, 19 Feb 2003 15:28:15 -0600
From: "Brandon D. Valentine" <bra...@dvalentine.com>
Subject: Re: scan_ffs for UFS2

[ Originally crossposted to -hackers and -fs. This reply Bcc'd to
- -hackers, followups to -fs. ]

On Wed, Feb 19, 2003 at 10:20:12PM +0100, Michael Ranner wrote:
> Scan_ffs is a system tool from OpenBSD to recover erased disklabels
> from your hard drive.

Forgive me if I'm being dense, but what features does scan_ffs provide
that are not a subset of the features provided by gpart[0]?

Seems like a duplicate wheel to me.

[0] - http://www.stud.uni-hannover.de/user/76201/gpart/ or [1]
[1] - ports/sysutils/gpart

Brandon D. Valentine
- --
bra...@dvalentine.com http://www.geekpunk.net

"We've been raised on replicas of fake and winding roads, and day after day up
on this beautiful stage we've been playing tambourine for minimum wage, but we
are real; I know we are real." -- David Berman

------------------------------

Date: Thu, 20 Feb 2003 03:30:34 +0100 (CET)
From: Vaclav Haisman <V.Ha...@sh.cvut.cz>
Subject: Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop

> Because POSIX mandates that it do so?
>
> man 3 signal tells us:
>
> The handled signal is unblocked when the function returns and the process
> continues from where it left off when the signal occurred. Unlike previ-
> ous signal facilities, the handler func() remains installed after a sig-
> nal has been delivered.
>
> If you want this to not happen, you should explicitly uninstall the
> handler, or you should call abort(3) (or _exit(2), if you don't want
> to leave a core dump).

Even though this is probably about my misunderstanding of things I post here
the test I used.

Vaclav Haisman

#include <signal.h>
#include <stdlib.h>
#include <iostream>

int f (int * x);

void handler (int, siginfo_t * info, ucontext_t * uap)
{
std::cerr << "SIGSEGV has been caught" << std::endl;
struct sigaction mysig;
mysig.sa_handler = SIG_DFL;
mysig.sa_sigaction = NULL;
mysig.sa_flags = 0;
if (sigaction(SIGSEGV, &mysig, NULL) == -1)
{
std::cerr << "Error in sigaction()" << std::endl;
abort();
}

f((int*)NULL);

/*mysig.sa_handler = SIG_DFL;
mysig.sa_sigaction = NULL;
mysig.sa_flags = 0;
if (sigaction(SIGSEGV, &mysig, NULL) == -1)
{
std::cerr << "Error in sigaction()" << std::endl;
return;
}*/
}

int f (int * x)
{
int y = *x;
return y;
}

int main ()
{
struct sigaction mysig;
mysig.sa_handler = NULL;
mysig.sa_sigaction = (void (*)(int, __siginfo *, void *))handler;
sigemptyset(&mysig.sa_mask);
sigaddset(&mysig.sa_mask, SIGSEGV);
mysig.sa_flags = SA_SIGINFO;

if (sigaction(SIGSEGV, &mysig, NULL) == -1)
{
std::cerr << "Error in sigaction()" << std::endl;
return 1;
}

int * x = NULL;
int y;
y = f(x);
return y;
}

------------------------------

Date: Wed, 19 Feb 2003 23:50:43 +0100
From: Marko Zec <z...@tel.fer.hr>
Subject: Re: Per-jail CPU limits?

Mooneer Salem wrote:

> Hello,
>
> I've been looking at the kernel source, in particular the scheduler
> in the past few weeks. I found a place in kern_switch.c where per-jail
> CPU controls could be added (in particular, in the kse_reassign() function).
> >From looking at that function, I could loop through td_runq until I either:
>
> 1. Found a thread that isn't jailed,
> 2. Found a jailed thread, but determine it's safe to let it run because
> it does not go over sysctl-defined limits, or
> 3. Find no usable thread, in which case the KSE would theoretically switch
> over to the idle process until it's time to repeat the process again.
>
> This should allow the use of the standard FreeBSD scheduler, except for
> the jail limits. The question is, how do we determine the total CPU used
> by the jail? I found the kg_estcpu entry in struct ksegrp, which the thread
> has a pointer to, but would that be enough? Is there a different approach we
> could take that would solve this problem?

A rudimentary CPU usage limiting on per virtual image basis (virtual image can
be considered a jailed environment with its own independent network stack
instance) was implemented using an algorithm very similar to what you proposed,
so you might check the original patch against 4.7-RELEASE kernel at
http://www.tel.fer.hr/zec/BSD/vimage/index.html
As I didn't have enough time yet to make a usable port to 5.0, my assumptions
regarding programming in -CURRENT might be slightly wrong, but I guess you'll
have to:

1) extend the jail structure to hold CPU usage accounting information on
per-jail basis;
2) update this field when doing normal per-process CPU accounting in
kern/kern_clock.c / statclock();
3) do some decay filtering to ensure stability and "smoothness" of the acquired
per-jail CPU usage data;
4) in kern/kern_switch.c / chooseproc() implement the steps you originally
defined as 1. to 3.
5) on each HZ tick in kern/kern_synch.c / schedclock() check the current
process/jail hasn't consumed more CPU time than it was allowed, and if it has,
reschedule a new process. This is necessary to ensure acceptable interactive
response for processes/jails running with administratively restricted CPU
resources, otherwise the process could consume the entire time quantum (10 ms by
default), and would than have to wait annoyingly long in order for the average
per-jail CPU usage to drop under the defined threshold.
6) optionally, extend procrunnable() in kern/kern_switch.c to return 0 in case
there are over-the-CPU-limit processes in active run queue, in order for idle
loop to be able to execute the halt instruction, instead of unnecessarily
looping endlessly through chooseproc() until the next clock tick. This can be
especially useful on laptops where you don't want a process with CPU usage limit
to actually burn the battery power in idle loop, and also burn your lap at the
same time :)

Note: everything I wrote is based on my experience with 4.7-R kernel, in 5.0
many things have changed replacing process with threads as the atomic entities
for scheduling, so probably the function naming and some logic has changed
also...

Marko

------------------------------

Date: Wed, 19 Feb 2003 20:35:24 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop

Vaclav Haisman wrote:
> > If you want this to not happen, you should explicitly uninstall the
> > handler, or you should call abort(3) (or _exit(2), if you don't want
> > to leave a core dump).
>
> Even though this is probably about my misunderstanding of things I post here
> the test I used.

[ ... ]

> void handler (int, siginfo_t * info, ucontext_t * uap)
> {
> std::cerr << "SIGSEGV has been caught" << std::endl;
> struct sigaction mysig;
> mysig.sa_handler = SIG_DFL;
> mysig.sa_sigaction = NULL;
> mysig.sa_flags = 0;
> if (sigaction(SIGSEGV, &mysig, NULL) == -1)
> {
> std::cerr << "Error in sigaction()" << std::endl;
> abort();
> }
>
> f((int*)NULL);

This is not legal.

> /*mysig.sa_handler = SIG_DFL;

[ ... commented out handler reset code ... ]

I don't understand why you do this.

Performing a NULL pointer dereference in a signal handler for a
signal which is generated by a NULL pointer dereference is not
really a good idea. The signal handler, once entered, masks the
signal. It's possible that the signal handler itself is reset
on exit (this is implementation defined).

The main problem here is that signals are not events, they are
persistent conditions. FreeBSD does not support POSIX queued
signals, at this time, so it's not possible to treat them as
events under any circumstances.

Though there may be issues with stack unwinding, with C++, I
don't think that's your problem. You could try implementing the
same program in C, and determine if it has the same symptoms.

You may also try adding:

memset( &mysig, 0, sizeof(struct sigaction));

after the declaration, but prior to your use of the stack
variable. Specifically, I do not see you setting the sa_mask
structure member anywhere, and that could be Bad(tm), particularly
if you were setting masking on the signal that triggered the call,
and then re-triggering it. It's conceivable that the implementation
would check the sa_mask before resetting the handler.

Also, note that any use of functions not in this list:

Base Interfaces

exit() access() alarm() cfgetispeed() cfgetospeed() cfsetispeed()
cfsetospeed() chdir() chmod() chown() close()
creat() dup() dup2() execle() execve() fcntl() fork() fpathconf()
fstat() fsync() getegid() geteuid() getgid() getgroups() getpgrp()
getpid() getppid() getuid() kill() link() lseek() mkdir() mkfifo()
open() pathconf() pause() pipe() raise() read() rename() rmdir()
setgid() setpgid() setsid() setuid() sigaction() sigaddset()
sigdelset() sigemptyset() sigfillset () sigismember() signal()
sigpending() sigprocmask() sigsuspend() sleep() stat() sysconf()
tcdrain() tcflow() tcflush() tcgetattr() tcgetpgrp() tcsendbreak()
tcsetattr() tcsetpgrp() time() times() umask() uname()
unlink() utime() wait() waitpid() write()

Realtime Interfaces

aio_error() clock_gettime() sigpause() timer_getoverrun()
aio_return() fdatasync() sigqueue() timer_gettime()
aio_suspend() sem_post() sigset() timer_settime()

are specifically considered "unsafe" by POSIX, and their behaviour is
undefined. Specifically:

All functions not in the above table are considered to be
unsafe with respect to signals. In the presence of signals,
all functions defined by this specification will behave as
defined when called from or interrupted by a signal-catching
function, with a single exception: when a signal interrupts
an unsafe function and the signal-catching function calls an
unsafe function, the behaviour is undefined.

I'd say that was exactly the case you were testing with the function
"f", and by using "cout" to do I/O in the handler.

- -- Terry

------------------------------

Date: Thu, 20 Feb 2003 07:29:16 +0100
From: p...@phk.freebsd.dk
Subject: Re: debugging a repeating panic that does not produce a dump

In message <5.2.0.9.0.200302...@marble.sentex.ca>, Mike Tancsa wr
ites:
>
>It only happens when periodic runs, but it on occasion skips a day. Eg.
>yesterday it did not do it. It only started happening post Jan28th. I can
>brutalize the server with repeated buildworlds (-j2 through 8) and it is
>always successful. Its only on periodic that it dies and find is always
>the process running. Its only with SMP as well on this 'oldish' machine

This sounds like the double-fault my laptop does every so often.

- --
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

------------------------------

Date: Thu, 20 Feb 2003 09:45:19 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: debugging a repeating panic that does not produce a dump

Mike Tancsa <mi...@sentex.net> writes:
> It only happens when periodic runs, but it on occasion skips a day.
> Eg. yesterday it did not do it. It only started happening post
> Jan28th. I can brutalize the server with repeated buildworlds (-j2
> through 8) and it is always successful. Its only on periodic that it
> dies and find is always the process running. Its only with SMP as well
> on this 'oldish' machine

Hmm, it would be great to know what process was running when it
crashed. Unfortunately, I don't know how to do that post-KSE...

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Thu, 20 Feb 2003 12:10:27 +0100
From: Sebastian Lederer <s...@linast.de>
Subject: Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop

On Wed, 19 Feb 2003 08:51:23 -0800
Wes Peters <w...@softweyr.com> wrote:

> On Wednesday 19 February 2003 04:43, Vaclav Haisman wrote:
[...]
> > Besides, this doesn't explain anything. I see I haven't asked any
> > question in my previous post. So, why does FreeBSD behave different?
>
> Because it *is* different? If you want to catch a signal and be
> able to handle it, the other two are wrong, are they not?
>

[...]

I think the real question here is, what happens if a SIGSEGV occurs when
SIGSEGV is already blocked (like inside the handler)?

See the simple test program below. It seems that on FreeBSD, the process
just loops on the faulting instruction, whereas Linux and Solaris
kill the process, producing a SIGSEGV exit code.

I don't know what the correct behaviour is. It is possible to
recover from such a SIGSEGV loop from inside the process, using a timer
signal, for example, so you might say it is legal to do this and
FreeBSD has the correct behaviour. On the other hand, it's most likely
just a badly coded crashed program that would waste all free CPU cycles
if not killed right away.

- - Sebastian Lederer

- ---
#include <signal.h>
#include <stdio.h>
void crash()
{
int *p=NULL;

*p=0xdead;
}

int main(int argc, char **argv)
{
sigset_t set;
sigset_t oset;

sigemptyset(&set);
sigaddset(&set,SIGSEGV);

sigprocmask(SIG_SETMASK,&set,&oset);
crash();
sigprocmask(SIG_SETMASK,&oset,NULL);
return 0;
}
- ---

------------------------------

Date: Thu, 20 Feb 2003 15:56:12 +0100
From: Andrea Franceschini <andrea.fr...@postecom.it>
Subject: Wireless PCI card

Hi All!

Browsing trough the mailing-list archive i've found a thread about a problem really similar to mine ( actually it was the same).
But, as often happen, that thread didn't have any follow-up.

This is part of the thread:

Alfred Perlstein <bri...@mu.org> wrote:
>* Chad David <dav...@acns.ab.ca> [011227 21:39] wrote:
>> On Thu, Dec 27, 2001 at 11:31:43AM -0800, Brooks Davis wrote:
>> > On Thu, Dec 27, 2001 at 12:10:32PM -0700, Chad David wrote:
>> >
>> > What you'll want to do is edit src/sys/dev/wi/if_wi.c, add an appropriate
>> > entry to the definition of pci_ids for your card, and recompile your
>> > kernel. If that works, you're all set.
>> >
>>
>> I took the advice, and now the attach is failing because the card doesn't
>> appear to have any I/O Space (WI_PCI_IORES). Both the local registers and
>> attribute memory are in the resource list, but no IO space. I've debugged
>> it to the limits of my ability, and now any advice on how to continue would
>> be welcome.
>>
>> hacked dmesg out:
>>
>> wi0: <SOHOWARE NCP130 PCI IEEE 802.11b> port 0xa400-0xa43f,0xa800-0xa80f irq 10 at device 11.0 on pci0
>> wi0: about to call wi_alloc(dev, WI_PCI_IORES)
>> wi0: type=1 rid=0
>> wi0: type=4 rid=24
>> wi0: type=4 rid=20
>> wi0: type = 4, rid = 28
>> wi0: No I/O space?!
>> device_probe_and_attach: wi0 attach returned 6
>>
>> Brooks is probably at home with his family, and not reading his email like
>> a sensible person, so I thought I would toss this out to the members at
>> large again, and see if anybody had any ideas... Alfred? you are the last
>> person to touch if_wi.c, doesn't that make it yours ;-).
>
>hahaha, no.
>
>Uh, it looks like you don't have the standard PCI card that people
>are getting, mine looks like this:
>wi0: <PRISM2STA PCI WaveLAN/IEEE 802.11> port 0xff00-0xff3f,0xfc00-0xfc7f mem 0xffbee000-0xffbeefff irq 11 at device 13.0 on pci0
>
>The fact that your card doesn't have a memory map concerns me that
>it's not what we're expecting. Where is the vendor's website?
>Can you ask them for more info?

I'm wondering if, by now, someone resolved this issue and how.

The thing really strange about all this ,is that the card is among those declared as supported by 'wi' driver.
I tried troubleshooting the problem on my own ,but i miss the very basilar knowledge about the PCI addressing... so if you cannot help me with problem i would appreciate any hints/links about PCI programming..

Thanks.

------------------------------

Date: Thu, 20 Feb 2003 10:05:52 -0500 (EST)
From: Robert Watson <rwa...@freebsd.org>
Subject: Re: Multi-level jailing.

On Mon, 17 Feb 2003, Pawel Jakub Dawidek wrote:

> I have prepared patch for jail functionality against FreeBSD
> 5.0-CURRENT. It provides multi-level jailing and multiple ips for
> jails.

Sounds cool, although I haven't had a chance to read the patch yet.
Question: how did you handle the problem (if at all) that INADDR_ANY
doesn't perform a wildcard binding with multiple IPs in the same jail?
It's not strictly required that it be handled, but it was always one of
the semantic problems I bumped into when I experimented with more IPs. A
single-IP jail "works" because it maps INADDR_ANY into the only IP
available. I'll try to get a box up and running with these changes in the
next few days and give them a spin.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
rob...@fledge.watson.org Network Associates Laboratories

------------------------------

Date: Thu, 20 Feb 2003 08:23:24 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Wireless PCI card

Andrea Franceschini wrote:
> Alfred Perlstein <bri...@mu.org> wrote:
> >Uh, it looks like you don't have the standard PCI card that people
> >are getting, mine looks like this:
> >wi0: <PRISM2STA PCI WaveLAN/IEEE 802.11> port 0xff00-0xff3f,0xfc00-0xfc7f mem 0xffbee000-0xffbeefff irq 11 at device 13.0 on pci0
> >
> >The fact that your card doesn't have a memory map concerns me that
> >it's not what we're expecting. Where is the vendor's website?
> >Can you ask them for more info?
>
> I'm wondering if, by now, someone resolved this issue and how.
>
> The thing really strange about all this ,is that the card is among
> those declared as supported by 'wi' driver. I tried troubleshooting
> the problem on my own ,but i miss the very basilar knowledge about
> the PCI addressing... so if you cannot help me with problem i would
> appreciate any hints/links about PCI programming..

So... going back to Alfred's question: what did the vendor say about
the PCI card not claiming a memory window?

- -- Terry

------------------------------

Date: Thu, 20 Feb 2003 19:00:54 +0100
From: Pawel Jakub Dawidek <ni...@garage.freebsd.pl>
Subject: Re: Multi-level jailing.

- --2hMgfIw2X+zgXrFs
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 20, 2003 at 10:05:52AM -0500, Robert Watson wrote:
+> > I have prepared patch for jail functionality against FreeBSD
+> > 5.0-CURRENT. It provides multi-level jailing and multiple ips for
+> > jails.=20
+>=20
+> Sounds cool, although I haven't had a chance to read the patch yet.
+> Question: how did you handle the problem (if at all) that INADDR_ANY
+> doesn't perform a wildcard binding with multiple IPs in the same jail?
+> It's not strictly required that it be handled, but it was always one of
+> the semantic problems I bumped into when I experimented with more IPs. A
+> single-IP jail "works" because it maps INADDR_ANY into the only IP
+> available. I'll try to get a box up and running with these changes in t=
he
+> next few days and give them a spin.

Hmm, this problem is still there, but I think that we could resolve it
by changing all code where IP is compared to INADDR_ANY, to function
like this:

int
prison_inaddr_any(struct ucred *cred, u_int32_t ip)
{
register u_int i;
register struct prison *pr =3D cred->cr_prison;

if (!jailed(cred))
return (ip =3D=3D INADDR_ANY);

for (i =3D 0; i < pr->pr_nips; ++i) {
if (pr->pr_ips[i] =3D=3D ip)
return (1);
}

return (0);
}

And remove mapping to specified IP, INADDR_ANY should stay there.

- --=20
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.

- --2hMgfIw2X+zgXrFs
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iQCVAwUBPlUX1j/PhmMH/Mf1AQFuygP5AatpA/DgGtMWTGKSUc0BKnDjmbJXp/Vx
cOs8GEg93nqHwmvH9m8K2X0hFzHAbwQ9qq5ZI/dX+aRAFa1nPxQLytS2yRlc9Uuk
x0EPhC1OTa2VHlhY1gQUF+8wRlqgspmgT8rBq8MWXLWTE6zvFD3Jr3kUgjHpvYCk
5PnoJWO7oxY=
=f1tn
- -----END PGP SIGNATURE-----

- --2hMgfIw2X+zgXrFs--

------------------------------

Date: Thu, 20 Feb 2003 11:37:20 -0800
From: Chuck Tuffli <chuck_...@agilent.com>
Subject: interrupt handler not getting called

I have a device driver for a fibre channel HBA that works correctly
with a PCI device but not a PCI-X device. The problem with the PCI-X
device is that the interrupt handler never gets involked eventhough
the chip status indicates that it is interrupting. This is using
4.7-RELEASE on a dual Xeon based system (E7500 mother board) from
SuperMicro. I loaded another OS with this same system/HBA and don't
observe this problem.

Below is an edited mptable dump. The problematic PCI-X device is
pci2:1:0 and pci2:1:1. pci3:3:0 is the PCI version of the product
which uses the same driver and does get its interrupt handler
called.

Is there any other info people want to see? Has anyone seen a problem
like this before? If not, any idea where I should start looking?

MP Config Table Header:

physical address: 0x0009fd70
signature: 'PCMP'
base table length: 380
version: 1.4
checksum: 0x55
OEM ID: ' '
Product ID: 'Kings Canyon'
OEM table pointer: 0x00000000
OEM table size: 0
entry count: 36
local APIC address: 0xfee00000
extended table length: 0
extended table checksum: 0

- -------------------------------------------------------------------------------

MP Config Base Table Entries:

- ---
Processors: APIC ID Version State Family Model Step Flags
6 0x14 BSP, usable 15 2 4 0x3febfbff
0 0x14 AP, usable 15 2 7 0xbfebfbff
1 0x14 AP, usable 15 2 7 0xbfebfbff
7 0x14 AP, usable 15 2 4 0x3febfbff
- ---
Bus: Bus ID Type
0 PCI
1 PCI
2 PCI
3 PCI
4 PCI
5 ISA
- ---
I/O APICs: APIC ID Version State Address
2 0x20 usable 0xfec00000
3 0x20 usable 0xfec80000
4 0x20 usable 0xfec80400
- ---
I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#
ExtINT active-hi edge 5 0 2 0
...
INT active-lo level 2 1:A 4 0
INT active-lo level 2 1:B 4 1
INT active-lo level 3 3:A 3 4

- --
Chuck Tuffli <chuck_tuffli AT NO_SPAM agilent DOT com>
Agilent Technologies, Storage and Networking

------------------------------

End of freebsd-hackers-digest V5 #725
*************************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message

0 new messages