jail && (ping && traceroute)
[Please Cc: me on reply] Hello, I have 2 questions: - where in code should I search for icmp socket binding prohibition in jail?; - what bad consequences will appear if I remove those checks and prohibition?. Thanks in advance! -- NEVE-RIPE, will build world for food Ukrainian FreeBSD User Group http://uafug.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
libc_r: threaded application could stuck in accept(2)
Hi!
We had a bug in our threaded application that would mistakenly close
the descriptor 0, and this triggers a bug in libc_r which I will try
to describe below.
The bug (in libc_r only, libpthread^Wlibkse is unaffected) causes a
threaded application to stuck in accept(2). libc_r makes every new
descriptor non-blocking, and uses poll(2) and thread context switching
to emulate a blocking behavior. The bug somehow causes the descriptor
to be left in a blocking mode.
Attached is the test case that demonstrates this bug (this is the
same on 4.8-STABLE and 5.1-BETA). The utility runs two threads:
the first thread prints the "alive" message every 3 seconds, and
the second thread emulates what our unfortunate application did,
i.e., open() a TCP socket, listen(), accept(), then close() it,
then mistakenly close() descriptor 0. (Closing the descriptor
0 causes the next socket() call to return 0.)
Some important notes: this bug is only applicable to descriptors
0 - 2 (stdio set), and might have something to do with the code
in uthread_fd.c. If you remove two lines that free the descriptor
0 in the attached test case, the bug won't manifest itself.
Attached also is the patch for the threaded close() function
that avoids the bug by disallowing the close() call on a
non-active descriptor.
The patch should be committed, but I'm now more interested in
what's going on inside libc_r that causes the descriptor 0 to
be left in the blocking mode. IOW, I wonder if the attached
patch is the real fix. ;)
Ah yes, when you'll run the application, it will report
which TCP port it listens to, you then connect to this port,
the application closes the connection, and on the next loop
the application gets stuck in accept().
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer.
#include
#include
#include
#include
#include
#include
#include
#include
static void *thread1(void *);
static void *thread2(void *);
int
main(void)
{
pthread_t thr1, thr2;
int r;
if ((r = pthread_create(&thr1, NULL, thread1, NULL)) != 0)
errc(1, r, "pthread_create");
if ((r = pthread_create(&thr2, NULL, thread2, NULL)) != 0)
errc(1, r, "pthread_create");
if ((r = pthread_join(thr1, NULL)) != 0)
errc(1, r, "pthread_join");
if ((r = pthread_join(thr2, NULL)) != 0)
errc(1, r, "pthread_join");
exit(0);
}
static void *
thread1(void *arg __unused)
{
for (;;) {
printf("thread 1: alive\n");
sleep(3);
}
}
static void *
thread2(void *arg __unused)
{
int s, s2;
struct sockaddr_in addr;
socklen_t addrlen;
printf("thread 2: freeing descriptor 0 (closing)\n");
close(0);
for (;;) {
if ((s = socket(AF_INET, SOCK_STREAM, 0)) == -1)
warn("thread 2: socket");
else {
printf("thread 2: socket() returned %d\n", s);
if (listen(s, 1) == -1)
warn("thread 2: listen");
else {
addrlen = sizeof(addr);
if (getsockname(s, (struct sockaddr *)&addr, &addrlen)
== -1)
warn("thread 2: getsockname");
else
printf("thread 2: listening on port %d\n",
ntohs(addr.sin_port));
printf("thread 2: calling accept() on %d\n", s);
s2 = accept(s, (struct sockaddr *)&addr, &addrlen);
if (s2 == -1)
warn("thread 2: accept");
else {
printf("thread 2: accept() returned %d,
closing\n", s2);
close(s2);
}
}
printf("thread 2: closing descriptor %d (1st)\n", s);
close(s);
printf("thread 2: closing descriptor %d (2nd)\n", s);
close(s);
}
sleep(1);
}
}
Index: uthread_close.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_close.c,v
retrieving revision 1.10.2.3
diff -u -p -r1.10.2.3 uthread_close.c
--- uthread_close.c 22 Oct 2002 14:44:02 - 1.10.2.3
+++ uthread_close.c 30 May 2003 14:13:54 -
@@ -47,7 +47,8 @@ _close(int fd)
struct stat sb;
struct fd_table_entry *entry;
- if ((fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1])) {
+ if ((fd =
Re: libc_r: threaded application could stuck in accept(2)
On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote: > We had a bug in our threaded application that would mistakenly close > the descriptor 0, and this triggers a bug in libc_r which I will try > to describe below. ... > Some important notes: this bug is only applicable to descriptors > 0 - 2 (stdio set), and might have something to do with the code > in uthread_fd.c. If you remove two lines that free the descriptor > 0 in the attached test case, the bug won't manifest itself. please have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=51535 Regards, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libc_r: threaded application could stuck in accept(2)
On Fri, 30 May 2003, Enache Adrian wrote: > On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote: > > We had a bug in our threaded application that would mistakenly close > > the descriptor 0, and this triggers a bug in libc_r which I will try > > to describe below. > ... > > Some important notes: this bug is only applicable to descriptors > > 0 - 2 (stdio set), and might have something to do with the code > > in uthread_fd.c. If you remove two lines that free the descriptor > > 0 in the attached test case, the bug won't manifest itself. > > please have a look at > > http://www.freebsd.org/cgi/query-pr.cgi?pr=51535 Yes, and PR 49087 also. If someone (Ruslan?) wants to commit them, go ahead. They are probably applicable to -stable also. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! Major commits in the tree coming soon
On Thu, 29 May 2003, [iso-8859-1] Thorsten Futrega wrote: > Dear users, > > The most important changes I'm going to commit today: > > - Remove gcc and replace it with a new TenDRA > snapshot. yay! but what about c++ support? > - Remove GNU tar. double yay! > - Fix httpd.ko to make it work on buggy AMD > processors. > - Drop support for 386 and 486 cpus. > - Remove ext2 support (GPL encumbered). > - Add perl 5.8 *and* python 2.2 to base. > - Remove Sendmail and replace it with Postfix. > mostly yawn... > If anyone has any reason why these should not be > committed, I'll give a 5 hours grace time. Send > replies > to the list. > > Thank you. > > Thorsten and the rest or the release engineering team. > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! Major commits in the tree coming soon
On Fri, 30 May 2003, Narvi wrote: [snip] Ahem.. i am very embarrassed about having sent the reply, everybody please pretend I was nowhere near the thread, pretty please? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libc_r: threaded application could stuck in accept(2)
On Fri, May 30, 2003 at 07:07:23PM +0300, Enache Adrian wrote: > On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote: > > We had a bug in our threaded application that would mistakenly close > > the descriptor 0, and this triggers a bug in libc_r which I will try > > to describe below. > ... > > Some important notes: this bug is only applicable to descriptors > > 0 - 2 (stdio set), and might have something to do with the code > > in uthread_fd.c. If you remove two lines that free the descriptor > > 0 in the attached test case, the bug won't manifest itself. > > please have a look at > > http://www.freebsd.org/cgi/query-pr.cgi?pr=51535 > Thanks, I had this same patch in my first version of the fix. Yes it works too, but do you have an insight what's going on without these fixes so that the 0..2 descriptors are left in a blocking mode? I just can't get it where this happens. P.S. I will commit both patches after the freeze is over. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer. pgp0.pgp Description: PGP signature
Re: Network stack cloning / virtualization patches
> at http://www.tel.fer.hr/zec/vimage/ you can find a set of patches > against 4.8-RELEASE kernel that provide support for network stack > cloning. The patched kernel allows multiple fully independent > network stack instances to simultaneously coexist within a single OS > kernel, providing a foundation for supporting diverse new > applications, including: > > - Enhanced virtual hosting (think of jails with its own private set of > network interfaces, IP addresses, routing tables, ipfw and dummynet > instance etc.); > - High-performance real-time network simulation / emulation; > - Fully isolated overlay VPN provisioning (using IP tunnels), including > the possibility of creating nested VPNs. > > The network stacks are embedded in new resource container entities > named "virtual images". Each process and network stack instance within > the system has to be associated with a virtual image, which in effect > becomes a light or pseudo virtual machine entity. Additional goodies > include the possibility to control some other resources besides the > network stack, most notably the independent CPU load and usage > accounting, as well as feedback-driven proportional share scheduling > among virtual images. For more details, check the above URL. > Note that the patch was designed to allow all existing applications and > utilities to run unmodified on the patched kernel, so no recompiling of > the userland is necessary. > > Hope you'll find use for the new framework :-) Has anyone stepped forward to possibly shepherd this code into the tree? I am highly interested in this code and would like to see it incorporated into the base system (read: -CURRENT, before 5.2). After looking at the TODO, I realize that this patch isn't 100% yet, but can it be broken down into a smaller set of commits? Anyone doing virtual hosting would kill to have this functionality in FreeBSD right now. -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network stack cloning / virtualization patches
* Sean Chittenden <[EMAIL PROTECTED]> [ Date: 2003-05-30 ] [ w.r.t. Re: Network stack cloning / virtualization patches ] > > at http://www.tel.fer.hr/zec/vimage/ you can find a set of patches > > against 4.8-RELEASE kernel that provide support for network stack > > cloning. The patched kernel allows multiple fully independent > > network stack instances to simultaneously coexist within a single OS > > kernel, providing a foundation for supporting diverse new > > applications, including: > > > > - Enhanced virtual hosting (think of jails with its own private set of > > network interfaces, IP addresses, routing tables, ipfw and dummynet > > instance etc.); > > - High-performance real-time network simulation / emulation; > > - Fully isolated overlay VPN provisioning (using IP tunnels), including > > the possibility of creating nested VPNs. > > > > The network stacks are embedded in new resource container entities > > named "virtual images". Each process and network stack instance within > > the system has to be associated with a virtual image, which in effect > > becomes a light or pseudo virtual machine entity. Additional goodies > > include the possibility to control some other resources besides the > > network stack, most notably the independent CPU load and usage > > accounting, as well as feedback-driven proportional share scheduling > > among virtual images. For more details, check the above URL. > > Note that the patch was designed to allow all existing applications and > > utilities to run unmodified on the patched kernel, so no recompiling of > > the userland is necessary. > > > > Hope you'll find use for the new framework :-) > > Has anyone stepped forward to possibly shepherd this code into the > tree? I am highly interested in this code and would like to see it > incorporated into the base system (read: -CURRENT, before 5.2). After > looking at the TODO, I realize that this patch isn't 100% yet, but can > it be broken down into a smaller set of commits? Has anyone looked at making the patch work with CURRENT? Does this do anything to degrade performance of UP systems with no (0?) virtualised images running? Does it make the locking situation much worse? Can it be stripped down to minimal, clean, well-architected diffs to accomplish a centralised goal, rather than a "Network+goodies, random subsystem overhaul"? Those are probably good questions for someone to know the answers to (by looking at the code, or someone trying such) before it gets too close to the tree. If this is your priority patch, hunting down someone with serious network\ stack-fu to review the diff, and whatnot, would probably be a good investment of your time in that regard. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libc_r: threaded application could stuck in accept(2)
On Fri, May 30, 2003 at 08:16:41PM +0300, Ruslan Ermilov wrote:
> On Fri, May 30, 2003 at 07:07:23PM +0300, Enache Adrian wrote:
> > On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote:
> > > We had a bug in our threaded application that would mistakenly close
> > > the descriptor 0, and this triggers a bug in libc_r which I will try
> > > to describe below.
> > ...
> > > Some important notes: this bug is only applicable to descriptors
> > > 0 - 2 (stdio set), and might have something to do with the code
> > > in uthread_fd.c. If you remove two lines that free the descriptor
> > > 0 in the attached test case, the bug won't manifest itself.
> >
> > please have a look at
> >
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=51535
> >
> Thanks, I had this same patch in my first version of the fix.
> Yes it works too, but do you have an insight what's going on
> without these fixes so that the 0..2 descriptors are left in
> a blocking mode? I just can't get it where this happens.
>
OK, I now know what's going on here. Without patches, a
second close(0) calls _FDLOCK(0, ...) which calls
_thread_fd_table_init(0). In this functions, the
following condition becomes false
/* Get the flags for the file: */
if (((fd >= 3) || (_pthread_stdio_flags[fd] == -1)) &&
(entry->flags = __sys_fcntl(fd, F_GETFL, 0)) == -1) {
ret = -1;
}
due to _pthread_stdio_flags[0] != -1, and we succeed
to the "else" block which eventually installs the "entry"
as _thread_fd_table[0].
Then, the call to socket() calls _thread_fd_table_init(0)
again, but since it detects that the memory is already
allocated (for non-existing descriptor 0), it doesn't
try to set it to non-blocking mode.
With my patch, we just don't allow the second call to
_thread_fd_table_init(0) when descriptor 0 doesn't exist.
With your patch that resets _pthread_stdio_flags[0] to -1
on close, attempting to close(0) for the second time
evaluates the condition above to true, and then
__sys_fcntl(0, F_GETFL, 0) returns -1 (EBADF), and
then the "entry" is free()'ed. Then, on the next socket()
call, _thread_fd_table_init(0) allocates the memory
for fd 0, and sets it to non-blocking mode.
> P.S. I will commit both patches after the freeze is over.
>
Your patch also fixes the bug you mentioned, so I will
commit both patches.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer.
pgp0.pgp
Description: PGP signature
Re: jail && (ping && traceroute)
This has been discussed at length. Search the archives of this mailing list (or maybe it was freebsd-security) for interesting insight. Sure set me straight as to the consequences Nate - Original Message - From: "Alexandr Kovalenko" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 30, 2003 8:35 Subject: jail && (ping && traceroute) > [Please Cc: me on reply] > > Hello, > > I have 2 questions: > > - where in code should I search for icmp socket binding prohibition in >jail?; > - what bad consequences will appear if I remove those checks and >prohibition?. > > Thanks in advance! > > -- > NEVE-RIPE, will build world for food > Ukrainian FreeBSD User Group > http://uafug.org.ua/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network stack cloning / virtualization patches
Juli Mallett wrote: > * Sean Chittenden <[EMAIL PROTECTED]> [ Date: 2003-05-30 ] > [ w.r.t. Re: Network stack cloning / virtualization patches ] > > > at http://www.tel.fer.hr/zec/vimage/ you can find a set of patches > > > against 4.8-RELEASE kernel that provide support for network stack > > > cloning. > > > > Has anyone stepped forward to possibly shepherd this code into the > > tree? I am highly interested in this code and would like to see it > > incorporated into the base system (read: -CURRENT, before 5.2). After > > looking at the TODO, I realize that this patch isn't 100% yet, but can > > it be broken down into a smaller set of commits? > > Has anyone looked at making the patch work with CURRENT? Does this do > anything to degrade performance of UP systems with no (0?) virtualised > images running? Does it make the locking situation much worse? Can it > be stripped down to minimal, clean, well-architected diffs to accomplish > a centralised goal, rather than a "Network+goodies, random subsystem > overhaul"? Those are probably good questions for someone to know the > answers to (by looking at the code, or someone trying such) before it > gets too close to the tree. I plan to start porting the cloning code to -CURRENT once it becomes -STABLE (that means once the 5.2 gets out, I guess). In the meanwhile I'd like to get more feedback on what people like / dislike regarding the general concept and the code as it is right now, in which direction I should strive to redesign the management API etc. I fully agree with Juli's comment that the patch coalesces many things not fundamentally related to the network stack itself, and that it therefore has to be slightly reengineered first. While at BSDCon in Amsterdam, idowse@ and phk@ suggested to me that the vimage framework should probably be implemented in a more modular fashion, so that admins could choose which system resources to virtualize and which not. My current experiments are going in that direction... Regarding the question on performance penalty, I suggest that you check the EuroBSDCon slides which provide a basic comparison between the standard and the patched kernel. The overhead increase is generally hardly measurable, and depending on traffic type it does not exceed 3-4% in worst case scenarios. Julian Elischer will be giving a talk accompanying a paper on the subject at the upcoming USENIX / FreeNIX ATC, so perhaps this could also be a good place to learn a couple of more details :-) Unfortunately I won't be able to attend the conference personally :-| , but I hope to hear some feedback though... Cheers, Marko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network stack cloning / virtualization patches
Sean Chittenden wrote: > can it be broken down into a smaller set of commits? No it can't. That's probably the biggest problem with the network stack cloning concept - you can either properly virtualize the entire stack or do no virtualization at all. Therefore even if I ever succeed in bringing the patch in full sync with -CURRENT, I assume that many people would stand out against it to be incorporated to the main source tree, as the patch would significantly change pretty much of the code in the net* portions of the kernel tree... At the moment your best option is to try out the available version (against 4.8-R), report any bugs you encounter, and provide suggestions for further reengineering... Cheers, Marko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: jail && (ping && traceroute)
Hello, It involves allowing all applications inside the jail access to raw sockets. Raw sockets are also responsible for ipfw and other services; therefore, it may be prudent to add separate sysctl settings allowing/denying access to those. I have a patch that does allow raw sockets and allows people inside a jail to add ipfw rules for their own IP address(es), among other things. See http://msalem.translator.cx/dist/jail_separation.v7.patch (for 5.0-RELEASE). :) Thanks, -- Mooneer Salem GPLTrans: http://www.translator.cx/ lifeafterking.org: http://www.lifeafterking.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alexandr Kovalenko Sent: Friday, May 30, 2003 7:36 AM To: [EMAIL PROTECTED] Subject: jail && (ping && traceroute) [Please Cc: me on reply] Hello, I have 2 questions: - where in code should I search for icmp socket binding prohibition in jail?; - what bad consequences will appear if I remove those checks and prohibition?. Thanks in advance! -- NEVE-RIPE, will build world for food Ukrainian FreeBSD User Group http://uafug.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Vinum / 4.8 / Referenced disk / Recovery
After a reboot on 4.8 I ended up with a degraded raid 5 partition... The only thing special about my setup is 4944 drives spread over 3 channels, running SMP kernel. One sub disk was down and the and the drive was referenced... in scouring the mailing lists I saw where a referenced disk means you have referenced a non-existent drive - I read this as one vinum didn't think was defined.. in my case it was drive29 --> /dev/da29s1e I don't know how this got referenced !!! It's been reboot many times and this has not happened. So I boldly created a config file for vinum and re-created the drive. --- config file drive drvie29 device /dev/da29e --- end but I still can not start the sub disk. ([EMAIL PROTECTED]) /home/staff/mikej# vinum start raid5-1.p0.s15 Can't start raid5-1.p0.s15: Drive is down (5) ([EMAIL PROTECTED]) /home/staff/mikej# Here is what vinum thinks.. Do I rm the sub disk and re-create it? Will this kill my raid-5 partition ?? Thanks !! ([EMAIL PROTECTED]) /home/staff/mikej# vinum printconfig # Vinum configuration of jammin.mikej.com, saved at Fri May 30 18:15:48 2003 drive drive1 device /dev/da1s1e drive drive2 device /dev/da2s1e drive drive3 device /dev/da3s1e drive d2 device /dev/da15s1e drive drive16 device /dev/da16s1e drive drive17 device /dev/da17s1e drive drive18 device /dev/da18s1e drive drive19 device /dev/da19s1e drive d1 device /dev/da20s1e drive drive21 device /dev/da21s1e drive drive22 device /dev/da22s1e drive drive23 device /dev/da23s1e drive drive24 device /dev/da24s1e drive drive25 device /dev/da25s1e drive drive26 device /dev/da26s1e drive drive27 device /dev/da27s1e drive drive28 device /dev/da28s1e drive drive29 device /dev/da29s1e drive *invalid* device volume mirror1 volume raid5-1 plex name mirror1.p0 org concat vol mirror1 plex name mirror1.p1 org concat vol mirror1 plex name raid5-1.p0 org raid5 62s vol raid5-1 sd name mirror.p0.s0 drive d1 plex mirror1.p0 len 35551232s driveoffset 265s plexoffset 0s sd name mirror.p1.s0 drive d2 plex mirror1.p1 len 35551232s driveoffset 265s plexoffset 0s sd name raid5-1.p0.s0 drive drive1 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 0s sd name raid5-1.p0.s1 drive drive2 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 62s sd name raid5-1.p0.s2 drive drive3 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 124s sd name raid5-1.p0.s3 drive drive16 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 186s sd name raid5-1.p0.s4 drive drive17 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 248s sd name raid5-1.p0.s5 drive drive18 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 310s sd name raid5-1.p0.s6 drive drive19 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 372s sd name raid5-1.p0.s7 drive drive21 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 434s sd name raid5-1.p0.s8 drive drive22 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 496s sd name raid5-1.p0.s9 drive drive23 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 558s sd name raid5-1.p0.s10 drive drive24 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 620s sd name raid5-1.p0.s11 drive drive25 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 682s sd name raid5-1.p0.s12 drive drive26 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 744s sd name raid5-1.p0.s13 drive drive27 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 806s sd name raid5-1.p0.s14 drive drive28 plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 868s sd name raid5-1.p0.s15 drive *invalid* plex raid5-1.p0 len 35551172s driveoffset 265s plexoffset 930s ([EMAIL PROTECTED]) /etc# vinum l 18 drives: D drive1State: up Device /dev/da1s1e Avail: 0/17359 MB (0%) D drive2State: up Device /dev/da2s1e Avail: 0/17359 MB (0%) D drive3State: up Device /dev/da3s1e Avail: 0/17359 MB (0%) D d2State: up Device /dev/da15s1e Avail: 0/17359 MB (0%) D drive16 State: up Device /dev/da16s1e Avail: 0/17359 MB (0%) D drive17 State: up Device /dev/da17s1e Avail: 0/17359 MB (0%) D drive18 State: up Device /dev/da18s1e Avail: 0/17359 MB (0%) D drive19 State: up Device /dev/da19s1e Avail: 0/17359 MB (0%) D d1State: up Device /dev/da20s1e Avail: 0/17359 MB (0%) D drive21 State: up Device /dev/da21s1e Avail: 0/17359 MB (0%) D drive22 State: up Device /dev/da22s1e Avail: 0/17359 MB (0%) D drive23 State: up Device /dev/da23s1e Avail: 0/17359 MB (0%) D drive24 State: up Device /dev/da24s1e Avail: 0/17359 MB (0%) D drive25 State: up Device /dev/da25s1e Avail: 0/17359 MB (0%) D drive26
Re: Network stack cloning / virtualization patches
On Fri, May 30, 2003 at 10:07:07PM +0200, Marko Zec wrote: >I plan to start porting the cloning code to -CURRENT once it becomes -STABLE >(that means once the 5.2 gets out, I guess). FreeBSD has a policy that all new features must be added to -CURRENT before they can be added to -STABLE (4.x or 5.x). This means that you are going to have to port the code to -CURRENT at some point in order to get it added to the main tree. That said, now is actually a relatively good time to look at porting code to -CURRENT. It has been in a 'semi-frozen' state since about last November and will stay in this like this until 5.x is branched (ie work is focused on bug-fixes and performance enhancements with minimal new features). Once 5-STABLE is branched, 6-CURRENT will go through a period of rapid change and instability as everyone gets 9 months or so of pent-up API changes and 'interesting new ideas' committed. In other words, the longer you leave it, the more effort you'll probably need to invest. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc bug? Openoffice port impossibel to compile on 4.8
On Thursday 29 May 2003 00:12, Dag-Erling Smorgrav wrote: > Bruce M Simpson <[EMAIL PROTECTED]> writes: > > However, we're dealing with something a bit more stable in terms of > > code base, anyway. Having to commit a whole bunch of fixes for the > > sake of a compiler upgrade isn't acceptable. Sounds like the GCC > > guys have been bitten by the Linux bug. > > May I remind you that K&R-style declarations have been deprecated for > the last 14 years? Funny, the last time I looked at a C language specification they were still supported. -- "Where am I, and what am I doing in this handbasket?" Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc bug? Openoffice port impossibel to compile on 4.8
Wes Peters <[EMAIL PROTECTED]> writes: > On Thursday 29 May 2003 00:12, Dag-Erling Smorgrav wrote: > > May I remind you that K&R-style declarations have been deprecated for > > the last 14 years? > Funny, the last time I looked at a C language specification they were > still supported. 6.11.5 Function definitions [#1] The use of function definitions with separate parameter identifier and declaration lists (not prototype-format parameter type and identifier declarators) is an obsolescent feature. and "obsolescent feature" is defined as follows in the introduction: [#2] Certain features are obsolescent, which means that they may be considered for withdrawal in future revisions of this International Standard. They are retained because of their widespread use, but their use in new implementations (for implementation features) or new programs (for language [6.11] or library features [7.26]) is discouraged. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
swapping over nfs might be broken
I've recently set up a diskless client and I noticed something. subnet mask 255.255.255.0 router 192.168.1.2 rootfs 192.168.1.100:/export/photon.freebsd/root swapfs 192.168.1.100:/export/photon.freebsd hostname photon Adjusted interface xl0 md_lookup_swap: Swap size is 131072 KB Mounting root from nfs:nfs:/export/photon.freebsd/root setrootbyname failed NFS ROOT: 192.168.1.100:/export/photon.freebsd/root NFS SWAP: 192.168.1.100:/export/photon.freebsd $ swapinfo Device 1K-blocks UsedAvail Capacity Type Everything looks normal except for swapinfo. It looks like nfs swapping is broken? Has anyone seen this? I have tried this with md.ko as a module or compiled into the kernel with the same results. I'm also using these flags in my kernel. options BOOTP options BOOTP_NFSROOT options BOOTP_NFSV3 options BOOTP_COMPAT My nfs server and diskless client are both running current from around may 25th. I'm also running rpc.lockd and rpc.statd on the nfs server. I also tried setting option-129, but that did not help. Why is option-129 limited to 4 bytes? I have also seen that "setrootbyname failed" message for at least a year. Should that message be removed or changed to something more useful? Regards, David Yeske __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: swapping over nfs might be broken
On Fri, 30 May 2003, David Yeske wrote:
> $ swapinfo
> Device 1K-blocks UsedAvail Capacity Type
>
> Everything looks normal except for swapinfo. It looks like nfs swapping
> is broken?
`man swapinfo` says:
BUGS
Does not understand NFS swap servers.
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vinum / 4.8 / Referenced disk / Recovery
On Friday, 30 May 2003 at 18:21:53 -0400, Michael G. Jung wrote: > After a reboot on 4.8 I ended up with a degraded raid 5 partition... > > The only thing special about my setup is 4944 drives spread over 3 channels, > running SMP kernel. That's a lot of drives. > One sub disk was down and the and the drive was referenced... in scouring the > mailing lists I saw where a referenced disk means you have referenced a > non-existent drive - I read this as one vinum didn't think was defined.. in my > case it was drive29 --> /dev/da29s1e > > I don't know how this got referenced !!! It's part of your configuration. From the printconfig output: > drive drive29 device /dev/da29s1e > It's been reboot many times and this has not happened. It probably hasn't failed for. > > So I boldly created a config file for vinum and re-created the drive. > > --- config file > drive drvie29 device /dev/da29e > --- end > > but I still can not start the sub disk. > > ([EMAIL PROTECTED]) /home/staff/mikej# vinum start raid5-1.p0.s15 > Can't start raid5-1.p0.s15: Drive is down (5) > ([EMAIL PROTECTED]) /home/staff/mikej# > > Here is what vinum thinks.. Do I rm the sub disk and re-create > it? No. > Will this kill my raid-5 partition ?? If you do enough messing around with the configuration, yes, you can kill your RAID-5 plex. In all probability, your drive has failed and requires replacement. You'll see that from the system log file. Look at http://www.vinumvm.org/vinum/how-to-debug.html and http://www.vinumvm.org/vinum/replacing-drive.html. You don't need to submit the information if you can understand it and take the appropriate action. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Network stack cloning / virtualization patches
On Fri, 30 May 2003, Juli Mallett wrote: > > Has anyone looked at making the patch work with CURRENT? Does this do > anything to degrade performance of UP systems with no (0?) virtualised > images running? I have been running tests between two machines with this patch installed. There is a "per packet" overhead increase of about 1%. there is no overhead increase in the per-byte overhead.. in ther words, sending 1 byte packets gets about a 1% decrease in throughput but sending 8k chunks has almost no overhead increase.. Both my machines end up maxing out the 100Mb ethernet between them before they see any speed difference at high packet sizes. > Does it make the locking situation much worse? Can it > be stripped down to minimal, clean, well-architected diffs to accomplish > a centralised goal, rather than a "Network+goodies, random subsystem > overhaul"? It is unlikely that the patches could be made in smaller orthogonal patches. Its kind of "all or nothing".. Either everything is global or it is in a structure (per VM). > Those are probably good questions for someone to know the > answers to (by looking at the code, or someone trying such) before it > gets too close to the tree. > > If this is your priority patch, hunting down someone with serious > network\ stack-fu to review the diff, and whatnot, would probably be > a good investment of your time in that regard. I'll bepresenting Marco's paper at USENIX on the (ummm 12th I think). His baby is due then so he can't make it.. (whereas mine arrived today so I'll be looking for an excuse to be away from the house for 2 days ;-) > > Thanx, > juli. > -- > juli mallett. email: [EMAIL PROTECTED]; efnet: juli; > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Proper behaviour for wait()?
Just curious,
anyone know what the "proper" behavior for wait() is when SIGCHLD
is ignored? Is it simply undefined? Don't see anything mentioned
in the wait(2) manpage one way or tother, and other OSes don't seem
to agree much.
-Paul.
bash$ cat wait.c
#include
#include
#include
#include
#include
int main() {
int status;
pid_t pid = fork();
if (!pid) { sleep(1); _exit(0); }
signal(SIGCHLD, SIG_IGN);
printf("waitpid() = %d\n", waitpid(pid, &status, 0));
signal(SIGCHLD, SIG_DFL);
return 0;
}
bash$ cc wait.c
[FreeBSD 4.8]
bash$ ./a.out
waitpid() = 7553
bash$
[Linux 2.4.21]
bash$ ./a.out
waitpid() = 24536
bash$
[Darwin 6.6]
bash$ ./a.out
waitpid() = -1
bash$
[Solaris 8]
bash$ ./a.out
waitpid() = -1
bash$
[OpenBSD 3.3]
bash$ ./a.out
...just hangs...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc bug? Openoffice port impossibel to compile on 4.8
In message: <[EMAIL PROTECTED]> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: : Wes Peters <[EMAIL PROTECTED]> writes: : > On Thursday 29 May 2003 00:12, Dag-Erling Smorgrav wrote: : > > May I remind you that K&R-style declarations have been deprecated for : > > the last 14 years? : > Funny, the last time I looked at a C language specification they were : > still supported. : :6.11.5 Function definitions : :[#1] The use of function definitions with separate parameter :identifier and declaration lists (not prototype-format :parameter type and identifier declarators) is an obsolescent :feature. : : and "obsolescent feature" is defined as follows in the introduction: : :[#2] Certain features are obsolescent, which means that they :may be considered for withdrawal in future revisions of this :International Standard. They are retained because of their :widespread use, but their use in new implementations (for :implementation features) or new programs (for language :[6.11] or library features [7.26]) is discouraged. Deprecated doesn't mean they are no longer part of the standard. Just that next standard they could go away. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc bug? Openoffice port impossibel to compile on 4.8
Wes Peters wrote: > On Thursday 29 May 2003 00:12, Dag-Erling Smorgrav wrote: > > May I remind you that K&R-style declarations have been deprecated for > > the last 14 years? > > Funny, the last time I looked at a C language specification they were > still supported. Give it up. You and I learned C when it was programmers, not compilers, which had to be intelligent. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc bug? Openoffice port impossibel to compile on 4.8
Sat, May 31, 2003 at 02:46:33, des (Dag-Erling Smorgrav) wrote about "Re: gcc bug? Openoffice port impossibel to compile on 4.8": DES> and "obsolescent feature" is defined as follows in the introduction: DES>[#2] Certain features are obsolescent, which means that they DES>may be considered for withdrawal in future revisions of this ~~ ~~ DES>International Standard. They are retained because of their DES>widespread use, but their use in new implementations (for ~~~ DES>implementation features) or new programs (for language ~~~ DES>[6.11] or library features [7.26]) is discouraged. Essential words are understriked. I can't imagine how it can be read as "unsupported". -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jail && (ping && traceroute)
On Fri, May 30, 2003 at 05:35:42PM +0300, Alexandr Kovalenko wrote: +> I have 2 questions: +> +> - where in code should I search for icmp socket binding prohibition in +>jail?; +> - what bad consequences will appear if I remove those checks and +>prohibition?. This is nasty to allow all jailed process to open RAW sockets. You can use CerbNG to allow only selected jailed process to open RAW socket. General policy is here: http://cerber.sourceforge.net/policies/jailed-icmp.cb but you can easly rewrite it to allow only selected process for this. Project's page is here: http://cerber.sourceforge.net And rest of policies: http://cerber.sourceforge.net/policies/ CerbNG works only on 4-STABLE systems for now and there will be soon 1.0-RC2 version, but I've started porting it to -CURRENT. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: kqueue/kevent support in scsi device drivers
Fri, May 30, 2003 at 12:14:50, jaya_bhat100 (Jayasheela Bhat) wrote about "kqueue/kevent support in scsi device drivers": JB> At present, kevent is supported for vnode, fifos, pipes and sockets, I believe. JB> I would like to use kevent notification in scsi devices. But the drivers scsi_xx.c do not support it. Whether I can implement it in scsi device driver using KNOTE? JB> I was going through tty.c where KNOTE is used. struct 'tty' has the support for it. The same is not available in struct 'disk'. JB> Could anyone tell me whether it is possible to implement it and how?? What is the aim to do it? tty, sockets, pipes, fifos are sequential devices with data pushing to it. Disks are random access devices, this is the main reason why disk/filesystem read() can't be nonblocking by itself: there are two different operations in them - 1) process says to kernel what it want read, 2) kernel returns data. (And similarly for write().) To read from random access devices, AIO API was created (aio_read(), aio_write(), etc.), and it doesn't require your explicit KNOTE adding: it already supports EVFILT_AIO and SIGEV_KEVENT. If you can access something at SCSI subsystem as sequential device, let you go. But, it's better to implement KNOTE in driver of this device itself, not common SCSI layer, which is too complicated to allow it. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proper behaviour for wait()?
Fri, May 30, 2003 at 22:00:18, pherman (Paul Herman) wrote about "Proper behaviour for wait()?": PH> anyone know what the "proper" behavior for wait() is when SIGCHLD PH> is ignored? Is it simply undefined? Don't see anything mentioned PH> in the wait(2) manpage one way or tother, and other OSes don't seem PH> to agree much. Citing SUSv2: SA_NOCLDWAIT If set, and sig equals SIGCHLD, child processes of the calling processes will not be transformed into zombie processes when they terminate. If the calling process subsequently waits for its children, and the process has no unwaited for children that were transformed into zombie processes, it will block until all of its children terminate, and wait(), wait3(), waitid() and waitpid() will fail and set errno to [ECHILD]. Otherwise, terminating child processes will be transformed into zombie processes, unless SIGCHLD is set to SIG_IGN. The same for SUSv3. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc bug? Openoffice port impossibel to compile on 4.8
Valentin Nechayev <[EMAIL PROTECTED]> writes: > Essential words are understriked. I can't imagine how it can be read > as "unsupported". I didn't use the word "unsupported", I said "deprecated". DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc bug? Openoffice port impossibel to compile on 4.8
Sat, May 31, 2003 at 11:19:06, des (Dag-Erling Smorgrav) wrote about "Re: gcc bug? Openoffice port impossibel to compile on 4.8": >> Essential words are understriked. I can't imagine how it can be read >> as "unsupported". DES> I didn't use the word "unsupported", I said "deprecated". Yes. But your message was reply to Wes Peters' one with the following: wp> Funny, the last time I looked at a C language specification they were wp> still supported. Your citation says they are supported, in spite of any deprecation. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
