From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 00:09:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C750516A4B3; Sun, 26 Oct 2003 00:09:28 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8927643FBD; Sun, 26 Oct 2003 00:09:27 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) h9Q79LiF034661; Sun, 26 Oct 2003 00:09:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id h9Q79LEq034660; Sun, 26 Oct 2003 00:09:21 -0700 (PDT) (envelope-from dillon) Date: Sun, 26 Oct 2003 00:09:21 -0700 (PDT) From: Matthew Dillon Message-Id: <200310260709.h9Q79LEq034660@apollo.backplane.com> To: Robert Watson References: cc: John-Mark Gurney cc: hackers@freebsd.org cc: Kip Macy cc: Marcel Moolenaar Subject: Re: Synchronization philosophy (was: Re: FreeBSD mail list etiquette) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 07:09:28 -0000 :... :Moving towards message passing helps to structure the code to avoid :sharing of this sort, although it's not the only way to motivate that sort :of change. I'm a big fan of the change in -CURRENT to use td->td_cred as :a read-only thread-local credential reference and avoid synchronization on :the credential reference--it nicely addresses the requirements for :consistency in the referenced data for the read-only cases (which are the :vast majority of uses of a credential). I saw td->td_cred in -current, but while figuring out what to do in DragonFly I realized that there was something fundamentally wrong with pulling a ucred out of a proc *OR* a thread. What's wrong is that the ucred associated with the current process, or current thread, or passed process, or passed thread may not be the correct ucred for a particular operation, especially in DragonFly where I/O operations are going to be messages and may be aggregated into a single thread for a particular target, filesystem, or protocol in the case of the network. There is also the potential of writing buggy code... if the programmer has a thread based ucred handy he might use it whether it is the correct ucred or not. So in DragonFly I kept the ucred in the proc structure but only refer to it at the highest level. The ucred is passed as an argument from the highest level and lower levels don't try to get it out of the proc or thread. I've already fixed this for VFS. I haven't fixed it for the network stack yet but it's pretty obvious to me that that is the only correct way of doing it, and actually not that hard to do. VFS was interesting... ucred was either being passed directly or pulled out of the proc structure inappropriately for things like VOP_WRITE, and indirectly via struct uio's proc/thread pointer. And then there were a dozen hacks to deal with the case where a flush or VM paging I/O might not occur from the originating user process, hence people may notice that existance of a ucred pointer in struct buf. It's was pretty bad. I ripped it all out. No ucred is passed for VOP I/O any more at all. The ucred is expected to be established to 'open' the file (aka vnode), but once open the driver is expected to be able to read and write through that vnode without any further ucred info. And, in fact, most filesystem drivers completely ignored the 'ucred' argument for VOP_READ and VOP_WRITE anyway. Only NFS didn't. For NFS I just used the root ucred but later wound up having to record the ucred at open to deal with -maproot exports that used something other then root. But that's a damn sight better then strewing ucred references all over the generic I/O APIs. :... :issues in FreeBSD: for example, even the relatively simple accounting file :rotation would benefit from queue-like operation to serialize the :accounting data/event stream and rotation events. Using locks and :condition variables to perform serialization as is currently done in the :accounting code is unwieldy and bug-prone. However, when moving to :event/message queuing, you also have to be very careful with data :ownership and referencing, as well as proper error-handling. With The accounting code is a really excellent example. The solution there is to not to queue to a single serializing thread, but instead to queue to the filesystem driver which pulls out the appropriate data (which it will own in DragonFly's case, hence no synchronization issue), and then queues to the accounting file or to a thread that manages the accounting file. All you would be queueing at the highest level might be a pointer to the vnode and not actually dereference the vnode. :... :regardless of whether accounting of that operation succeeds or fails, :execve() continues). The start/stop operation, however, is intended to be :synchronous. Happily, in the accounting case, all necessary error :checking can be performed in advance of the handoff to the accounting :thread from the user thread, but that won't always be the case... Synchronous ops can be queued as easily as asynchronous ops. The only difference is that the caller has to wait for the synchronizing event to complete. In DragonFly that would be a message that the caller waits for a reply on. In fact, this can be advantangious. Take filesystem snapshots for example. If all VOPs for a filesystem are queued to a single thread representing that filesystem (as a simplified view), then you don't need fancy snapshot support at what would normally be considered the API boundary. The message port becomes the API boundary and all a snapshot has to do is freeze the incoming messages and wait for the existing ones (who are undergoing I/O) to complete, then tell the underlying block device to snapshot. Bang! A poor-man's snapshot that could be adapted to virtually any filesystem. :One of the other risks that has worried me about this approach is that :explicit locking has some nice benefits from the perspective of :deadlocking and lock order management: monitoring for deadlocks and lock :orders is a well-understood topic, and the tools for tracking deadlocks :and wait conditions, as well as for performing locking and waiting safely, :are mature. As with with the older BSD sleeping interfaces, such as :tsleep(), synchronous waits on messages are harder to mechanically track, :and resulting deadlocks resemble resource deadlocks more than lock :deadlocks... On the other hand, some forms of tracing may be made easier. :I've had some pretty nasty experiences trying to track deadlocks between :cooperating threads due to message waits, and found tools such as WITNESS :much easier to work with. I would agree that tracking a message, which might traverse several threads before being returned, is far harder then breaking into DDB and doing a backtrace. On the otherhand, if you know the pointer to the message adding debugging fields to the message to track who retrieved or sent it last is quite easy. You only have to shim lwkt_sendmsg(), lwkt_domsg(), lwkt_waitmsg(), and so forth. Then from DDB> you just 'print *msg' from the frame of the process that is blocked waiting on the message. Deadlocking is something that a fine-grained model has to deal with a lot more then a serializing threaded model. In the threaded model one has to contend with far *fewer* high level locks. In DragonFly my hope is that the issue becomes even further removed due to the IPI messaging mechanism which devolves many things which have to be mutexes in 5.x into simple critical sections (like spl's) in DragonFly. :... :thread making use of thread-local storage to avoid explicit :synchronization. Having dealt both with lower level lock/cv primitives :for event passing, and message passing, I have to say I'm leaning far more :towards the message passing. However, it benefits particularly from the :approach due to its asynchronous nature... Message passing is far superior for asynchronous operations, when you don't have to wait, because there are a thousand ways to implement an asynch messaging backend and a thousand ways to optimize it in ways that can completely avoid conflicts, cache issues, mutexes, and so forth. With a locking abstraction you always have to execute the locking and unlocking primitive which can be far more expensive. A messaging backend, hidden by the messaging abstraction, can optimize for cases that would be EXTREMELY cumbersome to optimize for with a locking abstraction. Take the example below... it's overkill but it is only an illustration. Here the messaging backend can optimize for the same-cpu case, whether the client allows blocking or not (whether the client used lwkt_sendmsg() or lwkt_domsg(), basically), and potentially other optmizations. Every single optimization is COMPLETELY hidden from the client that dispatched the message. (this function is executed in the context of the client, not the target, but may queue to the target) messaging_backend_for_a_particular_port(msg, datastructure) { if (datastructure->cpu == mycpu) { crit_enter(); <<< not even this if interrupts don't mess <<< with the data structure do stuff crit_exit(); return(code) } if (client_wants_to_send_msg_synchronously) { ... fine, the client is allowed to block or switch ... ... just queue it, but without a reply port ... lwkt_switch(); /* do a quick blip blip, see if it's done */ if ((msg->ms_flags & MSGF_DONE) == 0) { ... wasn't a quick blip blip, formally block on the message , wait for wakeup ... } return(msg->ms_retcode); } else { ... just queue it ... return(EASYNC); } } On the otherhand, locking verses messaging in the synchronous case is a lot harder to quantify the performance for because theoretically you do not have the overhead of having to build a message in the synchronous case if you are using locking. So even if the message itself implements locking internally, degenerating into, well, locking, it would still be slower. But I would argue that for certain particular inflection points in the system, such as VOP_READ() or VOP_WRITE() for example, a messaging abstraction will be far superior to an API and/or locking abstraction because the tiny difference in overhead is well worth all the cool things you can hide behind the abstraction. System calls fall under this category as well. Encapsulating a system call in a message is trivial (because DragonFly already does it :-)), and only slightly slower then the direct syscall mechanism. But the power one gets out of that sort of abstraction is phenominal. :> For a protocol, a protocol thread will own a PCB, so the PCB will be :> 'owned' by the cpu the protocol thread is on. Any manipulation of the :> PCB must occur on that cpu or otherwise be very carefully managed :> (e.g. FIFO rindex/windex for the socket buffer and a memory barrier). :> Our intention is to encapsulate most operations as messages to the :> protocol thread owning the PCB. : :I'll be very interested to see how this ends up working out: even in :RELENG_4, FreeBSD has sufficient apparent parallelism/preemption in the :network stack to require synchronization at most levels. In RELENG_4, :most upward bound traffic is serialized via the netisr thread, but :downward traffic from user threads passes through the stack in parallel. :Do you anticipate handing off control to a netisr-like thread earlier than :RELENG_4 does in order to get things "into the right thread"? That's a good point. The real question here is determined by how one defines 'parallelism'. The reality of an N cpu system is that the only actual parallelism you have is N, the number of cpus you have in the system. So the only effect that really matters with the serializing effect on downward bound network traffic is the cost of the context switch. In DragonFly's case that would be a light weight kernel thread context switch, which is far less expensive then a heavy weight context switch. But it *is* still a context switch. The question in regards to DragonFly is whether the messaging function can deal with the case where, say, a write() results in queueing an output packet as efficiently as 4.x would be able to deal with the case by calling tcp_output(). (the messaging function that is executed in the context of the client, that is). My take on the situation is that on a 2xCPU system DragonFly could potentially be faster because the message that wakes up the protocol thread can potentially be waking up the protocol thread on a different cpu and return immediately to userland on the original cpu without userland having to wait for the protocol operation. On a UP system DragonFly would be slower along this path due to the extra context switch, at least under low loads. Under high loads DragonFly ought to be around the same speed because the messages would aggregate and the number of context switches into the protocol thread would actually go down relative to the number of write()'s being performed. It is also possible that DragonFly would not be slower under any circumstances, especially if the TCP pipe is full, because the protocol thread will be woken up by the ACK packet coming back up the stack from the NETIF interrupt (which is effectively a software interrupt), and it could process the WRITE-wakeup at the same time. In fact, this could potentially be faster because the WRITE going down the stack wouldn't even bother to run tcp_output(), it would just wakeup the protocol thread (send a wakeup message to it, anyway), which is a NOP if the protocol thread is already awake. So a WRITE would degenerate to appending to the socket buf and returning to userland and the protocol thread would primarily be driven by ACKs coming back over the wire. That's a 2-for-1 deal since ACKs are typically one per every two data packets. :One of the conceptual issues we've been wrestling with is the issue of :ordering of events: from the perspective of performance, guaranteeing the :weakest possible ordering is desirable. However, with parallelism in the :stack, you risk introducing weaker than permitted ordering of packets :(triggering fast retransmits, etc). In most situations, it's sufficient :to maintain source ordering: if two packets are from the same source, :their ordering should be maintained. If they are from separate sources, :maintaining order isn't required. This raises interesting questions about :when you want to defer processing, and when to try and "catch up" to :maintain performance and ordering. This is a problem if you have multiple protocol threads picking up random work. I don't think it is a problem if you partition the PCB's amoungst protocol threads so a particular PCB is always handled by a particular protocol thread. This is the old 'get a lock, pull work off the queue, execute it' problem, when one is using locks to parallelize operations on queues. It reminds me of NFS's nfsiod processes, which until I fixed it had EXACTLY the problem you describe. Several nfsiod processes would trip over each other trying to get the same VNODE lock for read-ahead and write ops. :> DragonFly is using its LWKT messaging API to abstract blocking verses :> non-blocking. In particular, if a client sends a message using an :> asynch interface it isn't supposed to block, but can return EASYNC if it :> wound up queueing the message due to not being able to execute it :> synchronous without blocking. If a client sends a message using a :> synchronous messaging interface then the client is telling the :> messaging subsystem that it is ok to block. : :The risk here is not so much that the first level of consumer code for an :interface can't determine if it will block or not, but that after a few :levels of abstraction, that information has disappeared (or worse, is :conditional on context in an opaque way). Ah, but that assumes that the levels of abstraction are enclosed within the one (originating) thread. With a messaging layer major inflection points are in different threads, so the problem becomes compartmentalized. An operation which MUST be asynch in thread #1 does not have to be async in thread #2 which picks it up. :> in the system. 90% of the 'not sure if we might block' problem :> is related to scheduling or memory allocation and neither of those :> subsystems needs to use extranious mutexes, so managing the blocking :> conditions is actually quite easy. : :Again, I think it comes down to the fact that memory allocation APIs :typically offer choices to the consumer: block if the resources aren't :available, or fail. My mood swings a bit back and forth as to what the :ideal strategy would/should be at the lowest level, but I think as you :move up the stack, the exact semantics at the bottom matter less. The :APIs are generally clear, but it's the programming layered on top of it :that's sloppy (alternatively: at the bottom level API, the behavior is :well-documented, but as you move up the stack, the behavior typically :becomes more poorly documented). While it's probably appropriate to say :"this is a property of poor programming, or at least, programming done :against a model that we want no longer to hold true", there's still the :issue of cleaning up the legacy code... : :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects :robert@fledge.watson.org Network Associates Laboratories In the case of FreeBSD-4.x, and 5.x as well, the problem devolves into the unknown quantity that locking the kernel_map represents, and the unknown quantity that obtaining and releasing a mutex represents. Even in DragonFly, for allocations, I have to deal with M_NOWAIT and locking the kernel_map if the slab allocator has no free memory in the per-cpu globaldata area. And in DragonFly I have to deal with the equivalent of mutexes in regards to the IPI messaging. Even though IPI messaging is effectively asynchronous, it can *STILL* stall for a bit. If the IPI message FIFO between two cpus is full the IPI messaging code must spin waiting for it to empty a little and at the same time process any incoming IPI messages (to avoid IPI messaging deadlocks between two cpus). This means that any time you send an IPI message you have to assume that your cpu will also have processed any pending IPI messages to it. It hasn't created any problems yet, because IPI operations are still serialized within the context of the cpu (so we don't have to worry about preemption), and since IPI messaging is used to serialize operations on a cpu anyway the fact that several IPI messages may execute when you send a new one does not really interfere with the abstraction. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 00:12:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 019D616A4B3; Sun, 26 Oct 2003 00:12:58 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A0AE43F3F; Sun, 26 Oct 2003 00:12:57 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) h9Q7CuiF034677; Sun, 26 Oct 2003 00:12:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id h9Q7CuSv034676; Sun, 26 Oct 2003 00:12:56 -0700 (PDT) (envelope-from dillon) Date: Sun, 26 Oct 2003 00:12:56 -0700 (PDT) From: Matthew Dillon Message-Id: <200310260712.h9Q7CuSv034676@apollo.backplane.com> To: Robert Watson References: cc: John-Mark Gurney cc: hackers@freebsd.org cc: Kip Macy cc: Marcel Moolenaar Subject: Re2: Synchronization philosophy (was: Re: FreeBSD mail list etiquette) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 07:12:58 -0000 :Again, I think it comes down to the fact that memory allocation APIs :typically offer choices to the consumer: block if the resources aren't :available, or fail. My mood swings a bit back and forth as to what the :ideal strategy would/should be at the lowest level, but I think as you :move up the stack, the exact semantics at the bottom matter less. The :APIs are generally clear, but it's the programming layered on top of it :that's sloppy (alternatively: at the bottom level API, the behavior is :well-documented, but as you move up the stack, the behavior typically :becomes more poorly documented). While it's probably appropriate to say :"this is a property of poor programming, or at least, programming done :against a model that we want no longer to hold true", there's still the :issue of cleaning up the legacy code... : :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects :robert@fledge.watson.org Network Associates Laboratories Oh, and I just realized... particularly in the case of 5.x, I have noticed that the vnode and lockmgr *INTERLOCK* mutexes seem to present a severe blocking/synchronization problem for coders. There is a lot of code in 5.x which must obtain and hold the interlock in order to guarentee that the lockmgr operation that is about to be executed with LK_NOWAIT will, in fact, not wait (on the interlock). Yowzer! I'd consider that a serious problem because it interferes directly with the abstraction that LK_NOWAIT is supposed to provide. The problem is even more severe due to the 5.x's other little quirks like kernel thread preemption by non-interrupts and cpu migration. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 01:30:50 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB18A16A4B3 for ; Sun, 26 Oct 2003 01:30:49 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B7EA43FCB for ; Sun, 26 Oct 2003 01:30:48 -0700 (PDT) (envelope-from juergen.spiegel@jsp-edv.de) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1ADgIR-0001I5-00 for hackers@freebsd.org; Sun, 26 Oct 2003 09:30:47 +0100 Received: from [217.84.70.185] (helo=jspedv-inet0.kundenserver.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1ADgIR-0007i4-00 for hackers@FreeBSD.org; Sun, 26 Oct 2003 09:30:47 +0100 Received: from localhost (localhost [127.0.0.1]) by jspedv-inet0.kundenserver.de (Postfix) with ESMTP id 66F1317B1E for ; Sun, 26 Oct 2003 09:30:46 +0100 (CET) Received: by jspedv-inet0.kundenserver.de (Postfix, from userid 524) id 712AF179D6; Sun, 26 Oct 2003 09:30:45 +0100 (CET) Received: from jspedv-inet1.kundenserver.de (jspedv-inet1.kundenserver.de [192.168.1.7]) by jspedv-inet0.kundenserver.de (Postfix) with ESMTP id EED1E234B for ; Sun, 26 Oct 2003 09:30:44 +0100 (CET) From: =?iso-8859-15?q?J=FCrgen=20Spiegel?= Organization: Netzwerke & Systemprogrammierung To: hackers@FreeBSD.org Date: Sun, 26 Oct 2003 09:30:33 +0100 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310260930.42950.juergen.spiegel@jsp-edv.de> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on jspedv-inet0.kundenserver.de X-Spam-Level: X-Spam-Status: No, hits=-100.0 required=5.0 tests=LINES_OF_YELLING, USER_IN_WHITELIST autolearn=no version=2.60 X-Virus-Scanned: by AMaViS 0.3.12 Subject: FreeBSD 4.2 NIS-Client with Linux NIS-Server Problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Juergen.spiegel@jsp-edv.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 08:30:50 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hi, I can't get it to work. I`ve read many of the Howtos and newgroups discussions on that theme, but=20 there are no usefull hints for this special proclem. The other NIS-Clients on my network (Solaris, AIX, Linux) can do connect wi= th=20 any username set in the /etc/passwd on the NIS-Server without any problems. I knew traditional NIS and the most of the common problems, but in this cas= e I=20 am perplex. Please help. Thanks in advance Juergen =2D----BEGIN PGP SIGNATURE----- Version: 2.6.3in Charset: noconv iQEVAwUBP5uGMFOhb7WzWBvjAQHBXQf+KYNFUTCF2PjrjLZqrLH7r4+v2HXpne3Z DuOQzmnIaqS9f2qPzDHXaZUSQ+LzmOkX6EOYqZ1gOFFVk+H8wLxBMIBJkz0nCZ2C d/aRat1Jt/B56HAjVgF9fCEmt1yyVcw1WKU/kUUh3uxP+TZ/9AtGwbfdkic/vM3J =462llKujkzxNwo3YkiXRDr9Z7YHrIN8Y7cfl/h8W1ZWwy6NWwZZE1mbYDtqSDUAOu zbMZ10IkP1rH9K1wS0fLiQjIYhcekcR8ZIuyiIoKpjvFUoc5sUBdFZ4XOQARCKzU wrbHVSNTDXFrlFEMiBnw8SsRe/lrfbm8vLwDf1dJCTbZq1RLLJmRtw=3D=3D =3DGhgN =2D----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 01:08:35 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5066216A4B3 for ; Sun, 26 Oct 2003 01:08:35 -0800 (PST) Received: from dixie.svsecure.net (dixie.svsecure.net [64.247.1.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B44B43FEC for ; Sun, 26 Oct 2003 01:08:04 -0800 (PST) (envelope-from info@bardic.com) Received: from nobody by dixie.svsecure.net with local (Exim 4.24) id 1ADgsV-00054i-6o for freebsd-hackers@freebsd.org; Sun, 26 Oct 2003 04:08:03 -0500 To: FREEBSD-HACKERS From: Roger Barnette Date: Sun, 26 Oct 2003 3:46:24 EST MIME-Version: 1.0 Message-Id: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dixie.svsecure.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - bardic.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: DigiTales newsletter: Last call... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 09:08:35 -0000 DigiTales newsletter: Last call... The newsletters will start flowing again next week. I am now gainfully employed full-time and it has indeed been the answer to 2 years of fervent prayer. The website is being reworked to just be fun and to capture these newsletter tips for future reference. A number of people confirmed their subscriptions in June. If you have already done that no further action is required to remain on the DigiTales newsletter email list. See the newly converted archive of DigiTales at: http://www.bardic.com/blog/blogger.html If you didn't confirm to remain on the list but have changed your mind visit the new registration page. http://bardic.com/mailman/listinfo/digitales_bardic.com Thank you for your patience as I have stuggled through self and under employment and into full employment. Your prayers and patronage has truly been a blessing to myself and my family. Thank you so very much! Blessings, Roger. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 03:06:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7C7F16A4B3 for ; Sun, 26 Oct 2003 03:06:55 -0800 (PST) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80FE443FA3 for ; Sun, 26 Oct 2003 03:06:54 -0800 (PST) (envelope-from des@des.no) Received: from smtp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 7E68C799EE; Sun, 26 Oct 2003 12:06:53 +0100 (MET) Received: by smtp.des.no (Pony Express, from userid 666) id 484CD9C04E; Sun, 26 Oct 2003 12:06:53 +0100 (CET) Received: from dwp.des.no (dwp.des.no [10.0.0.4]) by smtp.des.no (Pony Express) with ESMTP id 71C349C049; Sun, 26 Oct 2003 12:06:49 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 6114CB823; Sun, 26 Oct 2003 12:06:49 +0100 (CET) To: Mike Silbersack References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1066820436.25609.93.camel@boxster.onthenet.com.au> <20031026052854.GA20701@VARK.homeunix.com> <20031026005938.L2023@odysseus.silby.com> <20031026065621.GA21546@VARK.homeunix.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 26 Oct 2003 12:06:49 +0100 In-Reply-To: <20031026065621.GA21546@VARK.homeunix.com> (David Schultz's message of "Sat, 25 Oct 2003 23:56:21 -0700") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on dsa.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 cc: freebsd-hackers@FreeBSD.ORG cc: Q cc: Kris Kennaway Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 11:06:55 -0000 David Schultz writes: > I'm not particularly ``familiar'' with postgres, but I did some > performance tests on it a little while ago. Grepping through one > of the traces just now, I found that database system made 139 > calls to mmap(), and the maximum number of regions mapped at any > given time was 39.[1] PostgreSQL doesn't mmap its data. The mmap() calls you saw were from malloc(). The only place PostgreSQL calls mmap() directly is for IPC in the QNX port (because QNX apparently doesn't have SysV IPC). DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 04:34:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5109A16A4B3 for ; Sun, 26 Oct 2003 04:34:18 -0800 (PST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id C974A43FA3 for ; Sun, 26 Oct 2003 04:34:16 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au (ppp107-81.lns1.adl1.internode.on.net [150.101.107.81])h9QCY9i3041744; Sun, 26 Oct 2003 23:04:13 +1030 (CST) Received: from localhost (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.9) with ESMTP id h9QCXu1T021088; Sun, 26 Oct 2003 23:03:56 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Martin =?utf-8?q?V=C3=A1=C5=88a?= , freebsd-hackers@freebsd.org Date: Sun, 26 Oct 2003 23:03:44 +1030 User-Agent: KMail/1.5.3 References: <20031025211141.16475ea7.martin.vana@vslib.cz> In-Reply-To: <20031025211141.16475ea7.martin.vana@vslib.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200310262303.45293.doconnor@gsoft.com.au> X-Spam-Score: -4.7 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) Subject: Re: two soundcards and realplayer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 12:34:18 -0000 On Sunday 26 October 2003 05:41, Martin V=C3=A1=C5=88a wrote: > I use two soundcards on my Freebsd5.1 box - Sb Live and SB AWE64, FreeBSD > somehow figured out that Live is better than Awe and made it "primary" > soundcard. The reason I have AWE still in computer, is it's amplyfing > skills /2x4W/ so I don't need aditional amplyfier. With Xmms it's fine, I > just changed confile and enjoy music. But I can't figure out how to swap > soundcards in RealPlayer and Mplayer. Is there a way how to change it > system wide? In 4.x you can do=20 cd /dev sudo sh ./MAKEDEV snd1 With 5.x (and DEVFS), do hw.snd.unit=3D1 =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 04:43:35 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1747A16A4B3 for ; Sun, 26 Oct 2003 04:43:35 -0800 (PST) Received: from be-well.ilk.org (lowellg.ne.client2.attbi.com [66.30.200.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E8E143F85 for ; Sun, 26 Oct 2003 04:43:34 -0800 (PST) (envelope-from lowell@world.std.com) Received: by be-well.ilk.org (Postfix, from userid 1147) id BDFA53AB7; Sun, 26 Oct 2003 07:43:33 -0500 (EST) Sender: lowell@be-well.ilk.org To: References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1066820436.25609.93.camel@boxster.onthenet.com.au> <20031026052854.GA20701@VARK.homeunix.com> From: Lowell Gilbert Date: 26 Oct 2003 07:43:33 -0500 In-Reply-To: <20031026052854.GA20701@VARK.homeunix.com> Message-ID: <44he1wi2yy.fsf@be-well.ilk.org> Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 12:43:35 -0000 David Schultz writes: > On Sun, Oct 26, 2003, Dag-Erling Smrgrav wrote: > > Q writes: > > > Yes, it would appear this is a legacy thing that existed in the original > > > 1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still > > > use this technique, but OpenBSD changed to using Red-Black trees back in > > > Feb 2002. > > > [...] > > > I am wondering if there is a compelling reason why the technique used by > > > OpenBSD could not be adapted to FreeBSD's VM system. > > > > Adapting OpenBSD's red-balck patches would require quite a bit of work > > as FreeBSD and OpenBSD have diverged quite a bit in this area. Though > > it is a good idea to change the list into a tree, I think you'd get > > more mileage by addressing the fundamental problem, which is the lack > > of a free list. The current code (in both FreeBSD and OpenBSD) > > searches a list or tree of allocated extents, sorted by location, > > looking for a pair that have sufficient space between them for the > > extent you want to create. We should instead keep track of free > > extents in a structure that makes it easy to locate one of the correct > > size. We probably need a dual structure, though, because we need to > > keep the free extents sorted both by size (to quickly find what we > > need) and by location (to facilitate aggregation of adjacent extents, > > without which we'd suffer horribly from address space fragmentation). > > > > I have no idea how much this means for real-life workloads though. > > Your idea of using a size-hashed freelist as well as a > location-sorted list is appealing in its simplicity. Though it > can cause a bit of fragmentation, it gives you constant time > lookup. Bonwick's vmem allocator ([1], section 4.4.2 and > following), apparently works quite well using this principle. A hash probably isn't the right data structure for either dimension (DES didn't say it was, I notice). Finding the next-largest available entry is a useful operation, here, so a list would be better than a hash. [Or a tree; the point is that exact-match isn't the only kind of search you need.] > But regardless of the approach, someone has yet to demonstrate > that this is actually a performance problem in the real world. ;-) Yes. Wouldn't be easy to test even if you wanted to, either... From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 07:48:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADC5B16A4BF for ; Sun, 26 Oct 2003 07:48:58 -0800 (PST) Received: from bluebox.CS.Princeton.EDU (bluebox.CS.Princeton.EDU [128.112.136.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD2043FAF for ; Sun, 26 Oct 2003 07:48:57 -0800 (PST) (envelope-from vivek@CS.Princeton.EDU) Received: from web0.CS.Princeton.EDU (www [128.112.136.35]) h9QFmsDu026713; Sun, 26 Oct 2003 10:48:54 -0500 (EST) Received: (from www@localhost) by web0.CS.Princeton.EDU (8.11.7+Sun/8.11.6) id h9QFmr717794; Sun, 26 Oct 2003 10:48:53 -0500 (EST) X-Authentication-Warning: web0.CS.Princeton.EDU: www set sender to vivek@CS.Princeton.EDU using -f Received: from 216-99-244-15-hou-01.cvx.algx.net (216-99-244-15-hou-01.cvx.algx.net [216.99.244.15]) by webmail.cs.princeton.edu (IMP) with HTTP for ; Sun, 26 Oct 2003 10:48:52 -0500 Message-ID: <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> Date: Sun, 26 Oct 2003 10:48:52 -0500 From: vivek@CS.Princeton.EDU To: Dag-Erling =?iso-8859-1?b?U234cmdyYXY=?= References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1066820436.25609.93.camel@boxster.onthenet.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 216.99.244.15 cc: freebsd-hackers@freebsd.org cc: Q cc: Kris Kennaway Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 15:48:58 -0000 We've been trying to get good SpecWeb99 numbers on FreeBSD using a user-space server. Our initial results weren't that impressive, and we traced them to a number of issues, including VM system performance. We decided to avoid all mmap/mincore operations, and opted to instead add a flag to sendfile such that we can try sendfile and have it return an error (instead of blocking) when a page isn't in memory. So, we were able to adapt the server to avoid all of the VM problems, but one could imagine someone less eager just coming to the conclusion that freebsd is slower than linux. Incidentally, our resulting server gets a SpecWeb99 score of about 800 on a 1GHZ/1GB machine. The highest published score for a comparable machine is about 600, and that's using the kernel-space Tux server on Linux. Is anyone interested in merging our changes (mostly to sendfile) into the kernel? We've just bought a much faster box, and we're trying to see if we can set the uniprocessor record using only a user-space server. Details about what we have so far are at http://www.cs.princeton.edu/~yruan/debox/ Yaoping Ruan had mentioned this on the list before (and sent a pointer to the sendfile patches), but didn't seem to get much response. -Vivek Quoting Dag-Erling Smørgrav : > Q writes: > > Yes, it would appear this is a legacy thing that existed in the original > > 1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still > > use this technique, but OpenBSD changed to using Red-Black trees back in > > Feb 2002. > > [...] > > I am wondering if there is a compelling reason why the technique used by > > OpenBSD could not be adapted to FreeBSD's VM system. > > Adapting OpenBSD's red-balck patches would require quite a bit of work > as FreeBSD and OpenBSD have diverged quite a bit in this area. Though > it is a good idea to change the list into a tree, I think you'd get > more mileage by addressing the fundamental problem, which is the lack > of a free list. The current code (in both FreeBSD and OpenBSD) > searches a list or tree of allocated extents, sorted by location, > looking for a pair that have sufficient space between them for the > extent you want to create. We should instead keep track of free > extents in a structure that makes it easy to locate one of the correct > size. We probably need a dual structure, though, because we need to > keep the free extents sorted both by size (to quickly find what we > need) and by location (to facilitate aggregation of adjacent extents, > without which we'd suffer horribly from address space fragmentation). > > I have no idea how much this means for real-life workloads though. > > DES > -- > Dag-Erling Smørgrav - des@des.no > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 09:57:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B154C16A4B3 for ; Sun, 26 Oct 2003 09:57:32 -0800 (PST) Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C5B443F85 for ; Sun, 26 Oct 2003 09:57:31 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 29401 invoked from network); 26 Oct 2003 17:57:30 -0000 Received: from unknown (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2003 17:57:30 -0000 Received: from hydrogen.funkthat.com (vcpahe@localhost.funkthat.com [127.0.0.1])h9QHvTgP066491; Sun, 26 Oct 2003 09:57:30 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id h9QHvQa5066490; Sun, 26 Oct 2003 09:57:26 -0800 (PST) Date: Sun, 26 Oct 2003 09:57:26 -0800 From: John-Mark Gurney To: vivek@CS.Princeton.EDU Message-ID: <20031026175726.GC558@funkthat.com> Mail-Followup-To: vivek@CS.Princeton.EDU, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-hackers@freebsd.org, Q , Kris Kennaway References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1066820436.25609.93.camel@boxster.onthenet.com.au> <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: Kris Kennaway cc: Q cc: freebsd-hackers@freebsd.org Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 17:57:32 -0000 vivek@CS.Princeton.EDU wrote this message on Sun, Oct 26, 2003 at 10:48 -0500: > We decided to avoid all mmap/mincore operations, and opted to instead > add a flag to sendfile such that we can try sendfile and have it return > an error (instead of blocking) when a page isn't in memory. I was thinking about this myself, but how do you prevent spinning on the sendfile waiting for the page to become available? You have the send space to wait for on the socket, but there is no equivalent kqueue event to wait for when a page becomes available. Do you simply always spin on sendfile since the socket keeps returning available for writing? I have a similar web server design that I wrote at the end of last year, and your paper brought to light to problems of sendfile, so I have been thinking of switching to async io, since there you can get completion status when the io completes. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 10:06:59 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAA9716A4B3 for ; Sun, 26 Oct 2003 10:06:59 -0800 (PST) Received: from mail.speakeasy.net (mail10.speakeasy.net [216.254.0.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id E78DA43F93 for ; Sun, 26 Oct 2003 10:06:58 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 14816 invoked from network); 26 Oct 2003 18:06:58 -0000 Received: from unknown (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail10.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2003 18:06:58 -0000 Received: from hydrogen.funkthat.com (yvwfgj@localhost.funkthat.com [127.0.0.1])h9QI6mgP066726; Sun, 26 Oct 2003 10:06:48 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id h9QI6lnL066725; Sun, 26 Oct 2003 10:06:47 -0800 (PST) Date: Sun, 26 Oct 2003 10:06:47 -0800 From: John-Mark Gurney To: Sean Hamilton Message-ID: <20031026180647.GD558@funkthat.com> Mail-Followup-To: Sean Hamilton , freebsd-hackers@freebsd.org References: <005b01c398ed$87070080$0300000a@antalus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005b01c398ed$87070080$0300000a@antalus> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-hackers@freebsd.org Subject: Re: Passthrough block device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 18:07:00 -0000 Sean Hamilton wrote this message on Wed, Oct 22, 2003 at 15:40 -0700: > Does FreeBSD support a device that will allow for the passing of all reads > and writes on it to a userland application? I wish to handle swapping > myself, preferably without any kernel hacking. Take a look at geom_gate from Pawel Dawidek. You could probably very easily modify the client side to do your own code, instead of passing it over the network to the server. http://garage.freebsd.pl/geom_gate.README > What would happen if the kernel decided to swap out such a process? Probably a deadlock... you could partially avoid this by using mlock to prevent your process from swapping. It may still be possible to dead lock due to the stack of the process being able to be swapped out.. some one better versed in the process/VM interaction should answer that. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 10:23:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3D0B16A4BF for ; Sun, 26 Oct 2003 10:23:36 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 8C8B343FBD for ; Sun, 26 Oct 2003 10:23:35 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 57623 invoked from network); 26 Oct 2003 18:23:34 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 26 Oct 2003 18:23:34 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 26 Oct 2003 12:23:32 -0600 (CST) From: Mike Silbersack To: vivek@CS.Princeton.EDU In-Reply-To: <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> Message-ID: <20031026121527.K2023@odysseus.silby.com> References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <1066816287.25609.34.camel@boxster.onthenet.com.au> <1066820436.25609.93.camel@boxster.onthenet.com.au> <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Dag-Erling =?iso-8859-1?b?U234cmdyYXY=?= cc: Kris Kennaway cc: Q cc: freebsd-hackers@freebsd.org Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 18:23:37 -0000 On Sun, 26 Oct 2003 vivek@CS.Princeton.EDU wrote: > Details about what we have so far are at > http://www.cs.princeton.edu/~yruan/debox/ > > Yaoping Ruan had mentioned this on the list before (and sent a > pointer to the sendfile patches), but didn't seem to get much > response. > > -Vivek As always, you're seeing the lack of available committer time, not a real lack of interest. One way to accelerate the process might be for someone (not necessarily you, any reader of this mailing list could do it) to show that this change visibly benefits some easy to run benchmark. Some simple setup of apachebench vs thttpd (which uses sendfile, afaik) would be useful for this purpose. Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 10:46:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAC8316A4B3 for ; Sun, 26 Oct 2003 10:46:14 -0800 (PST) Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id E181443F3F for ; Sun, 26 Oct 2003 10:46:13 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 8671 invoked from network); 26 Oct 2003 18:46:13 -0000 Received: from unknown (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail9.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2003 18:46:13 -0000 Received: from hydrogen.funkthat.com (mzebix@localhost.funkthat.com [127.0.0.1])h9QIkCgP067650; Sun, 26 Oct 2003 10:46:12 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id h9QIkC0k067649; Sun, 26 Oct 2003 10:46:12 -0800 (PST) Date: Sun, 26 Oct 2003 10:46:12 -0800 From: John-Mark Gurney To: Jason Slagle Message-ID: <20031026184612.GF558@funkthat.com> Mail-Followup-To: Jason Slagle , freebsd-hackers@freebsd.org References: <20031025115710.Q647@mail.tacorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031025115710.Q647@mail.tacorp.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-hackers@freebsd.org Subject: Re: PCAP Open BPF R/W? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 18:46:15 -0000 Jason Slagle wrote this message on Sat, Oct 25, 2003 at 11:58 -0400: > Could someone consider applying the following to the in tree pcap? It > makes it possible to write to the pcap fd to send packets out the > interface. Some simulators expect this ability to properly do > networking.. You should probably add code to fall back to O_RDONLY if the O_RDWR open fails incase an admin has sent read permissions on /dev/bpfX, but not write for a group or something. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 11:19:38 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D2FE16A4BF for ; Sun, 26 Oct 2003 11:19:38 -0800 (PST) Received: from research.rutgers.edu (research.rutgers.edu [128.6.25.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3517F43F85 for ; Sun, 26 Oct 2003 11:19:37 -0800 (PST) (envelope-from bohra@cs.rutgers.edu) Received: from cs.rutgers.edu (sirtaki.rutgers.edu [128.6.171.146]) h9QJJVJ20392; Sun, 26 Oct 2003 14:19:31 -0500 (EST) Message-ID: <3F9C1E2C.50409@cs.rutgers.edu> Date: Sun, 26 Oct 2003 14:19:08 -0500 From: Aniruddha Bohra User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031024 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Silbersack References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <1066816287.25609.34.camel@boxster.onthenet.com.au> <1066820436.25609.93.camel@boxster.onthenet.com.au> <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> <20031026121527.K2023@odysseus.silby.com> In-Reply-To: <20031026121527.K2023@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: vivek@CS.Princeton.EDU Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 19:19:38 -0000 > > As always, you're seeing the lack of available committer time, not a real > lack of interest. One way to accelerate the process might be for someone > (not necessarily you, any reader of this mailing list could do it) to show > that this change visibly benefits some easy to run benchmark. Some simple > setup of apachebench vs thttpd (which uses sendfile, afaik) would be > useful for this purpose. I think he said in the mail that they are setting a record for SPEC Web benchmarking numbers. I think it is a very visible and referred to benchmark as far as web servers go, and it would be (800/600) as compared to the best linux webserver. I think it is proof enough. Would be fun to have the best SPEC number from FreeBSD and a university and not Linux and some industrial giant :) Thanks Aniruddha From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 14:09:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 780F016A4B3 for ; Sun, 26 Oct 2003 14:09:44 -0800 (PST) Received: from mail.volga.ru (mail.volga.ru [195.144.200.51]) by mx1.FreeBSD.org (Postfix) with SMTP id 48FF443FAF for ; Sun, 26 Oct 2003 14:09:41 -0800 (PST) (envelope-from bsv@csite.ru) Received: (qmail 54939 invoked by uid 89); 26 Oct 2003 22:09:51 -0000 Received: from unknown (HELO dexter.csite.ru) (195.144.194.54) by mail.volga.ru with SMTP; 26 Oct 2003 22:09:50 -0000 Received: from localhost (localhost [127.0.0.1]) by dexter.csite.ru (8.12.9/8.12.9) with SMTP id h9QL9PPX003820 for ; Mon, 27 Oct 2003 01:09:25 +0400 (SAMT) (envelope-from bsv@csite.ru) Date: Mon, 27 Oct 2003 01:09:25 +0400 From: "Sergey V. Belov" To: freebsd-hackers@freebsd.org Message-Id: <20031027010925.661d3edd.bsv@csite.ru> Organization: Home (~) X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Mon__27_Oct_2003_01:09:25_+0400_08725c00" Subject: Intel PILA 8460B LAN adapter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 22:09:44 -0000 This is a multi-part message in MIME format. --Multipart_Mon__27_Oct_2003_01:09:25_+0400_08725c00 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello all, I had an experience of install this LAN adapter on latest FreeBSD RELENG_4_8 (4.8p13): PILA 8460B \ EtherExpress PRO/100+ Server Adapter (PCI; TPE; 100 / 10 Mbps). After install, this card has not been responsed; but with following patch card is worked perfectly over three weeks. Comments? Finally, I should be glad to see this changes in the main source tree. -- Sergey V. Belov (aka Argail) \ UNIX: Live free or die. Now listening: No CD in /dev/acd0a --Multipart_Mon__27_Oct_2003_01:09:25_+0400_08725c00 Content-Type: application/octet-stream; name="if_fxp.c.diff" Content-Disposition: attachment; filename="if_fxp.c.diff" Content-Transfer-Encoding: base64 LS0tIGlmX2Z4cC5jLm9yaWcJTW9uIE9jdCAyNyAwMTowNjoyNyAyMDAzCisrKyBpZl9meHAuYwlN b24gT2N0IDI3IDAxOjA2OjIyIDIwMDMKQEAgLTE2MCw2ICsxNjAsNyBAQAogICAgIHsgMHgxMDM3 LAkJIkludGVsIFByby8xMDAgRXRoZXJuZXQiIH0sCiAgICAgeyAweDEwMzgsCQkiSW50ZWwgUHJv LzEwMCBFdGhlcm5ldCIgfSwKICAgICB7IDB4MTAzOSwJCSJJbnRlbCBQcm8vMTAwIEV0aGVybmV0 IiB9LAorICAgIHsgMHgxMDUwLAkJIkludGVsIFByby8xMDAgRXRoZXJuZXQiIH0sCiAgICAgeyAw eDEwM0EsCQkiSW50ZWwgUHJvLzEwMCBFdGhlcm5ldCIgfSwKICAgICB7IDB4MTAzQiwJCSJJbnRl bCBQcm8vMTAwIEV0aGVybmV0IiB9LAogICAgIHsgMHgxMDNDLAkJIkludGVsIFByby8xMDAgRXRo ZXJuZXQiIH0sCkBAIC01NDAsNyArNTQxLDcgQEAKIAkgKiBTZWUgSW50ZWwgODI4MDFCQS84Mjgw MUJBTSBTcGVjaWZpY2F0aW9uIFVwZGF0ZSwgRXJyYXRhICMzMC4KIAkgKi8KIAlpID0gcGNpX2dl dF9kZXZpY2UoZGV2KTsKLQlpZiAoaSA9PSAweDI0NDkgfHwgKGkgPiAweDEwMzAgJiYgaSA8IDB4 MTAzOSkgfHwKKwlpZiAoaSA9PSAweDI0NDkgfHwgKGkgPiAweDEwMzAgJiYgaSA8IDB4MTA1MCkg fHwKIAkgICAgc2MtPnJldmlzaW9uID49IEZYUF9SRVZfODI1NTlfQTApIHsKIAkJZnhwX3JlYWRf ZWVwcm9tKHNjLCAmZGF0YSwgMTAsIDEpOwogCQlpZiAoZGF0YSAmIDB4MDIpIHsJCQkvKiBTVEIg ZW5hYmxlICovCg== --Multipart_Mon__27_Oct_2003_01:09:25_+0400_08725c00-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 15:09:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F98416A4B3; Sun, 26 Oct 2003 15:09:40 -0800 (PST) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 616CB43FBD; Sun, 26 Oct 2003 15:09:39 -0800 (PST) (envelope-from alc@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id 141144AA01; Sun, 26 Oct 2003 17:09:39 -0600 (CST) Received: from cs.rice.edu ([127.0.0.1]) by localhost (cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14580-01-6; Sun, 26 Oct 2003 17:09:37 -0600 (CST) Received: by cs.rice.edu (Postfix, from userid 19572) id 957904A9C3; Sun, 26 Oct 2003 17:09:37 -0600 (CST) Date: Sun, 26 Oct 2003 17:09:37 -0600 From: Alan Cox To: Q , hackers@freebsd.org Message-ID: <20031026230937.GF20658@cs.rice.edu> References: <1066793641.22245.12.camel@boxster.onthenet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1066793641.22245.12.camel@boxster.onthenet.com.au> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavis-20030616-p5 at rice.edu cc: alc@freebsd.org cc: dillon@apollo.backplane.com Subject: Re: [Fwd: Some mmap observations compared to Linux 2.6/OpenBSD] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 23:09:40 -0000 On Wed, Oct 22, 2003 at 01:34:01PM +1000, Q wrote: > It has been suggested that I should direct this question to the VM > system guru's. Your comments on this would be appreciated. > An address space is represented by a data structure that we call a vm_map. A vm_map is, in the abstact, an ordered collection of in-use address ranges. FreeBSD 4.x implements the vm_map as a doubly-linked list of address ranges with a hint pointing to the last accessed entry. Thus, if the hint fails, the expected time to lookup an in-use address is O(n). FreeBSD 5.x overlays a balanced binary search tree over this structure. This accelerates the lookup to an (amortized) O(log n). In fact, for the kind of balanced binary search tree that we use, the last accessed entry is at the root of the tree. Thus, any locality in the pattern of lookups will produce even better results. Linux and OpenBSD are similar to FreeBSD 5.x. The differences lie in the details, like the kind of balanced binary tree that is used. That said, having a balanced binary tree to represent the address space does NOT inherently make finding unallocated space any faster. Instead, OpenBSD augments an address space entry with extra information to speed up this process: struct vm_map_entry { ... vaddr_t ownspace; /* free space after */ vaddr_t space; /* space in subtree */ ... The same could be done in FreeBSD, and you don't need a red-black tree in order to do it. If someone, especially a junior kernel hacker with a commit bit, is serious about trying this, I'll gladly mentor them. Recognize, however, that this approach may produce great results for a microbenchmark, but pessimize other more interesting workloads, like say, "buildworld", making it a poor choice. Nonetheless, I think we should strive to get better results in this area. Regards, Alan > > -----Forwarded Message----- > From: Q > To: freebsd-hackers@freebsd.org > Subject: Some mmap observations compared to Linux 2.6/OpenBSD > Date: Wed, 22 Oct 2003 12:22:35 +1000 > > As an effort to get more acquainted with the FreeBSD kernel, I have been > looking through how mmap works. I don't yet understand how it all fits > together, or of the exact implications things may have in the wild, but > I have noticed under some synthetic conditions, ie. mmaping small > non-contiguous pages of a file, mmap allocation scales much more poorly > on FreeBSD than on OpenBSD and Linux 2.6. > > After investigating this further I have observed that vm_map_findspace() > traverses a linked list to find the next region (O(n) cost), whereas > OpenBSD and Linux 2.6 both use Red-Black trees for the same purpose > (O(log n) cost). Profiling the FreeBSD kernel appears to confirm this. > > Can someone comment on whether this is something that has been done > intentionally, or avoided in favour of some other yet to be implemented > solution? Or is it still on someones todo list. > > -- > Seeya...Q > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > _____ / Quinton Dolan - q@OntheNet.com.au > __ __/ / / __/ / / > / __ / _/ / / Gold Coast, QLD, Australia > __/ __/ __/ ____/ / - / Ph: +61 419 729 806 > _______ / > _\ > From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 17:52:05 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBCC916A4B3 for ; Sun, 26 Oct 2003 17:52:05 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3374143FBD for ; Sun, 26 Oct 2003 17:52:05 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h9R1pxo4098351; Sun, 26 Oct 2003 19:51:59 -0600 (CST) (envelope-from dan) Date: Sun, 26 Oct 2003 19:51:59 -0600 From: Dan Nelson To: =?utf-8?Q?J=C3=BCrgen?= Spiegel Message-ID: <20031027015159.GB37992@dan.emsphone.com> References: <200310260930.42950.juergen.spiegel@jsp-edv.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310260930.42950.juergen.spiegel@jsp-edv.de> X-OS: FreeBSD 5.1-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: hackers@freebsd.org Subject: Re: FreeBSD 4.2 NIS-Client with Linux NIS-Server Problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 01:52:06 -0000 In the last episode (Oct 26), Jrgen Spiegel said: > I can't get it to work. > > I`ve read many of the Howtos and newgroups discussions on that theme, > but there are no usefull hints for this special proclem. > > The other NIS-Clients on my network (Solaris, AIX, Linux) can do > connect with any username set in the /etc/passwd on the NIS-Server > without any problems. > > I knew traditional NIS and the most of the common problems, but in > this case I am perplex. So far you have told us you have some unknown version of FreeBSD as a client, some unknown version of Linux, and you care having some unknown problem. We need details. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 22:54:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2435016A4B3 for ; Sun, 26 Oct 2003 22:54:58 -0800 (PST) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D82543F85 for ; Sun, 26 Oct 2003 22:54:57 -0800 (PST) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) h9R6rcft069110; Mon, 27 Oct 2003 07:53:38 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id h9R6rRVh069105; Mon, 27 Oct 2003 07:53:27 +0100 (CET) (envelope-from marius) Date: Mon, 27 Oct 2003 07:53:27 +0100 From: Marius Strobl To: "Sergey V. Belov" Message-ID: <20031027075327.A68883@newtrinity.zeist.de> References: <20031027010925.661d3edd.bsv@csite.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031027010925.661d3edd.bsv@csite.ru>; from bsv@csite.ru on Mon, Oct 27, 2003 at 01:09:25AM +0400 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.22.0.1; VDF 6.22.0.16 cc: freebsd-hackers@freebsd.org Subject: Re: Intel PILA 8460B LAN adapter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 06:54:58 -0000 On Mon, Oct 27, 2003 at 01:09:25AM +0400, Sergey V. Belov wrote: > Hello all, > I had an experience of install this LAN adapter on latest FreeBSD RELENG_4_8 (4.8p13): > PILA 8460B \ EtherExpress PRO/100+ Server Adapter (PCI; TPE; 100 / 10 Mbps). > After install, this card has not been responsed; but with following patch card is worked > perfectly over three weeks. > Comments? > Finally, I should be glad to see this changes in the main source tree. > Apart from that patch being wrong, support for this card was added to RELENG_4 on June 12. If you update to 4-stable or upcoming 4.9-release you will get it. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 01:45:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6DC616A4B3 for ; Mon, 27 Oct 2003 01:45:12 -0800 (PST) Received: from mail.volga.ru (mail.volga.ru [195.144.200.51]) by mx1.FreeBSD.org (Postfix) with SMTP id 3289143FE1 for ; Mon, 27 Oct 2003 01:45:10 -0800 (PST) (envelope-from bsv@csite.ru) Received: (qmail 85081 invoked by uid 89); 27 Oct 2003 09:45:14 -0000 Received: from unknown (HELO dexter.csite.ru) (195.144.194.56) by mail.volga.ru with SMTP; 27 Oct 2003 09:45:13 -0000 Received: from localhost (localhost [127.0.0.1]) by dexter.csite.ru (8.12.9/8.12.9) with SMTP id h9R9hd4K002981 for ; Mon, 27 Oct 2003 13:43:39 +0400 (SAMT) (envelope-from bsv@csite.ru) Date: Mon, 27 Oct 2003 13:43:38 +0400 From: "Sergey V. Belov" To: freebsd-hackers@freebsd.org Message-Id: <20031027134338.6dc9bca9.bsv@csite.ru> In-Reply-To: <20031027075327.A68883@newtrinity.zeist.de> References: <20031027010925.661d3edd.bsv@csite.ru> <20031027075327.A68883@newtrinity.zeist.de> Organization: Home (~) X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Intel PILA 8460B LAN adapter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 09:45:12 -0000 On Mon, 27 Oct 2003 07:53:27 +0100 Marius Strobl wrote: > On Mon, Oct 27, 2003 at 01:09:25AM +0400, Sergey V. Belov wrote: > > Hello all, > > I had an experience of install this LAN adapter on latest FreeBSD RELENG_4_8 (4.8p13): > > PILA 8460B \ EtherExpress PRO/100+ Server Adapter (PCI; TPE; 100 / 10 Mbps). > > After install, this card has not been responsed; but with following patch card is worked > > perfectly over three weeks. > > Comments? > > Finally, I should be glad to see this changes in the main source tree. > > > > Apart from that patch being wrong, support for this card was added to > RELENG_4 on June 12. If you update to 4-stable or upcoming 4.9-release > you will get it. Thanks for the reply, but why that change is not in RELENG_4_8 yet? And than, what's wrong with the patch that give me working card? I'm not a "kernel hacker", so more detailed comments are welcome. -- Sergey V. Belov (aka Argail) \ UNIX: Live free or die. Now listening: J. S. Bach - Fugue (BWV 582) From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 01:47:42 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B801B16A4B3 for ; Mon, 27 Oct 2003 01:47:42 -0800 (PST) Received: from proxy.riic.at (postoffice.riic.at [140.78.161.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2743143FB1 for ; Mon, 27 Oct 2003 01:47:41 -0800 (PST) (envelope-from hueber@riic.at) Received: from hanni.riic.uni-linz.ac.at (hanni.riic.uni-linz.ac.at [140.78.161.78])h9R9laPw007829 for ; Mon, 27 Oct 2003 10:47:36 +0100 Date: Mon, 27 Oct 2003 10:47:36 +0100 From: Gernot Hueber To: freebsd-hackers@freebsd.org Message-ID: <20031027094736.GW36100@hanni.riic.uni-linz.ac.at> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Mailer: Balsa 2.0.13 Lines: 280 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Subject: Patch Review: ulpt read patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 09:47:42 -0000 Hi, I have written a patch for ulpt.c which allows reading the lpt device. This operation is required to get status information of some printers (eg. Epson Stylus) when connected via usb. Please can you review this patch (it applies to 5.1 P6) Thanks, Gernot *** ulpt.c.orig Wed Oct 22 10:59:53 2003 --- ulpt.c Fri Oct 24 21:40:57 2003 *************** *** 71,76 **** --- 71,77 ---- #define LPTPRI (PZERO+8) #define ULPT_BSIZE 16384 + #define ULPT_IN_BUFFERLEN 1024 #ifdef USB_DEBUG #define DPRINTF(x) if (ulptdebug) logprintf x *************** *** 105,112 **** int sc_in; usbd_pipe_handle sc_in_pipe; /* bulk in pipe */ ! usbd_xfer_handle sc_in_xfer1; ! usbd_xfer_handle sc_in_xfer2; u_char sc_junk[64]; /* somewhere to dump input */ u_char sc_state; --- 106,114 ---- int sc_in; usbd_pipe_handle sc_in_pipe; /* bulk in pipe */ ! usbd_xfer_handle sc_in_xfer; ! void *sc_in_buffer; ! int sc_in_bufferlen; u_char sc_junk[64]; /* somewhere to dump input */ u_char sc_state; *************** *** 141,146 **** --- 143,149 ---- #elif defined(__FreeBSD__) Static d_open_t ulptopen; Static d_close_t ulptclose; + Static d_read_t ulptread; Static d_write_t ulptwrite; Static d_ioctl_t ulptioctl; *************** *** 149,154 **** --- 152,158 ---- Static struct cdevsw ulpt_cdevsw = { .d_open = ulptopen, .d_close = ulptclose, + .d_read = ulptread, .d_write = ulptwrite, .d_ioctl = ulptioctl, .d_name = "ulpt", *************** *** 162,167 **** --- 166,172 ---- void ulpt_disco(void *); int ulpt_do_write(struct ulpt_softc *, struct uio *uio, int); + int ulpt_do_read(struct ulpt_softc *, struct uio *uio, int); int ulpt_status(struct ulpt_softc *); void ulpt_reset(struct ulpt_softc *); int ulpt_statusmsg(u_char, struct ulpt_softc *); *************** *** 344,349 **** --- 349,356 ---- UID_ROOT, GID_OPERATOR, 0644, "unlpt%d", device_get_unit(self)); #endif + + usbd_add_drv_event(USB_EVENT_DRIVER_ATTACH, sc->sc_udev, USBDEV(sc->sc_dev)); *************** *** 473,497 **** } } - static void - ulpt_input(usbd_xfer_handle xfer, usbd_private_handle priv, usbd_status status) - { - struct ulpt_softc *sc = priv; - u_int32_t count; - - /* Don't loop on errors or 0-length input. */ - usbd_get_xfer_status(xfer, NULL, NULL, &count, NULL); - if (status != USBD_NORMAL_COMPLETION || count == 0) - return; - - DPRINTFN(2,("ulpt_input: got some data\n")); - /* Do it again. */ - if (xfer == sc->sc_in_xfer1) - usbd_transfer(sc->sc_in_xfer2); - else - usbd_transfer(sc->sc_in_xfer1); - } - int ulptusein = 1; /* --- 480,485 ---- *************** *** 517,522 **** --- 505,513 ---- sc->sc_flags = flags; DPRINTF(("ulptopen: flags=0x%x\n", (unsigned)flags)); + sc->sc_in_buffer = malloc(ULPT_IN_BUFFERLEN, M_USBDEV, M_WAITOK); + sc->sc_in_bufferlen = ULPT_IN_BUFFERLEN; + #if defined(USB_DEBUG) && defined(__FreeBSD__) /* Ignoring these flags might not be a good idea */ if ((flags & ~ULPT_NOPRIME) != 0) *************** *** 569,600 **** sc->sc_state = 0; goto done; } ! sc->sc_in_xfer1 = usbd_alloc_xfer(sc->sc_udev); ! sc->sc_in_xfer2 = usbd_alloc_xfer(sc->sc_udev); ! if (sc->sc_in_xfer1 == NULL || sc->sc_in_xfer2 == NULL) { ! error = ENOMEM; ! if (sc->sc_in_xfer1 != NULL) { ! usbd_free_xfer(sc->sc_in_xfer1); ! sc->sc_in_xfer1 = NULL; ! } ! if (sc->sc_in_xfer2 != NULL) { ! usbd_free_xfer(sc->sc_in_xfer2); ! sc->sc_in_xfer2 = NULL; ! } ! usbd_close_pipe(sc->sc_out_pipe); ! sc->sc_out_pipe = NULL; ! usbd_close_pipe(sc->sc_in_pipe); ! sc->sc_in_pipe = NULL; ! sc->sc_state = 0; ! goto done; ! } ! usbd_setup_xfer(sc->sc_in_xfer1, sc->sc_in_pipe, sc, ! sc->sc_junk, sizeof sc->sc_junk, USBD_SHORT_XFER_OK, ! USBD_NO_TIMEOUT, ulpt_input); ! usbd_setup_xfer(sc->sc_in_xfer2, sc->sc_in_pipe, sc, ! sc->sc_junk, sizeof sc->sc_junk, USBD_SHORT_XFER_OK, ! USBD_NO_TIMEOUT, ulpt_input); ! usbd_transfer(sc->sc_in_xfer1); /* ignore failed start */ } sc->sc_state = ULPT_OPEN; --- 560,571 ---- sc->sc_state = 0; goto done; } ! ! sc->sc_in_xfer = usbd_alloc_xfer(sc->sc_udev); ! if (sc->sc_in_xfer == NULL) { ! error=ENOMEM; ! goto done; ! } } sc->sc_state = ULPT_OPEN; *************** *** 645,664 **** usbd_abort_pipe(sc->sc_in_pipe); usbd_close_pipe(sc->sc_in_pipe); sc->sc_in_pipe = NULL; - if (sc->sc_in_xfer1 != NULL) { - usbd_free_xfer(sc->sc_in_xfer1); - sc->sc_in_xfer1 = NULL; - } - if (sc->sc_in_xfer2 != NULL) { - usbd_free_xfer(sc->sc_in_xfer2); - sc->sc_in_xfer2 = NULL; - } } sc->sc_state = 0; DPRINTF(("ulptclose: closed\n")); return (0); } int --- 616,690 ---- usbd_abort_pipe(sc->sc_in_pipe); usbd_close_pipe(sc->sc_in_pipe); sc->sc_in_pipe = NULL; } + if (sc->sc_in_xfer) { + usbd_free_xfer(sc->sc_in_xfer); + sc->sc_in_xfer = NULL; + } + if (sc->sc_in_buffer) { + free(sc->sc_in_buffer, M_USBDEV); + sc->sc_in_buffer = NULL; + } sc->sc_state = 0; DPRINTF(("ulptclose: closed\n")); return (0); + } + + int + ulpt_do_read(struct ulpt_softc *sc, struct uio *uio, int flag) + { + u_int32_t n, tn; + usbd_status err; + int error = 0; + + DPRINTFN(5, ("%s: ulptread\n", USBDEVNAME(sc->sc_dev))); + + if (sc->sc_dying) + return (EIO); + + while ((n = min(sc->sc_in_bufferlen, uio->uio_resid)) != 0) { + DPRINTFN(1, ("ulptread: start transfer %d bytes\n",n)); + tn = n; + + err = usbd_bulk_transfer( + sc->sc_in_xfer, sc->sc_in_pipe, + USBD_SHORT_XFER_OK, USBD_NO_TIMEOUT, + sc->sc_in_buffer, &tn, + "uscnrb"); + if (err) { + if (err == USBD_INTERRUPTED) + error = EINTR; + else if (err == USBD_TIMEOUT) + error = ETIMEDOUT; + else + error = EIO; + break; + } + DPRINTFN(1, ("ulptread: got %d bytes\n", tn)); + error = uiomove(sc->sc_in_buffer, tn, uio); + if (error || tn < n) + break; + } + + return (error); + } + + int + ulptread(dev_t dev, struct uio *uio, int flag) + { + struct ulpt_softc *sc; + int error; + + USB_GET_SC(ulpt, ULPTUNIT(dev), sc); + + sc->sc_refcnt++; + error = ulpt_do_read(sc, uio, flag); + if (--sc->sc_refcnt < 0) + usb_detach_wakeup(USBDEV(sc->sc_dev)); + + return (error); } int -- Dipl.-Ing. Gernot Hueber Institut f. Integrierte Schaltungen Altenbergerstr. 69 4040 Linz Tel: +43 732 2468-7120, Fax: -7126 E-mail: hueber@riic.at WWW: www.riic.at From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 02:29:11 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 018FE16A4B3 for ; Mon, 27 Oct 2003 02:29:11 -0800 (PST) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id C067843F93 for ; Mon, 27 Oct 2003 02:29:09 -0800 (PST) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) h9RAT1ft073664; Mon, 27 Oct 2003 11:29:01 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id h9RASukW073663; Mon, 27 Oct 2003 11:28:56 +0100 (CET) (envelope-from marius) Date: Mon, 27 Oct 2003 11:28:56 +0100 From: Marius Strobl To: "Sergey V. Belov" Message-ID: <20031027112856.A72984@newtrinity.zeist.de> References: <20031027010925.661d3edd.bsv@csite.ru> <20031027075327.A68883@newtrinity.zeist.de> <20031027134338.6dc9bca9.bsv@csite.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031027134338.6dc9bca9.bsv@csite.ru>; from bsv@csite.ru on Mon, Oct 27, 2003 at 01:43:38PM +0400 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.22.0.1; VDF 6.22.0.16 cc: freebsd-hackers@freebsd.org Subject: Re: Intel PILA 8460B LAN adapter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 10:29:11 -0000 On Mon, Oct 27, 2003 at 01:43:38PM +0400, Sergey V. Belov wrote: > On Mon, 27 Oct 2003 07:53:27 +0100 > Marius Strobl wrote: > > > On Mon, Oct 27, 2003 at 01:09:25AM +0400, Sergey V. Belov wrote: > > > Hello all, > > > I had an experience of install this LAN adapter on latest FreeBSD RELENG_4_8 (4.8p13): > > > PILA 8460B \ EtherExpress PRO/100+ Server Adapter (PCI; TPE; 100 / 10 Mbps). > > > After install, this card has not been responsed; but with following patch card is worked > > > perfectly over three weeks. > > > Comments? > > > Finally, I should be glad to see this changes in the main source tree. > > > > > > > Apart from that patch being wrong, support for this card was added to > > RELENG_4 on June 12. If you update to 4-stable or upcoming 4.9-release > > you will get it. > > Thanks for the reply, but why that change is not in RELENG_4_8 yet? Because only critical fixes, e.g. security fixes, go into RELENG_4_8 (and the other supported RELENG_4_* "security branches") and not new features, e.g. support for new hardware. > And than, what's wrong with the patch that give me working card? I'm not a "kernel hacker", > so more detailed comments are welcome. > It enables workarounds for fxp(4) controllers with chipid 0x1039 to 0x104F which are not intended for these chips and could have some negative impact. In any case this change is irrelevant for supporting fxp(4) controllers with chipid 0x0150. According to the change that was commited to if_fxp.c in order to support 0x0150 adding this id to the fxp_ident_table apparently is enough. Your patch also does this so that's why fxp(4) attaches to your card, but your patch breaks the sorting of the chipids/devids in fxp_ident_table. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 03:08:33 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47D7216A4B3 for ; Mon, 27 Oct 2003 03:08:33 -0800 (PST) Received: from xwing.cscrsa.com (xwing.cscrsa.com [196.14.130.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 6238043F93 for ; Mon, 27 Oct 2003 03:08:29 -0800 (PST) (envelope-from jacovt@cscrsa.com) Received: (qmail 45619 invoked from network); 27 Oct 2003 11:07:07 -0000 Received: from unknown (HELO jaco) (jacovt@cscrsa.com@196.39.98.50) by xwing.cscrsa.com with SMTP; 27 Oct 2003 11:07:07 -0000 Message-ID: <016a01c39c7a$a23a78b0$3635a8c0@jaco> From: "Jaco van Tonder" To: Date: Mon, 27 Oct 2003 13:08:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-hackers@freebsd.org Subject: [4.8-RELEASE - Stable, 5.1-RELEASE] Panics when system loaded X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 11:08:33 -0000 Hi, I installed 4.8-RELEASE from CD yesterday on my P4-2.4GHz machine. Updated sources to the latest 4.8-RELEASE-p13. Started doing buildworld and my machine panicked. Tried a few more times with random panics. Same random panics occur if I build the kernel. After a bit of struggling I managed to get a GENERIC kernel built with debug symbols on the latest source. I did not manage to build or install world on the new sources, but the panics happen regardless of what kernel is running. I also updated to the latest -STABLE, managed to build a kernel and installed it. Same problem exists there aswell (although this might be caused by a kernel and world that are not in sync?). I installed 5.1-RELEASE to find the same problem exists there aswell. Can anybody perhaps give a hint in which direction to look or to make this go away? Thanks in advance! Regards Jaco Setup: Intel P4, 2.4GHz CPU Gigabyte MB with Intel 865P chipset, Hyperthreading technology 512MB DDR333 Ram 40GB Maxtor drive 1024MB Swap USB disabled in BIOS as there is no need for it on this machine. Backtrace: frame# gdb -k kernel.debug.0 vmcore.0 GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf IdlePTD at phsyical address 0x00552000 initial pcb at physical address 0x00483f00 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xa96f98 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0342a10 stack pointer = 0x10:0xdf3d4e7c frame pointer = 0x10:0xdf3d4e84 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 78395 (cc1) interrupt mask = none panic: from debugger Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc0389031 stack pointer = 0x10:0xdf3d4c90 frame pointer = 0x10:0xdf3d4c98 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 78395 (cc1) interrupt mask = none Fatal trap 12: page fault while in kernel mode fault virtual address = 0xa96f98 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0342a10 stack pointer = 0x10:0xdf3d4e7c frame pointer = 0x10:0xdf3d4e84 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 78395 (cc1) interrupt mask = none panic: from debugger Uptime: 11m2s dumping to dev #ad/0x20001, offset 1048704 dump ata0: resetting devices .. done 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) where #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc021e258 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc021e6a5 in panic (fmt=0xc03bc2e4 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc014cedd in db_panic (addr=-1070323184, have_addr=0, count=-1, modif=0xdf3d4d0c "") at /usr/src/sys/ddb/db_command.c:435 #4 0xc014ce7b in db_command (last_cmdp=0xc0428844, cmd_table=0xc0428684, aux_cmd_tablep=0xc046bb78) at /usr/src/sys/ddb/db_command.c:333 #5 0xc014cf42 in db_command_loop () at /usr/src/sys/ddb/db_command.c:457 #6 0xc014f113 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:71 #7 0xc0388dd0 in kdb_trap (type=12, code=0, regs=0xdf3d4e3c) at /usr/src/sys/i386/i386/db_interface.c:158 #8 0xc039985c in trap_fatal (frame=0xdf3d4e3c, eva=11104152) at /usr/src/sys/i386/i386/trap.c:969 #9 0xc0399212 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 136372224, tf_esi = 37, tf_ebp = -549630332, tf_isp = -549630360, tf_ebx = -544384096, tf_edx = 11104132, tf_ecx = 12855290, tf_eax = 200316, tf_trapno = 12, tf_err = 0, tf_eip = -1070323184, tf_cs = 8, tf_eflags = 66054, tf_esp = 0, tf_ss = -549946880}) at /usr/src/sys/i386/i386/trap.c:636 #10 0xc0342a10 in vm_page_lookup (object=0xdf8d5ba0, pindex=37) at /usr/src/sys/vm/vm_page.c:514 #11 0xc033a562 in vm_fault (map=0xdf387a00, vaddr=136372224, fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:292 ---Type to continue, or q to quit--- #12 0xc03994af in trap_pfault (frame=0xdf3d4fa8, usermode=1, eva=136372228) at /usr/src/sys/i386/i386/trap.c:847 #13 0xc0398f2f in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 136372224, tf_esi = 136253088, tf_ebp = -1077938560, tf_isp = -549629996, tf_ebx = 4072, tf_edx = 26, tf_ecx = 1, tf_eax = 136368128, tf_trapno = 12, tf_err = 6, tf_eip = 135460607, tf_cs = 31, tf_eflags = 66054, tf_esp = -1077938600, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:377 #14 0x812f6ff in ?? () #15 0x8062ae7 in ?? () #16 0x80651ac in ?? () #17 0x80504ea in ?? () #18 0x8050274 in ?? () #19 0x8068797 in ?? () #20 0x806c0da in ?? () #21 0x804813e in ?? () uname -a: FreeBSD frame.symphiano 4.8-RELEASE-p13 FreeBSD 4.8-RELEASE-p13 #1: Fri Oct 24 07:22:44 SAST 2003 root@frame.symphiano:/usr/obj/usr/src/sys/GENERIC i386 dmesg: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE-p13 #1: Fri Oct 24 07:22:44 SAST 2003 root@frame.symphiano:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2411.60-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff real memory = 536805376 (524224K bytes) avail memory = 516980736 (504864K bytes) Preloaded elf kernel "kernel" at 0xc0533000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 10 entries at 0xc00fcde0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 agp0: mem 0xe8000000-0xefffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 12 pcib2: at device 30.0 on pci0 pci2: on pcib2 rl0: port 0x9000-0x90ff mem 0xf7000000-0xf70000ff irq 11 at device 1.0 on pci2 rl0: Ethernet address: 00:50:fc:c2:d4:1b miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 irq 0 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: (vendor=0x8086, dev=0x24d3) at 31.3 irq 11 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ad0: 38166MB [77545/16/63] at ata0-master BIOSDMA acd0: CDROM at ata1-slave PIO4 Mounting root from ufs:/dev/ad0s1a kernel: Standard GENERIC kernel with the following options enabled: options DDB makeoptions DEBUG=-g frame% Jaco van Tonder Magic Developer :: Premsoft Development (Pty) Ltd Direct: +27 11 312 2122 :: Fax: +27 11 312 2122 :: Mobile: +27 83 417 5424 Email: jaco@premsoft.co.za :: Web: http://www.premsoft.co.za/ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 03:23:39 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B04A16A4B3; Mon, 27 Oct 2003 03:23:39 -0800 (PST) Received: from smtp-relay1.barrysworld.com (ns1.barrysworld.com [213.221.172.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75FA843F85; Mon, 27 Oct 2003 03:23:37 -0800 (PST) (envelope-from killing@barrysworld.com) Received: from [213.221.181.50] (helo=barrysworld.com) by smtp-relay1.barrysworld.com with esmtp (Exim 4.24) id 1AE5RT-0001Us-FY; Mon, 27 Oct 2003 11:21:47 +0000 Received: from vader [212.135.219.179] by barrysworld.com with ESMTP (SMTPD32-7.15) id AFDB52C20120; Mon, 27 Oct 2003 11:22:03 +0000 Message-ID: <005701c39c7c$7f4434c0$b3db87d4@vader> From: "Steven Hartland" To: "Jaco van Tonder" , References: <016a01c39c7a$a23a78b0$3635a8c0@jaco> Date: Mon, 27 Oct 2003 11:21:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-hackers@freebsd.org Subject: Re: [4.8-RELEASE - Stable, 5.1-RELEASE] Panics when system loaded X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Steven Hartland List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 11:23:39 -0000 I had the same on box here turned out to be a dodgy netcard. Symptoms where when transferring locally 100MB switch ftp / scp would start off at 8Mb/s but quickly drop off then the box would panic. Possibly the same thing. Steve ----- Original Message ----- From: "Jaco van Tonder" To: Cc: Sent: Monday, October 27, 2003 11:08 AM Subject: [4.8-RELEASE - Stable, 5.1-RELEASE] Panics when system loaded > Hi, > > I installed 4.8-RELEASE from CD yesterday on my P4-2.4GHz machine. > Updated sources to the latest 4.8-RELEASE-p13. Started doing buildworld and > my > machine panicked. Tried a few more times with random panics. Same random > panics > occur if I build the kernel. After a bit of struggling I managed to get a > GENERIC > kernel built with debug symbols on the latest source. I did not manage to > build > or install world on the new sources, but the panics happen regardless of > what > kernel is running. > > I also updated to the latest -STABLE, managed to build a kernel and > installed it. > Same problem exists there aswell (although this might be caused by a kernel > and world that are not in sync?). > > I installed 5.1-RELEASE to find the same problem exists there aswell. > > Can anybody perhaps give a hint in which direction to look or to make this > go away? > > Thanks in advance! > > Regards > Jaco > > Setup: > Intel P4, 2.4GHz CPU > Gigabyte MB with Intel 865P chipset, Hyperthreading technology > 512MB DDR333 Ram > 40GB Maxtor drive > 1024MB Swap > > USB disabled in BIOS as there is no need for it on this machine. > > Backtrace: > > frame# gdb -k kernel.debug.0 vmcore.0 > GNU gdb 4.18 (FreeBSD) > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read > called at > /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line > 2627 in elfstab_build_psymtabs > Deprecated bfd_read called at > /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line > 933 in fill_symbuf > > IdlePTD at phsyical address 0x00552000 > initial pcb at physical address 0x00483f00 > panicstr: from debugger > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xa96f98 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0342a10 > stack pointer = 0x10:0xdf3d4e7c > frame pointer = 0x10:0xdf3d4e84 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 78395 (cc1) > interrupt mask = none > panic: from debugger > > > Fatal trap 3: breakpoint instruction fault while in kernel mode > instruction pointer = 0x8:0xc0389031 > stack pointer = 0x10:0xdf3d4c90 > frame pointer = 0x10:0xdf3d4c98 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 78395 (cc1) > interrupt mask = none > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xa96f98 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0342a10 > stack pointer = 0x10:0xdf3d4e7c > frame pointer = 0x10:0xdf3d4e84 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 78395 (cc1) > interrupt mask = none > panic: from debugger > Uptime: 11m2s > > dumping to dev #ad/0x20001, offset 1048704 > dump ata0: resetting devices .. done > 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 > 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 > 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 > 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 > 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 > 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 > 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 > 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 > 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 > 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 > 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 > 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 > 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 > 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 > 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 > 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 > 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 > 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 > 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 > 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 > 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 > 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 > 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 > 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 > 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 > 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 > --- > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 > 487 if (dumping++) { > (kgdb) where > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 > #1 0xc021e258 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 > #2 0xc021e6a5 in panic (fmt=0xc03bc2e4 "from debugger") > at /usr/src/sys/kern/kern_shutdown.c:595 > #3 0xc014cedd in db_panic (addr=-1070323184, have_addr=0, count=-1, > modif=0xdf3d4d0c "") at /usr/src/sys/ddb/db_command.c:435 > #4 0xc014ce7b in db_command (last_cmdp=0xc0428844, cmd_table=0xc0428684, > aux_cmd_tablep=0xc046bb78) at /usr/src/sys/ddb/db_command.c:333 > #5 0xc014cf42 in db_command_loop () at /usr/src/sys/ddb/db_command.c:457 > #6 0xc014f113 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:71 > #7 0xc0388dd0 in kdb_trap (type=12, code=0, regs=0xdf3d4e3c) > at /usr/src/sys/i386/i386/db_interface.c:158 > #8 0xc039985c in trap_fatal (frame=0xdf3d4e3c, eva=11104152) > at /usr/src/sys/i386/i386/trap.c:969 > #9 0xc0399212 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, > tf_edi = 136372224, tf_esi = 37, tf_ebp = -549630332, > tf_isp = -549630360, tf_ebx = -544384096, tf_edx = 11104132, > tf_ecx = 12855290, tf_eax = 200316, tf_trapno = 12, tf_err = 0, > tf_eip = -1070323184, tf_cs = 8, tf_eflags = 66054, tf_esp = 0, > tf_ss = -549946880}) at /usr/src/sys/i386/i386/trap.c:636 > #10 0xc0342a10 in vm_page_lookup (object=0xdf8d5ba0, pindex=37) > at /usr/src/sys/vm/vm_page.c:514 > #11 0xc033a562 in vm_fault (map=0xdf387a00, vaddr=136372224, > fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:292 > ---Type to continue, or q to quit--- > #12 0xc03994af in trap_pfault (frame=0xdf3d4fa8, usermode=1, eva=136372228) > at /usr/src/sys/i386/i386/trap.c:847 > #13 0xc0398f2f in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, > tf_edi = 136372224, tf_esi = 136253088, tf_ebp = -1077938560, > tf_isp = -549629996, tf_ebx = 4072, tf_edx = 26, tf_ecx = 1, > tf_eax = 136368128, tf_trapno = 12, tf_err = 6, tf_eip = 135460607, > tf_cs = 31, tf_eflags = 66054, tf_esp = -1077938600, tf_ss = 47}) > at /usr/src/sys/i386/i386/trap.c:377 > #14 0x812f6ff in ?? () > #15 0x8062ae7 in ?? () > #16 0x80651ac in ?? () > #17 0x80504ea in ?? () > #18 0x8050274 in ?? () > #19 0x8068797 in ?? () > #20 0x806c0da in ?? () > #21 0x804813e in ?? () > > uname -a: > FreeBSD frame.symphiano 4.8-RELEASE-p13 FreeBSD 4.8-RELEASE-p13 #1: Fri Oct > 24 07:22:44 SAST 2003 root@frame.symphiano:/usr/obj/usr/src/sys/GENERIC > i386 > > dmesg: > Copyright (c) 1992-2003 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 4.8-RELEASE-p13 #1: Fri Oct 24 07:22:44 SAST 2003 > root@frame.symphiano:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz > CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2411.60-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbff ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > real memory = 536805376 (524224K bytes) > avail memory = 516980736 (504864K bytes) > Preloaded elf kernel "kernel" at 0xc0533000. > Pentium Pro MTRR support enabled > md0: Malloc disk > Using $PIR table, 10 entries at 0xc00fcde0 > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > agp0: mem 0xe8000000-0xefffffff at device > 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at 0.0 irq 12 > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > rl0: port 0x9000-0x90ff mem > 0xf7000000-0xf70000ff irq 11 at device 1.0 on pci2 > rl0: Ethernet address: 00:50:fc:c2:d4:1b > miibus0: on rl0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 irq 0 at device 31.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > pci0: (vendor=0x8086, dev=0x24d3) at 31.3 irq 11 > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ad0: 38166MB [77545/16/63] at ata0-master BIOSDMA > acd0: CDROM at ata1-slave PIO4 > Mounting root from ufs:/dev/ad0s1a > > kernel: > Standard GENERIC kernel with the following options enabled: > options DDB > makeoptions DEBUG=-g > frame% > > Jaco van Tonder > Magic Developer :: Premsoft Development (Pty) Ltd > Direct: +27 11 312 2122 :: Fax: +27 11 312 2122 :: Mobile: +27 83 417 5424 > Email: jaco@premsoft.co.za :: Web: http://www.premsoft.co.za/ > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 03:56:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE89016A4B3 for ; Mon, 27 Oct 2003 03:56:53 -0800 (PST) Received: from xwing.cscrsa.com (xwing.cscrsa.com [196.14.130.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 524CC43F75 for ; Mon, 27 Oct 2003 03:56:51 -0800 (PST) (envelope-from jacovt@cscrsa.com) Received: (qmail 46437 invoked from network); 27 Oct 2003 11:55:32 -0000 Received: from unknown (HELO jaco) (jacovt@cscrsa.com@196.33.245.83) by xwing.cscrsa.com with SMTP; 27 Oct 2003 11:55:32 -0000 Message-ID: <017801c39c81$660f9f80$3635a8c0@jaco> From: "Jaco van Tonder" To: Date: Mon, 27 Oct 2003 13:56:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-hackers@freebsd.org Subject: [5.1-RELEASE-P10] panics when system loaded X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 11:56:53 -0000 Hi all, Here is a new backtrace on a 5.1-RELEASE-P10 that I got just now. I will however rip out this network card and replace it quickly as per Steven Hartland instructions. ;) Thanks in advance! Jaco gdb backtrace: frame# gdb -k kernel.debug.200310271200 vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xf000e837 fault code = supervisor read, page not present instruction pointer = 0x8:0xc044ef73 stack pointer = 0x10:0xdfa5aaf8 frame pointer = 0x10:0xdfa5ab58 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27103 (cc1) panic: from debugger Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc047b094 stack pointer = 0x10:0xdfa5a878 frame pointer = 0x10:0xdfa5a884 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = IOPL = 0 current process = 27103 (cc1) panic: from debugger Uptime: 8m42s Dumping 511 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:238 238 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:238 #1 0xc0309688 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:370 #2 0xc030997b in panic () at /usr/src/sys/kern/kern_shutdown.c:543 #3 0xc0162a82 in db_panic () at /usr/src/sys/ddb/db_command.c:448 #4 0xc0162a02 in db_command (last_cmdp=0xc05147a0, cmd_table=0x0, aux_cmd_tablep=0xc050b614, aux_cmd_tablep_end=0xc050b62c) at /usr/src/sys/ddb/db_command.c:346 #5 0xc0162b16 in db_command_loop () at /usr/src/sys/ddb/db_command.c:470 #6 0xc01658aa in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72 #7 0xc047adf5 in kdb_trap (type=12, code=0, regs=0xdfa5aab8) at /usr/src/sys/i386/i386/db_interface.c:170 #8 0xc048cb02 in trap_fatal (frame=0xdfa5aab8, eva=0) at /usr/src/sys/i386/i386/trap.c:829 #9 0xc048c812 in trap_pfault (frame=0xdfa5aab8, usermode=0, eva=4026591287) at /usr/src/sys/i386/i386/trap.c:748 #10 0xc048c3ed in trap (frame= {tf_fs = -1069219816, tf_es = -1065156592, tf_ds = 16, tf_edi = -542790916, tf_esi = 0, tf_ebp = -542790824, tf_isp = -542790940, tf_ebx = 827, tf_edx = -268376041, tf_ecx = -1073741824, tf_eax = -542790916, tf_trapno = 12, tf_err = 0, tf_eip = -1069224077, tf_cs = 8, tf_eflags = 66182, tf_esp = -542790916, tf_ss = -991544472}) at /usr/src/sys/i386/i386/trap.c:433 #11 0xc047c748 in calltrap () at {standard input}:96 #12 0xc044f1bd in vm_page_remove (m=0x33b) at /usr/src/sys/vm/vm_page.c:626 #13 0xc044f890 in vm_page_free_toq (m=0x0) at /usr/src/sys/vm/vm_page.c:1055 ---Type to continue, or q to quit--- #14 0xc044ede4 in vm_page_free (m=0xc0ace058) at /usr/src/sys/vm/vm_page.c:399 #15 0xc044c5b7 in vm_object_terminate (object=0xc4eb2a68) at /usr/src/sys/vm/vm_object.c:599 #16 0xc044c3df in vm_object_deallocate (object=0xc4eb2a68) at /usr/src/sys/vm/vm_object.c:528 #17 0xc0448a1b in vm_map_entry_delete (map=0xc43a5700, entry=0xc4e5503c) at /usr/src/sys/vm/vm_map.c:2033 #18 0xc0448e63 in vm_map_delete (map=0xc43a5700, start=3303362620, end=3217031168) at /usr/src/sys/vm/vm_map.c:2167 #19 0xc0448ee8 in vm_map_remove (map=0xc43a5700, start=0, end=3217031168) at /usr/src/sys/vm/vm_map.c:2189 #20 0xc02f4086 in exit1 (td=0xc40a6000, rv=0) at vm_map.h:191 #21 0xc02f3b01 in sys_exit () at /usr/src/sys/kern/kern_exit.c:100 #22 0xc048cdfe in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077939800, tf_esi = 0, tf_ebp = -1077939840, tf_isp = -542790284, tf_ebx = -1, tf_edx = 10, tf_ecx = 5, tf_eax = 1, tf_trapno = 22, tf_err = 2, tf_eip = 136866723, tf_cs = 31, tf_eflags = 662, tf_esp = -1077939868, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1021 #23 0xc047c79d in Xint0x80_syscall () at {standard input}:138 ---Can't read userspace from dump, or kernel process--- uname output: FreeBSD frame.symphiano 5.1-RELEASE-p10 FreeBSD 5.1-RELEASE-p10 #2: Mon Oct 27 09:42:35 SAST 2003 jacovt@frame.symphiano:/usr/obj/usr/src/sys/GENERIC i386 dmesg output: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE-p10 #2: Mon Oct 27 09:42:35 SAST 2003 jacovt@frame.symphiano:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0698000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2411601072 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2411.60-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff real memory = 536805376 (511 MB) avail memory = 514281472 (490 MB) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fcde0 pcib0: at pcibus 0 on motherboard pci0: on pcib0 agp0: mem 0xe8000000-0xefffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 rl0: port 0x9000-0x90ff mem 0xf7000000-0xf70000ff irq 11 at device 1.0 on pci2 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:50:fc:c2:d4:1b miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.3 (no driver attached) pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 10.000 msec ad0: 38166MB [77545/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-slave PIO4 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted /tmp: superblock summary recomputed WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 116 files 3 /usr: superblock summary recomputed WARNING: /var was not properly dismounted frame% Jaco van Tonder Magic Developer :: Premsoft Development (Pty) Ltd Direct: +27 11 312 2122 :: Fax: +27 11 312 2122 :: Mobile: +27 83 417 5424 Email: jaco@premsoft.co.za :: Web: http://www.premsoft.co.za/ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 07:31:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D45A016A4B3 for ; Mon, 27 Oct 2003 07:31:28 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2122143FE0 for ; Mon, 27 Oct 2003 07:31:24 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id D9FC13D34 for ; Mon, 27 Oct 2003 10:31:18 -0500 (EST) From: "Dan Langille" To: freebsd-hackers@freebsd.org Date: Mon, 27 Oct 2003 10:31:18 -0500 MIME-Version: 1.0 Message-ID: <3F9CF3F6.8307.ABC1250@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 15:31:28 -0000 If a process starts up and does a setuid, should it be writing the PID file before or after the setuid? Two methods exists AFAIK: 1 - write your PID immediately, and the file is chown root:wheel 2 - write your PID to /var/run/myapp/myapp.pid where /var/run/myapp/ is chown myapp:myapp Of the two, I think #1 is cleaner as it does not require another directory with special permissions. Any suggestions? -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 07:37:21 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A940B16A4B3 for ; Mon, 27 Oct 2003 07:37:21 -0800 (PST) Received: from mindfields.energyhq.es.eu.org (73.Red-213-97-200.pooles.rima-tde.net [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id A711543FAF for ; Mon, 27 Oct 2003 07:37:16 -0800 (PST) (envelope-from flynn@energyhq.es.eu.org) Received: from scienide.energyhq.es.eu.org (scienide.energyhq.es.eu.org [192.168.100.1]) by mindfields.energyhq.es.eu.org (Postfix) with SMTP id D55B735782; Mon, 27 Oct 2003 16:36:57 +0100 (CET) Date: Mon, 27 Oct 2003 16:36:58 +0100 From: Miguel Mendez To: "Dan Langille" Message-Id: <20031027163658.5d5af160.flynn@energyhq.es.eu.org> In-Reply-To: <3F9CF3F6.8307.ABC1250@localhost> References: <3F9CF3F6.8307.ABC1250@localhost> Organization: X-Mailer: Sylpheed version 0.9.5-gtk2-20030906 (GTK+ 2.2.4; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 15:37:21 -0000 Dixitur illum "Dan Langille" scribere... Hi, > If a process starts up and does a setuid, should it be writing the > PID file before or after the setuid? > > Two methods exists AFAIK: > > 1 - write your PID immediately, and the file is chown root:wheel OpenBSD seems to favor this approach, if that tells you something. [...] -rw-r--r-- 1 root wheel 6 Oct 10 21:17 mountd.pid -rw-r--r-- 1 root wheel 5 Oct 10 21:17 named.pid -rw-r--r-- 1 root wheel 20 Oct 12 22:13 nmbd.pid -rw-r--r-- 1 root wheel 5 Oct 10 21:17 ntpd.pid -rw-r--r-- 1 root wheel 6 Oct 10 21:17 pflogd.pid -rw-r--r-- 1 root wheel 5 Oct 11 10:15 rtadvd.pid -rw-r--r-- 1 root wheel 20 Oct 12 22:13 smbd.pid -rw-r--r-- 1 root wheel 6 Oct 10 21:17 sshd.pid -rw-r--r-- 1 root wheel 6 Oct 10 21:17 syslog.pid [...] > Of the two, I think #1 is cleaner as it does not require another > directory with special permissions. Agreed. Cheers, ---- Miguel Mendez http://www.energyhq.es.eu.org From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 07:55:42 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F48D16A4B3 for ; Mon, 27 Oct 2003 07:55:42 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 718D043F85 for ; Mon, 27 Oct 2003 07:55:39 -0800 (PST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 3A17072E34; Mon, 27 Oct 2003 07:51:00 -0800 (PST) From: Wes Peters Organization: Softweyr To: "Poul-Henning Kamp" , Kip Macy Date: Mon, 27 Oct 2003 06:56:08 -0800 User-Agent: KMail/1.5.2 References: <24644.1067112916@critter.freebsd.dk> In-Reply-To: <24644.1067112916@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310270656.08095.wes@softweyr.com> cc: hackers@freebsd.org Subject: Re: FreeBSD mail list etiquette X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 15:55:42 -0000 On Saturday 25 October 2003 13:15, Poul-Henning Kamp wrote: > > For the last ten years, the NetBSD, OpenBSD and FreeBSD projects > have had a tacit agreement not to post propaganda and inflamatory > accusations to each others email lists (what project members do in > their own projects is of course a different matter). > > I, and I think other members of FreeBSD, would appreciate it if > the members of DragonflyBSD would adhere to this peace-keeping > rule as well. Well said, and thank you. Tangential discussion full of wild, unsubstantiated accusation are certainly NOT going to help relationships between any groups of humans. Bad form, Mr. Macy. Please come back when you have a point. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 08:39:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA08D16A4B3 for ; Mon, 27 Oct 2003 08:39:46 -0800 (PST) Received: from mx2.fillmore-labs.com (lima.fillmore-labs.com [62.138.193.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id E390743FDD for ; Mon, 27 Oct 2003 08:39:37 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from pd951a39b.dip.t-dialin.net ([217.81.163.155] helo=fillmore-labs.com ident=0oupbh8kgqazljoe) by mx2.fillmore-labs.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.24; FreeBSD 4.9) id 1AEAP1-000LEB-Fl; Mon, 27 Oct 2003 17:39:35 +0100 Message-ID: <3F9D4A45.8070400@fillmore-labs.com> Date: Mon, 27 Oct 2003 17:39:33 +0100 From: Oliver Eikemeier MIME-Version: 1.0 To: Dan Langille References: <3F9CF3F6.8307.ABC1250@localhost> In-Reply-To: <3F9CF3F6.8307.ABC1250@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: eikemeier@fillmore-labs.com User-Agent: KMail/1.5.9 Organization: Fillmore Labs GmbH X-Complaints-To: abuse@fillmore-labs.com cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 16:39:46 -0000 Dan Langille wrote: > If a process starts up and does a setuid, should it be writing the > PID file before or after the setuid? > > Two methods exists AFAIK: > > 1 - write your PID immediately, and the file is chown root:wheel > 2 - write your PID to /var/run/myapp/myapp.pid where /var/run/myapp/ > is chown myapp:myapp > > Of the two, I think #1 is cleaner as it does not require another > directory with special permissions. You may have problems removing the file on exit, though. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 08:48:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E70A16A4B3 for ; Mon, 27 Oct 2003 08:48:32 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A44B43FBF for ; Mon, 27 Oct 2003 08:48:31 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id A81073D28; Mon, 27 Oct 2003 11:48:30 -0500 (EST) From: "Dan Langille" To: Oliver Eikemeier Date: Mon, 27 Oct 2003 11:48:30 -0500 MIME-Version: 1.0 Message-ID: <3F9D060E.26143.B02C07F@localhost> Priority: normal In-reply-to: <3F9D4A45.8070400@fillmore-labs.com> References: <3F9CF3F6.8307.ABC1250@localhost> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 16:48:32 -0000 On 27 Oct 2003 at 17:39, Oliver Eikemeier wrote: > Dan Langille wrote: > > > If a process starts up and does a setuid, should it be writing the > > PID file before or after the setuid? > > > > Two methods exists AFAIK: > > > > 1 - write your PID immediately, and the file is chown root:wheel > > 2 - write your PID to /var/run/myapp/myapp.pid where /var/run/myapp/ > > is chown myapp:myapp > > > > Of the two, I think #1 is cleaner as it does not require another > > directory with special permissions. > > You may have problems removing the file on exit, though. The plan was to not remove it. -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 09:09:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B063916A4B3 for ; Mon, 27 Oct 2003 09:09:34 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-123-40-77.dsl.pltn13.pacbell.net [68.123.40.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44CCB43FA3 for ; Mon, 27 Oct 2003 09:09:31 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.9/8.12.9) with ESMTP id h9RH90en030270; Mon, 27 Oct 2003 09:09:00 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.9/8.12.9/Submit) id h9RH8xKO030269; Mon, 27 Oct 2003 09:08:59 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Mon, 27 Oct 2003 09:08:59 -0800 From: David Schultz To: Lowell Gilbert Message-ID: <20031027170859.GA30164@VARK.homeunix.com> Mail-Followup-To: Lowell Gilbert , freebsd-hackers@FreeBSD.ORG References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1066820436.25609.93.camel@boxster.onthenet.com.au> <20031026052854.GA20701@VARK.homeunix.com> <44he1wi2yy.fsf@be-well.ilk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44he1wi2yy.fsf@be-well.ilk.org> cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 17:09:34 -0000 On Sun, Oct 26, 2003, Lowell Gilbert wrote: > David Schultz writes: > > > On Sun, Oct 26, 2003, Dag-Erling Smrgrav wrote: > > > Q writes: > > > > Yes, it would appear this is a legacy thing that existed in the original > > > > 1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still > > > > use this technique, but OpenBSD changed to using Red-Black trees back in > > > > Feb 2002. > > > > [...] > > > > I am wondering if there is a compelling reason why the technique used by > > > > OpenBSD could not be adapted to FreeBSD's VM system. > > > > > > Adapting OpenBSD's red-balck patches would require quite a bit of work > > > as FreeBSD and OpenBSD have diverged quite a bit in this area. Though > > > it is a good idea to change the list into a tree, I think you'd get > > > more mileage by addressing the fundamental problem, which is the lack > > > of a free list. The current code (in both FreeBSD and OpenBSD) > > > searches a list or tree of allocated extents, sorted by location, > > > looking for a pair that have sufficient space between them for the > > > extent you want to create. We should instead keep track of free > > > extents in a structure that makes it easy to locate one of the correct > > > size. We probably need a dual structure, though, because we need to > > > keep the free extents sorted both by size (to quickly find what we > > > need) and by location (to facilitate aggregation of adjacent extents, > > > without which we'd suffer horribly from address space fragmentation). > > > > > > I have no idea how much this means for real-life workloads though. > > > > Your idea of using a size-hashed freelist as well as a > > location-sorted list is appealing in its simplicity. Though it > > can cause a bit of fragmentation, it gives you constant time > > lookup. Bonwick's vmem allocator ([1], section 4.4.2 and > > following), apparently works quite well using this principle. > > A hash probably isn't the right data structure for either dimension > (DES didn't say it was, I notice). Finding the next-largest available > entry is a useful operation, here, so a list would be better than a > hash. [Or a tree; the point is that exact-match isn't the only kind > of search you need.] Erm, did you read the paper I referred to? If you have, say, 32 power-of-two buckets, you can use a bitmask representing which buckets are non-empty to locate spcae in constant time. The caveat (also in the paper) is that the price of the constant time operation is that your allocation may be up to twice as large as necessary. A tree lacks this disadvantage, but also carries with it some additional overhead. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 09:15:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DE2816A4B3 for ; Mon, 27 Oct 2003 09:15:03 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id B303243F85 for ; Mon, 27 Oct 2003 09:15:00 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h9RHF08i039127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Oct 2003 12:15:00 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id h9RHF0xY039126 for freebsd-hackers@freebsd.org; Mon, 27 Oct 2003 12:15:00 -0500 (EST) Date: Mon, 27 Oct 2003 12:15:00 -0500 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031027171500.GF35805@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org References: <3F9CF3F6.8307.ABC1250@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9ADF8FXzFeE7X4jE" Content-Disposition: inline In-Reply-To: <3F9CF3F6.8307.ABC1250@localhost> Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 17:15:03 -0000 --9ADF8FXzFeE7X4jE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Mon, Oct 27, 2003 at 10:31:18AM -0500, Dan Langille= wrote: > Any suggestions? Here's a slightly backwards concept. We're all familar with how you can open a file, remove it from the directory, and not have it "go away" until the application closes it. Well, extend those semantics to the namespace. That is, have a directory where any name that does not exist can be opened RW, any name that does exist can be opened RO. A file is automatically removed when no one has an open descriptor to it anymore. So, the "server app" does: open(pidfile) write(pid, pidfile) flush(pidfile) [go do all the server stuff, and then at shutdown] close(pidfile) All other apps just read it, but can't overwrite it because it's RO. I'm not sure how useful this sort of file system change would be in practice, but it would solve the problem, no? --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --9ADF8FXzFeE7X4jE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/nVKUNh6mMG5yMTYRAqn1AJ0XWbUmf1K1bKTHxbYqe5ONd/zE1QCfT2jy cwojcT3QB2Es0OzEaUK2tOw= =a6WR -----END PGP SIGNATURE----- --9ADF8FXzFeE7X4jE-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 10:12:42 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8D9416A4B3; Mon, 27 Oct 2003 10:12:42 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D444043FE0; Mon, 27 Oct 2003 10:12:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) h9RICfiF044117; Mon, 27 Oct 2003 10:12:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id h9RICfN0044116; Mon, 27 Oct 2003 10:12:41 -0800 (PST) (envelope-from dillon) Date: Mon, 27 Oct 2003 10:12:41 -0800 (PST) From: Matthew Dillon Message-Id: <200310271812.h9RICfN0044116@apollo.backplane.com> To: David Schultz References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1066820436.25609.93.camel@boxster.onthenet.com.au> <20031026052854.GA20701@VARK.homeunix.com> <20031027170859.GA30164@VARK.homeunix.com> cc: freebsd-hackers@freebsd.org cc: Lowell Gilbert Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 18:12:42 -0000 :... :> A hash probably isn't the right data structure for either dimension :> (DES didn't say it was, I notice). Finding the next-largest available :> entry is a useful operation, here, so a list would be better than a :> hash. [Or a tree; the point is that exact-match isn't the only kind :> of search you need.] : :Erm, did you read the paper I referred to? If you have, say, 32 :power-of-two buckets, you can use a bitmask representing which :buckets are non-empty to locate spcae in constant time. The :caveat (also in the paper) is that the price of the constant time :operation is that your allocation may be up to twice as large as :necessary. A tree lacks this disadvantage, but also carries with :it some additional overhead. The swap bitmap code I wrote uses a radix tree with size hinting for allocations, and while I haven't formally tested its scaleability I've never heard any complaints so I think I implemented it properly. While the swap radix tree could not be used directly (since it represents a preallocated fixed address space and a vm_map's VM space is too big, especially on a 64 bit system), the size hinting concept could certainly be used on top of a dynamic radix tree and might possibly be useable on the splay trees being used in current now. I say 'might' because splay trees manipulate nodes so much it might not be possible to maintain consistency in the hint information. In anycase, I suggest those interested in mmap performance play around with adding size hinting to the existing splay tree code for vm_map_entry. It could turn out to be the easy way out. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 11:02:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2660B16A4B3 for ; Mon, 27 Oct 2003 11:02:08 -0800 (PST) Received: from mail.advantagecom.net (mail.advantagecom.net [65.103.151.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D5443FB1 for ; Mon, 27 Oct 2003 11:01:58 -0800 (PST) (envelope-from andykinney@advantagecom.net) Received: from SCSI-MONSTER (scsi-monster.advantagecom.net [207.109.186.200]) by mail.advantagecom.net (8.11.6/8.11.6) with ESMTP id h9RJ1ps09219; Mon, 27 Oct 2003 11:01:54 -0800 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: "Jaco van Tonder" , freebsd-hackers@freebsd.org Date: Mon, 27 Oct 2003 11:02:17 -0800 MIME-Version: 1.0 Message-ID: <3F9CFB39.18896.330F6822@localhost> Priority: normal In-reply-to: <016a01c39c7a$a23a78b0$3635a8c0@jaco> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: [4.8-RELEASE - Stable, 5.1-RELEASE] Panics when system loaded X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andykinney@advantagecom.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 19:02:08 -0000 On 27 Oct 2003 at 13:08, Jaco van Tonder wrote: > buildworld and my machine panicked. Tried a few more times with random > panics. Same random panics occur if I build the kernel. After a bit of > struggling I managed to get a GENERIC kernel built with debug symbols > on the latest source. I did not manage to build or install world on > the new sources, but the panics happen regardless of what kernel is > running. > Last time we had random trap 12 panics, it was because we had some bad RAM. The RAM wasn't bad enough to fail post, but it did occasionally flip bits on the data registers of one of the chips. Not all RAM test software can catch that, but the Dell diagnostic software did. Of course the same thing can happen if your BIOS has overly aggressive RAM timings set. Since your problems occurred regardless of the kernel, it would certainly imply a hardware problem. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 11:50:25 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F99616A4B3 for ; Mon, 27 Oct 2003 11:50:25 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19A2844031 for ; Mon, 27 Oct 2003 11:50:25 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 91C015B674; Mon, 27 Oct 2003 11:45:44 -0800 (PST) From: Wes Peters Organization: Softweyr To: "Dan Langille" , freebsd-hackers@freebsd.org Date: Mon, 27 Oct 2003 11:50:23 -0800 User-Agent: KMail/1.5.4 References: <3F9CF3F6.8307.ABC1250@localhost> In-Reply-To: <3F9CF3F6.8307.ABC1250@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310271150.23193.wes@softweyr.com> Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 19:50:25 -0000 On Monday 27 October 2003 07:31 am, Dan Langille wrote: > If a process starts up and does a setuid, should it be writing the > PID file before or after the setuid? > > Two methods exists AFAIK: > > 1 - write your PID immediately, and the file is chown root:wheel > 2 - write your PID to /var/run/myapp/myapp.pid where /var/run/myapp/ > is chown myapp:myapp > > Of the two, I think #1 is cleaner as it does not require another > directory with special permissions. > > Any suggestions? Create the pid file while still root, and if you are going to change the user or group id, chown(2) or chgrp(2) the file just before setuid(2) / setgid(2) calls. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 12:35:51 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C243916A4B3 for ; Mon, 27 Oct 2003 12:35:51 -0800 (PST) Received: from pony2pub.arc.nasa.gov (pony2pub.arc.nasa.gov [128.102.31.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4529143FA3 for ; Mon, 27 Oct 2003 12:35:49 -0800 (PST) (envelope-from jtoung@arc.nasa.gov) Received: from nren-194.arc.nasa.gov ([128.102.196.194] verified) by pony2pub.arc.nasa.gov (CommuniGate Pro SMTP 4.1.3) with ESMTP id 4350674; Mon, 27 Oct 2003 12:35:48 -0800 Content-Type: text/plain; charset="us-ascii" From: Jerry Toung To: hackers Date: Mon, 27 Oct 2003 12:35:21 -0800 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200310271235.21885.jtoung@arc.nasa.gov> Subject: ifconfig w/ if_gre X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jtoung@arc.nasa.gov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 20:35:51 -0000 I am trying to figure out what is the ifconfig command to jump into case GRESADDRS: case GRESADDRD: in gre_ioctl.=20 Thank you, Jerry. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 12:42:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B9C416A4B3 for ; Mon, 27 Oct 2003 12:42:28 -0800 (PST) Received: from xeon.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 591A743F93 for ; Mon, 27 Oct 2003 12:42:27 -0800 (PST) (envelope-from dan@langille.org) Received: by xeon.unixathome.org (Postfix, from userid 1000) id 8A20C3E50; Mon, 27 Oct 2003 15:42:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by xeon.unixathome.org (Postfix) with ESMTP id 69CFC3E4F; Mon, 27 Oct 2003 15:42:26 -0500 (EST) Date: Mon, 27 Oct 2003 15:42:26 -0500 (EST) From: Dan Langille X-X-Sender: dan@xeon.unixathome.org To: Wes Peters In-Reply-To: <200310271150.23193.wes@softweyr.com> Message-ID: <20031027154010.Y61203@xeon.unixathome.org> References: <3F9CF3F6.8307.ABC1250@localhost> <200310271150.23193.wes@softweyr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 20:42:28 -0000 On Mon, 27 Oct 2003, Wes Peters wrote: > On Monday 27 October 2003 07:31 am, Dan Langille wrote: > > If a process starts up and does a setuid, should it be writing the > > PID file before or after the setuid? > > > > Two methods exists AFAIK: > > > > 1 - write your PID immediately, and the file is chown root:wheel > > 2 - write your PID to /var/run/myapp/myapp.pid where /var/run/myapp/ > > is chown myapp:myapp > > > > Of the two, I think #1 is cleaner as it does not require another > > directory with special permissions. > > > > Any suggestions? > > Create the pid file while still root, and if you are going to change the > user or group id, chown(2) or chgrp(2) the file just before setuid(2) / > setgid(2) calls. I'm told that this leaves you open to a symlink attack. If you leave the file chown root:wheel, then if an attacker does gain control of the application, they can't change the PID file. The key point is the app is root when writing the PID file. If the attacker symlinks the PID to something else (e.g. /etc/fstab), then that's when the fun starts. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 13:31:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15B3B16A4B3 for ; Mon, 27 Oct 2003 13:31:06 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C53043F75 for ; Mon, 27 Oct 2003 13:31:05 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 6924F72E34; Mon, 27 Oct 2003 13:26:24 -0800 (PST) From: Wes Peters Organization: Softweyr To: Dan Langille Date: Mon, 27 Oct 2003 13:31:03 -0800 User-Agent: KMail/1.5.4 References: <3F9CF3F6.8307.ABC1250@localhost> <200310271150.23193.wes@softweyr.com> <20031027154010.Y61203@xeon.unixathome.org> In-Reply-To: <20031027154010.Y61203@xeon.unixathome.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310271331.03822.wes@softweyr.com> cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 21:31:06 -0000 On Monday 27 October 2003 12:42 pm, Dan Langille wrote: > On Mon, 27 Oct 2003, Wes Peters wrote: > > On Monday 27 October 2003 07:31 am, Dan Langille wrote: > > > If a process starts up and does a setuid, should it be writing the > > > PID file before or after the setuid? > > > > > > Two methods exists AFAIK: > > > > > > 1 - write your PID immediately, and the file is chown root:wheel > > > 2 - write your PID to /var/run/myapp/myapp.pid where > > > /var/run/myapp/ is chown myapp:myapp > > > > > > Of the two, I think #1 is cleaner as it does not require another > > > directory with special permissions. > > > > > > Any suggestions? > > > > Create the pid file while still root, and if you are going to change > > the user or group id, chown(2) or chgrp(2) the file just before > > setuid(2) / setgid(2) calls. > > I'm told that this leaves you open to a symlink attack. If you leave > the file chown root:wheel, then if an attacker does gain control of the > application, they can't change the PID file. The key point is the app > is root when writing the PID file. If the attacker symlinks the PID to > something else (e.g. /etc/fstab), then that's when the fun starts. OK, bad knee-jerk design. In the past I've always just followed the standard 'clean it up when the daemon is restarted' philosophy because it seemed safe to leave the file 'protected' this way. For clean shutdowns, shutdown scripts run as root can clean up any pid file they want, right? If the process crashes, having the pid file available may prove helpful in debugging, at least in terms of log traces and such. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 14:12:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE3FF16A4B3 for ; Mon, 27 Oct 2003 14:12:12 -0800 (PST) Received: from pony2pub.arc.nasa.gov (pony2pub.arc.nasa.gov [128.102.31.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 560CA43FE3 for ; Mon, 27 Oct 2003 14:12:10 -0800 (PST) (envelope-from jtoung@arc.nasa.gov) Received: from nren-194.arc.nasa.gov ([128.102.196.194] verified) by pony2pub.arc.nasa.gov (CommuniGate Pro SMTP 4.1.3) with ESMTP id 4354470 for freebsd-hackers@freebsd.org; Mon, 27 Oct 2003 14:12:10 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Jerry Toung To: hackers Date: Mon, 27 Oct 2003 14:11:42 -0800 User-Agent: KMail/1.4.3 References: <200310271235.21885.jtoung@arc.nasa.gov> In-Reply-To: <200310271235.21885.jtoung@arc.nasa.gov> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200310271411.42564.jtoung@arc.nasa.gov> Subject: never mind, ifconfig w/ if_gre X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jtoung@arc.nasa.gov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 22:12:13 -0000 I got lazy, I figured it out. On Monday 27 October 2003 12:35 pm, Jerry Toung wrote: > I am trying to figure out what is the ifconfig command to jump into > case GRESADDRS: > case GRESADDRD: > > in gre_ioctl. > Thank you, > Jerry. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 16:45:20 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C689516A4D1; Mon, 27 Oct 2003 16:45:19 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-234.dsl.lsan03.pacbell.net [63.207.60.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEE7E44322; Mon, 27 Oct 2003 15:58:14 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 9FC9166CFA; Mon, 27 Oct 2003 15:58:14 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 80D6F5F4; Mon, 27 Oct 2003 15:58:14 -0800 (PST) Date: Mon, 27 Oct 2003 15:58:14 -0800 From: Kris Kennaway To: Jaco van Tonder Message-ID: <20031027235814.GA41472@rot13.obsecurity.org> References: <016a01c39c7a$a23a78b0$3635a8c0@jaco> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <016a01c39c7a$a23a78b0$3635a8c0@jaco> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: [4.8-RELEASE - Stable, 5.1-RELEASE] Panics when system loaded X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 00:45:21 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 27, 2003 at 01:08:18PM +0200, Jaco van Tonder wrote: > Can anybody perhaps give a hint in which direction to look or to make this > go away? Do you have stale modules loaded? Kris --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/nbEWWry0BWjoQKURArIyAKCTBxFwx4URj4cv8PVkApZTTyaO2wCeIaVX X4riv1XlCWZETDroZjAapAM= =OuVi -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 03:53:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70A5516A4CE; Tue, 28 Oct 2003 03:53:58 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75D7543FBF; Tue, 28 Oct 2003 03:53:57 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfl2a.dialup.mindspring.com ([165.247.212.74] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AESQ4-0002qL-00; Tue, 28 Oct 2003 03:53:53 -0800 Message-ID: <3F9E5686.2D92E598@mindspring.com> Date: Tue, 28 Oct 2003 03:44:06 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a45bf002efc08320df3e36f54bf4753e0e387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: Kip Macy cc: Matthew Dillon cc: hackers@freebsd.org cc: John-Mark Gurney cc: Marcel Moolenaar Subject: Re: Fine grained locking (was: FreeBSD mail list etiquitte) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 11:53:58 -0000 Robert Watson wrote: > On Sat, 25 Oct 2003, Matthew Dillon wrote: > > It's a lot easier lockup path then the direction 5.x is going, and > > a whole lot more maintainable IMHO because most of the coding doesn't > > have to worry about mutexes or LORs or anything like that. > > You still have to be pretty careful, though, with relying on implicit > synchronization, because while it works well deep in a subsystem, it can > break down on subsystem boundaries. One of the challenges I've been > bumping into recently when working with Darwin has been the split between > their Giant kernel lock, and their network lock. To give a high level > summary of the architecture, basically they have two Funnels, which behave > similarly to the Giant lock in -STABLE/-CURRENT: when you block, the lock > is released, allowing other threads to enter the kernel, and regained when > the thread starts to execute again. They then have fine-grained locking > for the Mach-derived components, such as memory allocation, VM, et al. > > Deep in a particular subsystem -- say, the network stack, all works fine. > The problem is at the boundaries, where structures are shared between > multiple compartments. I.e., process credentials are referenced by both > "halves" of the Darwin BSD kernel code, and are insufficiently protected > in the current implementation (they have a write lock, but no read lock, > so it looks like it should be possible to get stale references with > pointers accessed in a read form under two different locks). Similarly, > there's the potential for serious problems at the surprisingly frequently > occuring boundaries between the network subsystem and remainder of the > kernel: file descriptor related code, fifos, BPF, et al. By making use of > two large subsystem locks, they do simplify locking inside the subsystem, > but it's based on a web of implicit assumptions and boundary > synchronization that carries most of the risks of explicit locking. Are you maybe looking at the Jaguar (10.2) code base here? I personally fixed a number of these types of issues. Mostly, these types of issues come down to the fact that funnels, like the BGL in FreeBSD, are actually code locks, not data locks. FWIW, it looks like the 10.3 (Panther) code is available from the Darwin (7.0) project now: http://developer.apple.com/darwin/ Mixing code and data locks is where most problems happen; it's one of the reasons that the BGL and the push-down to fine grain locking in FreeBSD is, I think, the wrong way to go. The destination is right, but the path is probably wrong, and things will get much worse with the FreeBSD approach before they get any better. Part of the problem is FreeBSD's mutex implementation is complicated, and permits recursion (thereby tacitly encouraging recursion). I personally think that should result in a panic -- though you could maybe make an argument for it on the basis of pool mutexes, where the same mutex pool is used for all your locks. But FreeBSD doesn't really do that effectively, so it's kind of a lose/lose situation. It's really, really hard to put multiple code locks into a kernel, and get things right. That's the problem with the FreeBSD approach: having a BGL in the first place implicitly turns all your data locks that have to coexist with the BGL code lock into code locks as well. I think the right approach would have been to start with a single pool mutex implementation, allowing recursion, and a macro wrapper for grabbing/releasing locks so that the locks could be substituted for per-data item locks instead of pool locks, and the per-data item locks would *disallow* recursion. A smart appoach to that would be to have a structure prefix on all kernel structures, such that you could abuse a cast and use a single mutex implementation for all data items. > It's also worth noting that there have been some serious bugs associated > with a lack of explicit synchronization in the non-concurrent kernel model > used in RELENG_4 (and a host of other early UNIX systems relying on a > single kernel lock). These have to do with unexpected blocking deep in a > function call stack, where it's not anticipated by a developer writing > source code higher in the stack, resulting in race conditions. In the > past, there have been a number of exploitable security vulnerabilities due > to races opened up in low memory conditions, during paging, etc. I think this is a general problem. I noted early on that FreeBSD was going to have issues in this regard once there was real kernel threading support. The KSE model is much less prone to triggering the race conditions, but any model where the same process can be in the kernel multiple times is problematic. Particularly since the BSD code doesn't really support the concept of cancellation of a blocking system call in progress (you don't have a means of doing the wakeup to fail the tsleep's with a recognizable error code that could mean cancellation to back out state). It's likely that libthr could demonstrate the issues much more quickly, so at least in that respect it's a good test jig for needing to deal with these issues sooner rather than later. Really, I think the BSD code needs to be refactored. The problem is an inability to back out state once you are down one or more calls in the stack. The Mach code is much better in this regard. All the locking, if multiple data objects need to be locked, has to happen at the same level in the call graph. That's some serious hacking that has to happen. > One solution I was exploring was using the compiler to help track the > potential for functions to block, similar to the const qualifier, combined > with blocking/non-blocking assertions evaluated at compile-time. However, > some of our current APIs (M_NOWAIT, M_WAITOK, et al) make that approach > somewhat difficult to apply, and would have to be revised to use a > compiler solution. These potential weaknesses very much exist in an > explicit model, but with explicit locking, we have a clearer notion of how > to express assertions. Absolutely a great idea! Nothing beats proper tools. Tools don't forget to look at some functions, etc.. If you are getting into the asserts (which I think is a great idea), then you will want to change all the functions where you have them to single-entry, single-exit (more code refactoring). I tried to do this with some of the FS patches I did back in 1995/1996, but the changes were seen as gratuitous. Maybe now it's an idea whose time has come. This will likely involve some additional complexity (i.e. use of negative logic), but the payoff would definitely be worth it (and you'll get better performance on top of that, if you run on a processor supporting branch prediction, or your compiler supports tail-call optimization -- and GCC does). > In -CURRENT, we make use of thread-based serialization in a number of > places to avoid explicit synchronization costs (such as in GEOM for > processing work queues), and we should make more use of this practice. > I'm particularly interested in the use of interface interrupt threads > performing direct dispatch as a means to maintain interface ordering of > packets coming in network interfaces while allowing parallelism in network > processing (you'll find this in use in Sam's netperf branch currently). I don't know if I agree with the idea that this type of serialization is the right thing to do; it's basically implying code locks (again) which leaves you in the same hole as the BGL. Personally, I'd like to see more reference counting of objects (effectively, a read-lock, as you noted above). I don't think you can safely discard an object just because you have thread serialization. For example, I think it's very possible to shoot your foot off in FreeBSD right now with a simple multithreaded program that forces a close race against a blocking system call (e.g. a read on a socket). This would be a much more frequent occurance on an MP box, and as CPU affinity and negaffinity of threads in a single process to max out concurrency go in, the problem will go critical, all by itself, and become totally unlivable for the majority of FreeBSD users (it doesn't help that most Intel CPUs these days are Hyperthreaded, so even if you are on a UP system, you're on an MP system, which is just going to exacerbate the problem). Unfortunately, there's a lot of threaded code that depends on the Sun behaviour (full cancellation support; Sun already refactored their code back in 1993/1994), particularly Java code tends to do this a lot, and expect an exception will get thrown. Java is evil. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 05:00:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E1AB16A4CF for ; Tue, 28 Oct 2003 05:00:32 -0800 (PST) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6A7F43FA3 for ; Tue, 28 Oct 2003 05:00:20 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfnd3.dialup.mindspring.com ([165.247.221.163] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AETSI-00050n-00; Tue, 28 Oct 2003 05:00:18 -0800 Message-ID: <3F9E652C.B7CB762B@mindspring.com> Date: Tue, 28 Oct 2003 04:46:36 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Leo Bicknell References: <3F9CF3F6.8307.ABC1250@localhost> <20031027171500.GF35805@ussenterprise.ufp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4a32724b532e9f4ce5fdc17134384aa3ba8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 13:00:32 -0000 Leo Bicknell wrote: > Dan Langille wrote: > > Any suggestions? > > Here's a slightly backwards concept. > > We're all familar with how you can open a file, remove it from the > directory, and not have it "go away" until the application closes > it. Well, extend those semantics to the namespace. > > That is, have a directory where any name that does not exist can be > opened RW, any name that does exist can be opened RO. A file is > automatically removed when no one has an open descriptor to it anymore. This is a somewhat neat idea. However, it would open a pretty big race window, and you could denial-of-service a server by creating a PID file belonging to some server, and leaving it there with a bogus PID in it, and anything that was watching the file R/O to kill -0 it to check if the processs needs to be restarted would always think the process needs to be restarted. 8-). Basically, all your processes would end up needing to be SUID root, at least initially, which would mean breaking most mail server software. They'd need that so that you could deny any create except by root to keep ordinary users from DOS'ing a daemon. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 06:31:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F28C916A4CE for ; Tue, 28 Oct 2003 06:31:03 -0800 (PST) Received: from cg.c.is (xs.heimsnet.is [193.4.194.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35ADB43F3F for ; Tue, 28 Oct 2003 06:31:02 -0800 (PST) (envelope-from thib@bitcode.org) Received: from claufield.bitcode.org (bofh.bitcode.org [213.220.74.36]) by cg.c.is (8.12.9/8.12.9) with SMTP id h9SEUxff1335372 for ; Tue, 28 Oct 2003 14:31:00 GMT Date: Tue, 28 Oct 2003 14:31:00 +0000 From: Thordur Ivar To: freebsd-hackers@freebsd.org Message-Id: <20031028143100.2ae74752.thib@bitcode.org> In-Reply-To: <016a01c39c7a$a23a78b0$3635a8c0@jaco> References: <016a01c39c7a$a23a78b0$3635a8c0@jaco> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [4.8-RELEASE - Stable, 5.1-RELEASE] Panics when system loaded X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 14:31:04 -0000 On Mon, 27 Oct 2003 13:08:18 +0200 "Jaco van Tonder" wrote: > Hi, > > I installed 4.8-RELEASE from CD yesterday on my P4-2.4GHz machine. > Updated sources to the latest 4.8-RELEASE-p13. Started doing buildworld and > my > machine panicked. Tried a few more times with random panics. Same random > panics > occur if I build the kernel. After a bit of struggling I managed to get a > GENERIC > kernel built with debug symbols on the latest source. I did not manage to > build > or install world on the new sources, but the panics happen regardless of > what > kernel is running. > > I also updated to the latest -STABLE, managed to build a kernel and > installed it. > Same problem exists there aswell (although this might be caused by a kernel > and world that are not in sync?). > > I installed 5.1-RELEASE to find the same problem exists there aswell. > > Can anybody perhaps give a hint in which direction to look or to make this > go away? > > Thanks in advance! > > Regards > Jaco > > Setup: > Intel P4, 2.4GHz CPU > Gigabyte MB with Intel 865P chipset, Hyperthreading technology > 512MB DDR333 Ram > 40GB Maxtor drive > 1024MB Swap > > USB disabled in BIOS as there is no need for it on this machine. > > Backtrace: > > frame# gdb -k kernel.debug.0 vmcore.0 > GNU gdb 4.18 (FreeBSD) > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read > called at > /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line > 2627 in elfstab_build_psymtabs > Deprecated bfd_read called at > /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line > 933 in fill_symbuf > > IdlePTD at phsyical address 0x00552000 > initial pcb at physical address 0x00483f00 > panicstr: from debugger > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xa96f98 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0342a10 > stack pointer = 0x10:0xdf3d4e7c > frame pointer = 0x10:0xdf3d4e84 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 78395 (cc1) > interrupt mask = none > panic: from debugger > > > Fatal trap 3: breakpoint instruction fault while in kernel mode > instruction pointer = 0x8:0xc0389031 > stack pointer = 0x10:0xdf3d4c90 > frame pointer = 0x10:0xdf3d4c98 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 78395 (cc1) > interrupt mask = none > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xa96f98 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0342a10 > stack pointer = 0x10:0xdf3d4e7c > frame pointer = 0x10:0xdf3d4e84 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 78395 (cc1) > interrupt mask = none > panic: from debugger > Uptime: 11m2s > > dumping to dev #ad/0x20001, offset 1048704 > dump ata0: resetting devices .. done > 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 > 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 > 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 > 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 > 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 > 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 > 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 > 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 > 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 > 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 > 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 > 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 > 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 > 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 > 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 > 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 > 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 > 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 > 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 > 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 > 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 > 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 > 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 > 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 > 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 > 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 > --- > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 > 487 if (dumping++) { > (kgdb) where > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 > #1 0xc021e258 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 > #2 0xc021e6a5 in panic (fmt=0xc03bc2e4 "from debugger") > at /usr/src/sys/kern/kern_shutdown.c:595 > #3 0xc014cedd in db_panic (addr=-1070323184, have_addr=0, count=-1, > modif=0xdf3d4d0c "") at /usr/src/sys/ddb/db_command.c:435 > #4 0xc014ce7b in db_command (last_cmdp=0xc0428844, cmd_table=0xc0428684, > aux_cmd_tablep=0xc046bb78) at /usr/src/sys/ddb/db_command.c:333 > #5 0xc014cf42 in db_command_loop () at /usr/src/sys/ddb/db_command.c:457 > #6 0xc014f113 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:71 > #7 0xc0388dd0 in kdb_trap (type=12, code=0, regs=0xdf3d4e3c) > at /usr/src/sys/i386/i386/db_interface.c:158 > #8 0xc039985c in trap_fatal (frame=0xdf3d4e3c, eva=11104152) > at /usr/src/sys/i386/i386/trap.c:969 > #9 0xc0399212 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, > tf_edi = 136372224, tf_esi = 37, tf_ebp = -549630332, > tf_isp = -549630360, tf_ebx = -544384096, tf_edx = 11104132, > tf_ecx = 12855290, tf_eax = 200316, tf_trapno = 12, tf_err = 0, > tf_eip = -1070323184, tf_cs = 8, tf_eflags = 66054, tf_esp = 0, > tf_ss = -549946880}) at /usr/src/sys/i386/i386/trap.c:636 > #10 0xc0342a10 in vm_page_lookup (object=0xdf8d5ba0, pindex=37) > at /usr/src/sys/vm/vm_page.c:514 > #11 0xc033a562 in vm_fault (map=0xdf387a00, vaddr=136372224, > fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:292 > ---Type to continue, or q to quit--- > #12 0xc03994af in trap_pfault (frame=0xdf3d4fa8, usermode=1, eva=136372228) > at /usr/src/sys/i386/i386/trap.c:847 > #13 0xc0398f2f in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, > tf_edi = 136372224, tf_esi = 136253088, tf_ebp = -1077938560, > tf_isp = -549629996, tf_ebx = 4072, tf_edx = 26, tf_ecx = 1, > tf_eax = 136368128, tf_trapno = 12, tf_err = 6, tf_eip = 135460607, > tf_cs = 31, tf_eflags = 66054, tf_esp = -1077938600, tf_ss = 47}) > at /usr/src/sys/i386/i386/trap.c:377 > #14 0x812f6ff in ?? () > #15 0x8062ae7 in ?? () > #16 0x80651ac in ?? () > #17 0x80504ea in ?? () > #18 0x8050274 in ?? () > #19 0x8068797 in ?? () > #20 0x806c0da in ?? () > #21 0x804813e in ?? () > > uname -a: > FreeBSD frame.symphiano 4.8-RELEASE-p13 FreeBSD 4.8-RELEASE-p13 #1: Fri Oct > 24 07:22:44 SAST 2003 root@frame.symphiano:/usr/obj/usr/src/sys/GENERIC > i386 > > dmesg: > Copyright (c) 1992-2003 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 4.8-RELEASE-p13 #1: Fri Oct 24 07:22:44 SAST 2003 > root@frame.symphiano:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz > CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2411.60-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbff ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > real memory = 536805376 (524224K bytes) > avail memory = 516980736 (504864K bytes) > Preloaded elf kernel "kernel" at 0xc0533000. > Pentium Pro MTRR support enabled > md0: Malloc disk > Using $PIR table, 10 entries at 0xc00fcde0 > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > agp0: mem 0xe8000000-0xefffffff at device > 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at 0.0 irq 12 > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > rl0: port 0x9000-0x90ff mem > 0xf7000000-0xf70000ff irq 11 at device 1.0 on pci2 > rl0: Ethernet address: 00:50:fc:c2:d4:1b > miibus0: on rl0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 irq 0 at device 31.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > pci0: (vendor=0x8086, dev=0x24d3) at 31.3 irq 11 > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ad0: 38166MB [77545/16/63] at ata0-master BIOSDMA > acd0: CDROM at ata1-slave PIO4 > Mounting root from ufs:/dev/ad0s1a > > kernel: > Standard GENERIC kernel with the following options enabled: > options DDB > makeoptions DEBUG=-g > frame% > > Jaco van Tonder > Magic Developer :: Premsoft Development (Pty) Ltd > Direct: +27 11 312 2122 :: Fax: +27 11 312 2122 :: Mobile: +27 83 417 5424 > Email: jaco@premsoft.co.za :: Web: http://www.premsoft.co.za/ > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" I had almost the exact proplem when I tryed to make a kernel + world, what kinda of RAM do you have ( Kingston if so check for sure if it works with your mainboard Kingston has been known to be naughty on some mainboards ). I think this is a hardware proplem since replaceing the RAM modules on my box fixed the proplem :) -- Thordur Ivar -- Turning Coffee into stupity since 2000 -- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 09:48:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA45216A4CE for ; Tue, 28 Oct 2003 09:48:40 -0800 (PST) Received: from smtp.covadmail.net (mx05.covadmail.net [63.65.120.65]) by mx1.FreeBSD.org (Postfix) with SMTP id 793A243FAF for ; Tue, 28 Oct 2003 09:48:38 -0800 (PST) (envelope-from strick@covad.net) Received: (covad.net 10765 invoked from network); 28 Oct 2003 17:48:33 -0000 Received: from unknown (HELO ice.nodomain) (67.101.98.90) by sun-qmail15 with SMTP; 28 Oct 2003 17:48:32 -0000 Received: from ice.nodomain (localhost [127.0.0.1]) by ice.nodomain (8.12.8p1/8.12.8) with ESMTP id h9SHma8a000538; Tue, 28 Oct 2003 09:48:36 -0800 (PST) (envelope-from dan@ice.nodomain) Received: (from dan@localhost) by ice.nodomain (8.12.8p1/8.12.8/Submit) id h9SHmaiH000537; Tue, 28 Oct 2003 09:48:36 -0800 (PST) Date: Tue, 28 Oct 2003 09:48:36 -0800 (PST) From: Dan Strick Message-Id: <200310281748.h9SHmaiH000537@ice.nodomain> To: jhb@FreeBSD.org cc: freebsd-hackers@FreeBSD.org cc: dan@ice.nodomain Subject: RE: boot0/1 problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 17:48:41 -0000 On 22 Oct 2003 John Baldwin wrote: > > On 22-Oct-2003 Dan Strick wrote: > > I seem to have stubbed my toe on another nasty little bootstrap problem. > > My Gigabyte motherboard AWARD BIOS passes the wrong drive number in the > > %dl register when it invokes the MBR bootstrap program, boot0. > > This forces me to configure the MBR bootstrap with the setdrv option. > > The noupdate option must also be set because otherwise I risk writing > > the MBR partition table back to the wrong disk and that would be a major > > disaster. > > > > Here is the problem: the boot1 program depends on the boot0 program > > setting the active partition flag in the MBR partition table. This > > doesn't happen if the boot0 noupdate option is set. > > > > The boot1 program always boots the active FreeBSD slice (or the first > > FreeBSD slice if there is no active FreeBSD slice). > > If you have multiple FreeBSD slices on a disk whose boot0 program is > > configured with the noupdate option, YOU CAN ONLY BOOT ONE OF THE > > SLICES. > > > > I have release 4.9-RCx and 5.1 slices on the same disk. If the 5.1 > > slice is active, the system wedges hard if I attempt to boot the > > 4.9-RCx slice. If the 4.9-RCx slice is active, the system resets > > if I attempt to boot the 5.1 slice. > > > > This really sucks. > > > > Can someone who knows how the bootx programs are supposed to work > > verify that my understanding of the problem is probably correct? > > Yes, it is correct. > > > Can someone suggest a workaround? > > You can change the device you load the kernel from by changing the > 'cuurdev' variable. Thus, if you do 'set currdev=disk1s2a' you can > switch from the first slice to the second. You can set the device to > mount your root filesystem from by using > 'set vfs.root.mountfrom="ufs:/dev/ad0s2a"'. You might be able to use > the beastie menu in current and hack it to add a menu item for booting > your 4.x slice and then always boot into the current loader and pick > 4.x from the menu. Thanks for the suggestion. I think I want a "solution" that does not make booting one slice dependent on another slice. For the moment I have settled for not being able to boot the 5.1 slice on this disk. I don't know what I will do for a permanent fix. I think the basic source of the problem is that the boot0/1/2 system is currently just too fragile. One possible fix for the current glitch might be to make boot1 configurable with a setdrv option much like boot0. This would make a lot of sense since boot1 is always installed in a particular slice and is typically installed by the disklabel/bsdlabel program which could configure the setdrv option automagically. Another bootstrap improvement might be to copy the boot0 program to a new location in memory by rereading it from disk instead of copying it from memory location 0x7c00. This would guarantee that it could be safely rewritten back to the same disk. Another bootstrap improvement might be to always attempt to use the "extended" int13 disk i/o function and fall back on the traditional c/h/s function if the extended function fails. This would fix the problem where a boot0 program configured to use the extended BIOS functions cannot load the next MBR in the chain because it is on a disk whose BIOS does not support the extended functions. (This one also took me a while to figure out.) I don't know if any of these changes would be practical. There is not a lot of space in a 512 byte bootstrap sector. (And it has been many many years since I last wrote 8x86 code.) For the moment, I will have to use the bootstrap as it is and live within its limitations. Dan Strick strick@covad.net From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 11:45:20 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE94A16A4CE for ; Tue, 28 Oct 2003 11:45:20 -0800 (PST) Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9611043F93 for ; Tue, 28 Oct 2003 11:45:18 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 19612 invoked from network); 28 Oct 2003 19:45:16 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 28 Oct 2003 19:45:16 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h9SJj6ce028218; Tue, 28 Oct 2003 14:45:09 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200310281748.h9SHmaiH000537@ice.nodomain> Date: Tue, 28 Oct 2003 14:45:06 -0500 (EST) From: John Baldwin To: Dan Strick X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-hackers@FreeBSD.org cc: dan@ice.nodomain Subject: RE: boot0/1 problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 19:45:21 -0000 On 28-Oct-2003 Dan Strick wrote: > On 22 Oct 2003 John Baldwin wrote: >> >> On 22-Oct-2003 Dan Strick wrote: >> > I seem to have stubbed my toe on another nasty little bootstrap problem. >> > My Gigabyte motherboard AWARD BIOS passes the wrong drive number in the >> > %dl register when it invokes the MBR bootstrap program, boot0. >> > This forces me to configure the MBR bootstrap with the setdrv option. >> > The noupdate option must also be set because otherwise I risk writing >> > the MBR partition table back to the wrong disk and that would be a major >> > disaster. >> > >> > Here is the problem: the boot1 program depends on the boot0 program >> > setting the active partition flag in the MBR partition table. This >> > doesn't happen if the boot0 noupdate option is set. >> > >> > The boot1 program always boots the active FreeBSD slice (or the first >> > FreeBSD slice if there is no active FreeBSD slice). >> > If you have multiple FreeBSD slices on a disk whose boot0 program is >> > configured with the noupdate option, YOU CAN ONLY BOOT ONE OF THE >> > SLICES. >> > >> > I have release 4.9-RCx and 5.1 slices on the same disk. If the 5.1 >> > slice is active, the system wedges hard if I attempt to boot the >> > 4.9-RCx slice. If the 4.9-RCx slice is active, the system resets >> > if I attempt to boot the 5.1 slice. >> > >> > This really sucks. >> > >> > Can someone who knows how the bootx programs are supposed to work >> > verify that my understanding of the problem is probably correct? >> >> Yes, it is correct. >> >> > Can someone suggest a workaround? >> >> You can change the device you load the kernel from by changing the >> 'cuurdev' variable. Thus, if you do 'set currdev=disk1s2a' you can >> switch from the first slice to the second. You can set the device to >> mount your root filesystem from by using >> 'set vfs.root.mountfrom="ufs:/dev/ad0s2a"'. You might be able to use >> the beastie menu in current and hack it to add a menu item for booting >> your 4.x slice and then always boot into the current loader and pick >> 4.x from the menu. > > Thanks for the suggestion. I think I want a "solution" that does not > make booting one slice dependent on another slice. For the moment I > have settled for not being able to boot the 5.1 slice on this disk. > > I don't know what I will do for a permanent fix. I think the basic > source of the problem is that the boot0/1/2 system is currently just > too fragile. One possible fix for the current glitch might be to make > boot1 configurable with a setdrv option much like boot0. This would > make a lot of sense since boot1 is always installed in a particular > slice and is typically installed by the disklabel/bsdlabel program > which could configure the setdrv option automagically. So whoever runs disklabel last gets to boot? :) > Another bootstrap improvement might be to copy the boot0 program > to a new location in memory by rereading it from disk instead of > copying it from memory location 0x7c00. This would guarantee that > it could be safely rewritten back to the same disk. I implemented that, but it hung on some machines. > Another bootstrap improvement might be to always attempt to use the > "extended" int13 disk i/o function and fall back on the traditional > c/h/s function if the extended function fails. This would fix the > problem where a boot0 program configured to use the extended BIOS > functions cannot load the next MBR in the chain because it is on > a disk whose BIOS does not support the extended functions. > (This one also took me a while to figure out.) I also implemented this, but it required boot0 to grow to more than one sector and the modified boot0 didn't work on some systems. > I don't know if any of these changes would be practical. > There is not a lot of space in a 512 byte bootstrap sector. > (And it has been many many years since I last wrote 8x86 code.) > For the moment, I will have to use the bootstrap as it is and > live within its limitations. Yes, you are basically stuck due to lack of space and lots of quirky BIOSen out there. boot1 can't really read your mind, so how is it supposed to pick which slice to boot from other than scanning the MBR as it currently does and preferring an active slice to a non-active slice? One thing you might be able to do is write your own boot1 that has the slice hard-coded in it and build a custom boot1 for each slice to bypass boot1's algorithm to search the MBR. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 13:48:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75FFF16A4CE for ; Tue, 28 Oct 2003 13:48:28 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43DE343F93 for ; Tue, 28 Oct 2003 13:48:27 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h9SLmQ8i014487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Oct 2003 16:48:26 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id h9SLmQAg014486 for freebsd-hackers@freebsd.org; Tue, 28 Oct 2003 16:48:26 -0500 (EST) Date: Tue, 28 Oct 2003 16:48:26 -0500 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031028214826.GA13810@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: Loading a kernel module before the installer. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 21:48:28 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have a system today with a vinum disk setup. I'd like to install new FreeBSD (5.1) with the same disk layout. Here's what I'm wondering: Can I load the vinum module before the installer from the install CD, thus allowing the installer to see the existing file systems? I think if I can do this I should be able to tell the installer to newfs them and do an install saving a lot of trouble over the more manual vinum install procedure. If this should work, how do I load the kernel module from the new boot loader? --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/nuQqNh6mMG5yMTYRAoOyAJ9iM+yXLcAkKqKpvXq9lnWhSh5cqACdFzCA /YBo0dQLdCHYfz9lLvfpCh0= =aSHk -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 20:07:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CA9416A4CE for ; Tue, 28 Oct 2003 20:07:44 -0800 (PST) Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id B16B143F85 for ; Tue, 28 Oct 2003 20:07:42 -0800 (PST) (envelope-from jason@ec.rr.com) Received: from ec.rr.com (cpe-024-211-231-149.ec.rr.com [24.211.231.149]) h9T47chf018139; Tue, 28 Oct 2003 23:07:40 -0500 (EST) Message-ID: <3F9F3D90.8050304@ec.rr.com> Date: Tue, 28 Oct 2003 23:09:52 -0500 From: jason User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leo Bicknell References: <20031028214826.GA13810@ussenterprise.ufp.org> In-Reply-To: <20031028214826.GA13810@ussenterprise.ufp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: freebsd-hackers@freebsd.org Subject: Re: Loading a kernel module before the installer. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 04:07:44 -0000 I know if you boot off the floopies you can load any modules or drivers you need before booting into sysinstall. You can also hit anykey, I think, to stop the boot process from the cdrom and load the modules. Jason Leo Bicknell wrote: >I have a system today with a vinum disk setup. I'd like to install >new FreeBSD (5.1) with the same disk layout. Here's what I'm >wondering: > >Can I load the vinum module before the installer from the install >CD, thus allowing the installer to see the existing file systems? >I think if I can do this I should be able to tell the installer to >newfs them and do an install saving a lot of trouble over the more >manual vinum install procedure. > >If this should work, how do I load the kernel module from the new >boot loader? > > > From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 01:06:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D32B16A4CE for ; Wed, 29 Oct 2003 01:06:40 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8C1143F3F for ; Wed, 29 Oct 2003 01:06:38 -0800 (PST) (envelope-from andreas@klemm.apsfilter.org) Received: from srv1.cosmo-project.de (localhost [IPv6:::1]) h9T96at2021995 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 29 Oct 2003 10:06:37 +0100 (CET) (envelope-from andreas@klemm.apsfilter.org) Received: (from uucp@localhost)h9T96afS021994 for freebsd-hackers@freebsd.org; Wed, 29 Oct 2003 10:06:36 +0100 (CET) (envelope-from andreas@klemm.apsfilter.org) Received: from titan.klemm.apsfilter.org (localhost.klemm.apsfilter.org [127.0.0.1]) by klemm.apsfilter.org (8.12.10/8.12.9) with ESMTP id h9T91GZw001274 for ; Wed, 29 Oct 2003 10:01:23 +0100 (CET) (envelope-from andreas@titan.klemm.apsfilter.org) Received: (from andreas@localhost)h9T91GU3001273 for freebsd-hackers@freebsd.org; Wed, 29 Oct 2003 10:01:16 +0100 (CET) (envelope-from andreas) Date: Wed, 29 Oct 2003 10:01:16 +0100 From: Andreas Klemm To: freebsd-hackers@freebsd.org Message-ID: <20031029090116.GA960@titan.klemm.apsfilter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 5.1-CURRENT X-Disclaimer: A free society is one where it is safe to be unpopular User-Agent: Mutt/1.5.4i Subject: how to monitor remote users shell activities best ? watch / snp / ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 09:06:40 -0000 Is there a freebsd tool that shows you in realtime, which users are logged in from remote using which pty port ? So to say something like while true do clear; w; sleep 10 done Preferable as X11 application. Cool would be options like: - log the snooped data - show their running processes - click to pty to fire up xterm with "watch -X " to snoop their current traffic. Background, I help an open source project and now somebody is on my local machine, to troubleshoot something, and I only know this person since a day ... so to say not well. Then the snp option came to my mind and the question, if perhaps somebody had done such a monitor for similar purposes. Remote vendor access and such things come to my mind. Of course I would ask him if its o.k. for him, that I can snoop his terminal traffic, better to play with open cards. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? -> http://www.apsfilter.org/ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 02:47:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91AB416A4D8; Wed, 29 Oct 2003 02:47:26 -0800 (PST) Received: from frost.ath.cx (BSN-95-242-77.dsl.siol.net [193.95.242.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 404A743FCB; Wed, 29 Oct 2003 02:47:25 -0800 (PST) (envelope-from bfg@noviforum.si) Received: from noviforum.si (mordor.lucky.si [192.168.200.250]) by frost.ath.cx (ESMTP) with ESMTP id 728A178; Wed, 29 Oct 2003 11:47:25 +0100 (CET) Message-ID: <3F9F9884.3020309@noviforum.si> Date: Wed, 29 Oct 2003 11:37:56 +0100 From: =?ISO-8859-2?Q?=22Branko_F=2E_Gra=E8nar=22?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: FreeBSD 5.1-p10 reproducible crash with Apache2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 10:47:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. FreeBSD 5.1-p10 (and also possible other 5.1-pX version) can be remotely locked up if the following criteria is met: + apache2 has mod_ssl loaded and enabled + apache2 has the following configuration directives set to the following values: SSLMutex sem SSLSessionCache shm:/some/file(1048576) + client connects via SSL/TLS to apache fast enough. If all conditions above are satisfied except the last one, then lockup doesn't happen. I tested on three 5.1-p10 machines (SMP, uniprocessor, uniprocessor with hypterthreading) with JMeter 1.9.1. It is possible lockup machine with 100 requests (1 concurrent request) in 1-3 seconds. If SSLMutex is set to file:/path/somewhere and SSLSessionCache is set to dbm:/some/dbm lockup does not accour. Linux 2.4.22 is not affected by this issue. Details: apache: 2.0.47 php: 4.3.3 + turck mmcache 2.4.2 web application: horde imp webmail Best regards, Brane -----BEGIN PGP SIGNATURE----- iD8DBQE/n5iEfiC/E+t8hPcRAu9kAJ4lpD5CJf7HwYxphipHin0gUFaORACfV6ei Wxi5PvScjACrKmCxCEbt0l0= =UVfz -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 04:09:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A7C416A4CE for ; Wed, 29 Oct 2003 04:09:40 -0800 (PST) Received: from correo.tid.es (tidos.tid.es [193.145.240.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69DCE43FA3 for ; Wed, 29 Oct 2003 04:09:38 -0800 (PST) (envelope-from igf@tid.es) Received: from conversion-daemon.tid.hi.inet by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) id <0HNI00201OYB3E@tid.hi.inet> for freebsd-hackers@freebsd.org; Wed, 29 Oct 2003 13:09:34 +0100 (MET) Received: from tid.es (sophia.hi.inet [10.95.43.243]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HNI00262PQW31@tid.hi.inet> for freebsd-hackers@freebsd.org; Wed, 29 Oct 2003 13:08:56 +0100 (MET) Date: Wed, 29 Oct 2003 13:10:53 +0100 From: Isaac Gelado To: freebsd-hackers@freebsd.org Message-id: <3F9FAE4D.3020500@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: es-es, es, en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.0.1) Gecko/20020823 Netscape/7.0 Subject: POSIX Threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 12:09:40 -0000 Hello all, I am developing a distributed application based on MICO (mico-2.3.9), which uses Packet Capture Library (PCapLib). In the code, I create a posix thread to execute the pcap_loop function (this function waits until certain number of packets have been captured or infinite if the number is 0). When PCapLib captures a packet and pcap_loop is running it calls to a handle function inside the same thread. This schema is working correctly in a linux machine, so when a packet is captured an CORBA event is sent to clients. But, when the server is running under FreeBSD 5.0, the handle function isn't executed when a packet is received. In FreeBSD the handle function is executed, for each packet, after certain time (maybe when the buffer of PCapLib is full), which is a problem because it sends events too fast to clients so the CORBA event service fails. Why happens this? Thanks and Regards -- __________________________________________________________ | Isaac Gelado | | | Telefónica I+D | Tlf 983367649 | | Paq. Tec. de Boecillo | | | Valladolid | igf@tid.es | |_______________________________|__________________________| | As gold which he cannot spend will make no man rich | | so knowledge which he cannot apply will make no man wise | |__________________________________________________________| From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 05:47:47 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99FEC16A4CE for ; Wed, 29 Oct 2003 05:47:47 -0800 (PST) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by mx1.FreeBSD.org (Postfix) with SMTP id 0BD2643FDF for ; Wed, 29 Oct 2003 05:47:47 -0800 (PST) (envelope-from q_dolan@yahoo.com.au) Received: from q.onthenet.com.au (HELO ?192.168.100.154?) (q?dolan@203.10.89.214 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Oct 2003 13:47:46 -0000 From: Q To: Isaac Gelado In-Reply-To: <3F9FAE4D.3020500@tid.es> References: <3F9FAE4D.3020500@tid.es> Message-Id: <1067435261.793.7.camel@boxster.onthenet.com.au> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 29 Oct 2003 23:47:42 +1000 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-hackers@freebsd.org Subject: Re: POSIX Threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 13:47:47 -0000 Why don't you either coalesce the events or throttle your send-event frequency so that it waits a minimum amount of time between sending each CORBA event. That should make your application more robust and better able to handle any receive rate you care to throw at it. As for why it happens.. I don't know sorry. Seeya...Q On Wed, 2003-10-29 at 22:10, Isaac Gelado wrote: > Hello all, > I am developing a distributed application based on MICO (mico-2.3.9), > which uses Packet Capture Library (PCapLib). > > In the code, I create a posix thread to execute the pcap_loop function > (this function waits until certain number of packets have been captured > or infinite if the number is 0). When PCapLib captures a packet and > pcap_loop is running it calls to a handle function inside the same thread. > > This schema is working correctly in a linux machine, so when a packet > is captured an CORBA event is sent to clients. But, when the server is > running under FreeBSD 5.0, the handle function isn't executed when a > packet is received. In FreeBSD the handle function is executed, for each > packet, after certain time (maybe when the buffer of PCapLib is full), > which is a problem because it sends events too fast to clients so the > CORBA event service fails. > > Why happens this? > > Thanks and Regards From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 06:01:01 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC15E16A4CE for ; Wed, 29 Oct 2003 06:01:01 -0800 (PST) Received: from smtp2.enst.fr (reloaded.enst.fr [137.194.2.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EBA943FBD for ; Wed, 29 Oct 2003 06:00:58 -0800 (PST) (envelope-from beyssac@enst.fr) Received: from bofh.enst.fr (bofh.enst.fr [137.194.32.191]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "bofh.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id EAE63423; Wed, 29 Oct 2003 15:00:55 +0100 (CET) Received: from enst.fr (localhost [127.0.0.1]) by bofh.enst.fr (8.12.9p2/8.12.9) with ESMTP id h9TE0txP042260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2003 15:00:56 +0100 (CET) (envelope-from beyssac@enst.fr) Received: (from beyssac@localhost) by enst.fr (8.12.9p2/8.12.9/Submit) id h9TE0sOg042259; Wed, 29 Oct 2003 15:00:54 +0100 (CET) (envelope-from beyssac) Date: Wed, 29 Oct 2003 15:00:54 +0100 From: Pierre Beyssac To: Terry Lambert Message-ID: <20031029150054.A40485@bofh.enst.fr> References: <200310230143.32244.wes@softweyr.com> <20031025175948.GF683@funkthat.com> <3F9AC703.4DBAA14C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F9AC703.4DBAA14C@mindspring.com>; from tlambert2@mindspring.com on Sat, Oct 25, 2003 at 11:54:59AM -0700 X-message-flag: Warning! Use of Microsoft Outlook makes your system susceptible to worms and viruses cc: hackers@freebsd.org cc: Kip Macy Subject: Re: FreeBSD mail list etiquette X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 14:01:02 -0000 On Sat, Oct 25, 2003 at 11:54:59AM -0700, Terry Lambert wrote: > Frankly, FreeBSD has too many cooks, and not enough bottle washers; > this is a euphimism for saying that all anyone with a commit bit > seems to want to do any more is write new code, and no one is > willing to take on the integration and maintenance tasks. In Linux, > this work is done by Linus, Alan Cox, and a couple of other people. > People get commit bits so that they can do integration, and so that > patches don't sit in bug databases for 6 years unintegrated. > > The problem with this imbalance, is that you seem to be unwilling > to hire bottle washers, and people willing to wash bottles when > there are no clean bottles left are never given any respect, and > certainly not the level of respect accorded to cooks. I believe that's mostly a problem with FreeBSD 5. I partly agree with your analysis, in that too much attention is given to new developments, and not quite enough to stability fixes. Where I differ is that I believe the problem doesn't lie with commit bits attribution, but rather with the inherent complexity of the FreeBSD 5.x kernel. The 5.x kernel is a hell of a lot more difficult to work on than the 4.x kernel. More than once I've been unable to debug stuff myself under 5.x, due to giant push, locking intricacies, KSE, mutexes... The result seems to be that just a few people master each part of the kernel. The others either work by trial-and-error, or don't dare to work at all except in limited, obvious cases or in their area of competence. Two simple things could probably help: - having minimal documentation for developers about how to develop and debug the 5.x kernel, explaining stuff like KSE, mutexes, ... -- this is easier said than done, and a job in itself. Just maintaining -- or advertising -- a set of pointers to relevant man pages and source code samples, explaining the spirit of this stuff, would be a good start. - extending regression tests, trying to add new relevant tests when bugs are fixed. It is also easier said than done, but it is easier to distribute among people. Following Mike Silbersack's suggestion I've been trying to do that for bugs I fix, which as noted above does not happen often these times. On a different note, the checkpoint code announcement which started all this thread seems an extremely interesting functionality to me, thank you Kip for posting this information. -- Pierre Beyssac pb@enst.fr From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 06:38:57 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1A2E16A4D4 for ; Wed, 29 Oct 2003 06:38:57 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2CA943F3F for ; Wed, 29 Oct 2003 06:38:55 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 979233D29 for ; Wed, 29 Oct 2003 09:38:50 -0500 (EST) From: "Dan Langille" To: FreeBSD-hackers@freebsd.org Date: Wed, 29 Oct 2003 09:38:50 -0500 MIME-Version: 1.0 Message-ID: <3F9F8AAA.12507.14D8EE23@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: hosts_access(3) - correct usage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 14:38:58 -0000 Is this the right way to use hosts_access? The code blows up during the hosts_access call. I'm told it runs OK on Linux/Solaris. I'm wonderding if there's something different it needs to do be doing on FreeBSD. Thanks #ifdef HAVE_LIBWRAP P(mutex); /* hosts_access is not thread safe */ request_init(&request, RQ_DAEMON, my_name, RQ_FILE, newsockfd, 0); fromhost(&request); if (!hosts_access(&request)) { V(mutex); Jmsg2(NULL, M_WARNING, 0, _("Connection from %s:%d refused by hosts.access"), inet_ntoa(cli_addr.sin_addr), ntohs(cli_addr.sin_port)); close(newsockfd); continue; } V(mutex); #endif -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 06:48:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5D4016A4CE for ; Wed, 29 Oct 2003 06:48:37 -0800 (PST) Received: from isis.telemach.net (isis.telemach.net [213.143.65.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBC5143FBD for ; Wed, 29 Oct 2003 06:48:34 -0800 (PST) (envelope-from rp@telemach.net) Received: by isis.telemach.net (Postfix, from userid 1002) id D56147A319; Wed, 29 Oct 2003 15:48:29 +0100 (CET) Date: Wed, 29 Oct 2003 15:48:29 +0100 From: "(rp)" To: freebsd-hackers@freebsd.org Message-ID: <20031029144829.GA82230@isis.telemach.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: make_dev & cdevsw_add X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 14:48:38 -0000 Hello! I would kindly request explanation on how are cdevsw_add and make_dev related ? Maybe short example also with focus on cdevsw_add. Thing is i do not understand the function of cdevsw_add when i have make_dev. Also if there is any real good document that describes most of cdev related stuff i would appriciate if someone gives me an url. Second thing that i would like to know is: struct cdevsw { d_open_t *d_open; When a process calls open on character device and d_open function is called would it be possible to determine the file descriptor returned by the open system call on that device that is returned to the process from d_open ? That is i would like to implement character device that wouldn't require /dev/somedev[0-9]+ number of devices but only /dev/somedev and would identify the open/close/ read/write operations by pid and fd instead of dev_t's minor number. re RP From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 08:10:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C546E16A4CE for ; Wed, 29 Oct 2003 08:10:12 -0800 (PST) Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF38443F85 for ; Wed, 29 Oct 2003 08:10:10 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 5B12041; Wed, 29 Oct 2003 17:10:09 +0100 (CET) Date: Wed, 29 Oct 2003 17:10:09 +0100 From: Guido van Rooij To: Dan Langille Message-ID: <20031029161009.GA26309@gvr.gvr.org> References: <3F9F8AAA.12507.14D8EE23@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9F8AAA.12507.14D8EE23@localhost> cc: FreeBSD-hackers@freebsd.org Subject: Re: hosts_access(3) - correct usage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 16:10:12 -0000 On Wed, Oct 29, 2003 at 09:38:50AM -0500, Dan Langille wrote: > Is this the right way to use hosts_access? The code blows up during > the hosts_access call. I'm told it runs OK on Linux/Solaris. I'm > wonderding if there's something different it needs to do be doing on > FreeBSD. > > Thanks > > #ifdef HAVE_LIBWRAP > P(mutex); /* hosts_access is not thread safe */ > request_init(&request, RQ_DAEMON, my_name, RQ_FILE, newsockfd, > 0); > fromhost(&request); > if (!hosts_access(&request)) { > V(mutex); > Jmsg2(NULL, M_WARNING, 0, _("Connection from %s:%d refused > by hosts.access"), > inet_ntoa(cli_addr.sin_addr), ntohs(cli_addr.sin_port)); > close(newsockfd); > continue; > } > V(mutex); > #endif This seems okay to me. OpenSSH uses: struct request_info req; request_init(&req, RQ_DAEMON, __progname, RQ_FILE, sock_in, 0); fromhost(&req); if (!hosts_access(&req)) { debug("Connection refused by tcp wrapper"); refuse(&req); /* NOTREACHED */ fatal("libwrap refuse returns"); } I take it that newsockfd is the one returned from accept()? I'd try using a debug version of libwrap... -Guido From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 08:24:49 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B2CF16A4D1 for ; Wed, 29 Oct 2003 08:24:49 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B61B143FDD for ; Wed, 29 Oct 2003 08:24:48 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h9TGOlcN031248; Wed, 29 Oct 2003 10:24:47 -0600 (CST) (envelope-from dan) Date: Wed, 29 Oct 2003 10:24:47 -0600 From: Dan Nelson To: Isaac Gelado Message-ID: <20031029162447.GE2284@dan.emsphone.com> References: <3F9FAE4D.3020500@tid.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9FAE4D.3020500@tid.es> X-OS: FreeBSD 5.1-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: POSIX Threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 16:24:49 -0000 In the last episode (Oct 29), Isaac Gelado said: > I am developing a distributed application based on MICO (mico-2.3.9), > which uses Packet Capture Library (PCapLib). > > In the code, I create a posix thread to execute the pcap_loop > function (this function waits until certain number of packets have > been captured or infinite if the number is 0). When PCapLib captures > a packet and pcap_loop is running it calls to a handle function > inside the same thread. > > This schema is working correctly in a linux machine, so when a packet > is captured an CORBA event is sent to clients. But, when the server > is running under FreeBSD 5.0, the handle function isn't executed when > a packet is received. In FreeBSD the handle function is executed, for > each packet, after certain time (maybe when the buffer of PCapLib is > full), which is a problem because it sends events too fast to clients > so the CORBA event service fails. When you called pcap_open_live, what timeout did you set? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 11:50:39 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D39D16A4CE for ; Wed, 29 Oct 2003 11:50:39 -0800 (PST) Received: from hotmail.com (bay2-f168.bay2.hotmail.com [65.54.247.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id C29B743FBF for ; Wed, 29 Oct 2003 11:50:38 -0800 (PST) (envelope-from vinodrk@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 11:50:38 -0800 Received: from 67.122.122.226 by by2fd.bay2.hotmail.msn.com with HTTP; Wed, 29 Oct 2003 19:50:38 GMT X-Originating-IP: [67.122.122.226] X-Originating-Email: [vinodrk@hotmail.com] From: "Vinod R. Kashyap" To: freebsd-hackers@freebsd.org Date: Wed, 29 Oct 2003 11:50:38 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Oct 2003 19:50:38.0548 (UTC) FILETIME=[ED335940:01C39E55] Subject: freeing data segment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 19:50:39 -0000 Hi, I have this huge data structure in the data segment of my scsi driver. This data structure is initialized at driver build time, and is used only during driver initialization. I am trying to find out if I can free-up the memory it occupies, once I am done with the driver initialization. Does anyone know how to do this? Thanks, Vinod. _________________________________________________________________ See when your friends are online with MSN Messenger 6.0. Download it now FREE! http://msnmessenger-download.com From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 12:54:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAC8D16A4CE for ; Wed, 29 Oct 2003 12:54:08 -0800 (PST) Received: from serl.cs.colorado.edu (serl-fs.cs.colorado.edu [128.138.242.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B7F343FBD for ; Wed, 29 Oct 2003 12:54:06 -0800 (PST) (envelope-from John.Giacomoni@colorado.edu) Received: from colorado.edu (localhost [127.0.0.1]) by serl.cs.colorado.edu (8.12.9/8.12.6) with ESMTP id h9TKrviQ015470 for ; Wed, 29 Oct 2003 13:53:58 -0700 (MST) Date: Wed, 29 Oct 2003 13:53:56 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: John Giacomoni To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <03723039-0A52-11D8-8B79-0003930719D8@colorado.edu> X-Mailer: Apple Mail (2.552) Subject: Which mutex to lock when accessing a "struct ifnet*" ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 20:54:08 -0000 I'm writing some code which examines the the state of a "struct ifnet*" as returned by "ifunit". In what situations is it possible for the "struct _softc" to be deleted taking it's "struct ifnet" with it? Does it never go away? I assume it is possible for the structure to go away given support for pcmcia cards. Is Giant the correct lock as suggested by the /usr/src/sys/net/bpf.c (when it calls ifpromisc) to protect against this occurrence? doesn't seem right as my understanding is Giant is being eliminated. The other assumption would be struct ifnet's own mutex but there would be a race to locking it after one gets a reference to it (via ifunit). Ideas? thanks John G -- University of Colorado at Boulder John.Giacomoni@colorado.edu Department of Computer Science phone: 303.492.8115 Engineering Center, ECCS 121 303.492.7906 430 UCB fax: 303.492.2844 Boulder, CO 80303-0430 USA From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 15:26:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 030BA16A4CE for ; Wed, 29 Oct 2003 15:26:23 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4457443FF9 for ; Wed, 29 Oct 2003 15:26:22 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 31DD63D28; Wed, 29 Oct 2003 18:26:21 -0500 (EST) From: "Dan Langille" To: Guido van Rooij Date: Wed, 29 Oct 2003 18:26:20 -0500 MIME-Version: 1.0 Message-ID: <3FA0064C.1557.16BBE929@localhost> Priority: normal In-reply-to: <20031029161009.GA26309@gvr.gvr.org> References: <3F9F8AAA.12507.14D8EE23@localhost> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: FreeBSD-hackers@freebsd.org Subject: Re: hosts_access(3) - correct usage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 23:26:23 -0000 On 29 Oct 2003 at 17:10, Guido van Rooij wrote: > On Wed, Oct 29, 2003 at 09:38:50AM -0500, Dan Langille wrote: > > Is this the right way to use hosts_access? The code blows up during > > the hosts_access call. I'm told it runs OK on Linux/Solaris. I'm > > wonderding if there's something different it needs to do be doing on > > FreeBSD. > > > > Thanks > > > > #ifdef HAVE_LIBWRAP > > P(mutex); /* hosts_access is not thread safe */ > > request_init(&request, RQ_DAEMON, my_name, RQ_FILE, newsockfd, > > 0); > > fromhost(&request); > > if (!hosts_access(&request)) { > > V(mutex); > > Jmsg2(NULL, M_WARNING, 0, _("Connection from %s:%d refused > > by hosts.access"), > > inet_ntoa(cli_addr.sin_addr), ntohs(cli_addr.sin_port)); > > close(newsockfd); > > continue; > > } > > V(mutex); > > #endif > > > This seems okay to me. > OpenSSH uses: > struct request_info req; > > request_init(&req, RQ_DAEMON, __progname, RQ_FILE, sock_in, 0); > fromhost(&req); > > if (!hosts_access(&req)) { > debug("Connection refused by tcp wrapper"); > refuse(&req); > /* NOTREACHED */ > fatal("libwrap refuse returns"); > } > > I take it that newsockfd is the one returned from accept()? > I'd try using a debug version of libwrap... I was speaking with dwhite on IRC about this. The application (sysutils/bacula) has a hacked version of tcpd.h for use with C++. This didn't have the #ifdef INET6 statements. So I patched that up. But no difference in the results. If hosts.allow is going to deny access, the crash occurs: http://beta.freebsddiary.org/tmp/bacula-fd-gbd.success.html If access is denied, this occurs: http://beta.freebsddiary.org/tmp/bacula-fd-gbd.fails.html I haven't looked into libwrap yet, but in case someone sees something obvious, I've posted the above. thanks -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 16:32:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22B3616A4CE for ; Wed, 29 Oct 2003 16:32:02 -0800 (PST) Received: from smtp.sw.oz.au (alt.aurema.com [203.217.18.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54FAC43FEA for ; Wed, 29 Oct 2003 16:32:00 -0800 (PST) (envelope-from vance@aurema.com) Received: from smtp.sw.oz.au (localhost [127.0.0.1]) by smtp.sw.oz.au with ESMTP id h9U0VsQg029737; Thu, 30 Oct 2003 11:31:57 +1100 (EST) Received: (from vance@localhost) by smtp.sw.oz.au id h9U0VrgD029735; Thu, 30 Oct 2003 11:31:53 +1100 (EST) Date: Thu, 30 Oct 2003 11:31:53 +1100 From: Christopher Vance To: "Dan Langille" Message-ID: <20031030003153.GC16553@aurema.com> References: <3F9CF3F6.8307.ABC1250@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3F9CF3F6.8307.ABC1250@localhost> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 00:32:02 -0000 On Mon, Oct 27, 2003 at 10:31:18AM -0500, Dan Langille wrote: >If a process starts up and does a setuid, should it be writing the >PID file before or after the setuid? > >Two methods exists AFAIK: > >1 - write your PID immediately, and the file is chown root:wheel >2 - write your PID to /var/run/myapp/myapp.pid where /var/run/myapp/ > is chown myapp:myapp > >Of the two, I think #1 is cleaner as it does not require another >directory with special permissions. You can already mark a fd 'close on exec'. May I suggest a different feature: the ability to mark an open file (not just its fd) 'remove on close', with permission checked at mark time rather than close time (this status forgotten if not permitted when set) and the unlink actually done at close time only if the file has exactly one link and one open file instance at that time. That way your server can start as root open file to write/update downgrade/reopen file to readonly mark remove on close setuid non-root Or you could call it a future unlink. I'm sure there are holes in it, and I won't claim to have tried it, ... -- Christopher Vance From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 16:53:05 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E20C816A4CE for ; Wed, 29 Oct 2003 16:53:04 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C0F743F85 for ; Wed, 29 Oct 2003 16:53:02 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 99A3C3D28 for ; Wed, 29 Oct 2003 19:53:01 -0500 (EST) From: "Dan Langille" To: FreeBSD-hackers@freebsd.org Date: Wed, 29 Oct 2003 19:53:01 -0500 MIME-Version: 1.0 Message-ID: <3FA01A9D.29792.170B4536@localhost> Priority: normal In-reply-to: <3FA0064C.1557.16BBE929@localhost> References: <20031029161009.GA26309@gvr.gvr.org> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: hosts_access(3) - correct usage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 00:53:05 -0000 On 29 Oct 2003 at 18:26, Dan Langille wrote: > On 29 Oct 2003 at 17:10, Guido van Rooij wrote: > > > On Wed, Oct 29, 2003 at 09:38:50AM -0500, Dan Langille wrote: > > > Is this the right way to use hosts_access? The code blows up during > > > the hosts_access call. I'm told it runs OK on Linux/Solaris. I'm > > > wonderding if there's something different it needs to do be doing on > > > FreeBSD. > > > > > > Thanks > > > > > > #ifdef HAVE_LIBWRAP > > > P(mutex); /* hosts_access is not thread safe */ > > > request_init(&request, RQ_DAEMON, my_name, RQ_FILE, newsockfd, > > > 0); > > > fromhost(&request); > > > if (!hosts_access(&request)) { > > > V(mutex); > > > Jmsg2(NULL, M_WARNING, 0, _("Connection from %s:%d refused > > > by hosts.access"), > > > inet_ntoa(cli_addr.sin_addr), ntohs(cli_addr.sin_port)); > > > close(newsockfd); > > > continue; > > > } > > > V(mutex); > > > #endif > > > > > > This seems okay to me. > > OpenSSH uses: > > struct request_info req; > > > > request_init(&req, RQ_DAEMON, __progname, RQ_FILE, sock_in, 0); > > fromhost(&req); > > > > if (!hosts_access(&req)) { > > debug("Connection refused by tcp wrapper"); > > refuse(&req); > > /* NOTREACHED */ > > fatal("libwrap refuse returns"); > > } > > > > I take it that newsockfd is the one returned from accept()? > > I'd try using a debug version of libwrap... > > I was speaking with dwhite on IRC about this. The application > (sysutils/bacula) has a hacked version of tcpd.h for use with C++. > This didn't have the #ifdef INET6 statements. So I patched that up. > But no difference in the results. > > If hosts.allow is going to deny access, the crash occurs: > http://beta.freebsddiary.org/tmp/bacula-fd-gbd.success.html > > If access is denied, this occurs: > http://beta.freebsddiary.org/tmp/bacula-fd-gbd.fails.html > > I haven't looked into libwrap yet, but in case someone sees something > obvious, I've posted the above. Well, we've tracked it down to one set of allow statements. The server is at 192.168.0.56 (undef.unixathome.org). The daemon name is bast-fd. If we supply any one of these in /etc/hosts.allow, the crash does not occur. bast-fd : 192.168.0.0/255.255.255.0 : allow bast-fd : 192.168.0.0/255.255.255.0 : deny bast-fd : undef.unixathome.org : allow bast-fd : undef.unixathome.org : deny bast-fd : 192.168.0.56 : allow With this, the crash occurs: bast-fd : undef.blah.blah : allow This is how to make it crash: $ telnet bast 9102 Trying 192.168.0.21... Connected to bast.unixathome.org. Escape character is '^]'. You are not welcome to use bast-fd from undef.unixathome.org. Connection closed by foreign host. Also, if the first call the hosts_access succeeds, then all subequent calls will suceed. I actually have to restart the daemon, and then have a deny condition in hosts.allow in order for the hosts_access call to bomb. Any ideas? -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 20:20:05 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7296016A4CE for ; Wed, 29 Oct 2003 20:20:05 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F72643FBD for ; Wed, 29 Oct 2003 20:20:04 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id h9U4IpMg049460 for ; Wed, 29 Oct 2003 23:18:51 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h9U4IpmI049457 for ; Wed, 29 Oct 2003 23:18:51 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 29 Oct 2003 23:18:51 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: hackers@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Experimental FreeBSD and Linux kernel source cross reference web site X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 04:20:05 -0000 In the past when browsing the Linux source code, I've made extensive use of the Linux Cross-Reference (LXR) hosted at lxr.linux.no. This web site provides a cross-referenced and searchable HTML interface to the Linux source code; you can perform freetext and identifier searches, check differences between revisions, etc. For FreeBSD, we provide a cvsweb interface that is extremely useful for tracking changes, but a little less useful for "raw browsing" when you're looking for use of an identifier. In the past, CMU's PDL (and possibly others) have provided FreeBSD cross-reference web pages, but I was unable to find one once that site went down. As such, I've experimentally set up the LXR software with access to several branches of the FreeBSD source code, as well as 2.4 and 2.6 Linux kernels at: http://fxr.watson.org/ This is experimental, but I've found it to be quite useful for my own work. I'm intermittently synchronizing the checked out snapshots to CVS. LXR is a useful piece of software, but not designed to handle multiple source code collections so well (i.e., currently isn't a good candidate for all of src). On the other hand, making the source code more easy to search and browse is a very useful thing, so feel free to give it a spin :-). I'll probably keep tweaking and playing with the configuration, as well as put more revisions of the Linux source online, probably drop in an OpenBSD, NetBSD, or DFBSD snapshot or two, etc, soon also. I don't promise it will be there tomorrow, but if it proves useful and interesting, it probably will be :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 20:47:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E993A16A4CE for ; Wed, 29 Oct 2003 20:47:22 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14FE943FD7 for ; Wed, 29 Oct 2003 20:47:22 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id h9U4k9Mg050068 for ; Wed, 29 Oct 2003 23:46:09 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h9U4k9pu050065 for ; Wed, 29 Oct 2003 23:46:09 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 29 Oct 2003 23:46:09 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: hackers@FreeBSD.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Experimental FreeBSD and Linux kernel source cross reference web site X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 04:47:23 -0000 FYI, lxr's C parsing code appears to dislike some of our C constructs. I haven't had a chance to dig in much yet, but this is a warning that there are some glitches (for example, kern_prot.c seems to be improperly parsed in RELENG_4). Also, the identifier database seems somewhat prone to corruption if aborted part way through processing; the identifier database for HEAD appears currently to be corrupted so I'm rebuilding it. So if an identifier search fails unexpectedly, or you notice that a C file is not highlighted with cross-reference links for important identifiers, that's probably why: try again in ten minutes. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 21:05:43 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8CB816A4CE; Wed, 29 Oct 2003 21:05:43 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-234.dsl.lsan03.pacbell.net [63.207.60.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46D0E43FCB; Wed, 29 Oct 2003 21:05:42 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id BB91166B9B; Wed, 29 Oct 2003 21:05:40 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 8D55BB12; Wed, 29 Oct 2003 21:05:40 -0800 (PST) Date: Wed, 29 Oct 2003 21:05:40 -0800 From: Kris Kennaway To: "Branko F. Gra?nar" Message-ID: <20031030050540.GA25906@rot13.obsecurity.org> References: <3F9F9884.3020309@noviforum.si> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <3F9F9884.3020309@noviforum.si> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 5.1-p10 reproducible crash with Apache2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 05:05:44 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2003 at 11:37:56AM +0100, "Branko F. Gra?nar" wrote: > Hi. >=20 > FreeBSD 5.1-p10 (and also possible other 5.1-pX version) can be remotely > locked up if the following criteria is met: >=20 > + apache2 has mod_ssl loaded and enabled > + apache2 has the following configuration directives set to the > following values: >=20 > SSLMutex sem > SSLSessionCache shm:/some/file(1048576) >=20 > + client connects via SSL/TLS to apache fast enough. >=20 > If all conditions above are satisfied except the last one, then lockup > doesn't happen. >=20 > I tested on three 5.1-p10 machines (SMP, uniprocessor, uniprocessor with > hypterthreading) with JMeter 1.9.1. >=20 > It is possible lockup machine with 100 requests (1 concurrent request) > in 1-3 seconds. >=20 > If SSLMutex is set to file:/path/somewhere and SSLSessionCache is set to > dbm:/some/dbm lockup does not accour. >=20 > Linux 2.4.22 is not affected by this issue. >=20 > Details: What kernel configuration? What hardware? Kris --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/oJwkWry0BWjoQKURAqYYAJ92W7HTAmfl2EwIimKUc0Mrl+vWoACg3Qor Twxs3HZqj1X6/NtdWIt5nc0= =YJh4 -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 23:26:49 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A80716A4CE for ; Wed, 29 Oct 2003 23:26:49 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95D2F43FB1 for ; Wed, 29 Oct 2003 23:26:47 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9U7QkE7039851; Thu, 30 Oct 2003 00:26:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 30 Oct 2003 00:26:45 -0700 (MST) Message-Id: <20031030.002645.16965423.imp@bsdimp.com> To: vinodrk@hotmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: freeing data segment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 07:26:49 -0000 In message: "Vinod R. Kashyap" writes: : : Hi, : : I have this huge data structure in the data segment of my scsi driver. This : data structure is initialized at driver build time, and is used only during : driver : initialization. I am trying to find out if I can free-up the memory it : occupies, : once I am done with the driver initialization. Does anyone know how to do : this? Put it in a module, and unload the module. Alternatively, load it from userland. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 23:38:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 556EF16A4CE for ; Wed, 29 Oct 2003 23:38:28 -0800 (PST) Received: from correo.tid.es (tidos.tid.es [193.145.240.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3966643F93 for ; Wed, 29 Oct 2003 23:38:27 -0800 (PST) (envelope-from igf@tid.es) Received: from conversion-daemon.tid.hi.inet by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) id <0HNK00H01753R9@tid.hi.inet> for freebsd-hackers@freebsd.org; Thu, 30 Oct 2003 08:38:26 +0100 (MET) Received: from tid.es (sophia.hi.inet [10.95.43.243]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HNK001D57W1DU@tid.hi.inet>; Thu, 30 Oct 2003 08:38:26 +0100 (MET) Date: Thu, 30 Oct 2003 08:40:20 +0100 From: Isaac Gelado To: Dan Nelson Message-id: <3FA0C064.102@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: es-es, es, en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: <3F9FAE4D.3020500@tid.es> <20031029162447.GE2284@dan.emsphone.com> cc: freebsd-hackers@freebsd.org Subject: Re: POSIX Threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 07:38:28 -0000 Dan Nelson escribió: > In the last episode (Oct 29), Isaac Gelado said: > >>I am developing a distributed application based on MICO (mico-2.3.9), >>which uses Packet Capture Library (PCapLib). >> >>In the code, I create a posix thread to execute the pcap_loop >>function (this function waits until certain number of packets have >>been captured or infinite if the number is 0). When PCapLib captures >>a packet and pcap_loop is running it calls to a handle function >>inside the same thread. >> >>This schema is working correctly in a linux machine, so when a packet >>is captured an CORBA event is sent to clients. But, when the server >>is running under FreeBSD 5.0, the handle function isn't executed when >>a packet is received. In FreeBSD the handle function is executed, for >>each packet, after certain time (maybe when the buffer of PCapLib is >>full), which is a problem because it sends events too fast to clients >>so the CORBA event service fails. > > > When you called pcap_open_live, what timeout did you set? > I set it to 0, so PCapLib should return the packet inmediatly. Can the problem be in the PCapLib implementation? -- __________________________________________________________ | Isaac Gelado | | | Telefónica I+D | Tlf 983367649 | | Paq. Tec. de Boecillo | | | Valladolid | igf@tid.es | |_______________________________|__________________________| | As gold which he cannot spend will make no man rich | | so knowledge which he cannot apply will make no man wise | |__________________________________________________________| From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 00:12:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26F1316A4CE for ; Thu, 30 Oct 2003 00:12:26 -0800 (PST) Received: from www.premsoft.co.za (www.rune.za.net [196.37.142.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FA0D43FD7 for ; Thu, 30 Oct 2003 00:12:11 -0800 (PST) (envelope-from freebsd-questions@premsoft.co.za) Received: from jaco[196.30.236.80] by www.premsoft.co.za; Tue, 28 Oct 2003 22:23:39 +0200 Message-ID: <00b501c39d8e$6b564a80$3635a8c0@jaco> From: "Jaco H. van Tonder" To: "Kris Kennaway" References: <016a01c39c7a$a23a78b0$3635a8c0@jaco> <20031027235814.GA41472@rot13.obsecurity.org> Date: Tue, 28 Oct 2003 22:02:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-hackers@freebsd.org cc: Dark Schneider cc: freebsd-stable@freebsd.org cc: Steven Hartland Subject: Re: [SOLVED] [4.8-RELEASE - Stable, 5.1-RELEASE] Panics when system loaded X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 08:12:26 -0000 On Mon, Oct 27, 2003 at 01:08:18PM +0200, Jaco van Tonder wrote: >> Can anybody perhaps give a hint in which direction to look or to make this >> go away? >Do you have stale modules loaded? > >Kris Hi all, This problem was solved. The culprit was a bad memory module. :( Thanks to all for your ideas. Have a good one. Jaco From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 03:35:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1258316A4CE for ; Thu, 30 Oct 2003 03:35:22 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 311F243F75 for ; Thu, 30 Oct 2003 03:35:21 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfim6.dialup.mindspring.com ([165.247.202.198] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AFB5D-0004z2-00; Thu, 30 Oct 2003 03:35:20 -0800 Message-ID: <3FA0F745.7B9E34F0@mindspring.com> Date: Thu, 30 Oct 2003 03:34:29 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vinod R. Kashyap" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4802c02d67900a489e430697ac4e3d2f4a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: freeing data segment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 11:35:22 -0000 "Vinod R. Kashyap" wrote: > I have this huge data structure in the data segment of my scsi driver. This > data structure is initialized at driver build time, and is used only during > driver > initialization. I am trying to find out if I can free-up the memory it > occupies, > once I am done with the driver initialization. Does anyone know how to do > this? You can either implement it in a separate ELF section that's marked "init only" (this is a defined ELF attribute), and then fix FreeBSD to honor discarding of such sections (FreeBSD doesn't implement very much of the capabilities of ELF), or... You can make two drivers, make the init driver depend on the other driver, load the init driver, have it's init routine call an entry point in the other driver to give it a callback into itself, do the callback to do the actual initialization, and then unload the second driver. Convoluted, but it works (I used it for a firmware downaload in a GigE driver at one point). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 03:46:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF35F16A4CE for ; Thu, 30 Oct 2003 03:46:32 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1134843FCB for ; Thu, 30 Oct 2003 03:46:30 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfim6.dialup.mindspring.com ([165.247.202.198] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AFBFp-0006Jg-00; Thu, 30 Oct 2003 03:46:17 -0800 Message-ID: <3FA0F9D4.1AA51E73@mindspring.com> Date: Thu, 30 Oct 2003 03:45:24 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Vance References: <3F9CF3F6.8307.ABC1250@localhost> <20031030003153.GC16553@aurema.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d693b2ddcc2cca1b0dfcb9ca420d12e9a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Dan Langille Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 11:46:32 -0000 Christopher Vance wrote: > You can already mark a fd 'close on exec'. > > May I suggest a different feature: the ability to mark an open file > (not just its fd) 'remove on close', with permission checked at mark > time rather than close time (this status forgotten if not permitted > when set) and the unlink actually done at close time only if the file > has exactly one link and one open file instance at that time. If all you have is an fd, you can not get from an fd to a path without an exhaustive search of the disk, in most FS's. Also, leaving the path peresent permits someone to hard-link it to some other file, to make it stay around. Since /var has a /var/tmp, this would be a real danger, I think. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 04:57:50 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 238DE16A4CE; Thu, 30 Oct 2003 04:57:50 -0800 (PST) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FD9943FE0; Thu, 30 Oct 2003 04:57:49 -0800 (PST) (envelope-from hiten@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (hiten@localhost.unixdaemons.com [127.0.0.1])h9UCvliI090302; Thu, 30 Oct 2003 07:57:47 -0500 (EST) Received: (from hiten@localhost) by angelica.unixdaemons.com (8.12.10/8.12.1/Submit) id h9UCvlNc090301; Thu, 30 Oct 2003 07:57:47 -0500 (EST) (envelope-from hiten) Date: Thu, 30 Oct 2003 07:57:47 -0500 From: Hiten Pandya To: Robert Watson Message-ID: <20031030125747.GA38484@unixdaemons.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD i386 X-Public-Key: http://www.pittgoth.com/~hiten/pubkey.asc X-URL: http://www.unixdaemons.com/~hiten X-PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index cc: hackers@freebsd.org Subject: Re: Experimental FreeBSD and Linux kernel source cross reference web site X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 12:57:50 -0000 Robert Watson (Wed, Oct 29, 2003 at 11:18:51PM -0500) wrote: > > In the past when browsing the Linux source code, I've made extensive use > of the Linux Cross-Reference (LXR) hosted at lxr.linux.no. This web site > provides a cross-referenced and searchable HTML interface to the Linux > source code; you can perform freetext and identifier searches, check > differences between revisions, etc. For FreeBSD, we provide a cvsweb > interface that is extremely useful for tracking changes, but a little less > useful for "raw browsing" when you're looking for use of an identifier. In > the past, CMU's PDL (and possibly others) have provided FreeBSD > cross-reference web pages, but I was unable to find one once that site > went down. As such, I've experimentally set up the LXR software with > access to several branches of the FreeBSD source code, as well as 2.4 and > 2.6 Linux kernels at: > > http://fxr.watson.org/ > Thank you very very much! ;-) Atlast, someone got to it. I have been wanting to setup LXR for DragonFly for quite some time now, but did not have enough time on my hands to mess with it. Does it require any sort of patching for it to work on FreeBSD ? I recall it requires MySQL and some other stuff.. Regards, -- Hiten From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 06:42:15 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9155716A4CF for ; Thu, 30 Oct 2003 06:42:15 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDE5943FCB for ; Thu, 30 Oct 2003 06:42:14 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id AF36B3D28 for ; Thu, 30 Oct 2003 09:42:13 -0500 (EST) From: "Dan Langille" To: FreeBSD-hackers@freebsd.org Date: Thu, 30 Oct 2003 09:42:13 -0500 MIME-Version: 1.0 Message-ID: <3FA0DCF5.27646.1A027A88@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: libwrap crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 14:42:15 -0000 I've been tracking down a libwrap call which crashes the application. The crash occurs on line 395 of contrib/tcp_wrappers/options.c, but I have no idea. The situation: - The daemon starts on the remote client. - Connection is attempted from another box via port 9102 - The daemon uses hosts_access(3) to see if the connection is allowed - /etc/hosts.allow contains no explit allow/deny for this connection which means this line is invoked: # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." When the host_acess calls invokes twist_option (contrib/tcp_wrappers/options.c:370), things blow up on this call: (void) execl("/bin/sh", "sh", "-c", value, (char *) 0); Any ideas? Suggestions? Thank you [root@bast:/usr/ports/sysutils/bacula/work/bacula-1.32b/src/filed] # gdb ./bacula-fd GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../con trib/gdb/gdb/dwarf2read.c line 3049 in dwarf2_read_section (gdb) source ~/debug Breakpoint 1 at 0x805a365: file bnet_server.c, line 152. Breakpoint 1, bnet_thread_server (bind_addr=0x0, port=9102, max_clients=10, client_wq=0x807c4a0, handle_client_request=0x804d3c0 ) at bnet_server.c:152 152 fromhost(&request); Current language: auto; currently c++ (gdb) n 153 if (!hosts_access(&request)) { (gdb) s 0x8049cc8 in hosts_access () at /usr/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:126 126 (gdb) /usr/src/lib/libwrap/../../contrib/tcp_wrappers/options.c:395 Undefined command: "". Try "help". (gdb) b /usr/src/lib/libwrap/../../contrib/tcp_wrappers/options.c:395 Breakpoint 2 at 0x280a1766: file /usr/src/lib/libwrap/../../contrib/tcp_wrappers/options.c, line 395. (gdb) c Continuing. Breakpoint 2, twist_option (value=0xbfbfe890 "/bin/echo \"You are not welcome to use bast-fd from undef.unixathome.org.\"", request=0xbfbff574) at /usr/src/lib/libwrap/../../contrib/tcp_wrappers/options.c:395 395 (void) execl("/bin/sh", "sh", "-c", value, (char *) 0); Current language: auto; currently c (gdb) list 390 maybe_dup2(request->fd, 2) != 2) { 391 error = "twist_option: dup: %m"; 392 } else { 393 if (request->fd > 2) 394 close(request->fd); 395 (void) execl("/bin/sh", "sh", "-c", value, (char *) 0); 396 error = "twist_option: /bin/sh: %m"; 397 } 398 399 /* Something went wrong: we MUST terminate the process. */ (gdb) print value $1 = 0xbfbfe890 "/bin/echo \"You are not welcome to use bast-fd from undef.unixathome.org.\"" (gdb) n 0x2809fb4c in _init () from /usr/lib/libwrap.so.3 (gdb) n Single stepping until exit from function _init, which has no line number information. Error accessing memory address 0x281a1e84: Bad address. (gdb -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 07:46:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E44616A4CE for ; Thu, 30 Oct 2003 07:46:44 -0800 (PST) Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74BF843FE9 for ; Thu, 30 Oct 2003 07:46:43 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta11.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031030154645.JYJS24277.mta11.adelphia.net@[10.1.0.9]> for ; Thu, 30 Oct 2003 10:46:45 -0500 From: andi payn To: freebsd-hackers@freebsd.org Content-Type: text/plain Message-Id: <1067528798.36829.2128.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 30 Oct 2003 07:46:38 -0800 Content-Transfer-Encoding: 7bit Subject: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 15:46:44 -0000 As far as I can tell, FreeBSD doesn't have anything equivalent to linux's O_NOACCESS (which is not in any of the standard headers, but it's equal to O_WRONLY | O_RDWR, or O_ACCMODE). In linux, this can be used to say, "give me an fd for this file, but don't try to open it for reading or writing or anything else." This allows you to get an fd to pass to fcntl (e.g., for dnotify), or call ioctl's on, etc.--even if you don't have either read or write access to the file. The obvious question is, "Why should this ever be allowed?" Well, if you can stat the file, why can't you, e.g., ask kevent to monitor it? In FreeBSD, this doesn't work; you just get EINVAL. Having O_NOACCESS would be useful for the fam port, for porting pieces of lilo, and probably for other things I haven't thought of yet. (I believe that either this was added to linux to support lilo, or the open syscall just happened to work this way, and once the lilo developers discovered this and took advantage of it, it's been retained that way ever since to keep lilo working.) On the other hand, BSD has done without it for many years, and there's probably a good reason it's never been added. So, what is that good reason? I don't think there's a backwards-compatibility issue. The open(2) manpage specifies that EINVAL will be returned if "An attempt was made to open a descriptor with an illegal combination of O_RDONLY, O_WRONLY, and O_RDWR." However, it doesn't specify what constitutes an illegal combination--and nowhere does it say that exactly one of the three must be specified. (Interestingly, the manpage on my Mandrake 9.1 box _does_ say that exactly one must be specified, which is not true in linux....) While a reader would be unlikely to assume that "O_WRONLY | O_RDWR" means "open for no access," I can't imagine many programs rely on the fact that this combination returns an error. If there is such an issue, well, there are other flag bits left unused (3 in the low 16 bits, plus 15 in the high 16 bits); if not, it would probably be nicer to use the same value as linux. Meanwhile, as mentioned above, doesn't define O_NOACCESS in any of the standard header files (IIRC, programs that use it--like lilo--explicitly #define it as 3, or O_WRONLY | O_RDWR, or O_ACCMODE), and it's not documented in the man pages. I think that, if it's added to FreeBSD, it should be added in a cleaner and better-documented way. Anyway, would a patch to add this feature be considered? And if so, does anyone have any input into questions like whether O_NOACCESS should be 3 as it is in linux or use some unused flag bit instead, whether it should be defined in fcntl.h or elsewhere, etc.? Thanks. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 07:54:11 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EB2A16A4CE for ; Thu, 30 Oct 2003 07:54:11 -0800 (PST) Received: from mta8.adelphia.net (mta8.adelphia.net [68.168.78.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 630BB43F85 for ; Thu, 30 Oct 2003 07:54:10 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta8.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031030155412.XIWF28250.mta8.adelphia.net@[10.1.0.9]> for ; Thu, 30 Oct 2003 10:54:12 -0500 From: andi payn To: freebsd-hackers@freebsd.org Content-Type: text/plain Message-Id: <1067529247.36829.2138.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 30 Oct 2003 07:54:07 -0800 Content-Transfer-Encoding: 7bit Subject: kevent and related stuff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 15:54:11 -0000 First, let me mention that I'm not nearly as experienced coding for *BSD as for linux, so I may ask some stupid questions. I've been looking at the fam port, and this has brought up a whole slew of questions. I'm not sure if all of them are appropriate to this list, but I don't know who else to ask, so.... First, some background: On Irix and Linux, fam works by asking the kernel to send it a signal whenever the specified accesses occur. On FreeBSD, since there is no imon interface and no dnotify fcntl, it instead works by periodically stating all of the files it's watching--which is obviously not as good. The fam FAQ suggests that FreeBSD users should adapt fam to use the kevent interface. I looked into kevent, and it seems like there are a number of problems that lead me to suspect that this is a really stupid idea. And yet, I'd assume that someone on the fam team at SGI and/or one of the outside fam developers would know FreeBSD at least as well as me. Therefore, I'm guessing I'm missing something here. So, any ideas anyone can offer would be very helpful. So, here's the questions I have: * I think (but I'm not sure) that kevent doesn't notify at all if the only change to a file is its ATIME. If I'm right, this makes kevent completely useless for fam. Adding a NOTE_ACCESS or something similar would fix this. Since I'm pretty new to FreeBSD: What process do I go through to figure out whether anyone else wants this, whether the interface I've come up with is acceptable, etc.? And, once I write the code, do I submit it as a pr? * The kevent mechanism doesn't monitor directories in a sufficient way to make fam happy. If you change a file in a directory that you're watching, unlike imon or dnotify, kevent won't see anything worth reporting at all. This means that for directory monitoring, kevent is useless as-is. Again, if I wanted to patch kevent to provide this additional notification, would others want this? * When two equivalent events appear in the queue, kevent aggregates them. This means that if there are two updates to a file since the last time you checked, you'll only see the most recent one. For some uses of fam (keeping a folder window up to date), this is what you want; for others (keeping track of how often a file is read), this is useless. The only solution I can think of is to add an additional flag, or some other way to specify that you want duplicated events. * Unlike imon and dnotify, kevent doesn't provide any kind of callback mechanism; instead, you have to poll the queue for events. Would it be useful to specify another flag/parameter that would tell the kernel to signal the monitoring process whenever an event is available? (It would certainly make the fam code easier to write--but if it's not useful anywhere else, that's probably not enough.) * The kevent vnode stuff apparently only works on UFS. And it looks like it would be a major project to port it to other filesystems. Would this be useful for anything other than improving fam? What about a port of the imon kernel interface (and/or the dnotify fcntl) to FreeBSD instead? * The kqueue doesn't appear to have any maximum size. If this is true, the dnotify/fam problem where you get hideous errors from overflowing queues wouldn't be an issue, but you could instead end up wasting massive amounts of memory in the kernel if you didn't get around to reading the queue.... Which is it? Any answers, or pointers to where I can find these answers, would be greatly appreciated. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 08:29:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EAAA16A4CE for ; Thu, 30 Oct 2003 08:29:09 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D3CB43FCB for ; Thu, 30 Oct 2003 08:29:08 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h9UGT7JA003976; Thu, 30 Oct 2003 10:29:07 -0600 (CST) (envelope-from dan) Date: Thu, 30 Oct 2003 10:29:07 -0600 From: Dan Nelson To: Isaac Gelado Message-ID: <20031030162907.GB10973@dan.emsphone.com> References: <3F9FAE4D.3020500@tid.es> <20031029162447.GE2284@dan.emsphone.com> <3FA0C064.102@tid.es> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3FA0C064.102@tid.es> X-OS: FreeBSD 5.1-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: POSIX Threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 16:29:09 -0000 In the last episode (Oct 30), Isaac Gelado said: > Dan Nelson escribió: > >In the last episode (Oct 29), Isaac Gelado said: > >>This schema is working correctly in a linux machine, so when a > >>packet is captured an CORBA event is sent to clients. But, when the > >>server is running under FreeBSD 5.0, the handle function isn't > >>executed when a packet is received. In FreeBSD the handle function > >>is executed, for each packet, after certain time (maybe when the > >>buffer of PCapLib is full), which is a problem because it sends > >>events too fast to clients so the CORBA event service fails. > > > >When you called pcap_open_live, what timeout did you set? > > > I set it to 0, so PCapLib should return the packet inmediatly. > > Can the problem be in the PCapLib implementation? Are you sure 0 means "return immediately"? I think it might mean "Wait forever until the buffer fills". Try a very small timeout value. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 09:01:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F25BB16A4CE for ; Thu, 30 Oct 2003 09:01:04 -0800 (PST) Received: from mail.gulfgate-inc.com (mail.gulfgate-inc.com [64.1.98.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5591E43FA3 for ; Thu, 30 Oct 2003 09:01:02 -0800 (PST) (envelope-from m@beatlab.org) Received: (qmail 54323 invoked by uid 85); 30 Oct 2003 17:13:23 -0000 Received: from m@beatlab.org by linkdead.beatlab.org by uid 89 with qmail-scanner-1.15 (uvscan: v4.1.60/v4248. spamassassin: 2.x. Clear:. Processed in 0.933173 secs); 30 Oct 2003 17:13:23 -0000 Received: from unknown (HELO ns.gulfgate-inc.com) (64.1.98.182) by mail.gulfgate-inc.com with SMTP; 30 Oct 2003 17:13:22 -0000 From: Matt Freitag Date: Thu, 30 Oct 2003 17:01:33 GMT Message-ID: <20031030.17013300.1344636222@ns.gulfgate-inc.com> To: andreas@freebsd.org X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-hackers@freebsd.org Subject: Re: how to monitor remote users X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 17:01:05 -0000 On Wed, Oct 29, 2003 at 3:01 AM, Andreas Klemm wrote: > Is there a freebsd tool that shows you in realtime, which users > are logged in from remote using which pty port ? > > So to say something like > while true > do > clear; w; sleep 10 > done > > Preferable as X11 application. > The closest thing to my knowledge, would probably be "whowatch" which resides in /usr/ports/sysutils/whowatch. It doesn't allow you to click on the user to spawn a watch session, but = I doubt it'd be too difficult to add such functionality if you so desired.= Regards, -mpf From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 09:11:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F7E916A4CE for ; Thu, 30 Oct 2003 09:11:40 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03F4343FBD for ; Thu, 30 Oct 2003 09:11:39 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id h9UHAOMg062904; Thu, 30 Oct 2003 12:10:24 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h9UHAN70062901; Thu, 30 Oct 2003 12:10:24 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 30 Oct 2003 12:10:23 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Hiten Pandya In-Reply-To: <20031030125747.GA38484@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: Experimental FreeBSD and Linux kernel source cross reference web site X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 17:11:40 -0000 On Thu, 30 Oct 2003, Hiten Pandya wrote: > Thank you very very much! ;-) > > Atlast, someone got to it. I have been wanting to setup LXR for > DragonFly for quite some time now, but did not have enough time > on my hands to mess with it. Does it require any sort of > patching for it to work on FreeBSD ? I recall it requires MySQL > and some other stuff.. I'm actually using an older version of the lxr software, 0.3.1, which doesn't make use of a back-end SQL database, rather, some simple db-based data stores and glimpse for searches. It was a lot easier to set up, once I fixed some rather critical bugs :-). I've gone ahead and dropped a snapshot of the DFBSD sys tree on fxr as well, and am currently cvsuping opendarwin source to drop a recent snapshot of xnu. I'm not sure if there are any DFBSD tags worth using other than HEAD, so I just used a timestamp for the checkout. The rearrangement of the DFBSD tree makes diffing between FreeBSD and DFBSD bits a little more difficult, but in many cases it's fairly feasible. I've been trying to decide how to improve diffability between the FreeBSD and Darwin trees: most FreeBSD bits compare directly with xnu/bsd/..., not xnu/..., and lxr isn't very flexible about how it sets up diff comparisons. I've also noticed that lxr is currently unwilling to index macros as identifiers when they're generated at compile-time, which means (for example) that you have to use freetext searches to find vnode operation macro use. I'm not sure how much more time I'm willing to invest in further refining lxr itself, but I'll keep the source code snapshots up-to-date and bring in new sources of kernel source code as appropriate. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 10:39:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 687AC16A4CE; Thu, 30 Oct 2003 10:39:14 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8933143FDF; Thu, 30 Oct 2003 10:39:13 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.10/8.12.9) with ESMTP id h9UIdB8j032649; Thu, 30 Oct 2003 13:39:11 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Thu, 30 Oct 2003 13:39:10 -0500 To: Robert Watson , hackers@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Experimental FreeBSD and Linux kernel source cross reference web site X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 18:39:14 -0000 At 11:18 PM -0500 10/29/03, Robert Watson wrote: >In the past when browsing the Linux source code, I've made >extensive use of the Linux Cross-Reference (LXR) hosted at >lxr.linux.no. >For FreeBSD, we provide a cvsweb interface that is extremely >useful for tracking changes, but a little less useful for >"raw browsing" when you're looking for use of an identifier. >In the past, CMU's PDL (and possibly others) have provided >FreeBSD cross-reference web pages, but I was unable to find >one once that site went down. How about http://snapshots.jp.FreeBSD.org/tour/ ? That's what I have used from time-to-time, when on a random goose chase for various variables... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 11:28:51 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD43616A4CE for ; Thu, 30 Oct 2003 11:28:51 -0800 (PST) Received: from mail-pm.star.spb.ru (mail-pm.star.spb.ru [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 313FC43FB1 for ; Thu, 30 Oct 2003 11:28:50 -0800 (PST) (envelope-from nkritsky@star-sw.com) Received: from pink.star.spb.ru ([217.195.82.10]) by mail-pm.star.spb.ru (8.12.10/8.12.10) with ESMTP id h9UJSmwk029307 for ; Thu, 30 Oct 2003 22:28:48 +0300 (MSK) Received: from IBMKA ([217.195.82.7]) by pink.star.spb.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VTP9JZX6; Thu, 30 Oct 2003 22:28:48 +0300 Date: Thu, 30 Oct 2003 22:29:28 +0300 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <133488034726.20031030222928@star-sw.com> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: stupid C language question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 19:28:51 -0000 Hello freebsd-hackers, My fellow freebsd-hackers! I ran ino minor problem here. I am currently debugging some part of FreeBSD bridging/vlan'ing kernel code. Every N minutes I want to add some debugging printf's in kernel or remove some previously installed. And now - a stupid question! When I change some .c files in src/sys/net directory, do I need to do 'make depend && make kernel' or I can just 'make kernel'? System is 4.8-p3. Any help is very good, and please cc: me in your replies as I am not subscribed to this list. PS: I wish you good luck in your hacking. PPS: I heard about 10th FreeBSD bithday - receive my congratulations, gluckwunschen and all that! Thanks again. -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 11:40:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5436116A4CE for ; Thu, 30 Oct 2003 11:40:55 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 702A143FE0 for ; Thu, 30 Oct 2003 11:40:54 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h9UJer8i001255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2003 14:40:53 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id h9UJeriv001254 for freebsd-hackers@freebsd.org; Thu, 30 Oct 2003 14:40:53 -0500 (EST) Date: Thu, 30 Oct 2003 14:40:53 -0500 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031030194053.GA862@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: 5.x kernel config changes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 19:40:55 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I just built my first 5.1-RELEASE box requiring a custom kernel, and noticed some interesting things. 1) It appears IPFW just works (eg, configure it in /etc/rc.conf). It used to be you had to compile it in. What's interesting to me is that IPFW options are not in generic, and I didn't think "options" could be done in LKM's. What am I missing? 2) IPDIVERT is missing / doesn't work, so while my IPFW config seemed=20 to take/work natd did not work. If IPFW is just going to work having IPDIVERT just work seems like a good idea as well. 3) There seems to be no more LINT or other listing of all the options. Why? In particular I needed "options NETATALK" but couldn't remember the name and there was no file to quickly grep. Has the list of=20 options been moved somewhere else? 4) Due to the way the makefiles now work it seems impossible to build a new kernel after changing just "options" statements and install it without also rebuilding all the modules...which takes quite some time. This seems to be because it moves the whole directory out of the way in /boot. This seems a little suboptimal to me. --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/oWlFNh6mMG5yMTYRAqQEAKCAL7rgo3ZDD6iNvEeOzCtgVdhiDACeKpJX n1pQ2L+tflEpLS0GGCFg/ck= =8fXx -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 11:54:54 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B484C16A4CE for ; Thu, 30 Oct 2003 11:54:54 -0800 (PST) Received: from mail-pm.star.spb.ru (mail-pm.star.spb.ru [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8311A43F75 for ; Thu, 30 Oct 2003 11:54:53 -0800 (PST) (envelope-from nkritsky@star-sw.com) Received: from pink.star.spb.ru ([217.195.82.10]) by mail-pm.star.spb.ru (8.12.10/8.12.10) with ESMTP id h9UJsowk038218; Thu, 30 Oct 2003 22:54:50 +0300 (MSK) Received: from IBMKA ([217.195.82.7]) by pink.star.spb.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VTP9JZZR; Thu, 30 Oct 2003 22:54:49 +0300 Date: Thu, 30 Oct 2003 22:55:30 +0300 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <123489596332.20031030225530@star-sw.com> To: Tim Kientzle In-reply-To: <3FA16A66.2020407@acm.org> References: <133488034726.20031030222928@star-sw.com> <3FA16A66.2020407@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re[2]: stupid C language question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 19:54:54 -0000 Hello Tim & -hackers, zillion thanks to all who answered. Now I think that I understand :) Thursday, October 30, 2003, 10:45:42 PM, you wrote: TK> Nickolay A. Kritsky wrote: >> When >> I change some .c files in src/sys/net directory, do I need to do 'make >> depend && make kernel' or I can just 'make kernel'? TK> You should only need to 'make depend' if you change TK> the dependencies, for example, if you add or remove TK> a #include somewhere. TK> Usually, 'make kernel' suffices. -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 11:55:56 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA7AA16A4D3 for ; Thu, 30 Oct 2003 11:55:56 -0800 (PST) Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B09FA43FAF for ; Thu, 30 Oct 2003 11:55:55 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 26682 invoked from network); 30 Oct 2003 19:55:54 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 30 Oct 2003 19:55:54 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h9UJtpce039635; Thu, 30 Oct 2003 14:55:51 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031030194053.GA862@ussenterprise.ufp.org> Date: Thu, 30 Oct 2003 14:55:50 -0500 (EST) From: John Baldwin To: Leo Bicknell X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-hackers@freebsd.org Subject: RE: 5.x kernel config changes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 19:55:57 -0000 On 30-Oct-2003 Leo Bicknell wrote: > > I just built my first 5.1-RELEASE box requiring a custom kernel, and > noticed some interesting things. > > 1) It appears IPFW just works (eg, configure it in /etc/rc.conf). It > used to be you had to compile it in. What's interesting to me is > that IPFW options are not in generic, and I didn't think "options" > could be done in LKM's. What am I missing? It's loaded from the ipfw.ko module. You can build modules for some things that are compiled in using 'options'. > 2) IPDIVERT is missing / doesn't work, so while my IPFW config seemed > to take/work natd did not work. If IPFW is just going to work having > IPDIVERT just work seems like a good idea as well. You will probably need to just include IPFW and IPDIVERT in your kernel config for this to work. > 3) There seems to be no more LINT or other listing of all the options. > Why? In particular I needed "options NETATALK" but couldn't remember > the name and there was no file to quickly grep. Has the list of > options been moved somewhere else? sys/conf/NOTES and sys//conf/NOTES > 4) Due to the way the makefiles now work it seems impossible to build a > new kernel after changing just "options" statements and install it > without also rebuilding all the modules...which takes quite some > time. This seems to be because it moves the whole directory out of > the way in /boot. This seems a little suboptimal to me. You can add 'makeoptions NO_MODULES=yes' to your kernel config to have it only build a kernel and no modules. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 11:56:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33D8E16A4CE for ; Thu, 30 Oct 2003 11:56:08 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCFC43F85 for ; Thu, 30 Oct 2003 11:56:07 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h9UJu3ip006274 for ; Thu, 30 Oct 2003 11:56:03 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h9UJu3ws006272 for freebsd-hackers@freebsd.org; Thu, 30 Oct 2003 11:56:03 -0800 Date: Thu, 30 Oct 2003 11:56:02 -0800 From: Brooks Davis To: freebsd-hackers@freebsd.org Message-ID: <20031030195602.GA3185@Odin.AC.HMC.Edu> References: <20031030194053.GA862@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20031030194053.GA862@ussenterprise.ufp.org> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Subject: Re: 5.x kernel config changes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 19:56:08 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 30, 2003 at 02:40:53PM -0500, Leo Bicknell wrote: >=20 > 3) There seems to be no more LINT or other listing of all the options. > Why? In particular I needed "options NETATALK" but couldn't remember > the name and there was no file to quickly grep. Has the list of=20 > options been moved somewhere else? sys/conf/NOTES + sys//conf/NOTES > 4) Due to the way the makefiles now work it seems impossible to build a > new kernel after changing just "options" statements and install it > without also rebuilding all the modules...which takes quite some > time. This seems to be because it moves the whole directory out of > the way in /boot. This seems a little suboptimal to me. You can still use the old way of building kernels when you aren't updating the world. You can also use the reinstall target in conjunction with -DNO_MODULES to just reinstall the kernel. If you just want to change some options and you still want to use the new way, the unsupported workaround is: make -DNOCLEAN buildkernel It still configured the kernel and does a "make depend", but it won't delete the object files which speeds things up a lot. It does fail from time to time though so be sure to try without -DNOCLEAN before reporting breakage. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/oWzRXY6L6fI4GtQRAmESAJ94s/Fg0PSuThfyPuS83aXCU9IkCQCfZkO6 0MGho2npSCMXEsZhS6yUAgE= =ju9g -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 12:01:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF99316A4CE for ; Thu, 30 Oct 2003 12:01:40 -0800 (PST) Received: from isis.telemach.net (isis.telemach.net [213.143.65.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD9C743F3F for ; Thu, 30 Oct 2003 12:01:37 -0800 (PST) (envelope-from rp@telemach.net) Received: by isis.telemach.net (Postfix, from userid 1002) id B12CD7A142; Thu, 30 Oct 2003 21:01:25 +0100 (CET) Date: Thu, 30 Oct 2003 21:01:25 +0100 From: "(rp)" To: freebsd-hackers@freebsd.org Message-ID: <20031030200125.GA55692@isis.telemach.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: make_dev & cdevsw_add (Is there anyone that could answer this ?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 20:01:41 -0000 Hello (again)! I would kindly request explanation on how are cdevsw_add and make_dev related ? Maybe short example also with focus on cdevsw_add. Thing is i do not understand the function of cdevsw_add when i have make_dev. Also if there is any real good document that describes most of cdev related stuff i would appriciate if someone gives me an url. Second thing that i would like to know is: struct cdevsw { d_open_t *d_open; When a process calls open on character device and d_open function is called would it be possible to determine the file descriptor returned by the open system call on that device that is returned to the process from d_open ? That is i would like to implement character device that wouldn't require /dev/somedev[0-9]+ number of devices but only /dev/somedev and would identify the open/close/ read/write operations by pid and fd instead of dev_t's minor number. re RP From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 12:02:49 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8728F16A4CE for ; Thu, 30 Oct 2003 12:02:49 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E97043FE3 for ; Thu, 30 Oct 2003 12:02:48 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h9UK2m8i002490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2003 15:02:48 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id h9UK2mTK002489 for freebsd-hackers@FreeBSD.org; Thu, 30 Oct 2003 15:02:48 -0500 (EST) Date: Thu, 30 Oct 2003 15:02:47 -0500 From: Leo Bicknell To: freebsd-hackers@FreeBSD.org Message-ID: <20031030200247.GB862@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@FreeBSD.org References: <20031030194053.GA862@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline In-Reply-To: Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: Re: 5.x kernel config changes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 20:02:49 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Thu, Oct 30, 2003 at 02:55:50PM -0500, John Baldwin= wrote: > > 3) There seems to be no more LINT or other listing of all the options. > > Why? In particular I needed "options NETATALK" but couldn't remember > > the name and there was no file to quickly grep. Has the list of=20 > > options been moved somewhere else? >=20 > sys/conf/NOTES and sys//conf/NOTES I'll reply to this message although I got this from three other people privately. All pointed me towards /usr/src/UPDATING, and for reference: 20000621: Scott Flatman sent in a decent write-up on the config file update procedure. http://people.freebsd.org/~imp/config-upd.html NOTE: LINT is gone. It has been replaced with NOTES. NOTES isn't buildable. However, you can generate a LINT file: cd /sys//conf && make LINT So I looked in sys/i386/conf/NOTES which, well, had nothing of interest in it. Turns out the things I needed are in sys/conf/NOTES since it has been split. Someone with a commit bit should update the comment in UPDATING to say NOTES is now in two parts as well. :) Other than that, thanks much, I'm off to be a happy 5.x user now. --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --l76fUT7nc3MelDdI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/oW5nNh6mMG5yMTYRAs45AJwMGgA+7BvbyISfK11WGdC4KfFEoQCfUDcY pHPP83qxyghInAPMOkI/nUk= =hOKn -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 12:19:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 915E116A4CE for ; Thu, 30 Oct 2003 12:19:06 -0800 (PST) Received: from www.kjkoster.org (213-84-106-195.adsl.xs4all.nl [213.84.106.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id B30F143FDF for ; Thu, 30 Oct 2003 12:19:02 -0800 (PST) (envelope-from kjkoster@kjkoster.org) Received: from kjkoster.org (LikeEver [192.168.0.1]) by www.kjkoster.org (8.12.9p2/8.12.9) with ESMTP id h9UKIxuO040998 for ; Thu, 30 Oct 2003 21:19:00 +0100 (CET) (envelope-from kjkoster@kjkoster.org) Sender: kjkoster@www.kjkoster.org Message-ID: <3FA1803E.29807096@kjkoster.org> Date: Thu, 30 Oct 2003 22:18:54 +0100 From: Kees Jan Koster X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: FreeBSD Hackers mailing list References: <3F8D41CB.F4309999@kjkoster.org> <20031023055137.V59330@hamish.internode.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Crash 4.9-RC during heavy I/O, crashdump available. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 20:19:06 -0000 Dear All, > > *snip crash details* > So... Uhm... Anyone? I have gotten only one reply so far, from someone who says he's seen the same thing. Is there anyone who can help me get more details on what is happening? I have no experience with crashdumps and I will need a few pointers as to what I should be looking for. Yours, Kees Jan --------------------------------------------------------------- Kees Jan Koster e-mail: kjkoster "at" kjkoster.org www: http://www.kjkoster.org/ --------------------------------------------------------------- Life is uncertain; eat dessert first. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 12:47:48 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1266416A4CE for ; Thu, 30 Oct 2003 12:47:48 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6613E43FE0 for ; Thu, 30 Oct 2003 12:47:47 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id C39CA3D28 for ; Thu, 30 Oct 2003 15:47:46 -0500 (EST) From: "Dan Langille" To: freeBSD-hackers@freebsd.org Date: Thu, 30 Oct 2003 15:47:46 -0500 MIME-Version: 1.0 Message-ID: <3FA132A2.17071.1B512CC3@localhost> Priority: normal In-reply-to: <3FA0DCF5.27646.1A027A88@localhost> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: libwrap crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 20:47:48 -0000 On 30 Oct 2003 at 9:42, Dan Langille wrote: > I've been tracking down a libwrap call which crashes the application. > The crash occurs on line 395 of contrib/tcp_wrappers/options.c, but > I have no idea. I've been given some help in this offline. Apparently, the bacula code is incorrectly using hosts_access. bacula should fork before it calls hosts_access because hosts_access will kill you on twist. Otherwise, you'll get either a deny or an allowed, and the thread continue from here. My offline helper was comparing the inetd source code. I can't find any reference in host_options(5) or host_access(3) which point to the correct usage. Is the FreeBSD documentation incomplete? Is there a more accurate documentation I can point the bacula developers to? FYI: The bacula approach is said to work under Linux and Solaris but I have yet to run my reproducible tests on those platforms. Thank you. -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 15:36:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21F3F16A4D6 for ; Thu, 30 Oct 2003 15:36:46 -0800 (PST) Received: from smtp.sw.oz.au (alt.aurema.com [203.217.18.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5273F43FCB for ; Thu, 30 Oct 2003 15:36:44 -0800 (PST) (envelope-from vance@aurema.com) Received: from smtp.sw.oz.au (localhost [127.0.0.1]) by smtp.sw.oz.au with ESMTP id h9UNagQg024179; Fri, 31 Oct 2003 10:36:42 +1100 (EST) Received: (from vance@localhost) by smtp.sw.oz.au id h9UNaf4O024174; Fri, 31 Oct 2003 10:36:41 +1100 (EST) Date: Fri, 31 Oct 2003 10:36:41 +1100 From: Christopher Vance To: Terry Lambert Message-ID: <20031030233641.GA14427@aurema.com> References: <3F9CF3F6.8307.ABC1250@localhost> <20031030003153.GC16553@aurema.com> <3FA0F9D4.1AA51E73@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3FA0F9D4.1AA51E73@mindspring.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: freebsd-hackers@freebsd.org cc: Dan Langille Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 23:36:46 -0000 On Thu, Oct 30, 2003 at 03:45:24AM -0800, Terry Lambert wrote: >Christopher Vance wrote: >> You can already mark a fd 'close on exec'. >> >> May I suggest a different feature: the ability to mark an open file >> (not just its fd) 'remove on close', with permission checked at mark >> time rather than close time (this status forgotten if not permitted >> when set) and the unlink actually done at close time only if the file >> has exactly one link and one open file instance at that time. > >If all you have is an fd, you can not get from an fd to a path >without an exhaustive search of the disk, in most FS's. I know that, but you're right that it didn't show in my previous mail. If this thing is set at open time, rather than later, you do have a path. I guess for sanity, I would record the name to *node of immediately enclosing directory, name within directory and inode of file. That surely gives you enough at close time to determine whether the file is still where it was and is otherwise unattached. >Also, leaving the path peresent permits someone to hard-link it >to some other file, to make it stay around. Since /var has a >/var/tmp, this would be a real danger, I think. We were originally talking about pid files for root-dropping servers. Assuming there's enough in there for a new still-root server to determine if its predecessor is gone, there's nothing to stop the new server removing the existing file before creating a new one for itself, which won't have bogus links until somebody finds it again. The attacker has a link to a file no longer in use. Is the DOS disk full? Thanks for your comment, and my opportunity to learn from it; there's clearly more thought needed. And I know that the whole idea of setting up things to happen at a later time like this is not particularly in flavour with the rest of Unix. Simpler alternative not requiring kernel changes: program: fork if child setup file drop privs do stuff if parent wait for child remove file The post-fork parent code could be made very simple to audit by execing a program whose sole purpose is the wait/remove. -- Christopher Vance From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 15:47:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5378216A4CE; Thu, 30 Oct 2003 15:47:22 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49A0443FE5; Thu, 30 Oct 2003 15:47:19 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 83FEB6547C; Wed, 29 Oct 2003 22:38:43 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14162-03-2; Wed, 29 Oct 2003 22:38:43 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 207EB6544E; Wed, 29 Oct 2003 22:38:43 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 7ED5828; Wed, 29 Oct 2003 22:38:33 +0000 (GMT) Date: Wed, 29 Oct 2003 22:38:33 +0000 From: Bruce M Simpson To: Andreas Klemm Message-ID: <20031029223833.GD35062@saboteur.dek.spc.org> Mail-Followup-To: Andreas Klemm , freebsd-hackers@freebsd.org References: <20031029090116.GA960@titan.klemm.apsfilter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031029090116.GA960@titan.klemm.apsfilter.org> cc: freebsd-hackers@freebsd.org Subject: Re: how to monitor remote users shell activities best ? watch / snp / ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 23:47:22 -0000 On Wed, Oct 29, 2003 at 10:01:16AM +0100, Andreas Klemm wrote: > Is there a freebsd tool that shows you in realtime, which users > are logged in from remote using which pty port ? Check out the whowatch port. BMS From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 16:00:47 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AAFC16A4CE for ; Thu, 30 Oct 2003 16:00:47 -0800 (PST) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F9AB43FEC for ; Thu, 30 Oct 2003 16:00:46 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta13.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031030235736.PTZO20181.mta13.adelphia.net@[10.1.0.9]> for ; Thu, 30 Oct 2003 18:57:36 -0500 From: andi payn To: freebsd-hackers@freebsd.org In-Reply-To: <1067528798.36829.2128.camel@verdammt.falcotronic.net> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> Content-Type: text/plain Message-Id: <1067558254.36829.2315.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 30 Oct 2003 15:57:35 -0800 Content-Transfer-Encoding: 7bit Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 00:00:47 -0000 On Thu, 2003-10-30 at 07:46, andi payn wrote: > As far as I can tell, FreeBSD doesn't have anything equivalent to > linux's O_NOACCESS (which is not in any of the standard headers, but > it's equal to O_WRONLY | O_RDWR, or O_ACCMODE). In linux, this can be > used to say, "give me an fd for this file, but don't try to open it for > reading or writing or anything else." I've been playing with this. I took out the test for ((flags & O_ACCMODE) == O_ACCMODE) in kern_open (in sys/kern/vfs_syscalls.c), and modified FFLAGS and OFLAGS (in sys/fcntl.h) to wrap around the lower two bits (so 3, O_ACCMODE, becomes 0), then rebuilt everything. Everything seems to work as well as ever--as I expected, since only programs that depend on using open(O_ACCMODE) to get an EINVAL should be surprised. I suppose the slightly-more-complicated FFLAGS and OFLAGS macros is slowing down my system to a some degree, although there's no slowdown that I can tell by normal use, or by running benchmarks. Still, if I knew every place the fflags result was used, it would probably be better to use simpler macros wherever possible (usually the only part you need is FREAD | FWRITE, but not always). However, I haven't yet tested what all of the different vfs modules do when opening or processing a file with !FREAD and !FWRITE. I also haven't tested actually using O_ACCMODE yet--to see if I can get an fd for a file I have no access to, verify that it won't let me read or write on that fd, make sure I'm allowed to close it, etc. Can anyone think of anything I should expect to go wrong? Or, more important, anything I should test that I seem to have missed? Meanwhile, I've been looking into where this is used in linux, and other than internally (for symlinks), it seems like opening with neither read nor write access is only used by lilo (and lilo also does all kinds of other weird things--like opening with mode -1 for passthrough). I thought the dnotify utility or the fam dnotify patch would do this (anything you can stat, you should be able to monitor), but I was wrong. So maybe this isn't a very useful feature anyway. On the other hand, just because the dnotify patch for fam doesn't take advantage of it doesn't mean a kqueue patch for fam shouldn't.... From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 16:36:42 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE3D316A4CF for ; Thu, 30 Oct 2003 16:36:42 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B927443FDF for ; Thu, 30 Oct 2003 16:36:39 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9V0abE7049767; Thu, 30 Oct 2003 17:36:38 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 30 Oct 2003 17:36:34 -0700 (MST) Message-Id: <20031030.173634.100118443.imp@bsdimp.com> To: nkritsky@star-sw.com From: "M. Warner Losh" In-Reply-To: <133488034726.20031030222928@star-sw.com> References: <133488034726.20031030222928@star-sw.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: stupid C language question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 00:36:42 -0000 In message: <133488034726.20031030222928@star-sw.com> "Nickolay A. Kritsky" writes: : My fellow freebsd-hackers! I ran ino minor problem here. I am : currently debugging some part of FreeBSD bridging/vlan'ing kernel : code. Every N minutes I want to add some debugging printf's in kernel : or remove some previously installed. And now - a stupid question! When : I change some .c files in src/sys/net directory, do I need to do 'make : depend && make kernel' or I can just 'make kernel'? System is 4.8-p3. : Any help is very good, and please cc: me in your replies as I am not : subscribed to this list. If you've already done one make depend, you don't need to do another until you update your sources, or add new .h dependencies. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 16:37:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F06416A4CE for ; Thu, 30 Oct 2003 16:37:19 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B34A43F85 for ; Thu, 30 Oct 2003 16:37:18 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9V0bGE7049790; Thu, 30 Oct 2003 17:37:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 30 Oct 2003 17:37:13 -0700 (MST) Message-Id: <20031030.173713.35610796.imp@bsdimp.com> To: bicknell@ufp.org From: "M. Warner Losh" In-Reply-To: <20031030194053.GA862@ussenterprise.ufp.org> References: <20031030194053.GA862@ussenterprise.ufp.org> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: 5.x kernel config changes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 00:37:19 -0000 In message: <20031030194053.GA862@ussenterprise.ufp.org> Leo Bicknell writes: : 4) Due to the way the makefiles now work it seems impossible to build a : new kernel after changing just "options" statements and install it : without also rebuilding all the modules...which takes quite some : time. This seems to be because it moves the whole directory out of : the way in /boot. This seems a little suboptimal to me. make NO_MODULES=t Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 16:38:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 881AF16A4CF for ; Thu, 30 Oct 2003 16:38:02 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41E8043FEA for ; Thu, 30 Oct 2003 16:38:01 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9V0bxE7049793; Thu, 30 Oct 2003 17:37:59 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 30 Oct 2003 17:37:56 -0700 (MST) Message-Id: <20031030.173756.127525223.imp@bsdimp.com> To: bicknell@ufp.org From: "M. Warner Losh" In-Reply-To: <20031030194053.GA862@ussenterprise.ufp.org> References: <20031030194053.GA862@ussenterprise.ufp.org> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: 5.x kernel config changes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 00:38:02 -0000 In message: <20031030194053.GA862@ussenterprise.ufp.org> Leo Bicknell writes: : 3) There seems to be no more LINT or other listing of all the options. : Why? In particular I needed "options NETATALK" but couldn't remember : the name and there was no file to quickly grep. Has the list of : options been moved somewhere else? cd i386/conf make LINT There's a notes file that lint is now generated from. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 19:47:10 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE47916A4CE for ; Thu, 30 Oct 2003 19:47:10 -0800 (PST) Received: from mail.npubs.com (mail.zoneseven.net [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2413243FA3 for ; Thu, 30 Oct 2003 19:47:10 -0800 (PST) (envelope-from nielsen@memberwebs.com) Resent-Message-Id: From: Nielsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christopher Vance , freebsd-hackers@freebsd.org References: <3F9CF3F6.8307.ABC1250@localhost> <20031030003153.GC16553@aurema.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20031031034719.1CE445A3C88@mail.npubs.com> Resent-Date: Fri, 31 Oct 2003 03:47:19 +0000 (GMT) Resent-From: nielsen@memberwebs.com (Postfix Filters) Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 31 Oct 2003 03:47:10 -0000 X-List-Received-Date: Fri, 31 Oct 2003 03:47:10 -0000 Christopher Vance wrote: > May I suggest a different feature: the ability to mark an open file > (not just its fd) 'remove on close', with permission checked at mark > time rather than close time (this status forgotten if not permitted > when set) and the unlink actually done at close time only if the file > has exactly one link and one open file instance at that time. WinNT (2K etc...) has this capability. Not saying that this makes it a good idea though. Nate From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 23:31:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19EEF16A4CE for ; Thu, 30 Oct 2003 23:31:06 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20D2A43FD7 for ; Thu, 30 Oct 2003 23:31:04 -0800 (PST) (envelope-from andreas@klemm.apsfilter.org) Received: from srv1.cosmo-project.de (localhost [IPv6:::1]) h9V7UGt2064303 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 31 Oct 2003 08:30:18 +0100 (CET) (envelope-from andreas@klemm.apsfilter.org) Received: (from uucp@localhost)h9V7UFrc064302; Fri, 31 Oct 2003 08:30:15 +0100 (CET) (envelope-from andreas@klemm.apsfilter.org) Received: from titan.klemm.apsfilter.org (localhost.klemm.apsfilter.org [127.0.0.1]) by klemm.apsfilter.org (8.12.10/8.12.9) with ESMTP id h9V7REas018317; Fri, 31 Oct 2003 08:27:18 +0100 (CET) (envelope-from andreas@titan.klemm.apsfilter.org) Received: (from andreas@localhost)h9V7R4pd018316; Fri, 31 Oct 2003 08:27:04 +0100 (CET) (envelope-from andreas) Date: Fri, 31 Oct 2003 08:27:04 +0100 From: Andreas Klemm To: freebsd-hackers@freebsd.org Message-ID: <20031031072704.GA16466@titan.klemm.apsfilter.org> References: <20031030.17013300.1344636222@ns.gulfgate-inc.com> <20031029090116.GA960@titan.klemm.apsfilter.org> <20031029223833.GD35062@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031030.17013300.1344636222@ns.gulfgate-inc.com> <20031029223833.GD35062@saboteur.dek.spc.org> X-Operating-System: FreeBSD 5.1-CURRENT X-Disclaimer: A free society is one where it is safe to be unpopular User-Agent: Mutt/1.5.4i cc: Matt Freitag Subject: Re: how to monitor remote users shell activities best ? watch / snp / ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 07:31:06 -0000 On Wed, Oct 29, 2003 at 10:38:33PM +0000, Bruce M Simpson wrote: > Check out the whowatch port. On Thu, Oct 30, 2003 at 05:01:33PM +0000, Matt Freitag wrote: > The closest thing to my knowledge, would probably be "whowatch" > which resides in /usr/ports/sysutils/whowatch. > It doesn't allow you to click on the user to spawn a watch session, but I > doubt it'd be too difficult to add such functionality if you so desired. Thanks a lot for the answers. I had a look at whowatch, is a nice tool. I did it with multiple windows. Whowatch actually had saved me one window with the while loop of "w" every 10 seconds to look for new tty sessions. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? -> http://www.apsfilter.org/ From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 01:21:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38BFA16A4CE for ; Fri, 31 Oct 2003 01:21:06 -0800 (PST) Received: from firecrest.mail.pas.earthlink.net (firecrest.mail.pas.earthlink.net [207.217.121.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 769C843FBD for ; Fri, 31 Oct 2003 01:21:05 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfje9.dialup.mindspring.com ([165.247.205.201] helo=mindspring.com) by firecrest.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AFVSo-0006b1-00; Fri, 31 Oct 2003 01:21:03 -0800 Message-ID: <3FA22930.C6EC97A9@mindspring.com> Date: Fri, 31 Oct 2003 01:19:44 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: andi payn References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4015b3cb0a6b97a907c432b5b396dfc5fa2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 09:21:06 -0000 andi payn wrote: > As far as I can tell, FreeBSD doesn't have anything equivalent to > linux's O_NOACCESS (which is not in any of the standard headers, but > it's equal to O_WRONLY | O_RDWR, or O_ACCMODE). In linux, this can be > used to say, "give me an fd for this file, but don't try to open it for > reading or writing or anything else." The standard does not permit this. First off, O_ACCMODE is a bitmask, and is guaranteed to be inclusive of the bits for O_RDONLY, O_WRONLY, and O_RDWR, but *not* guaranteed to not be inclusive of additional bits, reserved or locally defined but outside the _POSIX_SOURCE namespace. By using this value as a parameter, you could very well be setting many more bits, and you could be setting bits for local implementation options that you really, really do not want to set. Second, the standard is ambiguous as to how O_RDWR is defined; it is perfectly permissable to define these values as: #define O_RDONLY 1 /* the read bit */ #define O_WRONLY 2 /* the write bit */ #define O_RDWR (O_RDONLY|O_WRONLY) /* read + write */ In which case, your example is (O_RDWR|O_WRONLY) == O_RDWR. The standard does not indicate whether the implementation is to use bits, or sequential manifest constants, only that the bits that make up the constants be in the range covered by O_ACCMODE. In fact, externally, they are bits, but internally, in the kernel, they are manifest constants. > This allows you to get an fd to pass to fcntl (e.g., for dnotify), or > call ioctl's on, etc.--even if you don't have either read or write > access to the file. The obvious question is, "Why should this ever be > allowed?" Well, if you can stat the file, why can't you, e.g., ask > kevent to monitor it? The most useful thing you could do with this, IMO, is opn a directory for fchdir(). Of course, allowing this on directories for which you are normally denied read/write permissions would be a neat way to escape from chroot'ed environments and compromise a host system... > In FreeBSD, this doesn't work; you just get EINVAL. > > Having O_NOACCESS would be useful for the fam port, for porting pieces > of lilo, and probably for other things I haven't thought of yet. (I > believe that either this was added to linux to support lilo, or the open > syscall just happened to work this way, and once the lilo developers > discovered this and took advantage of it, it's been retained that way > ever since to keep lilo working.) The latter is most likely. In any case, this would not be allowed by GEOM for the purpose to which LILO is trying to put it, unless you were to modify GEOM to add a control path for parents of already opened devices. If you did this, you might as well just add a proper set of abstract fcntl's to GEOM, and get rid of all the raw disk crap in user space, and unbreak dislabel and the other stuff that GEOM broke when it went in. > On the other hand, BSD has done without it for many years, and there's > probably a good reason it's never been added. So, what is that good > reason? fcntl.h: #define FFLAGS(oflags) ((oflags) + 1) > I don't think there's a backwards-compatibility issue. Unfortunately, yes, there is. The values are not bits, internally to the kernel. The conversion to internal form merely adds 1, it doesn't shift the values. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 01:43:35 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A92D616A4CE; Fri, 31 Oct 2003 01:43:35 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E45D843FE0; Fri, 31 Oct 2003 01:43:34 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.3) with ESMTP id h9V9hVsd081299; Fri, 31 Oct 2003 01:43:31 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id h9V9hVIv081298; Fri, 31 Oct 2003 01:43:31 -0800 (PST) (envelope-from rizzo) Date: Fri, 31 Oct 2003 01:43:31 -0800 From: Luigi Rizzo To: hackers@freebsd.org Message-ID: <20031031014331.A71967@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: RFC: proposed new builtin for /bin/sh (associative arrays) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 09:43:35 -0000 [Not sure what is the appropriate forum to discuss this, so please redirect the discussion if you know where. I have Bcc-ed a few /bin/sh committers] I am trying to implement, in the most unintrusive way, something resembliung associative arrays in /bin/sh. I am not interested in syntactic sugar, so i am happy to use something like _ as a separator between the array basename and the "index", i.e. foo_red foo_green foo_blue would be part of the same array. And, as a first step, I am also happy to be limited to [0-9A-Za-z_]+ as "index" values. So all it was necessary was a command to enumerate the indexes of an array, which is implemented by the attached patch, and can be used as follows: for i in `indexes foo_` do eval x=\$foo_$i echo "variable foo_$i has value $x" done (basically, "indexes xyz" lists the remaining part of all variable names that start with xyz. As a possibly useful side effect, indexes "" lists all variable names, which i believe is not an available sh function -- and i find it strange since we can list the names of readonly and export-ed variables with the "readonly" and "export" builtins). Any comments ? Is this interesting enough to be committed (with a proper manpage description) ? I could provide a flag to "indexes" to return the values instead of the names, but i believe this form is more useful. The next step would be to allow arbitrary strings as indexes, but that would be trickier because it would change the syntax for variable names (e.g. allowing \[.*\] as the last part of a variable name) cheers luigi Index: builtins.def =================================================================== RCS file: /home/ncvs/src/bin/sh/builtins.def,v retrieving revision 1.7.2.2 diff -u -r1.7.2.2 builtins.def --- builtins.def 27 Aug 2002 01:36:28 -0000 1.7.2.2 +++ builtins.def 30 Oct 2003 09:02:37 -0000 @@ -69,6 +69,7 @@ fgcmd -j fg getoptscmd getopts hashcmd hash +indexes indexes jobidcmd jobid jobscmd jobs #linecmd line Index: var.c =================================================================== RCS file: /home/ncvs/src/bin/sh/var.c,v retrieving revision 1.15.2.2 diff -u -r1.15.2.2 var.c --- var.c 27 Aug 2002 01:36:28 -0000 1.15.2.2 +++ var.c 31 Oct 2003 09:06:27 -0000 @@ -602,6 +602,28 @@ return 0; } +int +indexes(int argc, char **argv) +{ + struct var **vpp; + struct var *vp; + char *p, *q; + + if (argc != 2) + error("indexes require one argument"); + for (vpp = vartab ; vpp < vartab + VTABSIZE ; vpp++) { + for (vp = *vpp ; vp ; vp = vp->next) { + for (p = vp->text, q = argv[1]; + *p != '=' && *p == *q; p++, q++) + ; + if (*q != '\0') + continue; /* not found */ + while (*p != '=') + out1c(*p++); + out1c('\n'); + } + } +} /* * The "local" command. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 01:45:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E17F116A4CE for ; Fri, 31 Oct 2003 01:45:54 -0800 (PST) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1002143F75 for ; Fri, 31 Oct 2003 01:45:54 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfje9.dialup.mindspring.com ([165.247.205.201] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AFVqm-0001bQ-00; Fri, 31 Oct 2003 01:45:49 -0800 Message-ID: <3FA22EF1.39B64387@mindspring.com> Date: Fri, 31 Oct 2003 01:44:17 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: andi payn References: <1067529247.36829.2138.camel@verdammt.falcotronic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a489d52b5a41296f08bc19dfb764a696f4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: kevent and related stuff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 09:45:55 -0000 andi payn wrote: > First, let me mention that I'm not nearly as experienced coding for *BSD > as for linux, so I may ask some stupid questions. > > I've been looking at the fam port, and this has brought up a whole slew > of questions. I'm not sure if all of them are appropriate to this list, > but I don't know who else to ask, so.... > > First, some background: On Irix and Linux, fam works by asking the > kernel to send it a signal whenever the specified accesses occur. On > FreeBSD, since there is no imon interface and no dnotify fcntl, it > instead works by periodically stating all of the files it's > watching--which is obviously not as good. The fam FAQ suggests that > FreeBSD users should adapt fam to use the kevent interface. Yes. The "file access monitor" tool is the classic argument. > I looked into kevent, and it seems like there are a number of problems > that lead me to suspect that this is a really stupid idea. And yet, I'd > assume that someone on the fam team at SGI and/or one of the outside fam > developers would know FreeBSD at least as well as me. Therefore, I'm > guessing I'm missing something here. So, any ideas anyone can offer > would be very helpful. > > So, here's the questions I have: > > * I think (but I'm not sure) that kevent doesn't notify at all if the > only change to a file is its ATIME. If I'm right, this makes kevent > completely useless for fam. Adding a NOTE_ACCESS or something similar > would fix this. Since I'm pretty new to FreeBSD: What process do I go > through to figure out whether anyone else wants this, whether the > interface I've come up with is acceptable, etc.? And, once I write the > code, do I submit it as a pr? You add it, submit it as a PR, if send-pr will work from your machine properly, discuss it on the lists, and if someone with a commit bit has the time and likes the idea, it will be committed. > * The kevent mechanism doesn't monitor directories in a sufficient way > to make fam happy. If you change a file in a directory that you're > watching, unlike imon or dnotify, kevent won't see anything worth > reporting at all. This means that for directory monitoring, kevent is > useless as-is. Again, if I wanted to patch kevent to provide this > additional notification, would others want this? I'm not sure that this is correct, unless you are talking about monitoring all files in a directory by merely monitoring the directory. If you make a modification to the file metadata (e.g. add a link or rename it), then you will be notified that the directory has changed. The argument against subhierarchy monitoring is that it will, by definition, stop at the directory level, and it can not be successfully implemented for all FS types. > * When two equivalent events appear in the queue, kevent aggregates > them. This means that if there are two updates to a file since the last > time you checked, you'll only see the most recent one. For some uses of > fam (keeping a folder window up to date), this is what you want; for > others (keeping track of how often a file is read), this is useless. The > only solution I can think of is to add an additional flag, or some other > way to specify that you want duplicated events. This is the classic "edge triggered vs. level triggered" argument that Linux people bring up every time someone suggest they implement kqueue in Linux. This is easily fixable: you seperate the flag from the data, adding an additional argument to KNOTE(). This also has the side effect of removing the restriction on the PID size, which is imposed by the limited number of bits left over for representing the PID. This is a trivial change, and I've done it several times. The way this works is that you establish, via definition of the udata argument, a contract between the kernel and the user space over what the udata means. The additional argument to KNOTE can then be used by the per event note handling code in the kernel to fill out a udata structure with as much data as you want to give it, and to identify the place in user space to copy it out to. For example, you could set up an accept filter to accept up to 10 connections at a time, and return the fd's into the user space structure's int [10] array and fill out the int count value with how many were returned. For your case, you could use it to copy out each and every event instance, rather than aggregating the events. > * Unlike imon and dnotify, kevent doesn't provide any kind of callback > mechanism; instead, you have to poll the queue for events. Would it be > useful to specify another flag/parameter that would tell the kernel to > signal the monitoring process whenever an event is available? (It would > certainly make the fam code easier to write--but if it's not useful > anywhere else, that's probably not enough.) You can SIGPOLL on the event descriptor returned by kqueue(). You can use it in a select() or poll() call. You can pass it to another kqueue() as an EVFILT_READ event. Snding signals ("callbacks") is probably the absolutely least efficient way of getting the notification back. The presumption here (and it's likely a good one) is that, rather than polling, your application will be event driven, and get the events by blocking and waiting for them. > * The kevent vnode stuff apparently only works on UFS. And it looks like > it would be a major project to port it to other filesystems. It's actually pretty trivial, so long as you know the FS you are porting it to. The notifications for many things should probably be migrated to the VFS layer, instead (see Darwin's implementation). > Would this be useful for anything other than improving fam? Sure; it would be as useful for other FS's as it's useful in UFS now. The primary utility (IMO) is for GUI interfaces which want to update their displays in as close to real time as possible. > What about a port of > the imon kernel interface (and/or the dnotify fcntl) to FreeBSD instead? The way Linux people feel about "edge vs. level triggered" kqueue is about the same way FreeBSD people feel about "dnotify"... but there's no obvious way to fix the complaints about "dnotify". imon is pretty useless; if it would be implemented at all, the way to do it is in terms of kevents. Either way, you are resolving the kqueue "issue", so you might as well use kqueue. > * The kqueue doesn't appear to have any maximum size. If this is true, > the dnotify/fam problem where you get hideous errors from overflowing > queues wouldn't be an issue, but you could instead end up wasting > massive amounts of memory in the kernel if you didn't get around to > reading the queue.... Which is it? This is not strictly true; with the non-contract kqueue interface, it will aggregate the notes on a per object basis, so it's very hard to overflow (you'd have to monitor more things than you have memory available to monitor). With the contract kqueue, you would do one of two things: 1) Block the code in the KNOTE() addition until there was room on the queue 2) Have a ring buffer in user space as part of the contract, and if it overflows, it overflows Both of these boild down to "what do I do when I'm getting more events in the kernel than user space is able to process before buffer exhaustion sets in?". > Any answers, or pointers to where I can find these answers, would be > greatly appreciated. I don't pretend that my answers are authoritative; however, having done what you want to do for two commercial companies now, I can tell you the approach I describe (using a contract between the kernel an user space, and separating the parameter from the flag bits) will work. 8-). In fact, if you check the -current archives from about two years ago in June or July or so, you will see patches that perform this separation, and which add support for System V IPC message queues sending events, thereby allowing them to be selected/polled/etc. via their kqueue descriptor. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 01:59:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A59ED16A4CF for ; Fri, 31 Oct 2003 01:59:53 -0800 (PST) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by mx1.FreeBSD.org (Postfix) with SMTP id 3181E43FA3 for ; Fri, 31 Oct 2003 01:59:53 -0800 (PST) (envelope-from jasaorp@yahoo.com.br) Received: from 200-98-70-129.tlf.dialuol.com.br (HELO yahoo.com.br) (jasaorp@200.98.70.129 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 31 Oct 2003 09:59:41 -0000 Sender: jasaorp@FreeBSD.ORG Message-ID: <3F9E4FB4.9487515F@yahoo.com.br> Date: Tue, 28 Oct 2003 09:15:00 -0200 From: jasaorp X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Kylix in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 09:59:53 -0000 Somebody uses Kylix in FreeBSD? What is the performance? Jasao From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 02:14:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A6F216A4CE for ; Fri, 31 Oct 2003 02:14:03 -0800 (PST) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C8F243FBF for ; Fri, 31 Oct 2003 02:14:02 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfje9.dialup.mindspring.com ([165.247.205.201] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AFWHr-0004Kr-00; Fri, 31 Oct 2003 02:13:49 -0800 Message-ID: <3FA23574.4876BFFB@mindspring.com> Date: Fri, 31 Oct 2003 02:12:04 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nielsen References: <3F9CF3F6.8307.ABC1250@localhost> <20031031034719.1CE445A3C88@mail.npubs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a41b6c9186c2bfbdac91626ae58f657405387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 10:14:03 -0000 Nielsen wrote: > Christopher Vance wrote: > > May I suggest a different feature: the ability to mark an open file > > (not just its fd) 'remove on close', with permission checked at mark > > time rather than close time (this status forgotten if not permitted > > when set) and the unlink actually done at close time only if the file > > has exactly one link and one open file instance at that time. > > WinNT (2K etc...) has this capability. Not saying that this makes it a > good idea though. In all Windows supported FS's, there is no separation between the inode and the directory entry referencing the inode, so you'd expect them to be able to do this from an open file reference, since they can always get the directory entry back. In response to another post: saving the path at startup time is no good, since if someone moves the file (if it's open) or removes it preemptively (and it's closed), then there's a race window in which another instance of the program may start, and the program exiting removes the wrong file (or gets a permission denied error). All this hacking to solve the problem of harmless old files lying around in /var/run is fraught with peril... -- Terry From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 02:58:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F77A16A4CE for ; Fri, 31 Oct 2003 02:58:28 -0800 (PST) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 72AD643FBF for ; Fri, 31 Oct 2003 02:58:26 -0800 (PST) (envelope-from roam@ringlet.net) Received: (qmail 12148 invoked from network); 31 Oct 2003 10:57:30 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 31 Oct 2003 10:57:30 -0000 Received: (qmail 5431 invoked by uid 1000); 31 Oct 2003 10:58:23 -0000 Date: Fri, 31 Oct 2003 12:58:23 +0200 From: Peter Pentchev To: Luigi Rizzo Message-ID: <20031031105823.GF569@straylight.oblivion.bg> Mail-Followup-To: Luigi Rizzo , hackers@freebsd.org References: <20031031014331.A71967@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vv4Sf/kQfcwinyKX" Content-Disposition: inline In-Reply-To: <20031031014331.A71967@xorpc.icir.org> User-Agent: Mutt/1.5.4i cc: hackers@freebsd.org Subject: Re: RFC: proposed new builtin for /bin/sh (associative arrays) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 10:58:28 -0000 --vv4Sf/kQfcwinyKX Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 31, 2003 at 01:43:31AM -0800, Luigi Rizzo wrote: [snip description of a new 'indexes' builtin] > Any comments ? Is this interesting enough to be committed > (with a proper manpage description) ? > I could provide a flag to "indexes" to return the values instead > of the names, but i believe this form is more useful. Just a minor suggestion: could this be done as another form of variable expansion instead of as another keyword? Rationale: bash already does this - from the 'EXPANSION' section of its manpage: ${!prefix*} Expands to the names of variables whose names begin with prefix, separated by the first character of the IFS special variable. Thus, 'indexes foo_' would be equivalent to '${!foo_*}'. What you've done is great - several times I've found myself wishing that our sh had this, especially after finding that bash does it - but wouldn't it be better not to introduce a gratuitious syntax incompatibility if we can help it? :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence were in Chinese, it would say something else. --vv4Sf/kQfcwinyKX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/okBP7Ri2jRYZRVMRAlSlAKCFaaHpWgp4GDuTDONOqk6UHAq2ZgCfZz7U bRXJBQ33zAX86tk1bw60fBM= =eWCx -----END PGP SIGNATURE----- --vv4Sf/kQfcwinyKX-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 05:45:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2995916A4D3 for ; Fri, 31 Oct 2003 05:45:18 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id D8BC143FD7 for ; Fri, 31 Oct 2003 05:45:16 -0800 (PST) (envelope-from s_mazanek@gmx.de) Received: (qmail 15803 invoked by uid 0); 31 Oct 2003 13:45:15 -0000 Received: from 193.98.119.29 by www37.gmx.net with HTTP; Fri, 31 Oct 2003 14:45:15 +0100 (MET) Date: Fri, 31 Oct 2003 14:45:15 +0100 (MET) From: "Steffen Mazanek" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated: #6268088 Message-ID: <22966.1067607915@www37.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: FreeBSD 4.9 stable and Minolta DIMAGE S414 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 13:45:18 -0000 Hello, whenever I plug my Minolta DIMAGE S414 in my FreeBSD 4.9-stable box, it crashes with mysterious errors. I have a screenshot at http://www.steffen-mazanek.de/mixed/images/freebsdscreen.jpg Is anybody running this digicam on FreeBSD successfully? A -current system crashed as well, but this test is older and the problem may be fixed already. Best regards, Steffen Mazanek -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 06:13:56 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E236216A4CE for ; Fri, 31 Oct 2003 06:13:56 -0800 (PST) Received: from proto.pvv.ntnu.no (proto.pvv.ntnu.no [129.241.210.168]) by mx1.FreeBSD.org (Postfix) with SMTP id 428E043FBD for ; Fri, 31 Oct 2003 06:13:55 -0800 (PST) (envelope-from markusk@pvv.ntnu.no) Received: (qmail 67616 invoked by uid 28724); 31 Oct 2003 14:13:53 -0000 Date: Fri, 31 Oct 2003 15:13:53 +0100 (CET) From: =?ISO-8859-1?Q?Markus_B_Kr=FCger?= X-X-Sender: markusk@proto.pvv.ntnu.no To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Suggested improvement to radixsort() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 14:13:57 -0000 (I hope this is the correct forum for this post; if not, please let me know where it should go.) I've found a possible improvement to the implementation of radixsort() located in /usr/src/lib/libc/stdlib/radixsort.c, which will make the implementation more efficient when sorting data sets containing many strings that share a common prefix. The improvement consists in checking for bins where all strings have the same character at the current position of the radix sort, and moving on to the next character instead of needlessly shuffling the strings in the bin around. When I used the modified radixsort() to sort a web log file, which typically contains many strings with common prefixes (IP addresses), I registered a speedup of approximately 15%. On a constructed dataset where all strings had a long common prefix, the speedup was 50%. My modifications are listed below in patch format. Corrections, comments and questions are welcome. Is this patch something that I should send with send-pr, or should it be submitted elsewhere? --- begin radixsort.c.patch --- *** radixsort.c=09Tue Mar 11 12:39:57 1997 --- radixsort.c.patch=09Fri Oct 31 12:55:10 2003 *************** *** 175,180 **** --- 175,191 ---- =09=09} =09=09/* + =09=09 * Special case: if all strings have the same + =09=09 * character at position i, move on to the next + =09=09 * character. + =09=09 */ + =09=09if (nc =3D=3D 1 && count[bmin] =3D=3D n) { + =09=09=09push(a, n, i+1); + =09=09=09nc =3D count[bmin] =3D 0; + =09=09=09continue; + =09=09} + + =09=09/* =09=09 * Set top[]; push incompletely sorted bins onto stack. =09=09 * top[] =3D pointers to last out-of-place element in bins. =09=09 * count[] =3D counts of elements in bins. --- end radixsort.c.patch --- --=20 ,------------------- Markus Bjartveit Kr=FCger ---------------------. ' ` ` E-mail: markusk@pvv.org WWW: http://www.pvv.org/~markusk/ ' )-------------------------------------------------------------------( From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 08:28:01 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C83416A4CE for ; Fri, 31 Oct 2003 08:28:01 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id C06AB43FB1 for ; Fri, 31 Oct 2003 08:27:59 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 31 Oct 2003 16:27:58 +0000 (GMT) Date: Fri, 31 Oct 2003 16:27:57 +0000 From: David Malone To: andi payn Message-ID: <20031031162757.GA56981@walton.maths.tcd.ie> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1067528798.36829.2128.camel@verdammt.falcotronic.net> User-Agent: Mutt/1.5.3i Sender: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 16:28:01 -0000 On Thu, Oct 30, 2003 at 07:46:38AM -0800, andi payn wrote: > In FreeBSD, this doesn't work; you just get EINVAL. I believe this is because of a security problem discovered a few years ago, where you could open a file like /dev/io for neither read nor write but still get the special privelages associated with having the file open. If you were to allow people to open files without read or write permission you'd need to fix problems like this in a different way. David. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 09:24:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2725116A4CF for ; Fri, 31 Oct 2003 09:24:53 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67AB943FD7 for ; Fri, 31 Oct 2003 09:24:51 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 074866520E; Fri, 31 Oct 2003 17:24:50 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19846-02; Fri, 31 Oct 2003 17:24:49 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [195.206.69.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 59FC8651F7; Fri, 31 Oct 2003 17:24:49 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id F21AD11; Fri, 31 Oct 2003 17:24:47 +0000 (GMT) Date: Fri, 31 Oct 2003 17:24:47 +0000 From: Bruce M Simpson To: freebsd-hackers@freebsd.org Message-ID: <20031031172447.GA716@saboteur.dek.spc.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline Subject: User asks: can we decouple device vendor IDs from drivers? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 17:24:53 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, This sounds like one for the NEWBUS people. BMS --0F1p//8PRICkK4MW Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: bms@spc.org Delivered-To: bms@spc.org Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id B458E65480 for ; Fri, 31 Oct 2003 17:08:28 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19546-03-7 for ; Fri, 31 Oct 2003 17:08:28 +0000 (GMT) Received: from beethoven.kewl.org (beethoven.kewl.org [212.161.35.251]) by arginine.spc.org (Postfix) with ESMTP id 4EBC665211 for ; Fri, 31 Oct 2003 17:08:28 +0000 (GMT) Received: from beethoven.kewl.org ([212.161.35.251]) by beethoven.kewl.org with esmtp (Exim 3.35 #1) id 1AFcl9-000Pq5-00 for bms@spc.org; Fri, 31 Oct 2003 17:08:27 +0000 To: Bruce M Simpson From: Darron Broad Subject: Re: ATMEL atwi driver In-Reply-To: Your message of "Wed, 22 Oct 2003 16:29:53 BST." <20031022152953.GD3640@saboteur.dek.spc.org> X-Mailer: nmh-1.04 Date: Fri, 31 Oct 2003 17:08:27 +0000 Sender: darron@beethoven.kewl.org Message-Id: X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) In message <20031022152953.GD3640@saboteur.dek.spc.org>, Bruce M Simpson wrote: Hiya To follow up what I said down the pub... The file in solaris i was referring to is called /etc/driver_aliases do a search to find out about it. Looking at the mess in FreeBSD device drivers and how the drivers decide to attach to a device or not, then a lot of effort would be needed to clean those up, but should an alias file such as the solaris one exist in FBSD, IMHO it would make the life of everyone much easier. Perhaps you should look into it and propose to the FBSD team about implementing something sane like this, hacking every driver to add a new device ID is really a pain. Cya -- // / {:)==={ Darron Broad \\ \ --0F1p//8PRICkK4MW-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 09:52:42 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D12416A4CE for ; Fri, 31 Oct 2003 09:52:42 -0800 (PST) Received: from basement.kutulu.org (pcp03610121pcs.longhl01.md.comcast.net [68.49.239.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C33243FBF for ; Fri, 31 Oct 2003 09:52:41 -0800 (PST) (envelope-from kutulu@kutulu.org) Received: from wombat.localnet (wombat.localnet [192.168.69.3]) by basement.kutulu.org (Postfix) with ESMTP id 731E4AA0E; Fri, 31 Oct 2003 12:52:38 -0500 (EST) Received: by wombat.localnet (Postfix, from userid 1001) id 76A79B856; Fri, 31 Oct 2003 12:51:58 -0500 (EST) Date: Fri, 31 Oct 2003 12:51:58 -0500 From: Michael Edenfield To: jasaorp Message-ID: <20031031175158.GA27709@wombat.localnet> Mail-Followup-To: jasaorp , freebsd-hackers@freebsd.org References: <3F9E4FB4.9487515F@yahoo.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <3F9E4FB4.9487515F@yahoo.com.br> X-Mailer: Mutt http://www.mutt.org/ X-Accept-Language: en X-PGP-Key: http://www.kutulu.org/pgp/kutulu.asc X-PGP-Fingerprint: 1CE0 3C31 7013 D529 406D 37DC 09CC CD84 A46C 878F User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: Kylix in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 17:52:42 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * jasaorp [031031 04:59]: > Somebody uses Kylix in FreeBSD? > What is the performance? The IDE doesn't run under FreeBSD. I worked on it a bit over this summer when the most recent Kylix came out, and it appears to rely on too many Linux-isms. The command-line tools work just fine, and produce binaries that are on par with the ones you get from Linux. If I remember from my testing, the compiler produces Linux-style ELF binaries. Getting the Kylix IDE to function on FreeBSD has been one of the ongoing hair-pulling tasks I undertake every few months. The installer alone is a pain in the ass, since it performs "compatibility checks" in such Linux-centric ways as hard-coding /bin/bash into the shell scripts, and searching for shared libraries by name from hard-coded paths. (GTK especially gives the installer fits because FreeBSD's gtk library has a -x11 at the end of the name.) But once you work around those issues with some creative symlinking and script editing, the console tools install fairly painlessly. --Mike --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/oqE+CczNhKRsh48RAuuzAKCNknbBBFCwxPp4fopP7hmBBGPRgwCdE6Hg 2KafLnmbQ723v3zAezir3gE= =jZtG -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 11:09:36 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CB0516A4CF for ; Fri, 31 Oct 2003 11:09:36 -0800 (PST) Received: from jbhosting.de (alice.jbhosting.de [217.172.182.32]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F26743FBF for ; Fri, 31 Oct 2003 11:09:33 -0800 (PST) (envelope-from jonas.sonntag@jbhosting.de) Received: (qmail 17430 invoked by uid 545); 31 Oct 2003 19:15:44 -0000 Received: from ppp-62-245-211-129.mnet-online.de (HELO jbhosting.de) (jonsonn@jbhosting.de@62.245.211.129) by alice.jbhosting.de with SMTP; 31 Oct 2003 19:15:44 -0000 Message-ID: <3FA2B351.9050407@jbhosting.de> Date: Fri, 31 Oct 2003 20:09:05 +0100 From: Jonas Sonntag User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20031003 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonas Sonntag References: <3FA19C72.2050607@jbhosting.de> In-Reply-To: <3FA19C72.2050607@jbhosting.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: vinum on atapi raid X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 19:09:36 -0000 hi again just for the record: this really seems to be an issue with the ar device. i took one of the drives off from the promise controller (ar), attached it to the onboard controller (ad) and everything works fine. i'm cc'ing to freebsd-hackers because of this post: http://www.geocrawler.com/mail/msg.php3?msg_id=6949487&list=159 (see below). now, another question: looking at dmesg i found that ar2 is also given the device name ad7 (don't be confused by my previous post, the order of the disks changed): ar2: 117246MB [14946/255/63] status: READY subdisks: 0 READY ad7: 117246MB [238216/16/63] at ata3-slave UDMA100 so i though i might use ad7 instead of ar2 but trying to use /dev/ad7 with disklabel gives me 'Device is busy' error. please note that this is in fact no raid configuration. the disks just appear as ar because they are attached to the promise controller. hum... again, any hints how i could build a concatenated vinum volume from the single ar drives ? thanks and br, jonas Jonas Sonntag wrote: > hi list > > i'm trying to set up a concatenated vinum volume. i read chapter 13 in > the handbook and as so often i've found a nice how-to on > freebsddiary.org but somehow i'm stuck. > > my /etc/vinum.conf file is like this: > drive a device /dev/ar1h > drive b device /dev/ar2h > volume stuff > plex org concat > sd length 117239m drive a > sd length 78528m drive b > > > disklabels: > # /dev/ar1c: > type: ESDI > disk: ar1s1 > label: > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 14945 > sectors/unit: 240107427 > rpm: 3600 > interleave: 1 > trackskew: 0 > cylinderskew: 0 > headswitch: 0 # milliseconds > track-to-track seek: 0 # milliseconds > drivedata: 0 > > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 240107427 0 unused 0 0 # (Cyl. 0 - > 14945*) > h: 240107427 0 vinum # (Cyl. 0 - > 14945*) > > # /dev/ar2c: > type: ESDI > disk: ar2s1 > label: > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 10010 > sectors/unit: 160826652 > rpm: 3600 > interleave: 1 > trackskew: 0 > cylinderskew: 0 > headswitch: 0 # milliseconds > track-to-track seek: 0 # milliseconds > drivedata: 0 > > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 160826652 0 unused 0 0 # (Cyl. 0 - > 10010*) > h: 160826652 0 vinum # (Cyl. 0 - > 10010*) > > > fidsk also looks good: > > /dev/ar1: > The data for partition 1 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 63, size 240107427 (117239 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 1023/ head 254/ sector 63 > > /dev/ar2: > The data for partition 1 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 63, size 160826652 (78528 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 1023/ head 254/ sector 63 > > > now i seem to be missing something here.. when i do > vinum create -f /etc/vinum.conf > > what i get is: > > 1: drive a device /dev/ar1h > ** 1 Can't initialize drive a: Operation not supported by device > 2: drive b device /dev/ar2h > ** 2 Can't initialize drive b: Operation not supported by device > 0 drives: > 1 volumes: > V stuff State: down Plexes: 1 Size: > 191 GB > > 1 plexes: > P stuff.p0 C State: faulty Subdisks: 2 Size: > 191 GB > > 2 subdisks: > S stuff.p0.s0 State: crashed PO: 0 B Size: > 114 GB > S stuff.p0.s1 State: crashed PO: 114 GB Size: > 76 GB > > messages says: > /kernel: vinum: stuff.p0.s0 is crashed > /kernel: vinum: stuff.p0 is faulty > /kernel: vinum: stuff.p0.s1 is crashed > > > i have 'obliterated' the volume, i have remade the devices i allways > end up with "Operation not supported by device". > > something similar happens when i'm using the concat command to vinum: > vinum -> concat -v /dev/ar1h /dev/ar2h > volume vinum0 > plex name vinum0.p0 org concat > drive vinumdrive0 device /dev/ar1h > Can't create drive vinumdrive0, device /dev/ar1h: Can't initialize > drive vinumdrive0 > > i have come across this post: > http://www.geocrawler.com/mail/msg.php3?msg_id=6949487&list=159 > could that be the case with /dev/ar, too? i'm on 4.8-stable. > > any hints how to go on would be great. please cc me, as i'm not on the > list. > > thanks and br > jonas > From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 11:13:39 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1DAA16A4CE for ; Fri, 31 Oct 2003 11:13:39 -0800 (PST) Received: from mta3.adelphia.net (mta3.adelphia.net [68.168.78.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 580BC43FB1 for ; Fri, 31 Oct 2003 11:13:38 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta3.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031031191340.DBRF16926.mta3.adelphia.net@[10.1.0.9]>; Fri, 31 Oct 2003 14:13:40 -0500 From: andi payn To: Terry Lambert In-Reply-To: <3FA22930.C6EC97A9@mindspring.com> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <3FA22930.C6EC97A9@mindspring.com> Content-Type: text/plain Message-Id: <1067627608.825.56.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 11:13:36 -0800 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 19:13:39 -0000 On Fri, 2003-10-31 at 01:19, Terry Lambert wrote: > andi payn wrote: > > As far as I can tell, FreeBSD doesn't have anything equivalent to > > linux's O_NOACCESS (which is not in any of the standard headers, but > > it's equal to O_WRONLY | O_RDWR, or O_ACCMODE). In linux, this can be > > used to say, "give me an fd for this file, but don't try to open it for > > reading or writing or anything else." > > The standard does not permit this. > > First off, O_ACCMODE is a bitmask, and is guaranteed to be > inclusive of the bits for O_RDONLY, O_WRONLY, and O_RDWR, but > *not* guaranteed to not be inclusive of additional bits, > reserved or locally defined but outside the _POSIX_SOURCE > namespace. By using this value as a parameter, you could very > well be setting many more bits, and you could be setting bits > for local implementation options that you really, really do > not want to set. Now hold on. The standard (by which I you mean POSIX? or one of the UNIX standards?) doesn't say that you can't have an additional flag called O_NOACCESS with whatever value and meaning you want. Obviously, code that relies on such a flag will be non-portable, since no standard defines such a flag, but that's fine, since the intended uses (writing a FreeBSD-specific backend for fam, for example) aren't expected to be portable anyway. If O_NOACCESS happens to be == O_ACCMODE on FreeBSD--just as it is on linux--and if that happens to also be == O_WRONLY | O_RDWR (with no other flags set), I don't see how that changes anything. > Second, the standard is ambiguous as to how O_RDWR is defined; > it is perfectly permissable to define these values as: > > #define O_RDONLY 1 /* the read bit */ > #define O_WRONLY 2 /* the write bit */ > #define O_RDWR (O_RDONLY|O_WRONLY) /* read + write */ > > In which case, your example is (O_RDWR|O_WRONLY) == O_RDWR. The > standard does not indicate whether the implementation is to use > bits, or sequential manifest constants, only that the bits that > make up the constants be in the range covered by O_ACCMODE. First, again, this is intended to be used for non-portable code, and therefore, the fact that this happens not to be true on FreeBSD means it's irrelevant that it could be true elsewhere. Especially since, if O_NOACCESS were added to FreeBSD, it would still fail to exist entirely on other platforms, which means it matters little what value it might have if it did exist--code written to use O_NOACCESS won't compile on platforms without O_NOACCESS. Second, any platform that defines O_NOACCESS could do so differently. On FreeBSD, as on linux, the most sensible definition is O_NOACCESS == O_WRONLY | O_RDWR == 3. Or a platform that defined O_RDONLY as 1 and O_WRONLY as 2, the most sensible definition would be O_NOACCESS == 0. > In fact, externally, they are bits, but internally, in the kernel, > they are manifest constants. Yes, FFLAGS and OFLAGS convert between the two. If you look at how this works in the linux kernel, you'll see that O_RDONLY (0) converts to FREAD (1); O_WRONLY (1) to FWRITE (2); O_RDWR (2) to FREAD | FWRITE (3); and O_NOACCESS (3) to 0. This could be done the same way in FreeBSD.* * Actually, this is a tiny lie; linux has a 2-bit internal access flags value which it derives in this way, and uses the original passed-in flags for everything except access. FreeBSD instead just adds 1, relying on the fact that the lower 2 bits will never be 3, and therefore all of the other bits will stay the same. This means that enabling this value would make the FFLAGS and OFLAGS macros slightly more complicated on FreeBSD. > > This allows you to get an fd to pass to fcntl (e.g., for dnotify), or > > call ioctl's on, etc.--even if you don't have either read or write > > access to the file. The obvious question is, "Why should this ever be > > allowed?" Well, if you can stat the file, why can't you, e.g., ask > > kevent to monitor it? > > The most useful thing you could do with this, IMO, is opn a directory > for fchdir(). Except that you can already do exactly this with chdir(). But I can see that you might at some point want to check the directory before chdir'ing to it, or pass an fd down into some function instead of a string, and this would be useful in such a case. > Of course, allowing this on directories for which you > are normally denied read/write permissions would be a neat way to > escape from chroot'ed environments and compromise a host system... How would it allow that? If you can open files outside your chroot environment--even files you would otherwise have read access to--it's not much of a chroot! To put this all together: chdir already allows you to change to directories for which you have execute permissions but not read or write; fchdir already prevents you from changing to directories for which you don't have execute permissions; and any path you can pass to open you could pass to chdir instead Therefore: fd = open(path, O_NOACCESS); fchdir(fd); fclose(fd) allows exactly the same exploits as chdir(path) So, if this would allow you to escape chroot, then the kernel is heavily flawed and chdir is an exploit waiting to happen.... What if you inherent the fd from an ancestor? Well, so what? You could just as easily have inherited it with O_RDONLY as O_NOACCESS, and the "exploit" is exactly the same in either case. > > In FreeBSD, this doesn't work; you just get EINVAL. > > > > Having O_NOACCESS would be useful for the fam port, for porting pieces > > of lilo, and probably for other things I haven't thought of yet. (I > > believe that either this was added to linux to support lilo, or the open > > syscall just happened to work this way, and once the lilo developers > > discovered this and took advantage of it, it's been retained that way > > ever since to keep lilo working.) > > The latter is most likely. Actually, you'd be surprised at how much has been explicitly added to the kernel (and, more, to the filesystem code, especially reiser) for lilo's benefit. > In any case, this would not be allowed > by GEOM for the purpose to which LILO is trying to put it, unless > you were to modify GEOM to add a control path for parents of > already opened devices. I think that in the case you're thinking of, lilo is actually passing -1, which has a special meaning to the linux kernel ("pass all ioctl's through"), rather than 3 (but both end up as !FREAD, !FWRITE if you try to use the fd for anything normal). Anyway, I wasn't proposing to make O_NOACCESS work for this purpose. As a quick glance will show, successfully opening the fd wouldn't do lilo any good if all it wants to do is call a dozen ioctl's that FreeBSD's devices have never heard of.... > If you did this, you might as well just > add a proper set of abstract fcntl's to GEOM, and get rid of all > the raw disk crap in user space, and unbreak dislabel and the other > stuff that GEOM broke when it went in. Sure, I'll agree that it would probably be better to expand GEOM than to hack it for lilo's benefit. > > On the other hand, BSD has done without it for many years, and there's > > probably a good reason it's never been added. So, what is that good > > reason? > > fcntl.h: > #define FFLAGS(oflags) ((oflags) + 1) Yes, I mentioned that before. Unlike linux, FreeBSD depends on the fact that, e.g., O_NOBLOCK is the same in FFLAGS(flags) as in flags. This is only true because (flags & 3) != 3 is guaranteed, and therefore ((flags + 1) & 4) == (flags & 4) is also guaranteed. So, this would require either using something more complicated for FFLAGS (and OFLAGS), or changing a few lines of code where this assumption is made. > > I don't think there's a backwards-compatibility issue. > > Unfortunately, yes, there is. The values are not bits, internally > to the kernel. The conversion to internal form merely adds 1, it > doesn't shift the values. Well, OK, let me restate this: I don't think there's a backwards-compatibility issue if this is done properly. Just removing the one-line check against O_WRONLY | O_RDWR would not work, therefore I suppose there would be a backwards-compatibility issue, in the sense that a broken kernel is not backwards-compatible with a working one.... From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 11:20:17 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD7E916A4CE for ; Fri, 31 Oct 2003 11:20:17 -0800 (PST) Received: from mta7.adelphia.net (mta7.adelphia.net [68.168.78.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1044C43FBD for ; Fri, 31 Oct 2003 11:20:17 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta7.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031031192019.CAPH29257.mta7.adelphia.net@[10.1.0.9]>; Fri, 31 Oct 2003 14:20:19 -0500 From: andi payn To: David Malone In-Reply-To: <20031031162757.GA56981@walton.maths.tcd.ie> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <20031031162757.GA56981@walton.maths.tcd.ie> Content-Type: text/plain Message-Id: <1067628015.825.64.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 11:20:15 -0800 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 19:20:18 -0000 On Fri, 2003-10-31 at 08:27, David Malone wrote: > On Thu, Oct 30, 2003 at 07:46:38AM -0800, andi payn wrote: > > In FreeBSD, this doesn't work; you just get EINVAL. > > I believe this is because of a security problem discovered a few > years ago, where you could open a file like /dev/io for neither > read nor write but still get the special privelages associated with > having the file open. > > If you were to allow people to open files without read or write > permission you'd need to fix problems like this in a different way. It seems to me that the right way to fix this is to ensure that only the superuser can open /dev/io device, no matter what permissions are on it. And the manpage says that this restriction is there. Of course it would be a good idea to check the code and make sure this really is true before (re-?)enabling O_NOACCESS. Are there any other special devices like this in FreeBSD? From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 11:36:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64E7716A4CE for ; Fri, 31 Oct 2003 11:36:46 -0800 (PST) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8538C43F75 for ; Fri, 31 Oct 2003 11:36:45 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta9.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031031193648.EWJ25728.mta9.adelphia.net@[10.1.0.9]>; Fri, 31 Oct 2003 14:36:48 -0500 From: andi payn To: Ruben de Groot In-Reply-To: <20031031063303.GA38640@ei.bzerk.org> References: <1067529247.36829.2138.camel@verdammt.falcotronic.net> <20031031063303.GA38640@ei.bzerk.org> Content-Type: text/plain Message-Id: <1067629003.825.97.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 11:36:43 -0800 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: kevent and related stuff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 19:36:46 -0000 On Thu, 2003-10-30 at 22:33, Ruben de Groot wrote: > On Thu, Oct 30, 2003 at 07:54:07AM -0800, andi payn typed: > > [...] > > > * I think (but I'm not sure) that kevent doesn't notify at all if the > > only change to a file is its ATIME. If I'm right, this makes kevent > > completely useless for fam. Adding a NOTE_ACCESS or something similar > > would fix this. > Wouldn't NOTE_ATTRIB (EVFILT_VNODE) do what you want? That was my first guess, but I first tested it with wait_on (before sending the original email), and have since tested it directly, and apparently you don't get NOTE_ATTRIB notifications just because the ATIME changes. As far as I can tell, there is no way to get notifications on only the ATIME changing. Now, if everyone seems to write the manpage as implying that NOTE_ATTRIB should in fact get triggered by a change in the ATIME, maybe the right solution is to make this true. However, I could easily see that breaking existing code. That's why I suggested adding a new NOTE_ACCESS instead. To see for yourself, here's the simplest possible test: # touch /tmp/file # ls -lu /tmp/file -rw------- 1 andi users 0 Oct 31 11:29 /tmp/file # wait_on -h /tmp/file > /tmp/out & # cat /tmp/file # cat /tmp/out # ls -lu /tmp/file -rw------- 1 andi users 0 Oct 31 11:30 /tmp/file # touch /tmp/file [1]+ Exit 4 wait_on -h /tmp/file > /tmp/out # cat /tmp/out /tmp/file: attributed In other words, changing the ATIME (e.g., with cat) does not trigger NOTE_ATTRIB; changing the MTIME (e.g., with touch), does. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 11:46:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE01A16A4CE for ; Fri, 31 Oct 2003 11:46:28 -0800 (PST) Received: from usw2.natel.net (2b.bz [209.152.117.190]) by mx1.FreeBSD.org (Postfix) with SMTP id 5948A43F85 for ; Fri, 31 Oct 2003 11:46:27 -0800 (PST) (envelope-from WD@US-Webmasters.com) Received: (qmail 12559 invoked from network); 31 Oct 2003 19:46:23 -0000 Received: from batv-01-025.dialup.netins.net (HELO xyz.US-Webmasters.com) (216.248.109.26) by us-webmasters.com with SMTP; 31 Oct 2003 19:46:23 -0000 Message-Id: <5.1.0.14.2.20031031134420.04813850@209.152.117.178> X-Sender: wd@209.152.117.178 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 31 Oct 2003 13:46:14 -0600 To: freebsd-hackers@freebsd.org From: "W. D." In-Reply-To: <20031031175158.GA27709@wombat.localnet> References: <3F9E4FB4.9487515F@yahoo.com.br> <3F9E4FB4.9487515F@yahoo.com.br> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_14378962==_" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: Kylix in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 19:46:29 -0000 --=====================_14378962==_ Content-Type: multipart/related; type="text/plain"; boundary="=====================_14378962==_.REL" --=====================_14378962==_.REL Content-Type: text/plain; charset="us-ascii" Does this mean that one could possibly develop some GUI programs on Linux, them compile them to run on FreeBSD? Or, can one only compile command line apps? At 11:51 10/31/2003, Michael Edenfield, wrote: >d87b8c.jpg Re Kylix in FreeBSD.ems> >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline > >* jasaorp [031031 04:59]: >> Somebody uses Kylix in FreeBSD? >> What is the performance? > >The IDE doesn't run under FreeBSD. I worked on it a bit over this >summer when the most recent Kylix came out, and it appears to rely on >too many Linux-isms. > >The command-line tools work just fine, and produce binaries that are on >par with the ones you get from Linux. If I remember from my testing, >the compiler produces Linux-style ELF binaries. > >Getting the Kylix IDE to function on FreeBSD has been one of the ongoing >hair-pulling tasks I undertake every few months. The installer alone is >a pain in the ass, since it performs "compatibility checks" in such >Linux-centric ways as hard-coding /bin/bash into the shell scripts, and >searching for shared libraries by name from hard-coded paths. (GTK >especially gives the installer fits because FreeBSD's gtk library has a >-x11 at the end of the name.) But once you work around those issues >with some creative symlinking and script editing, the console tools >install fairly painlessly. > >--Mike > --=====================_14378962==_.REL-- --=====================_14378962==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Start Here to Find It Fast!=99 -> http://www.US-Webmasters.com/best-start-pa= ge/ --=====================_14378962==_-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 11:58:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CA4D16A4CE for ; Fri, 31 Oct 2003 11:58:04 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28DA443FB1 for ; Fri, 31 Oct 2003 11:58:01 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9VJvxE7061341; Fri, 31 Oct 2003 12:57:59 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 31 Oct 2003 12:57:53 -0700 (MST) Message-Id: <20031031.125753.124085663.imp@bsdimp.com> To: bms@spc.org From: "M. Warner Losh" In-Reply-To: <20031031172447.GA716@saboteur.dek.spc.org> References: <20031031172447.GA716@saboteur.dek.spc.org> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: User asks: can we decouple device vendor IDs from drivers? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 19:58:04 -0000 In message: <20031031172447.GA716@saboteur.dek.spc.org> Bruce M Simpson writes: : This sounds like one for the NEWBUS people. A number of people have proposed this in the past. It is a big deal, and won't be in 5, although a 'treat this pnpid as that pnpid' might be, which would be sufficient. The problem with decoupling things entirely from the drivers is that many drivers will say "if I have this revision of that card, do this workaround." or "if I'm this or newer, I have this feature" both of which are broken by the kernel forcing the driver to service a given hunk of hardware. The other down side is that when you bork the alias file on solaris, you are so hozed. However, it would make the dynamic loading of drivers easier. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:02:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9516916A4CE for ; Fri, 31 Oct 2003 12:02:40 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4030F43FAF for ; Fri, 31 Oct 2003 12:02:37 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9VK2XE7061410; Fri, 31 Oct 2003 13:02:34 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 31 Oct 2003 13:02:29 -0700 (MST) Message-Id: <20031031.130229.132929054.imp@bsdimp.com> To: andi_payn@speedymail.org From: "M. Warner Losh" In-Reply-To: <1067628015.825.64.camel@verdammt.falcotronic.net> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <20031031162757.GA56981@walton.maths.tcd.ie> <1067628015.825.64.camel@verdammt.falcotronic.net> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:02:40 -0000 In message: <1067628015.825.64.camel@verdammt.falcotronic.net> andi payn writes: : On Fri, 2003-10-31 at 08:27, David Malone wrote: : > On Thu, Oct 30, 2003 at 07:46:38AM -0800, andi payn wrote: : > > In FreeBSD, this doesn't work; you just get EINVAL. : > : > I believe this is because of a security problem discovered a few : > years ago, where you could open a file like /dev/io for neither : > read nor write but still get the special privelages associated with : > having the file open. : > : > If you were to allow people to open files without read or write : > permission you'd need to fix problems like this in a different way. : : It seems to me that the right way to fix this is to ensure that only the : superuser can open /dev/io device, no matter what permissions are on it. This might not be a bad idea, but it would force at least one company (mine) to rewrite at least some of their software to run as root. we currently don't run some things as root because we don't trust them. But then you are getting into special case kludges. Better to require that it is opened read or write permissions. : Are there any other special devices like this in FreeBSD? Rewind units on tape drives? If there's no access check done, and I open the rewind unit as joe-smoe? The close code is what does the rewind, and you don't have enough knowledge to know if the tape was opened r/w there. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:12:43 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF28D16A4CF for ; Fri, 31 Oct 2003 12:12:43 -0800 (PST) Received: from basement.kutulu.org (pcp03610121pcs.longhl01.md.comcast.net [68.49.239.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1128E43FA3 for ; Fri, 31 Oct 2003 12:12:43 -0800 (PST) (envelope-from kutulu@kutulu.org) Received: from wombat.localnet (wombat.localnet [192.168.69.3]) by basement.kutulu.org (Postfix) with ESMTP id 60194AA2E; Fri, 31 Oct 2003 15:12:42 -0500 (EST) Received: by wombat.localnet (Postfix, from userid 1001) id 5AD3BB855; Fri, 31 Oct 2003 15:12:02 -0500 (EST) Date: Fri, 31 Oct 2003 15:12:02 -0500 From: Michael Edenfield To: "W. D." Message-ID: <20031031201202.GB54594@wombat.localnet> Mail-Followup-To: "W. D." , freebsd-hackers@freebsd.org References: <3F9E4FB4.9487515F@yahoo.com.br> <3F9E4FB4.9487515F@yahoo.com.br> <5.1.0.14.2.20031031134420.04813850@209.152.117.178> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20031031134420.04813850@209.152.117.178> X-Mailer: Mutt http://www.mutt.org/ X-Accept-Language: en X-PGP-Key: http://www.kutulu.org/pgp/kutulu.asc X-PGP-Fingerprint: 1CE0 3C31 7013 D529 406D 37DC 09CC CD84 A46C 878F User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: Kylix in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:12:44 -0000 --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * W. D. [031031 14:45]: > Does this mean that one could possibly develop some GUI programs > on Linux, them compile them to run on FreeBSD? Or, can one only > compile command line apps? This should, in theory, be possible. Kylix links against Qt and some additional CLX runtime libraries, which are covered under a dual-lisenced: if you pay for Kylix you get a commercial lisence for Qt and CLX, if you use the Open Kylix version you get GPL'd copies of the license. As far as I can tell, the problem with Kylix on FreeBSD is the IDE itself, using customized WINE-like libraries internally, and has nothing to do with the output of the compiler/linker. It does sortof assume you have glibc, but I don't think there are any issues with Kylix that don't exists with Linux-built gcc/gld binaries. --Mike --f2QGlHpHGjS2mn6Y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/osIRCczNhKRsh48RAoe1AKCTW5i2rQj9KLh4KPiHKummY6EG4gCgt9Mp 9fGODjyb3rRfdEqlSokog/U= =5Of0 -----END PGP SIGNATURE----- --f2QGlHpHGjS2mn6Y-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:15:35 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9CC116A4CE for ; Fri, 31 Oct 2003 12:15:35 -0800 (PST) Received: from bluebox.CS.Princeton.EDU (bluebox.CS.Princeton.EDU [128.112.136.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id E887543F75 for ; Fri, 31 Oct 2003 12:15:34 -0800 (PST) (envelope-from vivek@CS.Princeton.EDU) Received: from cs.princeton.edu (oakley [128.112.139.27]) (authenticated bits=0)h9VKFDFn022667 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 15:15:13 -0500 (EST) Message-ID: <3FA2C2D1.7000406@cs.princeton.edu> Date: Fri, 31 Oct 2003 15:15:13 -0500 From: Vivek Pai User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1066820436.25609.93.camel@boxster.onthenet.com.au> <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> <20031026175726.GC558@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: Q cc: freebsd-hackers@freebsd.org cc: Kris Kennaway Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:15:36 -0000 There are two scenarios - sendfile can't proceed immediately because all sfbuf space is exhausted, and sendfile can't proceed immediately because the page to be sent isn't in physical memory. In both cases, we can have another process/thread call sendfile with the flag cleared, allowing sendfile to block as needed. This work is being done in the context of the Flash Web Server, which already had helper processes to perform all of the disk-related operations. These helpers use pipes/sockets to communicate back to the main process that a page has been loaded into memory (or that the page has been sent directly). We don't currently initiate async I/O's using a nonportable interface, but that's also a possibility. -Vivek John-Mark Gurney wrote: > vivek@CS.Princeton.EDU wrote this message on Sun, Oct 26, 2003 at 10:48 -0500: > >>We decided to avoid all mmap/mincore operations, and opted to instead >>add a flag to sendfile such that we can try sendfile and have it return >>an error (instead of blocking) when a page isn't in memory. > > > I was thinking about this myself, but how do you prevent spinning on > the sendfile waiting for the page to become available? You have the > send space to wait for on the socket, but there is no equivalent kqueue > event to wait for when a page becomes available. Do you simply always > spin on sendfile since the socket keeps returning available for writing? > > I have a similar web server design that I wrote at the end of last > year, and your paper brought to light to problems of sendfile, so I have > been thinking of switching to async io, since there you can get > completion status when the io completes. > From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:17:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC1BD16A4CE for ; Fri, 31 Oct 2003 12:17:02 -0800 (PST) Received: from lurza.secnetix.de (lurza.secnetix.de [195.143.231.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id C039943FB1 for ; Fri, 31 Oct 2003 12:16:59 -0800 (PST) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dazwtc@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.9p1/8.12.8) with ESMTP id h9VKGvOC006951 for ; Fri, 31 Oct 2003 21:16:57 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.9p1/8.12.8/Submit) id h9VKGv8X006950; Fri, 31 Oct 2003 21:16:57 +0100 (CET) Date: Fri, 31 Oct 2003 21:16:57 +0100 (CET) Message-Id: <200310312016.h9VKGv8X006950@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20031031014331.A71967@xorpc.icir.org> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.8-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: RFC: proposed new builtin for /bin/sh (associative arrays) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:17:02 -0000 Luigi Rizzo wrote: > I am trying to implement, in the most unintrusive way, something > resembliung associative arrays in /bin/sh. I am not interested in > syntactic sugar, so i am happy to use something like _ as a separator > between the array basename and the "index", i.e. > > foo_red foo_green foo_blue > > would be part of the same array. And, as a first step, I am also > happy to be limited to [0-9A-Za-z_]+ as "index" values. It would be cool to have real associative arrays like in zsh, i.e. ${foo[red]}. Would be even backwards-compatible without breaking existing scripts. Well, wishful thinking ... :-) (Personally, when I needed to do things with associative arrays, I wrote that part of the shell script in awk, which supports associative arrays natively, cleanly, _and_ it is portable.) > So all it was necessary was a command to enumerate the indexes > of an array, which is implemented by the attached patch, and > can be used as follows: > > for i in `indexes foo_` > do > eval x=\$foo_$i > echo "variable foo_$i has value $x" > done Maybe I'm not understanding your intentions, but isn't that already possible using "set | sed -n '/^foo_/s/=.*//p'"? Or do you want to avoid external programs? In that case it would be a little bit more difficult to do, but it's still possible to do with existing builtins: indexes() { for i in `set`; do case $i in $1*) echo ${i%%=*} esac done } Then you could use `indexes foo_` like above. No patch to /bin/sh necessary. > (basically, "indexes xyz" lists the remaining part of all variable > names that start with xyz. As a possibly useful side effect, > indexes "" lists all variable names, which i believe is not an > available sh function -- and i find it strange since we can > list the names of readonly and export-ed variables with the > "readonly" and "export" builtins). Well, "set" (without arguments) lists all variables and their values. You can easily filter the variable names from it. > Any comments ? Is this interesting enough to be committed > (with a proper manpage description) ? My personal opinion (please don't kill me): It appears to me to be a "dirty hack" with very limited usefulness. If associative arrays are to be implemented, it should be done properly (like in zsh, for example). Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ) From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:19:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37CBB16A4CE for ; Fri, 31 Oct 2003 12:19:37 -0800 (PST) Received: from usw2.natel.net (2b.bz [209.152.117.190]) by mx1.FreeBSD.org (Postfix) with SMTP id 4256D43FB1 for ; Fri, 31 Oct 2003 12:19:36 -0800 (PST) (envelope-from WD@US-Webmasters.com) Received: (qmail 13224 invoked from network); 31 Oct 2003 20:19:32 -0000 Received: from batv-01-025.dialup.netins.net (HELO xyz.US-Webmasters.com) (216.248.109.26) by us-webmasters.com with SMTP; 31 Oct 2003 20:19:32 -0000 Message-Id: <5.1.0.14.2.20031031141841.053bd6b0@209.152.117.178> X-Sender: wd@209.152.117.178 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 31 Oct 2003 14:19:18 -0600 To: freebsd-hackers@freebsd.org From: "W. D." In-Reply-To: <20031031201202.GB54594@wombat.localnet> References: <5.1.0.14.2.20031031134420.04813850@209.152.117.178> <3F9E4FB4.9487515F@yahoo.com.br> <3F9E4FB4.9487515F@yahoo.com.br> <5.1.0.14.2.20031031134420.04813850@209.152.117.178> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_16366325==_" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: Kylix in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:19:37 -0000 --=====================_16366325==_ Content-Type: multipart/related; type="text/plain"; boundary="=====================_16366325==_.REL" --=====================_16366325==_.REL Content-Type: text/plain; charset="us-ascii" Hmmmm. Which Linux would be most compatible? At 14:12 10/31/2003, Michael Edenfield wrote: >f7173a.jpg Re Kylix in FreeBSD1.ems> >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline > >* W. D. [031031 14:45]: >> Does this mean that one could possibly develop some GUI programs >> on Linux, them compile them to run on FreeBSD? Or, can one only >> compile command line apps? > >This should, in theory, be possible. Kylix links against Qt and some >additional CLX runtime libraries, which are covered under a >dual-lisenced: if you pay for Kylix you get a commercial lisence for Qt >and CLX, if you use the Open Kylix version you get GPL'd copies of the >license. As far as I can tell, the problem with Kylix on FreeBSD is the >IDE itself, using customized WINE-like libraries internally, and has >nothing to do with the output of the compiler/linker. > >It does sortof assume you have glibc, but I don't think there are any >issues with Kylix that don't exists with Linux-built gcc/gld binaries. > >--Mike --=====================_16366325==_.REL-- --=====================_16366325==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Start Here to Find It Fast!=99 -> http://www.US-Webmasters.com/best-start-pa= ge/ --=====================_16366325==_-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:21:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 547D616A4CF for ; Fri, 31 Oct 2003 12:21:23 -0800 (PST) Received: from bluebox.CS.Princeton.EDU (bluebox.CS.Princeton.EDU [128.112.136.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5164F43F3F for ; Fri, 31 Oct 2003 12:21:21 -0800 (PST) (envelope-from vivek@CS.Princeton.EDU) Received: from cs.princeton.edu (oakley [128.112.139.27]) (authenticated bits=0)h9VKLIFn023012 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 15:21:19 -0500 (EST) Message-ID: <3FA2C43E.3030204@cs.princeton.edu> Date: Fri, 31 Oct 2003 15:21:18 -0500 From: Vivek Pai User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Silbersack References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1066820436.25609.93.camel@boxster.onthenet.com.au> <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> <20031026121527.K2023@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: Kris Kennaway cc: Q cc: freebsd-hackers@freebsd.org Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:21:23 -0000 Before we proceed on this, I'd like to ask is there actuall a committer ready to follow up on this? We currently make our patches available on Ping's homepage, and they're relatively clean. He spent a fair bit of time getting it from a relatively ugly set of changes to something more elegant and better integrated with the rest of the kernel. However, even with the benchmark success that we've gotten (which Aniruddha Bohra mentioned in a different e-mail), we haven't had a single nibble from a committer. FreeBSD lags Linux badly on the SpecWeb99 benchmarks, and those are probably more representative than some arbitrary microbenchmark. It would be nice to get some respectable numbers on it, especially if we could do it with a stable user-space server. -Vivek Mike Silbersack wrote: > On Sun, 26 Oct 2003 vivek@CS.Princeton.EDU wrote: > > >>Details about what we have so far are at >>http://www.cs.princeton.edu/~yruan/debox/ >> >>Yaoping Ruan had mentioned this on the list before (and sent a >>pointer to the sendfile patches), but didn't seem to get much >>response. >> >>-Vivek > > > As always, you're seeing the lack of available committer time, not a real > lack of interest. One way to accelerate the process might be for someone > (not necessarily you, any reader of this mailing list could do it) to show > that this change visibly benefits some easy to run benchmark. Some simple > setup of apachebench vs thttpd (which uses sendfile, afaik) would be > useful for this purpose. > > Mike "Silby" Silbersack > From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:29:51 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D02D16A4CE; Fri, 31 Oct 2003 12:29:51 -0800 (PST) Received: from bluebox.CS.Princeton.EDU (bluebox.CS.Princeton.EDU [128.112.136.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BC2943F85; Fri, 31 Oct 2003 12:29:50 -0800 (PST) (envelope-from vivek@CS.Princeton.EDU) Received: from cs.princeton.edu (oakley [128.112.139.27]) (authenticated bits=0)h9VKTmFn023496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 15:29:48 -0500 (EST) Message-ID: <3FA2C63C.5000900@cs.princeton.edu> Date: Fri, 31 Oct 2003 15:29:48 -0500 From: Vivek Pai User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1066820436.25609.93.camel@boxster.onthenet.com.au> <20031026052854.GA20701@VARK.homeunix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: =?us-ascii@FreeBSD.ORG cc: Q cc: freebsd-hackers@freebsd.org cc: Kris Kennaway cc: iso-8859-1?Q?Sm=F8rgrav?= cc: Dag-Erling@FreeBSD.ORG Subject: Re: Some mmap observations compared to Linux 2.6/OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:29:51 -0000 Take a look at Figure 6, page 9 in the following: http://www.cs.princeton.edu/~yruan/DeBox/debox.pdf On a 1GHz box with 1GB of memory, we were spending 4-5 milliseconds per mmap call, and that was limiting the throughput of our server on SpecWeb99. Figure 9 on page 11 shows that just getting rid of the mmap/munmap/mincore calls in this server got us a 50% performance boost on a fairly complicated workload. The SpecWeb99 workload was modeled after several web sites, so this might actually be a performance problem in the real world. If you look at figure 11, page 12, you'll see that with various improvements, our server's median latency dropped to less than 1ms. An mmap time of several milliseconds would kill that benefit. -Vivek David Schultz wrote: > Your idea of using a size-hashed freelist as well as a > location-sorted list is appealing in its simplicity. Though it > can cause a bit of fragmentation, it gives you constant time > lookup. Bonwick's vmem allocator ([1], section 4.4.2 and > following), apparently works quite well using this principle. > > But regardless of the approach, someone has yet to demonstrate > that this is actually a performance problem in the real world. ;-) > > [1] http://www.usenix.org/event/usenix01/full_papers/bonwick/ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:42:54 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92DCE16A4CE for ; Fri, 31 Oct 2003 12:42:54 -0800 (PST) Received: from mta1.adelphia.net (mta1.adelphia.net [68.168.78.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 391504400F for ; Fri, 31 Oct 2003 12:42:53 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta1.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031031204512.NNXX16569.mta1.adelphia.net@[10.1.0.9]>; Fri, 31 Oct 2003 15:45:12 -0500 From: andi payn To: Terry Lambert In-Reply-To: <3FA22EF1.39B64387@mindspring.com> References: <1067529247.36829.2138.camel@verdammt.falcotronic.net> <3FA22EF1.39B64387@mindspring.com> Content-Type: text/plain Message-Id: <1067632970.825.164.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 12:42:51 -0800 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: kevent and related stuff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:42:54 -0000 On Fri, 2003-10-31 at 01:44, Terry Lambert wrote: > andi payn wrote: > > First, some background: On Irix and Linux, fam works by asking the > > kernel to send it a signal whenever the specified accesses occur. On > > FreeBSD, since there is no imon interface and no dnotify fcntl, it > > instead works by periodically stating all of the files it's > > watching--which is obviously not as good. The fam FAQ suggests that > > FreeBSD users should adapt fam to use the kevent interface. > > Yes. The "file access monitor" tool is the classic argument. The "classic argument" for what? As far as I can tell, the fam FAQ is only arguing that fam needs to be adapted to use kevent. Why do I get the impression that I've inadvertently opened a can of worms that had only recently been shoved back into the can? > > * I think (but I'm not sure) that kevent doesn't notify at all if the > > only change to a file is its ATIME. If I'm right, this makes kevent > > completely useless for fam. Adding a NOTE_ACCESS or something similar > > would fix this. Since I'm pretty new to FreeBSD: What process do I go > > through to figure out whether anyone else wants this, whether the > > interface I've come up with is acceptable, etc.? And, once I write the > > code, do I submit it as a pr? > > You add it, submit it as a PR, if send-pr will work from your > machine properly, discuss it on the lists, and if someone with > a commit bit has the time and likes the idea, it will be committed. OK, that's what I would have guessed/hoped. And I'd assume it's worth splitting separatable issues into separate patches (e.g., NOTE_ACCESS doesn't rely on anything else changing). > > * The kevent mechanism doesn't monitor directories in a sufficient way > > to make fam happy. If you change a file in a directory that you're > > watching, unlike imon or dnotify, kevent won't see anything worth > > reporting at all. This means that for directory monitoring, kevent is > > useless as-is. Again, if I wanted to patch kevent to provide this > > additional notification, would others want this? > > I'm not sure that this is correct, unless you are talking about > monitoring all files in a directory by merely monitoring the > directory. If you make a modification to the file metadata (e.g. > add a link or rename it), then you will be notified that the > directory has changed. Well, the way imon works, you get notified whenever a file in the directory changes--and this includes a change to ATIME or MTIME. Presumably this is because you could have a GUI folder displaying, or even sorting by, that value, and SGI wanted that to be updated in real time just like anything else. In fact, if you look at the way fam works without kernel support (e.g., the way it works on FreeBSD right now) you get such notifications. Therefore, if fam were converted to use kevent, not having such notifications could break existing FreeBSD usage of fam (as well as being incompatible with usage on other platforms). (By the way, dnotify will, in that situation, notify you that something in the directory has changed, but then you have to go stat all of the files in the directory to see which one--which is a bit ugly, to say the least. But the dnotify patch to fam actually does this, so fam can work the way it's supposed to.) > The argument against subhierarchy monitoring is that it will, by > definition, stop at the directory level, and it can not be > successfully implemented for all FS types. If an extra flag were added (say, "EV_CONTAINED" to scan one level down), and this could not be implemented for some FS type, then trying to add such a notification would fail for such FS types. In which case the app would do whatever's appropriate--decide not to monitor files within that directory, or fall back to explicitly monitoring all files, or spit out a message and abort. In fam's case, it would fall back to monitoring all of the files. As it already does when, e.g., imon support is missing on some filesystems. More important, trying to add a vnode notification with _any_ flags already fails for anything but UFS--so fam had better be prepared to fall back when kevent fails! So, the fact that contents-monitoring won't work on every filesystem is not much of an argument against implementing it where it can work. > > * When two equivalent events appear in the queue, kevent aggregates > > them. This means that if there are two updates to a file since the last > > time you checked, you'll only see the most recent one. For some uses of > > fam (keeping a folder window up to date), this is what you want; for > > others (keeping track of how often a file is read), this is useless. The > > only solution I can think of is to add an additional flag, or some other > > way to specify that you want duplicated events. > > This is the classic "edge triggered vs. level triggered" argument > that Linux people bring up every time someone suggest they implement > kqueue in Linux. Yes, but the argument can be avoided entirely if it's possible to provide both edge-triggered and level-triggered behavior (on the basis of a flag) with almost no additional code complexity. The fact that linux people like to insist that there's a right way and a wrong way and FreeBSD does it wrong is irrelevant; if both ways are possible, why not provide both? > This is easily fixable: you seperate the flag from the data, adding > an additional argument to KNOTE(). This also has the side effect > of removing the restriction on the PID size, which is imposed by > the limited number of bits left over for representing the PID. > > This is a trivial change, and I've done it several times. OK, it's a trivial change to the kernel, but doesn't it break every piece of existing code that uses kevent? A "don't aggregate duplicates" flag, off by default, would have no effect on existing code, and would give new code the choice. "Every piece of existing code that uses kevent" may well be only a handful of code, in which case this compatibility isn't much of an argument; if so, feel free to correct me. > > * Unlike imon and dnotify, kevent doesn't provide any kind of callback > > mechanism; instead, you have to poll the queue for events. Would it be > > useful to specify another flag/parameter that would tell the kernel to > > signal the monitoring process whenever an event is available? (It would > > certainly make the fam code easier to write--but if it's not useful > > anywhere else, that's probably not enough.) > > You can SIGPOLL on the event descriptor returned by kqueue(). You > can use it in a select() or poll() call. You can pass it to another > kqueue() as an EVFILT_READ event. > > Snding signals ("callbacks") is probably the absolutely least > efficient way of getting the notification back. The presumption > here (and it's likely a good one) is that, rather than polling, > your application will be event driven, and get the events by > blocking and waiting for them. The point isn't (just) how user code should be written; it's how fam is already written. Converting fam's dnotify code to a signaling kevent would be a matter of half an hour's work; writing code for a mechanism that doesn't work like either dnotify or imon would be substantially less trivial. However, adding signaling support to the kernel is also obviously non-trivial. That's why, as I said before, if this behavior is not useful anywhere else, that's probably not enough reason to add it. > > * The kevent vnode stuff apparently only works on UFS. And it looks like > > it would be a major project to port it to other filesystems. > > It's actually pretty trivial, so long as you know the FS you are > porting it to. The notifications for many things should probably > be migrated to the VFS layer, instead (see Darwin's implementation). That does make sense; I'll look into it. > > Would this be useful for anything other than improving fam? > > Sure; it would be as useful for other FS's as it's useful in UFS > now. The primary utility (IMO) is for GUI interfaces which want > to update their displays in as close to real time as possible. Except that lots of existing file managers and other GUIs already use fam, and I don't think many use kevent. (Of course if kevent were ported to linux, that would probably change....) So, improving kevent for the benefit of file managers may not be particularly useful. > > What about a port of > > the imon kernel interface (and/or the dnotify fcntl) to FreeBSD instead? > > The way Linux people feel about "edge vs. level triggered" kqueue > is about the same way FreeBSD people feel about "dnotify"... but > there's no obvious way to fix the complaints about "dnotify". The complaints being the signaling mechanism that it uses? Or is there something else wrong with it? > imon is pretty useless; if it would be implemented at all, the way > to do it is in terms of kevents. Either way, you are resolving the > kqueue "issue", so you might as well use kqueue. Well, for imon to be implemented in terms of kevents would require the changes I mentioned above. If people were unwilling to accept NOTE_ACCESS, EV_CONTAINED, etc., but willing to accept imon, then you wouldn't implement imon in terms of kqueue. If they were willing to accept those changes, then you're right, there'd be little or no reason to implement imon. > > * The kqueue doesn't appear to have any maximum size. If this is true, > > the dnotify/fam problem where you get hideous errors from overflowing > > queues wouldn't be an issue, but you could instead end up wasting > > massive amounts of memory in the kernel if you didn't get around to > > reading the queue.... Which is it? > > This is not strictly true; with the non-contract kqueue interface, it > will aggregate the notes on a per object basis, so it's very hard to > overflow (you'd have to monitor more things than you have memory > available to monitor). OK, so you won't get the overflow issue that fam's dnotify patch had to deal with. Which is good. > > Any answers, or pointers to where I can find these answers, would be > > greatly appreciated. > > I don't pretend that my answers are authoritative; however, having > done what you want to do for two commercial companies now, I can > tell you the approach I describe (using a contract between the > kernel an user space, and separating the parameter from the flag > bits) will work. 8-). > > In fact, if you check the -current archives from about two years > ago in June or July or so, you will see patches that perform this > separation, and which add support for System V IPC message queues > sending events, thereby allowing them to be selected/polled/etc. > via their kqueue descriptor. This brings up another question: When I try to scan the archives, they only go back about 8 months. Where are the old archives? Actually, it brings up another question: Presumably these patches were suggested and rejected; in other words, the FreeBSD community didn't want this separation. Therefore, it might be worth pitching a different change even if it doesn't sound as good.... (Maybe FreeBSD developers aren't supposed to have ideas like this one, or the one about imon above? If so, I apologize; too many years in linuxland and/or corporate development land have warped my fragile little mind....) From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:43:01 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C512716A4CE for ; Fri, 31 Oct 2003 12:43:01 -0800 (PST) Received: from basement.kutulu.org (pcp03610121pcs.longhl01.md.comcast.net [68.49.239.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id D81CC44011 for ; Fri, 31 Oct 2003 12:43:00 -0800 (PST) (envelope-from kutulu@kutulu.org) Received: from wombat.localnet (wombat.localnet [192.168.69.3]) by basement.kutulu.org (Postfix) with ESMTP id 38D96AA2E; Fri, 31 Oct 2003 15:43:00 -0500 (EST) Received: by wombat.localnet (Postfix, from userid 1001) id 4387DB855; Fri, 31 Oct 2003 15:42:20 -0500 (EST) Date: Fri, 31 Oct 2003 15:42:20 -0500 From: Michael Edenfield To: "W. D." Message-ID: <20031031204220.GC54594@wombat.localnet> Mail-Followup-To: "W. D." , freebsd-hackers@freebsd.org References: <5.1.0.14.2.20031031134420.04813850@209.152.117.178> <3F9E4FB4.9487515F@yahoo.com.br> <3F9E4FB4.9487515F@yahoo.com.br> <5.1.0.14.2.20031031134420.04813850@209.152.117.178> <5.1.0.14.2.20031031141841.053bd6b0@209.152.117.178> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="32u276st3Jlj2kUU" Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20031031141841.053bd6b0@209.152.117.178> X-Mailer: Mutt http://www.mutt.org/ X-Accept-Language: en X-PGP-Key: http://www.kutulu.org/pgp/kutulu.asc X-PGP-Fingerprint: 1CE0 3C31 7013 D529 406D 37DC 09CC CD84 A46C 878F User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: Kylix in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:43:01 -0000 --32u276st3Jlj2kUU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * W. D. [031031 15:18]: > Hmmmm. Which Linux would be most compatible? >=20 > At 14:12 10/31/2003, Michael Edenfield wrote: > >f7173a.jpg Re Kylix in FreeBSD1.ems>=20 > >Content-Type: text/plain; charset=3Dus-ascii > >Content-Disposition: inline > > > >* W. D. [031031 14:45]: > >> Does this mean that one could possibly develop some GUI programs > >> on Linux, them compile them to run on FreeBSD? Or, can one only > >> compile command line apps? > > > >This should, in theory, be possible. Kylix links against Qt and some > >additional CLX runtime libraries, which are covered under a > >dual-lisenced: if you pay for Kylix you get a commercial lisence for Qt > >and CLX, if you use the Open Kylix version you get GPL'd copies of the > >license. As far as I can tell, the problem with Kylix on FreeBSD is the > >IDE itself, using customized WINE-like libraries internally, and has > >nothing to do with the output of the compiler/linker. Borland "officially" supports RedHat, Mandrake, and SuSE. The details are at http://www.borland.com/kylix. But anything with a recent glibc version and GTK installed will work. --Mike --32u276st3Jlj2kUU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/oskrCczNhKRsh48RAt8GAJ9MEOQT1Mwi7Bbs7/zDb/6o2jVzSwCguEv/ xcSTYW/j4d0yNfSVy18hR4k= =0ysS -----END PGP SIGNATURE----- --32u276st3Jlj2kUU-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:55:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 769AB16A4CE for ; Fri, 31 Oct 2003 12:55:08 -0800 (PST) Received: from anubis.ecci.ucr.ac.cr (anubis.ecci.ucr.ac.cr [163.178.104.133]) by mx1.FreeBSD.org (Postfix) with SMTP id D7F8C43F85 for ; Fri, 31 Oct 2003 12:55:06 -0800 (PST) (envelope-from braulio@solsoft.co.cr) Received: (qmail 31728 invoked by uid 0); 31 Oct 2003 20:56:33 -0000 Received: from chacal.ecci.ucr.ac.cr (HELO OF247) (163.178.104.130) by anubis.ecci.ucr.ac.cr with SMTP; 31 Oct 2003 20:56:33 -0000 Message-ID: <008a01c39ff0$47cf6f10$9e01010a@ecci.ucr.ac.cr> From: =?iso-8859-1?Q?Braulio_Jos=E9_Solano_Rojas?= To: "Michael Edenfield" , "W. D." References: <5.1.0.14.2.20031031134420.04813850@209.152.117.178><3F9E4FB4.9487515F@yahoo.com.br> <3F9E4FB4.9487515F@yahoo.com.br><5.1.0.14.2.20031031134420.04813850@209.152.117.178><5.1.0.14.2.20031031141841.053bd6b0@209.152.117.178> <20031031204220.GC54594@wombat.localnet> Date: Fri, 31 Oct 2003 14:48:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: freebsd-hackers@freebsd.org Subject: Re: Kylix in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:55:08 -0000 Hi! I do not know about the C++ part of Kylix, but about the Delphi part, maybe it could be replaced with FreePascal (http://www.freepascal.org/). There are even some projects that try to produce an IDE similar to Delphi (http://www.freepascal.org/links.html). Has anyone gived a try to FreePascal? Regards, B. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 13:20:36 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EB3116A4CF for ; Fri, 31 Oct 2003 13:20:36 -0800 (PST) Received: from mta4.adelphia.net (mta4.adelphia.net [68.168.78.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0412743FAF for ; Fri, 31 Oct 2003 13:20:35 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta4.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031031212037.MRWM16324.mta4.adelphia.net@[10.1.0.9]>; Fri, 31 Oct 2003 16:20:37 -0500 From: andi payn To: "M. Warner Losh" In-Reply-To: <20031031.130229.132929054.imp@bsdimp.com> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <20031031162757.GA56981@walton.maths.tcd.ie> <1067628015.825.64.camel@verdammt.falcotronic.net> <20031031.130229.132929054.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1067635232.825.202.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 13:20:33 -0800 Content-Transfer-Encoding: 7bit cc: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 21:20:36 -0000 On Fri, 2003-10-31 at 12:02, M. Warner Losh wrote: > In message: <1067628015.825.64.camel@verdammt.falcotronic.net> > andi payn writes: > : On Fri, 2003-10-31 at 08:27, David Malone wrote: > : > On Thu, Oct 30, 2003 at 07:46:38AM -0800, andi payn wrote: > : > > In FreeBSD, this doesn't work; you just get EINVAL. > : > > : > I believe this is because of a security problem discovered a few > : > years ago, where you could open a file like /dev/io for neither > : > read nor write but still get the special privelages associated with > : > having the file open. > : > > : > If you were to allow people to open files without read or write > : > permission you'd need to fix problems like this in a different way. > : > : It seems to me that the right way to fix this is to ensure that only the > : superuser can open /dev/io device, no matter what permissions are on it. > > This might not be a bad idea, but it would force at least one company > (mine) to rewrite at least some of their software to run as root. we > currently don't run some things as root because we don't trust them. > But then you are getting into special case kludges. Better to require > that it is opened read or write permissions. Well, the io(4) manpage says: > In addition to any file access permissions on /dev/io, the kernel > enforces that only the super-user may open this device. If this is not true--and especially if it's not true by design--then the manpage ought to be changed. If O_NOACCESS were added, and /dev/io were not changed to match the manpage, then it could instead be changed so that read-only access grants full I/O privileges, but no access does not? > : Are there any other special devices like this in FreeBSD? > > Rewind units on tape drives? If there's no access check done, and I > open the rewind unit as joe-smoe? The close code is what does the > rewind, and you don't have enough knowledge to know if the tape was > opened r/w there. Thanks; that's a good example. Do you have an example of a specific driver so I can look at the code and see what would need to be done? From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 13:30:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 206AA16A4CF for ; Fri, 31 Oct 2003 13:30:04 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1425743F93 for ; Fri, 31 Oct 2003 13:30:03 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9VLU1E7062416; Fri, 31 Oct 2003 14:30:01 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 31 Oct 2003 14:29:59 -0700 (MST) Message-Id: <20031031.142959.33240958.imp@bsdimp.com> To: andi_payn@speedymail.org From: "M. Warner Losh" In-Reply-To: <1067635232.825.202.camel@verdammt.falcotronic.net> References: <1067628015.825.64.camel@verdammt.falcotronic.net> <20031031.130229.132929054.imp@bsdimp.com> <1067635232.825.202.camel@verdammt.falcotronic.net> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 21:30:04 -0000 In message: <1067635232.825.202.camel@verdammt.falcotronic.net> andi payn writes: : > : Are there any other special devices like this in FreeBSD? : > : > Rewind units on tape drives? If there's no access check done, and I : > open the rewind unit as joe-smoe? The close code is what does the : > rewind, and you don't have enough knowledge to know if the tape was : > opened r/w there. Actually, it looks like there's a flags parameter passed to close, which I think could be used to 'know'. No one uses it now. : Thanks; that's a good example. Do you have an example of a specific : driver so I can look at the code and see what would need to be done? src/sys/cam/scsi/scsi_sa.c. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 15:13:45 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2508416A4CE for ; Fri, 31 Oct 2003 15:13:45 -0800 (PST) Received: from mta4.adelphia.net (mta4.adelphia.net [68.168.78.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id F360F43FDF for ; Fri, 31 Oct 2003 15:13:43 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta13.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031031230105.IEGX20181.mta13.adelphia.net@[10.1.0.9]>; Fri, 31 Oct 2003 18:01:05 -0500 From: andi payn To: "M. Warner Losh" In-Reply-To: <20031031.142959.33240958.imp@bsdimp.com> References: <1067628015.825.64.camel@verdammt.falcotronic.net> <20031031.130229.132929054.imp@bsdimp.com> <1067635232.825.202.camel@verdammt.falcotronic.net> <20031031.142959.33240958.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1067641263.825.298.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 15:01:04 -0800 Content-Transfer-Encoding: 7bit cc: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 23:13:45 -0000 Before I go any further, I'd like some indication of whether this is worth pursuing. In particular, if any device driver issues can be resolved easily, and if the FFLAGS conversion is efficient enough (I'll look into whether it's better to do this the linux way, or to use slightly more complicated FFLAGS and OFLAGS macros), is this a good idea, or a bad one? I personally think that being able to fstat anything you can stat, fchdir anything you can chdir, add ioctl's that don't require read access, etc. would be a good thing. And of course my original motivation (being able to kqueue-monitor any vnode you can stat) also still sounds like a good one to me. However, if nobody agrees, I'll drop it. Meanwhile: On Fri, 2003-10-31 at 13:29, M. Warner Losh wrote: > In message: <1067635232.825.202.camel@verdammt.falcotronic.net> > andi payn writes: > : > : Are there any other special devices like this in FreeBSD? > : > > : > Rewind units on tape drives? If there's no access check done, and I > : > open the rewind unit as joe-smoe? The close code is what does the > : > rewind, and you don't have enough knowledge to know if the tape was > : > opened r/w there. > > Actually, it looks like there's a flags parameter passed to close, > which I think could be used to 'know'. No one uses it now. > > : Thanks; that's a good example. Do you have an example of a specific > : driver so I can look at the code and see what would need to be done? > > src/sys/cam/scsi/scsi_sa.c. OK, thanks again. While it looks like the problem you mentioned would be easy to work around, I can see a few other potential problems here. For example, the driver seems to give anyone who opens its device an inherent exclusive lock: a successful open always sets SA_FLAG_OPEN, and anyone who tries to do an open when SA_FLAG_OPEN is set will get an EBUSY no matter what. (Notice that linux's st_open has similar issues, and this doesn't cause a problem in linux--I'll have to look deeper to see why.) I'd assume other drivers might have similar issues--in fact, a quick scan shows a handful of other devices that would need to be checked. Presumably, the way this _should_ work is that opening a device file with O_NOACCESS shouldn't create a lock, set up for any kind of special handling on close, or do anything else except give you an fd. And of course that fd shouldn't be usable for anything you shouldn't be allowed to do (that is, it can be fstat'd iff the file you opened could be stat'd, etc.). Next time I reboot to linux, I'll check what it does in a variety of similar cases (and trace through the kernel if it's not obvious how and why). From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 02:15:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D76F416A4CE for ; Sat, 1 Nov 2003 02:15:41 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4584443FA3 for ; Sat, 1 Nov 2003 02:15:40 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) hA1AFFRo047652; Sat, 1 Nov 2003 10:15:16 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)hA1AFE1l047651; Sat, 1 Nov 2003 10:15:14 GMT (envelope-from mark@grondar.org) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])hA1ADH4L032554; Sat, 1 Nov 2003 10:13:18 GMT (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200311011013.hA1ADH4L032554@grimreaper.grondar.org> To: "M. Warner Losh" In-Reply-To: Your message of "Fri, 31 Oct 2003 12:57:53 MST." <20031031.125753.124085663.imp@bsdimp.com> Date: Sat, 01 Nov 2003 10:13:16 +0000 Sender: mark@grondar.org X-Spam-Status: No, hits=0.2 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_NO_LOWER,IN_REP_TO, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-hackers@freebsd.org Subject: Re: User asks: can we decouple device vendor IDs from drivers? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 10:15:42 -0000 "M. Warner Losh" writes: > The problem with decoupling things entirely from the drivers is that > many drivers will say "if I have this revision of that card, do this > workaround." or "if I'm this or newer, I have this feature" both of > which are broken by the kernel forcing the driver to service a given > hunk of hardware. Hmm. Careful design may sort this out, methinks. If the file (which sounds analagous to /boot/device.hints to me) turned devid's into generic griver requrements (DEVID(0x04589045) == driver(foo) revision(bar) flags(baz, qux)) would that not be usable? (/me wonders if he has the time to do this - he's certainly interested) > The other down side is that when you bork the alias > file on solaris, you are so hozed. ... like most of the files in /boot/... > However, it would make the dynamic loading of drivers easier. I really like to concept of configuring things with vi(1), instead of with gcc :-) M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 04:03:49 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D4E716A4CE for ; Sat, 1 Nov 2003 04:03:49 -0800 (PST) Received: from pc5.i.0x5.de (sam.staff.webport.de [217.145.105.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 619C443FA3 for ; Sat, 1 Nov 2003 04:03:47 -0800 (PST) (envelope-from nicolas@dauerreden.de) Received: from pc5.i.0x5.de (localhost [127.0.0.1]) by pc5.i.0x5.de (8.12.8p2/8.12.8) with ESMTP id hA1C3jPA077358 for ; Sat, 1 Nov 2003 13:03:45 +0100 (CET) (envelope-from nicolas@pc5.i.0x5.de) Received: (from nicolas@localhost) by pc5.i.0x5.de (8.12.8p2/8.12.8/Submit) id hA1Bpw1E058027 for freebsd-hackers@freebsd.org; Sat, 1 Nov 2003 12:51:58 +0100 (CET) Date: Sat, 1 Nov 2003 12:51:58 +0100 From: Nicolas Rachinsky To: freebsd-hackers@freebsd.org Message-ID: <20031101115158.GA48033@pc5.i.0x5.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20031031014331.A71967@xorpc.icir.org> <200310312016.h9VKGv8X006950@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310312016.h9VKGv8X006950@lurza.secnetix.de> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: C11ABC0E X-PGP-Fingerprint: 19DB 8392 8FE0 814A 7362 EEBD A53B 526A C11A BC0E X-PGP-Key: http://www.rachinsky.de/nicolas/nicolas_rachinsky.asc X-SECURITY: Never trust a running system User-Agent: Mutt/1.5.4i Subject: Re: RFC: proposed new builtin for /bin/sh (associative arrays) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 12:03:49 -0000 * Oliver Fromme [2003-10-31 21:16 +0100]: > Maybe I'm not understanding your intentions, but isn't that > already possible using "set | sed -n '/^foo_/s/=.*//p'"? > > Or do you want to avoid external programs? In that case it > would be a little bit more difficult to do, but it's still > possible to do with existing builtins: > > indexes() > { > for i in `set`; do > case $i in > $1*) echo ${i%%=*} > esac > done > } I think both of these could fail with multiline values. Nicolas From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 11:22:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF58A16A4CE for ; Sat, 1 Nov 2003 11:22:21 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79BA543FBD for ; Sat, 1 Nov 2003 11:22:20 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id hA1JMJeG011595; Sat, 1 Nov 2003 12:22:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 01 Nov 2003 12:22:18 -0700 (MST) Message-Id: <20031101.122218.13771065.imp@bsdimp.com> To: mark@grondar.org From: "M. Warner Losh" In-Reply-To: <200311011013.hA1ADH4L032554@grimreaper.grondar.org> References: <20031031.125753.124085663.imp@bsdimp.com> <200311011013.hA1ADH4L032554@grimreaper.grondar.org> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: User asks: can we decouple device vendor IDs from drivers? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 19:22:22 -0000 In message: <200311011013.hA1ADH4L032554@grimreaper.grondar.org> Mark Murray writes: : "M. Warner Losh" writes: : > The problem with decoupling things entirely from the drivers is that : > many drivers will say "if I have this revision of that card, do this : > workaround." or "if I'm this or newer, I have this feature" both of : > which are broken by the kernel forcing the driver to service a given : > hunk of hardware. : : Hmm. Careful design may sort this out, methinks. If the file (which : sounds analagous to /boot/device.hints to me) turned devid's into : generic griver requrements (DEVID(0x04589045) == driver(foo) revision(bar) : flags(baz, qux)) would that not be usable? (/me wonders if he has the time : to do this - he's certainly interested) I think you miss the point of my objection. It isn't to match the card. That's trivially easy to do in a config file like the hints file (boot loader). The problem is that drivers often have code that looks like: if (id == CARD_3C589) set some flags else if (id == CARD_3C572) set some flags else some defaults. Now then, if 3com comes out with a new card that's like the 3c572 (say the 3c574), then the driver still has to be changed to grok the new card. However, if you say 'map this id to that id' then you could say 'map 3c574 to 3c572' and the driver would just work. See the difference? In your case, the default flags would be set, and the device would fail to work. In my case the driver thinks it is talking to a 3c572, and sets the flags correctly for that card. Maybe you need both, but the mapping feature is critical. Also, you need to do the same sorts of matching functionality that devd has to match things. If this replaces the 'probe' part of the system, then you also have to deal with those busses that aren't self-identifying. : > The other down side is that when you bork the alias : > file on solaris, you are so hozed. : : ... like most of the files in /boot/... No. You can boot if /boot is f*'d up fairly easily. If all the driver information is codified in one file, then you are one file away from having a totally hozed system. With the rest of the files in /boot/ there typically is a backup file that you can boot, ditto with kernel vs kernel.old. I've been ass raped by missing /etc/driver_aliases file on solaris many many times. I'm not keen on making it easier for freebsd to do this to its users. : > However, it would make the dynamic loading of drivers easier. : : I really like to concept of configuring things with vi(1), instead of : with gcc :-) You can like that concept all you want. It is not completely appropriate to the driver stuff. There's typically only one or two drivers in the tree that have a large traffic in adding devices: ed and wi. Most of the other drivers in the tree do need occasional devices added, but There's actually a lot of work here to make this work right, and I'm not trying to get in the way of it. I just don't want to wind up with a half-assed system in the end. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 13:47:13 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B8D316A4CE for ; Sat, 1 Nov 2003 13:47:13 -0800 (PST) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DA7043FBF for ; Sat, 1 Nov 2003 13:47:12 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38ldtjc.dialup.mindspring.com ([209.86.246.108] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AG3aM-0007N8-00; Sat, 01 Nov 2003 13:47:07 -0800 Message-ID: <3FA42803.BA6EDF62@mindspring.com> Date: Sat, 01 Nov 2003 13:39:15 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: andi payn References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <1067627608.825.56.camel@verdammt.falcotronic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4dbf0814f578a02a707b634d34702bb9d93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 21:47:13 -0000 andi payn wrote: > Now hold on. The standard (by which I you mean POSIX? or one of the UNIX > standards?) doesn't say that you can't have an additional flag called > O_NOACCESS with whatever value and meaning you want. A strictly conforming implementation can not expose things into the namespace that are not defined by the standard to be in the namespace, when a manifest constant specifying a conformance level is in scope. This is the main reason for things like _types.h. > Obviously, code that relies on such a flag will be non-portable, since > no standard defines such a flag, but that's fine, since the intended > uses (writing a FreeBSD-specific backend for fam, for example) aren't > expected to be portable anyway. Not just"not portable", but "fails to conform to standards". > If O_NOACCESS happens to be == O_ACCMODE on FreeBSD--just as it is on > linux--and if that happens to also be == O_WRONLY | O_RDWR (with no > other flags set), I don't see how that changes anything. Other than the security issues it raises, you mean, right? [ ... ] > > In which case, your example is (O_RDWR|O_WRONLY) == O_RDWR. The > > standard does not indicate whether the implementation is to use > > bits, or sequential manifest constants, only that the bits that > > make up the constants be in the range covered by O_ACCMODE. > > First, again, this is intended to be used for non-portable code, and > therefore, the fact that this happens not to be true on FreeBSD means > it's irrelevant that it could be true elsewhere. Especially since, if > O_NOACCESS were added to FreeBSD, it would still fail to exist entirely > on other platforms, which means it matters little what value it might > have if it did exist--code written to use O_NOACCESS won't compile on > platforms without O_NOACCESS. You nead to look at the implementation of VOP_OPEN in FreeBSD; specifically, you need to look at the fact that fp->f_flags is passed as one of its parameters, and that the FS is permitted to interpret these flags in an FS-dependent fashion. Then you need to at the fact that FreeBSD supports locadable FS types, and that there are third party FS's that proxy operations over the network, which can include a network version of the flags, and conversion back and forth could therefore end up being ambiguous. Really, it needs to be a bitmap internally in FreeBSD, as well, but that's a big step. > Second, any platform that defines O_NOACCESS could do so differently. On > FreeBSD, as on linux, the most sensible definition is O_NOACCESS == > O_WRONLY | O_RDWR == 3. Or a platform that defined O_RDONLY as 1 and > O_WRONLY as 2, the most sensible definition would be O_NOACCESS == 0. I pray this flag never gets adopted outside of Linux... > > In fact, externally, they are bits, but internally, in the kernel, > > they are manifest constants. > > Yes, FFLAGS and OFLAGS convert between the two. If you look at how this > works in the linux kernel, you'll see that O_RDONLY (0) converts to > FREAD (1); O_WRONLY (1) to FWRITE (2); O_RDWR (2) to FREAD | FWRITE (3); > and O_NOACCESS (3) to 0. This could be done the same way in FreeBSD.* > > * Actually, this is a tiny lie; linux has a 2-bit internal access flags > value which it derives in this way, and uses the original passed-in > flags for everything except access. FreeBSD instead just adds 1, relying > on the fact that the lower 2 bits will never be 3, and therefore all of > the other bits will stay the same. This means that enabling this value > would make the FFLAGS and OFLAGS macros slightly more complicated on > FreeBSD. It would be more useful to intern them as a bitmap, IMO, and get rid of the conversion. The problm is compatability with historical source code passing literal constants instead of manifest values. > > The most useful thing you could do with this, IMO, is opn a directory > > for fchdir(). > > Except that you can already do exactly this with chdir(). But I can see > that you might at some point want to check the directory before > chdir'ing to it, or pass an fd down into some function instead of a > string, and this would be useful in such a case. Or deal with issues of privilege granted merely by open. For example, on FreeBSD, an implementation of this would permit any normal user to do INB/OUTB to any I/O port on any hardare on the machine. This is a can of worms. > > Of course, allowing this on directories for which you > > are normally denied read/write permissions would be a neat way to > > escape from chroot'ed environments and compromise a host system... > > How would it allow that? If you can open files outside your chroot > environment--even files you would otherwise have read access to--it's > not much of a chroot! Mounted procfs within a chrooted environment. Admittedly, FreeBSD is moving away from procfs, but on Linux, it's a serious issue, since such basic utilities as "ps" and so on won't work without it. > > > Having O_NOACCESS would be useful for the fam port, for porting pieces > > > of lilo, and probably for other things I haven't thought of yet. (I > > > believe that either this was added to linux to support lilo, or the open > > > syscall just happened to work this way, and once the lilo developers > > > discovered this and took advantage of it, it's been retained that way > > > ever since to keep lilo working.) > > > > The latter is most likely. > > Actually, you'd be surprised at how much has been explicitly added to > the kernel (and, more, to the filesystem code, especially reiser) for > lilo's benefit. I wouldn't. I think it's "too much", and I'd hate to drag the same cruft into FreeBSD for the same reasons. One option for you would be to make this a kernel module... then it could be of use to the people who need it, while not bothering the rest of the world. Sort of like FreeBSD installing ports with restricted privileges by default, and requiring that you do some small amount of reconfiguration to get additional features in them at a reduced security level. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 13:52:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A5516A4CE for ; Sat, 1 Nov 2003 13:52:53 -0800 (PST) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0658343F75 for ; Sat, 1 Nov 2003 13:52:53 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38ldtjc.dialup.mindspring.com ([209.86.246.108] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AG3fi-0000ZF-00; Sat, 01 Nov 2003 13:52:39 -0800 Message-ID: <3FA42945.A5EA17C1@mindspring.com> Date: Sat, 01 Nov 2003 13:44:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <20031031162757.GA56981@walton.maths.tcd.ie> <20031031.130229.132929054.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4dbf0814f578a02a75d57a53f0dc480f8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org cc: andi_payn@speedymail.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 21:52:53 -0000 "M. Warner Losh" wrote: > Rewind units on tape drives? If there's no access check done, and I > open the rewind unit as joe-smoe? The close code is what does the > rewind, and you don't have enough knowledge to know if the tape was > opened r/w there. Which brings up the idea of passing fp->fd_flags to VOP_CLOSE()... -- Terry From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 14:40:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04C1516A4CE for ; Sat, 1 Nov 2003 14:40:53 -0800 (PST) Received: from orngca-mls03.socal.rr.com (mls03.hawaii.rr.com [66.75.160.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B81243F3F for ; Sat, 1 Nov 2003 14:40:52 -0800 (PST) (envelope-from sean@mcneil.com) Received: from blue.mcneil.com (cpe-66-75-176-109.socal.rr.com [66.75.176.109])hA1MepU01525 for ; Sat, 1 Nov 2003 14:40:51 -0800 (PST) Received: from [66.75.176.109] (mcneil.com [66.75.176.109]) by blue.mcneil.com (8.12.9p2/8.12.9) with ESMTP id hA1Meogh065602 for ; Sat, 1 Nov 2003 14:40:51 -0800 (PST) (envelope-from sean@mcneil.com) From: Sean McNeil To: freebsd-hackers@freebsd.org Content-Type: text/plain Organization: Sean McNeil Consulting Message-Id: <1067726450.65578.6.camel@blue.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 01 Nov 2003 14:40:50 -0800 Content-Transfer-Encoding: 7bit X-DCC-NIET-Metrics: blue.mcneil.com 1080; Body=1 Fuz1=1 Fuz2=1 Subject: question about user space addressed, mmap, and getting phys address X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 22:40:53 -0000 Hi everyone, Sorry I am not on the list, but I was hoping someone here might be able to help me. I have a design that I cannot change that does the following: 1) Calls mmap on a chunk of memory that the device driver uses to DMA to a video decoder. 2) This chunk of memory is treated as several DMA buffers. There is an ioctl setup to indicate when a section of that memory is being used and when it is freed (usage count). I need to take the address from the mmap, add an offset, send it through an ioctl, and then relate it back to the physical address that it was originally mapped from. Unfortunately, the address I get from the ioctl is a user-space address and when I use vtophys I get back 0. Is there some other mechanism to convert a user-space address to a physical address? Any and all help will be greatly appreciated. Thanks in advance, Sean From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 15:34:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05E2416A4CE for ; Sat, 1 Nov 2003 15:34:14 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27E0D43F93 for ; Sat, 1 Nov 2003 15:34:13 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id hA1NYC8i034253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 1 Nov 2003 18:34:12 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id hA1NYCiw034252 for freebsd-hackers@freebsd.org; Sat, 1 Nov 2003 18:34:12 -0500 (EST) Date: Sat, 1 Nov 2003 18:34:12 -0500 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031101233412.GA33988@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: dhclient & dynamic DNS updates X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 23:34:14 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm having problems getting dhclient to do dynamic DNS updates. I'm wondering if anyone else has gotten this working. I want dhclient to dynamically update a forward zone. I can't have the server do it, as I don't control the server (cable modem setup). I know I have named set up right, as I can have dhcpd update (at a different site) update the server just fine. So, my basic dynamic DNS config seems to be ok. I put the same key config and zone config in /etc/dhclient.conf. Right off the bat I noticed something odd, in dhcpd.conf 'secret' (in key) takes an argument in double quotes, qutoes in dhclient.conf give an error. With no quotes there's no error. Similarly for 'key' (in zone). Beyond that the only other things I've added are: prepend domain-name-servers 127.0.0.1; supersede domain-name "my.example.com"; send fqdn.fqdn "hostname.my.example.com."; send fqdn.encoded on; send fqdn.server-update off; Best I can tell from the config this should make dhclient send a dynamic DNS update to the server listed as "primary" in the zone section adding hostname.my.example.com. However, tcpdump shows no DNS update packets of any kind coming from the machine running dhclient. What's the magic to get dhclient to emit a dynamic DNS update? --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/pEL0Nh6mMG5yMTYRAm1BAKCIReH1yG8oR0Ka312z4uvSqNKwXQCeIcmb GUUYhlFxIpN+YmCZCZa8pX4= =Q0NS -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 16:28:30 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3418416A4CE for ; Sat, 1 Nov 2003 16:28:30 -0800 (PST) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C23B443F93 for ; Sat, 1 Nov 2003 16:28:28 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta13.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031102002111.CWIE20181.mta13.adelphia.net@[10.1.0.9]>; Sat, 1 Nov 2003 19:21:11 -0500 From: andi payn To: Terry Lambert In-Reply-To: <3FA42803.BA6EDF62@mindspring.com> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <3FA22930.C6EC97A9@mindspring.com> <1067627608.825.56.camel@verdammt.falcotronic.net> <3FA42803.BA6EDF62@mindspring.com> Content-Type: text/plain Message-Id: <1067732469.825.487.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 01 Nov 2003 16:21:10 -0800 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2003 00:28:30 -0000 On Sat, 2003-11-01 at 13:39, Terry Lambert wrote: > andi payn wrote: > > Now hold on. The standard (by which I you mean POSIX? or one of the UNIX [...] > A strictly conforming implementation can not expose things into > the namespace that are not defined by the standard to be in the > namespace, when a manifest constant specifying a conformance level > is in scope. Yes. As I mentioned at the beginning, you don't get O_NOACCESS in linux by pulling in the standard headers, and I wasn't suggesting anything different. [...] > Not just"not portable", but "fails to conform to standards". Note that the Single UNIX Specification says that open _may_ fail with EINVAL if the value of the oflag argument does not contain exactly one of the three access modes. So, if you've written code (for some reason) that expects that it _must_ fail in such a situation, that's non-comforming code. > > If O_NOACCESS happens to be == O_ACCMODE on FreeBSD--just as it is on > > linux--and if that happens to also be == O_WRONLY | O_RDWR (with no > > other flags set), I don't see how that changes anything. > > Other than the security issues it raises, you mean, right? Are you saying that having O_NOACCESS == O_ACCMODE raises security issues beyond any raised by having O_NOACCESS at all? Or is it the fact that it would the same value as in linux, so linux code (whether recompiled for FreeBSD or run under ABI compatibility) that expected to be able to open a file without getting read or write access would be able to do so? Again, I don't see how this raises security issues beyond whatever may be inherent in O_NOACCESS, if any. Or are you just getting ahead of yourself? > You nead to look at the implementation of VOP_OPEN in FreeBSD; > specifically, you need to look at the fact that fp->f_flags is > passed as one of its parameters, and that the FS is permitted > to interpret these flags in an FS-dependent fashion. Which version are you looking at? In 5.1, what gets passed if fmode, which is ultimately the result of applying FFLAGS to the original flags passed to open. As for the FS being permitted to interpret these flags in an FS-dependent fashion: I'm pretty sure that a FS that interpreted FREAD to mean write permission, or O_APPEND to mean truncate, would not be considered good. Any FS that assumes that it can read if FREAD is set, and it can write if FWRITE is set, will work correctly when neither is set. And any filesystem that doesn't work this way is already broken. However, there may be some FS's with more subtle issues. For example, an FS might assume that if it doesn't have FWRITE, it must have FREAD. This is (probably) not guaranteed anywhere--but it is currently true, a fact which is logically deducible from the values of the flags, the way FFLAGS works, and the fact that O_ACCMODE returns EINVAL. If this ceases to be true, such an FS might do things wrong. I'd have no problem with providing for each filesystem to specify "I can handle no-access opens," and for any FS that doesn't do so, the kernel would return EINVAL before even talking to the FS (thus preserving current behavior); only if the FS does so could it ever get an fmode with neither FREAD nor FWRITE set. [...] > Really, it needs to be a bitmap internally in FreeBSD, as well, > but that's a big step. By "it needs to be a bitmap internally," you mean that fmode needs to be a bitmap? Well, then, good news: It already is. In fact, I think the equivalent parameter has been a bitmap for every *BSD and going back into AT&T Unix. Currently FFLAGS() is a macro that adds 1. Now, look at the original flags. The low two bits are the O_ACCMODE mask. This part is not a bitmap (O_RDONLY == 0, O_WRONLY == 1, and O_RDWR == 2). But once you add 1, the result is (FREAD == 1, FWRITE == 2, FREAD|FWRITE == 3 == 1|2). The flags value with O_ACCMODE masked out is already a bitmap (not just in FreeBSD; it's even defined to be one in the Single Unix Standard). Adding 1 to flags could only change any of these bits if the two low bits were both 1. But this is not possible, since we've already checked that (flags & O_ACCMODE) != O_ACCMODE. Therefore, fmode is a bitmap. QED. Now, what I'm proposing would allow the low two bits to be 11, which FFLAGS would map to 00 (as it does in linux). While adding 1 does this, it would also affect the higher bits (O_NOACCESS | O_NOBLOCK + 1 is not 0 | O_NOBLOCK, it's 0 | O_APPEND). Therefore, a slightly more complicated FFLAGS is needed if we want fmode to remain a bitmap. (The alternative--the way linux does this--is to pass along both flags and fflags, and using fflags only for the low two bits, which is ugly and messy. I'd much prefer a slightly more complicated FFLAGS.) > > Second, any platform that defines O_NOACCESS could do so differently. On > > FreeBSD, as on linux, the most sensible definition is O_NOACCESS == > > O_WRONLY | O_RDWR == 3. Or a platform that defined O_RDONLY as 1 and > > O_WRONLY as 2, the most sensible definition would be O_NOACCESS == 0. > > I pray this flag never gets adopted outside of Linux... Is this just a non-sequitur, or are you praying that it never gets adopted because it could have different definitions or different systems? In the same way that O_RDONLY can be 0 or 1 on two different platforms, O_NOACCESS could be 3 or 0 on two different platforms. That seems like a good thing, not a bad thing. [...] > Or deal with issues of privilege granted merely by open. For > example, on FreeBSD, an implementation of this would permit any > normal user to do INB/OUTB to any I/O port on any hardare on the > machine. > > This is a can of worms. You mean by opening /dev/io? There's already a thread about that. The manpage says that "In addition to any file access permissions on /dev/io, the kernel enforces that only the super-user may open this device." Unfortunately, the kernel appears to not enforce any such thing. That's the can of worms. Either the kernel needs to enforce it, or the manpage needs to stop saying that it does. Meanwhile, the manpage says that "even read-only access will grant the full I/O privileges." I'd say that /dev/io should be changed to not allow the privileges if neither FREAD or FWRITE is set (which would require no change to the manpage, or to existing apps, and would open no new security issues)--whichever way the other issue is fixed. > > > Of course, allowing this on directories for which you > > > are normally denied read/write permissions would be a neat way to > > > escape from chroot'ed environments and compromise a host system... > > > > How would it allow that? If you can open files outside your chroot > > environment--even files you would otherwise have read access to--it's > > not much of a chroot! > > Mounted procfs within a chrooted environment. Admittedly, FreeBSD > is moving away from procfs, but on Linux, it's a serious issue, > since such basic utilities as "ps" and so on won't work without it. So, being able to open a file and then fchdir to it would provide you with... exactly the same exploit that you can already get by chdir'd to it. There's no new security issue here. > > Actually, you'd be surprised at how much has been explicitly added to > > the kernel (and, more, to the filesystem code, especially reiser) for > > lilo's benefit. > > I wouldn't. I think it's "too much", and I'd hate to drag the same > cruft into FreeBSD for the same reasons. I agree completely. However, I don't think that adding O_NOACCESS is the same thing as dragging in dozens of device-specific and fs-specific ioctl's and two special flags values (if the flags == -1 or -2, it's no longer a bitfield and instead has a special meaning), etc. As opposed to those examples, NOACCESS is a single change, at a high level, with an obvious meaning, with fully general semantics that are the same on any fs/device that supports it. (In fact, I suspect that one of the special flags values was added because one of the lilo developers didn't know about NOACCESS, so instead of opening a device file NOACCESS to call an ioctl, he got new code added into the kernel to allow him to use a special value with open to pass through ioctl's to the parent device....) > One option for you would be to make this a kernel module... then it > could be of use to the people who need it, while not bothering the > rest of the world. That's not a bad idea! The kernel itself would still have to be changed to work through this module (when present), but it should be much easier in that case to verify that the default behavior (without the module) is identical to current behavior, than if the change were implemented directly in the kernel. Also, combining this with the idea of an fs being able to report whether or not it can handle O_NOACCESS: You should be able to disable this support for an fs at compile time or (for FS's which are in modules) at load time. That should be trivial to add. It might also be worth providing a mount option to disable it at mount time even when it is compiled in and enabled at load time (so I could have it on, say, /mnt/linux/usr, but not /mnt/linux, or on /usr but not /, or whatever). From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 17:06:13 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D3AE16A4CE for ; Sat, 1 Nov 2003 17:06:13 -0800 (PST) Received: from mta1.adelphia.net (mta1.adelphia.net [68.168.78.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AE6E43FA3 for ; Sat, 1 Nov 2003 17:06:12 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta1.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031102010838.UKYL16569.mta1.adelphia.net@[10.1.0.9]>; Sat, 1 Nov 2003 20:08:38 -0500 From: andi payn To: Terry Lambert In-Reply-To: <3FA42803.BA6EDF62@mindspring.com> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <3FA22930.C6EC97A9@mindspring.com> <1067627608.825.56.camel@verdammt.falcotronic.net> <3FA42803.BA6EDF62@mindspring.com> Content-Type: text/plain Message-Id: <1067732469.825.487.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 01 Nov 2003 17:06:10 -0800 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2003 01:06:13 -0000 On Sat, 2003-11-01 at 13:39, Terry Lambert wrote: > andi payn wrote: > > Now hold on. The standard (by which I you mean POSIX? or one of the UNIX [...] > A strictly conforming implementation can not expose things into > the namespace that are not defined by the standard to be in the > namespace, when a manifest constant specifying a conformance level > is in scope. Yes. As I mentioned at the beginning, you don't get O_NOACCESS in linux by pulling in the standard headers, and I wasn't suggesting anything different. [...] > Not just"not portable", but "fails to conform to standards". Note that the Single UNIX Specification says that open _may_ fail with EINVAL if the value of the oflag argument does not contain exactly one of the three access modes. So, if you've written code (for some reason) that expects that it _must_ fail in such a situation, that's non-comforming code. > > If O_NOACCESS happens to be == O_ACCMODE on FreeBSD--just as it is on > > linux--and if that happens to also be == O_WRONLY | O_RDWR (with no > > other flags set), I don't see how that changes anything. > > Other than the security issues it raises, you mean, right? Are you saying that having O_NOACCESS == O_ACCMODE raises security issues beyond any raised by having O_NOACCESS at all? Or is it the fact that it would the same value as in linux, so linux code (whether recompiled for FreeBSD or run under ABI compatibility) that expected to be able to open a file without getting read or write access would be able to do so? Again, I don't see how this raises security issues beyond whatever may be inherent in O_NOACCESS, if any. Or are you just getting ahead of yourself? > You nead to look at the implementation of VOP_OPEN in FreeBSD; > specifically, you need to look at the fact that fp->f_flags is > passed as one of its parameters, and that the FS is permitted > to interpret these flags in an FS-dependent fashion. Which version are you looking at? In 5.1, what gets passed if fmode, which is ultimately the result of applying FFLAGS to the original flags passed to open. As for the FS being permitted to interpret these flags in an FS-dependent fashion: I'm pretty sure that a FS that interpreted FREAD to mean write permission, or O_APPEND to mean truncate, would not be considered good. Any FS that assumes that it can read if FREAD is set, and it can write if FWRITE is set, will work correctly when neither is set. And any filesystem that doesn't work this way is already broken. However, there may be some FS's with more subtle issues. For example, an FS might assume that if it doesn't have FWRITE, it must have FREAD. This is (probably) not guaranteed anywhere--but it is currently true, a fact which is logically deducible from the values of the flags, the way FFLAGS works, and the fact that O_ACCMODE returns EINVAL. If this ceases to be true, such an FS might do things wrong. I'd have no problem with providing for each filesystem to specify "I can handle no-access opens," and for any FS that doesn't do so, the kernel would return EINVAL before even talking to the FS (thus preserving current behavior); only if the FS does so could it ever get an fmode with neither FREAD nor FWRITE set. [...] > Really, it needs to be a bitmap internally in FreeBSD, as well, > but that's a big step. By "it needs to be a bitmap internally," you mean that fmode needs to be a bitmap? Well, then, good news: It already is. In fact, I think the equivalent parameter has been a bitmap for every *BSD and going back into AT&T Unix. Currently FFLAGS() is a macro that adds 1. Now, look at the original flags. The low two bits are the O_ACCMODE mask. This part is not a bitmap (O_RDONLY == 0, O_WRONLY == 1, and O_RDWR == 2). But once you add 1, the result is (FREAD == 1, FWRITE == 2, FREAD|FWRITE == 3 == 1|2). The flags value with O_ACCMODE masked out is already a bitmap (not just in FreeBSD; it's even defined to be one in the Single Unix Standard). Adding 1 to flags could only change any of these bits if the two low bits were both 1. But this is not possible, since we've already checked that (flags & O_ACCMODE) != O_ACCMODE. Therefore, fmode is a bitmap. QED. Now, what I'm proposing would allow the low two bits to be 11, which FFLAGS would map to 00 (as it does in linux). While adding 1 does this, it would also affect the higher bits (O_NOACCESS | O_NOBLOCK + 1 is not 0 | O_NOBLOCK, it's 0 | O_APPEND). Therefore, a slightly more complicated FFLAGS is needed if we want fmode to remain a bitmap. (The alternative--the way linux does this--is to pass along both flags and fflags, and using fflags only for the low two bits, which is ugly and messy. I'd much prefer a slightly more complicated FFLAGS.) > > Second, any platform that defines O_NOACCESS could do so differently. On > > FreeBSD, as on linux, the most sensible definition is O_NOACCESS == > > O_WRONLY | O_RDWR == 3. Or a platform that defined O_RDONLY as 1 and > > O_WRONLY as 2, the most sensible definition would be O_NOACCESS == 0. > > I pray this flag never gets adopted outside of Linux... Is this just a non-sequitur, or are you praying that it never gets adopted because it could have different definitions or different systems? In the same way that O_RDONLY can be 0 or 1 on two different platforms, O_NOACCESS could be 3 or 0 on two different platforms. That seems like a good thing, not a bad thing. [...] > Or deal with issues of privilege granted merely by open. For > example, on FreeBSD, an implementation of this would permit any > normal user to do INB/OUTB to any I/O port on any hardare on the > machine. > > This is a can of worms. You mean by opening /dev/io? There's already a thread about that. The manpage says that "In addition to any file access permissions on /dev/io, the kernel enforces that only the super-user may open this device." Unfortunately, the kernel appears to not enforce any such thing. That's the can of worms. Either the kernel needs to enforce it, or the manpage needs to stop saying that it does. Meanwhile, the manpage says that "even read-only access will grant the full I/O privileges." I'd say that /dev/io should be changed to not allow the privileges if neither FREAD or FWRITE is set (which would require no change to the manpage, or to existing apps, and would open no new security issues)--whichever way the other issue is fixed. > > > Of course, allowing this on directories for which you > > > are normally denied read/write permissions would be a neat way to > > > escape from chroot'ed environments and compromise a host system... > > > > How would it allow that? If you can open files outside your chroot > > environment--even files you would otherwise have read access to--it's > > not much of a chroot! > > Mounted procfs within a chrooted environment. Admittedly, FreeBSD > is moving away from procfs, but on Linux, it's a serious issue, > since such basic utilities as "ps" and so on won't work without it. So, being able to open a file and then fchdir to it would provide you with... exactly the same exploit that you can already get by chdir'd to it. There's no new security issue here. > > Actually, you'd be surprised at how much has been explicitly added to > > the kernel (and, more, to the filesystem code, especially reiser) for > > lilo's benefit. > > I wouldn't. I think it's "too much", and I'd hate to drag the same > cruft into FreeBSD for the same reasons. I agree completely. However, I don't think that adding O_NOACCESS is the same thing as dragging in dozens of device-specific and fs-specific ioctl's and two special flags values (if the flags == -1 or -2, it's no longer a bitfield and instead has a special meaning), etc. As opposed to those examples, NOACCESS is a single change, at a high level, with an obvious meaning, with fully general semantics that are the same on any fs/device that supports it. (In fact, I suspect that one of the special flags values was added because one of the lilo developers didn't know about NOACCESS, so instead of opening a device file NOACCESS to call an ioctl, he got new code added into the kernel to allow him to use a special value with open to pass through ioctl's to the parent device....) > One option for you would be to make this a kernel module... then it > could be of use to the people who need it, while not bothering the > rest of the world. That's not a bad idea! The kernel itself would still have to be changed to work through this module (when present), but it should be much easier in that case to verify that the default behavior (without the module) is identical to current behavior, than if the change were implemented directly in the kernel. Also, combining this with the idea of an fs being able to report whether or not it can handle O_NOACCESS: You should be able to disable this support for an fs at compile time or (for FS's which are in modules) at load time. That should be trivial to add. It might also be worth providing a mount option to disable it at mount time even when it is compiled in and enabled at load time (so I could have it on, say, /mnt/linux/usr, but not /mnt/linux, or on /usr but not /, or whatever). From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 17:12:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8F8F16A4CE for ; Sat, 1 Nov 2003 17:12:04 -0800 (PST) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8979E43FB1 for ; Sat, 1 Nov 2003 17:12:03 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta9.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031102011205.XWGU25728.mta9.adelphia.net@[10.1.0.9]>; Sat, 1 Nov 2003 20:12:05 -0500 From: andi payn To: Terry Lambert In-Reply-To: <3FA42803.BA6EDF62@mindspring.com> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <3FA22930.C6EC97A9@mindspring.com> <1067627608.825.56.camel@verdammt.falcotronic.net> <3FA42803.BA6EDF62@mindspring.com> Content-Type: text/plain Message-Id: <1067732469.825.487.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 01 Nov 2003 17:12:01 -0800 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2003 01:12:05 -0000 On Sat, 2003-11-01 at 13:39, Terry Lambert wrote: > andi payn wrote: > > Now hold on. The standard (by which I you mean POSIX? or one of the UNIX [...] > A strictly conforming implementation can not expose things into > the namespace that are not defined by the standard to be in the > namespace, when a manifest constant specifying a conformance level > is in scope. Yes. As I mentioned at the beginning, you don't get O_NOACCESS in linux by pulling in the standard headers, and I wasn't suggesting anything different. [...] > Not just"not portable", but "fails to conform to standards". Note that the Single UNIX Specification says that open _may_ fail with EINVAL if the value of the oflag argument does not contain exactly one of the three access modes. So, if you've written code (for some reason) that expects that it _must_ fail in such a situation, that's non-comforming code. > > If O_NOACCESS happens to be == O_ACCMODE on FreeBSD--just as it is on > > linux--and if that happens to also be == O_WRONLY | O_RDWR (with no > > other flags set), I don't see how that changes anything. > > Other than the security issues it raises, you mean, right? Are you saying that having O_NOACCESS == O_ACCMODE raises security issues beyond any raised by having O_NOACCESS at all? Or is it the fact that it would the same value as in linux, so linux code (whether recompiled for FreeBSD or run under ABI compatibility) that expected to be able to open a file without getting read or write access would be able to do so? Again, I don't see how this raises security issues beyond whatever may be inherent in O_NOACCESS, if any. Or are you just getting ahead of yourself? > You nead to look at the implementation of VOP_OPEN in FreeBSD; > specifically, you need to look at the fact that fp->f_flags is > passed as one of its parameters, and that the FS is permitted > to interpret these flags in an FS-dependent fashion. Which version are you looking at? In 5.1, what gets passed if fmode, which is ultimately the result of applying FFLAGS to the original flags passed to open. As for the FS being permitted to interpret these flags in an FS-dependent fashion: I'm pretty sure that a FS that interpreted FREAD to mean write permission, or O_APPEND to mean truncate, would not be considered good. Any FS that assumes that it can read if FREAD is set, and it can write if FWRITE is set, will work correctly when neither is set. And any filesystem that doesn't work this way is already broken. However, there may be some FS's with more subtle issues. For example, an FS might assume that if it doesn't have FWRITE, it must have FREAD. This is (probably) not guaranteed anywhere--but it is currently true, a fact which is logically deducible from the values of the flags, the way FFLAGS works, and the fact that O_ACCMODE returns EINVAL. If this ceases to be true, such an FS might do things wrong. I'd have no problem with providing for each filesystem to specify "I can handle no-access opens," and for any FS that doesn't do so, the kernel would return EINVAL before even talking to the FS (thus preserving current behavior); only if the FS does so could it ever get an fmode with neither FREAD nor FWRITE set. [...] > Really, it needs to be a bitmap internally in FreeBSD, as well, > but that's a big step. By "it needs to be a bitmap internally," you mean that fmode needs to be a bitmap? Well, then, good news: It already is. In fact, I think the equivalent parameter has been a bitmap for every *BSD and going back into AT&T Unix. Currently FFLAGS() is a macro that adds 1. Now, look at the original flags. The low two bits are the O_ACCMODE mask. This part is not a bitmap (O_RDONLY == 0, O_WRONLY == 1, and O_RDWR == 2). But once you add 1, the result is (FREAD == 1, FWRITE == 2, FREAD|FWRITE == 3 == 1|2). The flags value with O_ACCMODE masked out is already a bitmap (not just in FreeBSD; it's even defined to be one in the Single Unix Standard). Adding 1 to flags could only change any of these bits if the two low bits were both 1. But this is not possible, since we've already checked that (flags & O_ACCMODE) != O_ACCMODE. Therefore, fmode is a bitmap. QED. Now, what I'm proposing would allow the low two bits to be 11, which FFLAGS would map to 00 (as it does in linux). While adding 1 does this, it would also affect the higher bits (O_NOACCESS | O_NOBLOCK + 1 is not 0 | O_NOBLOCK, it's 0 | O_APPEND). Therefore, a slightly more complicated FFLAGS is needed if we want fmode to remain a bitmap. (The alternative--the way linux does this--is to pass along both flags and fflags, and using fflags only for the low two bits, which is ugly and messy. I'd much prefer a slightly more complicated FFLAGS.) > > Second, any platform that defines O_NOACCESS could do so differently. On > > FreeBSD, as on linux, the most sensible definition is O_NOACCESS == > > O_WRONLY | O_RDWR == 3. Or a platform that defined O_RDONLY as 1 and > > O_WRONLY as 2, the most sensible definition would be O_NOACCESS == 0. > > I pray this flag never gets adopted outside of Linux... Is this just a non-sequitur, or are you praying that it never gets adopted because it could have different definitions or different systems? In the same way that O_RDONLY can be 0 or 1 on two different platforms, O_NOACCESS could be 3 or 0 on two different platforms. That seems like a good thing, not a bad thing. [...] > Or deal with issues of privilege granted merely by open. For > example, on FreeBSD, an implementation of this would permit any > normal user to do INB/OUTB to any I/O port on any hardare on the > machine. > > This is a can of worms. You mean by opening /dev/io? There's already a thread about that. The manpage says that "In addition to any file access permissions on /dev/io, the kernel enforces that only the super-user may open this device." Unfortunately, the kernel appears to not enforce any such thing. That's the can of worms. Either the kernel needs to enforce it, or the manpage needs to stop saying that it does. Meanwhile, the manpage says that "even read-only access will grant the full I/O privileges." I'd say that /dev/io should be changed to not allow the privileges if neither FREAD or FWRITE is set (which would require no change to the manpage, or to existing apps, and would open no new security issues)--whichever way the other issue is fixed. > > > Of course, allowing this on directories for which you > > > are normally denied read/write permissions would be a neat way to > > > escape from chroot'ed environments and compromise a host system... > > > > How would it allow that? If you can open files outside your chroot > > environment--even files you would otherwise have read access to--it's > > not much of a chroot! > > Mounted procfs within a chrooted environment. Admittedly, FreeBSD > is moving away from procfs, but on Linux, it's a serious issue, > since such basic utilities as "ps" and so on won't work without it. So, being able to open a file and then fchdir to it would provide you with... exactly the same exploit that you can already get by chdir'd to it. There's no new security issue here. > > Actually, you'd be surprised at how much has been explicitly added to > > the kernel (and, more, to the filesystem code, especially reiser) for > > lilo's benefit. > > I wouldn't. I think it's "too much", and I'd hate to drag the same > cruft into FreeBSD for the same reasons. I agree completely. However, I don't think that adding O_NOACCESS is the same thing as dragging in dozens of device-specific and fs-specific ioctl's and two special flags values (if the flags == -1 or -2, it's no longer a bitfield and instead has a special meaning), etc. As opposed to those examples, NOACCESS is a single change, at a high level, with an obvious meaning, with fully general semantics that are the same on any fs/device that supports it. (In fact, I suspect that one of the special flags values was added because one of the lilo developers didn't know about NOACCESS, so instead of opening a device file NOACCESS to call an ioctl, he got new code added into the kernel to allow him to use a special value with open to pass through ioctl's to the parent device....) > One option for you would be to make this a kernel module... then it > could be of use to the people who need it, while not bothering the > rest of the world. That's not a bad idea! The kernel itself would still have to be changed to work through this module (when present), but it should be much easier in that case to verify that the default behavior (without the module) is identical to current behavior, than if the change were implemented directly in the kernel. Also, combining this with the idea of an fs being able to report whether or not it can handle O_NOACCESS: You should be able to disable this support for an fs at compile time or (for FS's which are in modules) at load time. That should be trivial to add. It might also be worth providing a mount option to disable it at mount time even when it is compiled in and enabled at load time (so I could have it on, say, /mnt/linux/usr, but not /mnt/linux, or on /usr but not /, or whatever). From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 17:48:57 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C458C16A4CE for ; Sat, 1 Nov 2003 17:48:57 -0800 (PST) Received: from mta7.adelphia.net (mta7.adelphia.net [68.168.78.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5C4E43FAF for ; Sat, 1 Nov 2003 17:48:56 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta13.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031102011207.GCHX20181.mta13.adelphia.net@[10.1.0.9]>; Sat, 1 Nov 2003 20:12:07 -0500 From: andi payn To: Terry Lambert In-Reply-To: <3FA42945.A5EA17C1@mindspring.com> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> <20031031162757.GA56981@walton.maths.tcd.ie> <1067628015.825.64.camel@verdammt.falcotronic.net> <20031031.130229.132929054.imp@bsdimp.com> <3FA42945.A5EA17C1@mindspring.com> Content-Type: text/plain Message-Id: <1067735516.825.492.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 01 Nov 2003 17:12:06 -0800 Content-Transfer-Encoding: 7bit cc: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2003 01:48:57 -0000 On Sat, 2003-11-01 at 13:44, Terry Lambert wrote: > "M. Warner Losh" wrote: > > Rewind units on tape drives? If there's no access check done, and I > > open the rewind unit as joe-smoe? The close code is what does the > > rewind, and you don't have enough knowledge to know if the tape was > > opened r/w there. > > Which brings up the idea of passing fp->fd_flags to VOP_CLOSE()... Looking at the calls to VOP_CLOSE, there's either a flags variable, or the fmode variable I mentioned before, being passed as the second parameter. I haven't checked where this comes from in all cases, but when vn_closefile gets called, the value of this parameter is fp->f_flag. Similarly, when an open cannot be completed, the value is fmode. In other words, it looks like the flags are already there. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 18:00:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8068416A4CE for ; Sat, 1 Nov 2003 18:00:23 -0800 (PST) Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FA5843FE1 for ; Sat, 1 Nov 2003 18:00:22 -0800 (PST) (envelope-from ler@airmail.net) Received: from lerlaptop.lerctr.org (lerlaptop.lerctr.org [207.158.72.14]) (authenticated bits=0)hA220I7X027572 for ; Sat, 1 Nov 2003 20:00:19 -0600 (CST) Date: Sat, 01 Nov 2003 20:00:18 -0600 From: Larry Rosenman To: freebsd-hackers@freebsd.org Message-ID: <155150000.1067738418@lerlaptop.lerctr.org> X-Mailer: Mulberry/3.1.0b9 (Linux/x86) X-PGP-Info: All other keys are old/dead. X-PGP-Key: 0x3c49bdd6 X-PGP-Fingerprint: D0D1 3C11 F42F 6B29 FA67 6BF3 AD13 4685 3C49 BDD6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: Samsung SPH-I500 (Palm/Phone) CDMA Modem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2003 02:00:23 -0000 I bought one of these a while back, and just got a cable that I can carry with my Laptop. I get the following: Nov 1 19:57:31 lerlaptop kernel: ucom0: SAMSUNG Electronics Co.,Ltd. SAMSUNG CDMA Technologies, rev 1.01/0.00, addr 2, iclass 2/2 Nov 1 19:57:31 lerlaptop kernel: ucom0: data interface 1, has CM over data, has break Nov 1 19:57:36 lerlaptop kernel: ucom0: could not set data multiplex mode Nov 1 19:57:36 lerlaptop kernel: device_probe_and_attach: ucom0 attach returned 6 Nov 1 19:57:36 lerlaptop kernel: ugen0: SAMSUNG Electronics Co.,Ltd. SAMSUNG CDMA Technologies, rev 1.01/0.00, addr 2 ^C$ I'm wondering if any of the UMODEM guru's can decode this, (or ask me for more info) so I can use this phone as a modem. This is on -CURRENT from a week or so ago. Thanks! LER -- Larry Rosenman, Sr. Network Engineer, Internet America, Inc. E-Mail: ler@airmail.net Phone: +1 214-861-2571, Fax: 214-861-2663 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201