From owner-freebsd-arch@FreeBSD.ORG Sun May 22 00:34:37 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71EDE16A41C; Sun, 22 May 2005 00:34:37 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 297C843D1F; Sun, 22 May 2005 00:34:37 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j4M0YalD022912; Sat, 21 May 2005 17:34:37 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <428FC00B.3080909@freebsd.org> References: <428FC00B.3080909@freebsd.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 21 May 2005 17:34:37 -0700 To: Colin Percival X-Mailer: Apple Mail (2.622) cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 00:34:37 -0000 On May 21, 2005, at 4:11 PM, Colin Percival wrote: *snip* > The following must be done before hyperthreading is re-enabled: > > 1. The scheduler must be taught to not run threads on the same > processor core unless they p_candebug() each other. For reasons > of performance and locking, this is probably best accomplished by > only allowing threads to share a processor core if they belong > to the same process. > 2. When a thread is in the kernel, there must be a mechanism for > it to IPI its siblings and put them to sleep, and then wake them > up later. This would be used any time when a thread in the kernel > is about to handle sensitive data in a non-oblivious manner; IPsec > is a good example of where this would be necessary. > > Does anyone want to step forward to work on this? Maybe it's a better idea to describe the problem in much more detail, rather than dictate what you want someone else to do? A pointer to where the problem is described/discussed would do. Just a thought, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Sun May 22 00:49:29 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79B2816A41C for ; Sun, 22 May 2005 00:49:29 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BEA843D1F for ; Sun, 22 May 2005 00:49:28 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV00JDF8YGIIF0@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 18:49:28 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd3mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV0018R8YGV700@pd3mr3so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 21 May 2005 18:49:28 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGV0029N8YFXX@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 18:49:28 -0600 (MDT) Date: Sat, 21 May 2005 17:49:20 -0700 From: Colin Percival In-reply-to: To: Marcel Moolenaar Message-id: <428FD710.4060200@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <428FC00B.3080909@freebsd.org> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 00:49:29 -0000 Marcel Moolenaar wrote: > On May 21, 2005, at 4:11 PM, Colin Percival wrote: >> The following must be done before hyperthreading is re-enabled: >> [snip] > > Maybe it's a better idea to describe the problem in much more > detail, rather than dictate what you want someone else to do? > A pointer to where the problem is described/discussed would > do. The problem is described in my paper "Cache missing for fun and profit": http://www.daemonology.net/papers/htt.pdf Put simply, threads which share a processor core can monitor each others' memory access patterns, so we need to ensure that such co-scheduling never happens between threads which have different privileges. The reason I cut through to explaining what needed to be done is that I discussed this at length with several people from the FreeBSD security team before and during BSDCan; but these discussions were obviously not public, so I can't give a reference to them. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sun May 22 01:04:22 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B734316A41C; Sun, 22 May 2005 01:04:22 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F06243D1F; Sun, 22 May 2005 01:04:22 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j4M14MGa023025; Sat, 21 May 2005 18:04:22 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <428FD710.4060200@freebsd.org> References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9e8314b53980a379445cc8c07086901d@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 21 May 2005 18:04:23 -0700 To: Colin Percival X-Mailer: Apple Mail (2.622) cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 01:04:22 -0000 On May 21, 2005, at 5:49 PM, Colin Percival wrote: > Marcel Moolenaar wrote: >> On May 21, 2005, at 4:11 PM, Colin Percival wrote: >>> The following must be done before hyperthreading is re-enabled: >>> [snip] >> >> Maybe it's a better idea to describe the problem in much more >> detail, rather than dictate what you want someone else to do? >> A pointer to where the problem is described/discussed would >> do. > > The problem is described in my paper "Cache missing for fun and > profit": > http://www.daemonology.net/papers/htt.pdf Thanks. > Put simply, threads which share a processor core can monitor each > others' > memory access patterns, so we need to ensure that such co-scheduling > never > happens between threads which have different privileges. I'll be studying your paper to see if it can be shown that the HT implementation in Itanium is affected as well. If not, any solution must be sufficiently machine dependent. > The reason I cut through to explaining what needed to be done is that > I discussed this at length with several people from the FreeBSD > security > team before and during BSDCan; but these discussions were obviously not > public, so I can't give a reference to them. I can only assume that the discussion was i386 centric (as this is typically the case). Hence my request for a problem description. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Sun May 22 01:59:47 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 762CC16A41C for ; Sun, 22 May 2005 01:59:47 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E46C43D48 for ; Sun, 22 May 2005 01:59:46 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mr4so.prod.shaw.ca (pd2mr4so-qfe3.prod.shaw.ca [10.0.141.107]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV00MK9C7K04TD@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 19:59:44 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd2mr4so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV002F7C7KCYJ0@pd2mr4so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 21 May 2005 19:59:44 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGV00L2TC7K5C@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 19:59:44 -0600 (MDT) Date: Sat, 21 May 2005 18:59:36 -0700 From: Colin Percival In-reply-to: <9e8314b53980a379445cc8c07086901d@xcllnt.net> To: Marcel Moolenaar Message-id: <428FE788.8020408@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> <9e8314b53980a379445cc8c07086901d@xcllnt.net> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 01:59:47 -0000 Marcel Moolenaar wrote: > On May 21, 2005, at 5:49 PM, Colin Percival wrote: >> Put simply, threads which share a processor core can monitor each others' >> memory access patterns, so we need to ensure that such co-scheduling >> never >> happens between threads which have different privileges. > > I'll be studying your paper to see if it can be shown that the HT > implementation in Itanium is affected as well. My understanding is that there are no currently released ia64 processors with hyperthreading support, but that some future ia64 processor(s) are likely to be affected. > I can only assume that the discussion was i386 centric (as this is > typically the case). Hence my request for a problem description. In addition to i386 and amd64, which are certainly affected, and ia64, which will probably be affected, there is a good chance that some powerpc processors are affected... the problem is a general one with shared caches and probably affects all currently existing simultaneous multithreading processors. I think the "right solution" is to make the basic functionality machine independent, but have the machine dependent initialization code determine which sets of threads share caches. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sun May 22 02:44:27 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E51B216A41C for ; Sun, 22 May 2005 02:44:27 +0000 (GMT) (envelope-from ups@tree.com) Received: from smtp.speedfactory.net (talon.speedfactory.net [66.23.216.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 814F843D53 for ; Sun, 22 May 2005 02:44:27 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 9498 invoked from network); 21 May 2005 22:44:47 +0000 Received: from 66-23-216-49.clients.speedfactory.net (HELO palm.tree.com) (66.23.216.49) by smtp.speedfactory.net with AES256-SHA encrypted SMTP; 21 May 2005 22:44:47 +0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j4M2iPpP001992; Sat, 21 May 2005 22:44:26 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Colin Percival In-Reply-To: <428FC00B.3080909@freebsd.org> References: <428FC00B.3080909@freebsd.org> Content-Type: text/plain Message-Id: <1116729865.1917.92.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 21 May 2005 22:44:25 -0400 Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 02:44:28 -0000 On Sat, 2005-05-21 at 19:11, Colin Percival wrote: > As you are probably all aware by now, HyperThreading has been > disabled on the stable and security branches due to a problem > with information leakage between threads which are scheduled > simultaneously on the two processor cores. Clearly, some people > (and at least one large company) are unhappy about us having > hyperthreading disbaled, so the security team would like to see > hyperthreading re-enabled by default as soon as we believe that > this can be done safely. > > The following must be done before hyperthreading is re-enabled: > > 1. The scheduler must be taught to not run threads on the same > processor core unless they p_candebug() each other. For reasons > of performance and locking, this is probably best accomplished by > only allowing threads to share a processor core if they belong > to the same process. > 2. When a thread is in the kernel, there must be a mechanism for > it to IPI its siblings and put them to sleep, and then wake them > up later. This would be used any time when a thread in the kernel > is about to handle sensitive data in a non-oblivious manner; IPsec > is a good example of where this would be necessary. > > Does anyone want to step forward to work on this? > > Colin Percival While I have been to your talk I have not read your paper yet and the following may be totally uninformed (Please be gentle :-) : Would it be enough to disable access to RDTSC for user processes? I believe the attack needs a very exact time source. Beside benchmarking - is there any other real use for RDTSC ? Is there any use of RDTSC that system requiring the security cannot live without? (We could even try to emulate the instruction if we really need to) I have to think more about possible scheduler changes. Currently we don't even know if a thread running on another virtual CPU is in the kernel or not. Throwing preemption, interrupt and kernel threads, pinned threads,priority inheritance and the IPIs in the mix make correct and efficient hyperthreading safe scheduling difficult. This also looks like a lot of work and I am wondering if it would not be better spend on other scheduler improvements. Stephan From owner-freebsd-arch@FreeBSD.ORG Sun May 22 03:25:53 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B03E16A41C for ; Sun, 22 May 2005 03:25:53 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51D8743D53 for ; Sun, 22 May 2005 03:25:53 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr5so.prod.shaw.ca (pd4mr5so-qfe3.prod.shaw.ca [10.0.141.50])2004))freebsd-arch@freebsd.org; Sat, 21 May 2005 21:25:52 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd4mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV00HJEG74HOG0@pd4mr5so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 21 May 2005 21:25:52 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGV00L0OG730H@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 21:25:52 -0600 (MDT) Date: Sat, 21 May 2005 20:25:44 -0700 From: Colin Percival In-reply-to: <1116729865.1917.92.camel@palm> To: Stephan Uphoff Message-id: <428FFBB8.5010201@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <428FC00B.3080909@freebsd.org> <1116729865.1917.92.camel@palm> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: "freebsd-arch@freebsd.org" Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 03:25:53 -0000 Stephan Uphoff wrote: > Would it be enough to disable access to RDTSC for user processes? On single-core systems (single socket, not dual-core), yes. Otherwise, no. > I believe the attack needs a very exact time source. It needs ~100 cycle resolution. If you have two processors, you can get good enough precision for the attack by constructing a "virtual TSC" by using a second thread which repeatedly increments a location in memory. > Beside benchmarking - is there any other real use for RDTSC ? Some (broken) software uses the TSC in combination with external events in order to obtain entropy for cryptographic key generation. As a result, disabling RDTSC could lead to non-obvious but very problematic breakage. > I have to think more about possible scheduler changes. > Currently we don't even know if a thread running on another virtual CPU > is in the kernel or not. > Throwing preemption, interrupt and kernel threads, pinned > threads,priority inheritance and the IPIs in the mix make correct and > efficient hyperthreading safe scheduling difficult. > This also looks like a lot of work and I am wondering if it would not be > better spend on other scheduler improvements. If nobody wants to do this, then we could always just keep on telling our users "sorry, hyperthreading is broken on multi-user systems". I don't mind, personally -- I only have one system with a hyperthreaded cpu, and I have hyperthreading turned off for performance reasons. :-) Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sun May 22 04:21:48 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BDB216A41F; Sun, 22 May 2005 04:21:48 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2659943D1F; Sun, 22 May 2005 04:21:48 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j4M4LlJb023710; Sat, 21 May 2005 21:21:48 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <428FE788.8020408@freebsd.org> References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> <9e8314b53980a379445cc8c07086901d@xcllnt.net> <428FE788.8020408@freebsd.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6451b639f2e0ddacb18f62c571dfeedb@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 21 May 2005 21:21:47 -0700 To: Colin Percival X-Mailer: Apple Mail (2.622) cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 04:21:48 -0000 On May 21, 2005, at 6:59 PM, Colin Percival wrote: > Marcel Moolenaar wrote: >> On May 21, 2005, at 5:49 PM, Colin Percival wrote: >>> Put simply, threads which share a processor core can monitor each >>> others' >>> memory access patterns, so we need to ensure that such co-scheduling >>> never >>> happens between threads which have different privileges. >> >> I'll be studying your paper to see if it can be shown that the HT >> implementation in Itanium is affected as well. > > My understanding is that there are no currently released ia64 > processors > with hyperthreading support, but that some future ia64 processor(s) are > likely to be affected. There are a lot of variables that need to be taken into account and those variables do not necessarily map perfectly from a P4 to an I2. Sharing of the L1 cache is not a sufficient condition to create a side-channel for timing attacks. A reliable time source with enough precision is also necessary (as you and Stephan have pointed out). The precision of the time source depends on latencies of the various cache levels and the micro-architectural behavior of the processor. All I'm saying is: remain precise and careful. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Sun May 22 04:35:43 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6719816A41F for ; Sun, 22 May 2005 04:35:43 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12CF143D1D for ; Sun, 22 May 2005 04:35:42 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV005FDJEYHHE0@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 22:35:22 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd3mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV001Q2JEXV4I0@pd3mr3so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 21 May 2005 22:35:22 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGV00K3PJEX6N@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 22:35:21 -0600 (MDT) Date: Sat, 21 May 2005 21:35:13 -0700 From: Colin Percival In-reply-to: <6451b639f2e0ddacb18f62c571dfeedb@xcllnt.net> To: Marcel Moolenaar Message-id: <42900C01.10904@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> <9e8314b53980a379445cc8c07086901d@xcllnt.net> <428FE788.8020408@freebsd.org> <6451b639f2e0ddacb18f62c571dfeedb@xcllnt.net> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 04:35:43 -0000 Marcel Moolenaar wrote: > There are a lot of variables that need to be taken into account and > those variables do not necessarily map perfectly from a P4 to an I2. > Sharing of the L1 cache is not a sufficient condition to create a > side-channel for timing attacks. A reliable time source with enough > precision is also necessary (as you and Stephan have pointed out). > The precision of the time source depends on latencies of the various > cache levels and the micro-architectural behavior of the processor. Point taken. I maintain, however, that it is much better to make "information can leak between these processors" a machine-independent concept which is handled appropriately by the scheduler (with the necessary machine-dependent code to specify *which* sets of processors, if any, have such leakage). Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sun May 22 05:02:12 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 600AB16A41C; Sun, 22 May 2005 05:02:12 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9A5343D49; Sun, 22 May 2005 05:02:10 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from ppp2C32.dyn.pacific.net.au (ppp2C32.dyn.pacific.net.au [61.8.44.50])j4M5260m016178; Sun, 22 May 2005 15:02:07 +1000 From: Sam Lawrance To: Colin Percival In-Reply-To: <42900C01.10904@freebsd.org> References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> <9e8314b53980a379445cc8c07086901d@xcllnt.net> <428FE788.8020408@freebsd.org><42900C01.10904@freebsd.org> Content-Type: text/plain Date: Sun, 22 May 2005 15:02:50 +1000 Message-Id: <1116738170.867.28.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org cc: Marcel Moolenaar Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 05:02:12 -0000 On Sat, 2005-05-21 at 21:35 -0700, Colin Percival wrote: > Marcel Moolenaar wrote: > > There are a lot of variables that need to be taken into account and > > those variables do not necessarily map perfectly from a P4 to an I2. > > Sharing of the L1 cache is not a sufficient condition to create a > > side-channel for timing attacks. A reliable time source with enough > > precision is also necessary (as you and Stephan have pointed out). > > The precision of the time source depends on latencies of the various > > cache levels and the micro-architectural behavior of the processor. > > Point taken. I maintain, however, that it is much better to make > "information can leak between these processors" a machine-independent > concept which is handled appropriately by the scheduler (with the > necessary machine-dependent code to specify *which* sets of processors, > if any, have such leakage). I'm just curious here... would the mac_seeotheruids policy help in obscuring the value of any information collected by a spy process? From owner-freebsd-arch@FreeBSD.ORG Sun May 22 05:04:59 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AECA016A41C for ; Sun, 22 May 2005 05:04:59 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0581C43D1D for ; Sun, 22 May 2005 05:04:59 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr1so.prod.shaw.ca (pd4mr1so-qfe3.prod.shaw.ca [10.0.141.212]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV008M5KRFFX80@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 23:04:27 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd4mr1so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV00EYTKRF2780@pd4mr1so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 21 May 2005 23:04:27 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGV00G4WKRFTL@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 23:04:27 -0600 (MDT) Date: Sat, 21 May 2005 22:04:19 -0700 From: Colin Percival In-reply-to: <1116738170.867.28.camel@dirk.no.domain> To: Sam Lawrance Message-id: <429012D3.6070803@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> <9e8314b53980a379445cc8c07086901d@xcllnt.net> <428FE788.8020408@freebsd.org> <6451b639f2e0ddacb18f62c571dfeedb@xcllnt.net> <42900C01.10904@freebsd.org> <1116738170.867.28.camel@dirk.no.domain> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 05:04:59 -0000 Sam Lawrance wrote: > I'm just curious here... would the mac_seeotheruids policy help in > obscuring the value of any information collected by a spy process? Yes. It would mean that the spy could steal an SSL certificate, but not know whose SSL certificate it was. :-) Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sun May 22 05:09:48 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CEA116A41C; Sun, 22 May 2005 05:09:48 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id D752E43D1F; Sun, 22 May 2005 05:09:47 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from ppp2C32.dyn.pacific.net.au (ppp2C32.dyn.pacific.net.au [61.8.44.50])j4M59i0m018860; Sun, 22 May 2005 15:09:45 +1000 From: Sam Lawrance To: Colin Percival In-Reply-To: <429012D3.6070803@freebsd.org> References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> <9e8314b53980a379445cc8c07086901d@xcllnt.net> <428FE788.8020408@freebsd.org><42900C01.10904@freebsd.org> <429012D3.6070803@freebsd.org> Content-Type: text/plain Date: Sun, 22 May 2005 15:10:28 +1000 Message-Id: <1116738628.867.33.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 05:09:48 -0000 On Sat, 2005-05-21 at 22:04 -0700, Colin Percival wrote: > Sam Lawrance wrote: > > I'm just curious here... would the mac_seeotheruids policy help in > > obscuring the value of any information collected by a spy process? > > Yes. It would mean that the spy could steal an SSL certificate, but > not know whose SSL certificate it was. :-) Can the spy be sure that it's not just stealing fortunes though? I mean for example, can the cache timings shown on page 7 of your paper be used to reliably identify what the other thread on the CPU is? From owner-freebsd-arch@FreeBSD.ORG Sun May 22 05:15:32 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9809E16A41C for ; Sun, 22 May 2005 05:15:32 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 310C343D49 for ; Sun, 22 May 2005 05:15:32 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd5mr6so.prod.shaw.ca (pd5mr6so-qfe3.prod.shaw.ca [10.0.141.182]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV006U8L7RAP30@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 23:14:15 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd5mr6so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV00BYLL7R8GH0@pd5mr6so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 21 May 2005 23:14:15 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGV00H5RL7Q9C@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 23:14:14 -0600 (MDT) Date: Sat, 21 May 2005 22:14:06 -0700 From: Colin Percival In-reply-to: <1116738628.867.33.camel@dirk.no.domain> To: Sam Lawrance Message-id: <4290151E.9020508@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> <9e8314b53980a379445cc8c07086901d@xcllnt.net> <428FE788.8020408@freebsd.org> <42900C01.10904@freebsd.org> <429012D3.6070803@freebsd.org> <1116738628.867.33.camel@dirk.no.domain> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 05:15:32 -0000 Sam Lawrance wrote: > On Sat, 2005-05-21 at 22:04 -0700, Colin Percival wrote: >>Sam Lawrance wrote: >>>I'm just curious here... would the mac_seeotheruids policy help in >>>obscuring the value of any information collected by a spy process? >> >>Yes. It would mean that the spy could steal an SSL certificate, but >>not know whose SSL certificate it was. :-) > > Can the spy be sure that it's not just stealing fortunes though? > > I mean for example, can the cache timings shown on page 7 of your paper > be used to reliably identify what the other thread on the CPU is? Yes. The patterns are very distinctive. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sun May 22 06:46:10 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F004716A41C; Sun, 22 May 2005 06:46:10 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7814143D4C; Sun, 22 May 2005 06:46:10 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4M6k9kG011449; Sun, 22 May 2005 16:46:09 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4M6k5qB010126; Sun, 22 May 2005 16:46:07 +1000 Date: Sun, 22 May 2005 16:46:07 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Colin Percival In-Reply-To: <428FFBB8.5010201@freebsd.org> Message-ID: <20050522163024.Q1381@epsplex.bde.org> References: <428FC00B.3080909@freebsd.org> <1116729865.1917.92.camel@palm> <428FFBB8.5010201@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-arch@freebsd.org" , Stephan Uphoff Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 06:46:11 -0000 On Sat, 21 May 2005, Colin Percival wrote: > Stephan Uphoff wrote: >> Would it be enough to disable access to RDTSC for user processes? Doing so would be a kernel bug. > On single-core systems (single socket, not dual-core), yes. Otherwise, no. > >> I believe the attack needs a very exact time source. > > It needs ~100 cycle resolution. If you have two processors, you can get > good enough precision for the attack by constructing a "virtual TSC" by > using a second thread which repeatedly increments a location in memory. clock_gettime() with takes about 600 cycles if kern.timecounter.hardware=TSC. It should take fewer cycles, but syscalls are inefficient in FreeBSD. Does a factor of 6 make much difference to the attack? >> Beside benchmarking - is there any other real use for RDTSC ? > > Some (broken) software uses the TSC in combination with external events in > order to obtain entropy for cryptographic key generation. As a result, > disabling RDTSC could lead to non-obvious but very problematic breakage. Profiling (a form of benchmarking) should optionally be high resolution and high resolution profiling would use the TSC if it is available. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun May 22 08:19:42 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C91916A41C; Sun, 22 May 2005 08:19:42 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A09DB43D48; Sun, 22 May 2005 08:19:41 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j4M8JfaJ024451; Sun, 22 May 2005 01:19:41 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <42900C01.10904@freebsd.org> References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> <9e8314b53980a379445cc8c07086901d@xcllnt.net> <428FE788.8020408@freebsd.org> <6451b639f2e0ddacb18f62c571dfeedb@xcllnt.net> <42900C01.10904@freebsd.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <401480a79de1cc474eec20c1943da574@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sun, 22 May 2005 01:19:40 -0700 To: Colin Percival X-Mailer: Apple Mail (2.622) Cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 08:19:42 -0000 On May 21, 2005, at 9:35 PM, Colin Percival wrote: > Marcel Moolenaar wrote: >> There are a lot of variables that need to be taken into account and >> those variables do not necessarily map perfectly from a P4 to an I2. >> Sharing of the L1 cache is not a sufficient condition to create a >> side-channel for timing attacks. A reliable time source with enough >> precision is also necessary (as you and Stephan have pointed out). >> The precision of the time source depends on latencies of the various >> cache levels and the micro-architectural behavior of the processor. > > Point taken. I maintain, however, that it is much better to make > "information can leak between these processors" a machine-independent > concept which is handled appropriately by the scheduler (with the > necessary machine-dependent code to specify *which* sets of processors, > if any, have such leakage). Yes, I agree. I forgot to explicitly acknowledge that point in my previous emails. Sorry about that... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Sun May 22 08:32:06 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 355A216A41C; Sun, 22 May 2005 08:32:06 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79A4C43D48; Sun, 22 May 2005 08:32:05 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x535c0e2a.sgnxx1.adsl-dhcp.tele.dk [83.92.14.42]) by pasmtp.tele.dk (Postfix) with ESMTP id 7B0BE1EC319; Sun, 22 May 2005 10:32:04 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j4M8VxBu040427; Sun, 22 May 2005 10:32:00 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Stephan Uphoff From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 21 May 2005 22:44:25 EDT." <1116729865.1917.92.camel@palm> Date: Sun, 22 May 2005 10:31:59 +0200 Message-ID: <40426.1116750719@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Colin Percival , "freebsd-arch@freebsd.org" Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 08:32:06 -0000 In message <1116729865.1917.92.camel@palm>, Stephan Uphoff writes: >Would it be enough to disable access to RDTSC for user processes? >I believe the attack needs a very exact time source. You'd be surprised how much software breaks if you do that :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon May 23 00:08:27 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61E3516A41C; Mon, 23 May 2005 00:08:27 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 827C343D54; Mon, 23 May 2005 00:08:24 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 8F45E85642; Mon, 23 May 2005 09:38:22 +0930 (CST) Date: Mon, 23 May 2005 09:38:22 +0930 From: Greg 'groggy' Lehey To: Colin Percival Message-ID: <20050523000822.GF34798@wantadilla.lemis.com> References: <428FC00B.3080909@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TeJTyD9hb8KJN2Jy" Content-Disposition: inline In-Reply-To: <428FC00B.3080909@freebsd.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 00:08:27 -0000 --TeJTyD9hb8KJN2Jy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Saturday, 21 May 2005 at 16:11:07 -0700, Colin Percival wrote: > As you are probably all aware by now, HyperThreading has been > disabled on the stable and security branches due to a problem > with information leakage between threads which are scheduled > simultaneously on the two processor cores. Clearly, some people > (and at least one large company) are unhappy about us having > hyperthreading disbaled, so the security team would like to see > hyperthreading re-enabled by default as soon as we believe that > this can be done safely. > > The following must be done before hyperthreading is re-enabled: > > 1. The scheduler must be taught to not run threads on the same > processor core unless they p_candebug() each other. For reasons > of performance and locking, this is probably best accomplished by > only allowing threads to share a processor core if they belong > to the same process. > 2. When a thread is in the kernel, there must be a mechanism for > it to IPI its siblings and put them to sleep, and then wake them > up later. This would be used any time when a thread in the kernel > is about to handle sensitive data in a non-oblivious manner; IPsec > is a good example of where this would be necessary. Yes, I've read the rest of the thread, but I think we probably need to step back here and see what we're addressing: this is a security issue that won't worry the vast majority of users. It seems that we should provide a choice: * For the really paranoid, disable HTT altogether. * For the relatively paranoid, something like what you propose above. * For the moderate risk-takesrs and the pedantic, provide a system call that tells the scheduler when the process is going through a critical section that could be vulnerable to this kind of attack, and that until further notice no other process (or only one what meets that meets the criteria above) should be scheduled. This would require a "further notice" system call as well, of course. * For those who have no serious security concerns (trusted environments, probably the majority of users), simply enable HTT. Greg -- See complete headers for address and phone numbers. --TeJTyD9hb8KJN2Jy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCkR72IubykFB6QiMRAhRkAKCMrePxsT7lkVGCurIOxZyZ6TT/eQCfWWnS pKOqKukC4aEgOpG2QAlXjJ4= =6UGp -----END PGP SIGNATURE----- --TeJTyD9hb8KJN2Jy-- From owner-freebsd-arch@FreeBSD.ORG Mon May 23 01:34:08 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56AE516A41C for ; Mon, 23 May 2005 01:34:08 +0000 (GMT) (envelope-from ups@tree.com) Received: from smtp.speedfactory.net (talon.speedfactory.net [66.23.216.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id E916043D4C for ; Mon, 23 May 2005 01:34:07 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 29613 invoked from network); 22 May 2005 21:34:32 +0000 Received: from 66-23-216-49.clients.speedfactory.net (HELO palm.tree.com) (66.23.216.49) by smtp.speedfactory.net with AES256-SHA encrypted SMTP; 22 May 2005 21:34:32 +0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j4N1Y6pP007035; Sun, 22 May 2005 21:34:06 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Colin Percival In-Reply-To: <428FFBB8.5010201@freebsd.org> References: <428FC00B.3080909@freebsd.org> <1116729865.1917.92.camel@palm> <428FFBB8.5010201@freebsd.org> Content-Type: text/plain Message-Id: <1116812046.1917.4493.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 22 May 2005 21:34:06 -0400 Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@freebsd.org" Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 01:34:08 -0000 On Sat, 2005-05-21 at 23:25, Colin Percival wrote: > Stephan Uphoff wrote: > > Would it be enough to disable access to RDTSC for user processes? > > On single-core systems (single socket, not dual-core), yes. Otherwise, no. > > > I believe the attack needs a very exact time source. > > It needs ~100 cycle resolution. If you have two processors, you can get > good enough precision for the attack by constructing a "virtual TSC" by > using a second thread which repeatedly increments a location in memory. OK > > Beside benchmarking - is there any other real use for RDTSC ? > > Some (broken) software uses the TSC in combination with external events in > order to obtain entropy for cryptographic key generation. As a result, > disabling RDTSC could lead to non-obvious but very problematic breakage. Both bde and phk seem to agree with you that just disabling RDTSC is not an option :-( However I am still wondering if single core, single socket hyperthreading systems may not benefit from "on demand" enabling of the RDTSC. This way threads from different processes that do no use RDTSC in userspace can be scheduled concurrently. The extra work may make this scheme unworkable - but it think it is worth to keep in mind. > > I have to think more about possible scheduler changes. > > Currently we don't even know if a thread running on another virtual CPU > > is in the kernel or not. > > Throwing preemption, interrupt and kernel threads, pinned > > threads,priority inheritance and the IPIs in the mix make correct and > > efficient hyperthreading safe scheduling difficult. > > This also looks like a lot of work and I am wondering if it would not be > > better spend on other scheduler improvements. > > If nobody wants to do this, then we could always just keep on telling our > users "sorry, hyperthreading is broken on multi-user systems". I don't > mind, personally -- I only have one system with a hyperthreaded cpu, and I > have hyperthreading turned off for performance reasons. :-) I enable/disable hyperthreading on my dual Xeon test box to stress the scheduler but haven't really measured performance differences. Maybe we should ask on stable/current if anyone would be upset ... While I am starting to have a few ideas on how to modify the 4bsd scheduler working on it is not my priority. However should re@ decide that this is really a must have feature I am willing to give it a try. Stephan From owner-freebsd-arch@FreeBSD.ORG Mon May 23 01:51:51 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4F7616A41C for ; Mon, 23 May 2005 01:51:51 +0000 (GMT) (envelope-from Anton.Bobrov@Sun.COM) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C43643D49 for ; Mon, 23 May 2005 01:51:50 +0000 (GMT) (envelope-from Anton.Bobrov@Sun.COM) Received: from phys-gadget-1 ([129.156.85.171]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4N1pn0T012705 for ; Sun, 22 May 2005 19:51:50 -0600 (MDT) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IGX005016DW4R@gadget-mail1.uk.sun.com> (original mail from Anton.Bobrov@Sun.COM) for freebsd-arch@freebsd.org; Mon, 23 May 2005 02:51:49 +0100 (BST) Received: from [10.0.1.2] (vpn-129-150-116-35.UK.Sun.COM [129.150.116.35]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IGX002XU6I7HX@gadget-mail1.uk.sun.com>; Mon, 23 May 2005 02:51:49 +0100 (BST) Date: Mon, 23 May 2005 03:54:26 +0200 From: Anton Bobrov In-reply-to: <428FC00B.3080909@freebsd.org> To: Colin Percival Message-id: <429137D2.10801@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, ru User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 References: <428FC00B.3080909@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 01:51:51 -0000 or perhaps processor sets + processor bindings + tweakable config/api system to allow users to do what they like could address that, no? i know thats alot of work however what you suggest in point 1 + point 2 aint a piece of cake either so as long as somebody goes with the complication maybe its a good idea to make a flexible system that will address other problems and benefits as well? just a thought... Colin Percival wrote: > As you are probably all aware by now, HyperThreading has been > disabled on the stable and security branches due to a problem > with information leakage between threads which are scheduled > simultaneously on the two processor cores. Clearly, some people > (and at least one large company) are unhappy about us having > hyperthreading disbaled, so the security team would like to see > hyperthreading re-enabled by default as soon as we believe that > this can be done safely. > > The following must be done before hyperthreading is re-enabled: > > 1. The scheduler must be taught to not run threads on the same > processor core unless they p_candebug() each other. For reasons > of performance and locking, this is probably best accomplished by > only allowing threads to share a processor core if they belong > to the same process. > 2. When a thread is in the kernel, there must be a mechanism for > it to IPI its siblings and put them to sleep, and then wake them > up later. This would be used any time when a thread in the kernel > is about to handle sensitive data in a non-oblivious manner; IPsec > is a good example of where this would be necessary. > > Does anyone want to step forward to work on this? > > Colin Percival > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Mon May 23 05:22:17 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E55216A41C; Mon, 23 May 2005 05:22:17 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D28043D1D; Mon, 23 May 2005 05:22:16 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4N5MD4j065582; Sun, 22 May 2005 22:22:13 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4N5MB2P065581; Sun, 22 May 2005 22:22:11 -0700 (PDT) (envelope-from obrien) Date: Sun, 22 May 2005 22:22:11 -0700 From: "David O'Brien" To: Jung-uk Kim Message-ID: <20050523052211.GA65514@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Jung-uk Kim , freebsd-arch@freebsd.org, rwatson@freebsd.org, freebsd-amd64@freebsd.org References: <200505191431.08189.jkim@niksun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505191431.08189.jkim@niksun.com> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: rwatson@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: AMD64 NUMA-awareness? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 05:22:17 -0000 On Thu, May 19, 2005 at 02:31:08PM -0400, Jung-uk Kim wrote: > I am not sure about the meaning of 'true NUMA capable machines' but > AMD64 is ccNUMA unless I am completely mistaken, and FreeBSD/amd64 is > well-supported. Even multicore processors are available now ..snip.. I am working on extracting the CPU & memory topology on AMD Opteron machines. For Athlon64 X2 (dual-core) there is nothing for FreeBSD to do differently than today. Once I have the ability to nicely express the topology on an Opteron system, there are two heavy hitters that have said they will consume the bits and work on optimizing FreeBSD for Opteron systems. For Intel dual-core HTT systems, there aren't any NUMA characteristics I'm aware of. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Mon May 23 12:08:58 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC29F16A41C; Mon, 23 May 2005 12:08:58 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E61843D1F; Mon, 23 May 2005 12:08:58 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms064.mailsrvcs.net ([192.168.1.1]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGX00HLOZ2VJCZ1@vms040.mailsrvcs.net>; Mon, 23 May 2005 07:08:55 -0500 (CDT) Date: Mon, 23 May 2005 07:08:55 -0500 (CDT) From: Sergey Babkin To: Stephan Uphoff , Colin Percival Message-id: <17227882.1116850135277.JavaMail.root@vms064.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: "freebsd-arch@freebsd.org" Subject: Re: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 12:08:58 -0000 >> > Beside benchmarking - is there any other real use for RDTSC ? >> >> Some (broken) software uses the TSC in combination with external events in >> order to obtain entropy for cryptographic key generation. As a result, >> disabling RDTSC could lead to non-obvious but very problematic breakage. > >Both bde and phk seem to agree with you that just disabling RDTSC is not >an option :-( RDTSC is very useful for profiling. So given a choice for disabling RDTSC or disabling hyperthreading personally I'd have no doubts that disabling hyperthreading wins. So far I've seen no use for hyperthreading whatsoever. If anything, it seems to make the machine slower due to I think extra contention for memory/cache, and probably due to the extra scheduling overhead. So I just get it disabled in the BIOS. Maybe I've just haven't seen the "right" kind of applications. -SB From owner-freebsd-arch@FreeBSD.ORG Mon May 23 13:51:17 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C46416A422 for ; Mon, 23 May 2005 13:51:17 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 090F343D49 for ; Mon, 23 May 2005 13:51:16 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 15:51:15 +0200 Date: Mon, 23 May 2005 15:51:16 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: arch@freebsd.org Message-ID: <20050523153118.C28521@beagle.kn.op.dlr.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 23 May 2005 13:51:15.0948 (UTC) FILETIME=[7D2CB2C0:01C55F9E] Cc: Subject: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 13:51:17 -0000 Hi all, I think I found a problem in the shell code in make(1), but I'm not sure whether to fix it or not and how. The problem is as follows: in compat mode (this is the default mode when make(1) is not called with -j) the command lines of a target are executed by one shell per line (this is also how Posix wants it). To reduce the number of shells make does an optimisation: when the command line does not contain one of a pre-defined set of meta characters and does not start with one of a predefined set of shell builtins, make directly exec's the command instead of using an intermediate shell. The problem is that the current list of builtins is limited to: alias cd eval exec exit read set ulimit unalias umask unset wait Obviously this is not the full set of shell builtins and does also not contain the shell reserved words. The result of this is that for one and the same command you can get different behaviour whether you execute it via make(1) or via sh -c '...'. As an example take echo(1). When called via the sh -c you get the builtin echo which supports the -e option, when executed by make(1) you get /bin/echo which doesn't. If you suddenly include a shell meta character in the command line: foo: echo "MAKEFLAGS: ${MAKEFLAGS}" you suddenly get also the builtin (':' is a meta character). For the reserved words the situation is almost the same. With the following makefile: foo: if one gets: if:No such file or directory, while foo: if [ -x /bin/sh ] ; then echo hey ; fi you get what you expect. I think all this may be very confusing. The question is what to do. I see the following options: 1. leave it as it is. 2. include the Posix reserved words and builtins into the list. 3. include all reserved words and builtins of our shell into the list. Option (3) is probably best. With (2) you still get different behaviour for the two command lines in: foo: bind -h bind -h * (the first line will try to find bind in the path while the second will execute the shell builtin). Opinions? harti From owner-freebsd-arch@FreeBSD.ORG Mon May 23 14:10:08 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A6A816A41C; Mon, 23 May 2005 14:10:08 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 932A443D1F; Mon, 23 May 2005 14:10:06 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from ppp231D.dyn.pacific.net.au (ppp231D.dyn.pacific.net.au [61.8.35.29]) by bloodwood.hunterlink.net.au (8.12.8/8.12.8) with ESMTP id j4NEA0SK002030; Tue, 24 May 2005 00:10:04 +1000 From: Sam Lawrance To: Harti Brandt In-Reply-To: <20050523153118.C28521@beagle.kn.op.dlr.de> References: <20050523153118.C28521@beagle.kn.op.dlr.de> Content-Type: text/plain Date: Tue, 24 May 2005 00:10:44 +1000 Message-Id: <1116857445.1537.4.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 14:10:08 -0000 On Mon, 2005-05-23 at 15:51 +0200, Harti Brandt wrote: > Hi all, > > I think I found a problem in the shell code in make(1), but I'm not sure > whether to fix it or not and how. The problem is as follows: in compat > mode (this is the default mode when make(1) is not called with -j) the > command lines of a target are executed by one shell per line (this is also > how Posix wants it). To reduce the number of shells make does an > optimisation: when the command line does not contain one of a pre-defined > set of meta characters and does not start with one of a predefined set of > shell builtins, make directly exec's the command instead of using an > intermediate shell. The problem is that the current list of builtins is > limited to: > > alias cd eval exec exit read set ulimit unalias umask unset wait > That explains some of ports/66342 for me.. in particular why setting "ECHO_CMD=echo -e" didn't perform entirely as I expected. From owner-freebsd-arch@FreeBSD.ORG Mon May 23 14:50:08 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2764F16A41C; Mon, 23 May 2005 14:50:08 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7EED43D1F; Mon, 23 May 2005 14:50:07 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j4NEqJoG007820; Mon, 23 May 2005 10:52:20 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: obrien@freebsd.org Date: Mon, 23 May 2005 10:49:55 -0400 User-Agent: KMail/1.6.2 References: <200505191431.08189.jkim@niksun.com> <20050523052211.GA65514@dragon.NUXI.org> In-Reply-To: <20050523052211.GA65514@dragon.NUXI.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200505231049.55883.jkim@niksun.com> X-Virus-Scanned: ClamAV 0.83/889/Sun May 22 06:18:49 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: rwatson@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: AMD64 NUMA-awareness? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 14:50:08 -0000 On Monday 23 May 2005 01:22 am, David O'Brien wrote: > On Thu, May 19, 2005 at 02:31:08PM -0400, Jung-uk Kim wrote: > > I am not sure about the meaning of 'true NUMA capable machines' > > but AMD64 is ccNUMA unless I am completely mistaken, and > > FreeBSD/amd64 is well-supported. Even multicore processors are > > available now > > ..snip.. > > I am working on extracting the CPU & memory topology on AMD Opteron > machines. For Athlon64 X2 (dual-core) there is nothing for FreeBSD > to do differently than today. Great. I am assuming you're working on ACPI SRAT/SLIT parsing, correct? > Once I have the ability to nicely express the topology on an > Opteron system, there are two heavy hitters that have said they > will consume the bits and work on optimizing FreeBSD for Opteron > systems. If you need any help, let me know. > For Intel dual-core HTT systems, there aren't any NUMA > characteristics I'm aware of. I believe you are correct. Jung-uk Kim > -- > -- David  (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Mon May 23 19:33:15 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27AE916A41C; Mon, 23 May 2005 19:33:15 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00BE343D1D; Mon, 23 May 2005 19:33:14 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 1771A653AD; Mon, 23 May 2005 20:31:38 +0100 (BST) 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 23084-01-5; Mon, 23 May 2005 20:31:37 +0100 (BST) Received: from empiric.dek.spc.org (wifi177.icsi.berkeley.edu [192.150.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 6A578653E8; Mon, 23 May 2005 20:31:33 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 125E76238; Sun, 22 May 2005 03:59:15 +0100 (BST) Date: Sun, 22 May 2005 03:59:15 +0100 From: Bruce M Simpson To: Stephan Uphoff Message-ID: <20050522025914.GD1108@empiric.icir.org> References: <428FC00B.3080909@freebsd.org> <1116729865.1917.92.camel@palm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116729865.1917.92.camel@palm> Cc: Colin Percival , "freebsd-arch@freebsd.org" Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 19:33:15 -0000 On Sat, May 21, 2005 at 10:44:25PM -0400, Stephan Uphoff wrote: > Beside benchmarking - is there any other real use for RDTSC ? > Is there any use of RDTSC that system requiring the security cannot live > without? (We could even try to emulate the instruction if we really need > to) A number of ports use RDTSC for high-resolution timing. The most obvious examples being machine emulators mostly used for gaming (UAE and MAME spring to mind, possibly also dosbox and others). I daresay VMware probably uses RDTSC too. BMS From owner-freebsd-arch@FreeBSD.ORG Tue May 24 00:21:08 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE01716A41C; Tue, 24 May 2005 00:21:07 +0000 (GMT) (envelope-from okumoto@ucsd.edu) Received: from oec-server4.ucsd.edu (oec-server4.ucsd.edu [132.239.8.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9707D43D1F; Tue, 24 May 2005 00:21:07 +0000 (GMT) (envelope-from okumoto@ucsd.edu) Received: from oec-server2.ucsd.edu (oec-server2.ucsd.edu [132.239.8.82]) by oec-server4.ucsd.edu (8.12.10/8.12.10) with ESMTP id j4O0L6uv046442; Mon, 23 May 2005 17:21:06 -0700 (PDT) (envelope-from okumoto@ucsd.edu) Received: (from okumoto@localhost) by oec-server2.ucsd.edu (8.12.9p2/8.12.9/Submit) id j4O0L665032530; Mon, 23 May 2005 17:21:06 -0700 (PDT) (envelope-from okumoto@ucsd.edu) X-Authentication-Warning: oec-server2.ucsd.edu: okumoto set sender to okumoto@ucsd.edu using -f To: Harti Brandt References: <20050523153118.C28521@beagle.kn.op.dlr.de> From: Max Okumoto In-Reply-To: <20050523153118.C28521@beagle.kn.op.dlr.de> (Harti Brandt's message of "Mon, 23 May 2005 15:51:16 +0200 (CEST)") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) Date: Mon, 23 May 2005 17:21:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Milter: oec-server4.ucsd.edu spamtagger ($Revision: 1.100 $) X-Milter: oec-server4.ucsd.edu mailscan ($Revision: 1.143 $) X-MailscanStatus: Pass X-Spam-Level: Level X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on oec-server4.ucsd.edu X-Spam-Status: No, hits=-104.9 required=5.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.60 Cc: arch@freebsd.org Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 00:21:08 -0000 Harti Brandt writes: > Hi all, > > I think I found a problem in the shell code in make(1), but I'm not > sure whether to fix it or not and how. The problem is as follows: in > compat mode (this is the default mode when make(1) is not called with > -j) the command lines of a target are executed by one shell per line > (this is also how Posix wants it). To reduce the number of shells make > does an optimisation: when the command line does not contain one of a > pre-defined set of meta characters and does not start with one of a > predefined set of shell builtins, make directly exec's the command > instead of using an intermediate shell. The problem is that the > current list of builtins is limited to: > > alias cd eval exec exit read set ulimit unalias umask unset wait > > Obviously this is not the full set of shell builtins and does also not > contain the shell reserved words. > > The result of this is that for one and the same command you can get > different behaviour whether you execute it via make(1) or via sh -c > '...'. > As an example take echo(1). When called via the sh -c you get the builtin > echo which supports the -e option, when executed by make(1) you get > /bin/echo which doesn't. If you suddenly include a shell meta > character in the command line: > > foo: > echo "MAKEFLAGS: ${MAKEFLAGS}" > > you suddenly get also the builtin (':' is a meta character). > > For the reserved words the situation is almost the same. With the > following makefile: > > foo: > if > > one gets: > > if:No such file or directory, while > > foo: > if [ -x /bin/sh ] ; then echo hey ; fi > > you get what you expect. > > I think all this may be very confusing. The question is what to do. I > see the following options: > > 1. leave it as it is. > > 2. include the Posix reserved words and builtins into the list. > > 3. include all reserved words and builtins of our shell into the list. 4. Extend .SHELL: to allow specifing a list of built-in. And then we should define them in bsd.sys.mk or some other config file. > Option (3) is probably best. With (2) you still get different > behaviour for the two command lines in: > > foo: > bind -h > bind -h * > > (the first line will try to find bind in the path while the second > will execute the shell builtin). > > Opinions? This will allow people to add keywords for their shells, and remove that stuff from the make source code. Hard coding it in the binary is wrong. Max Okumoto > > harti > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue May 24 02:52:03 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 284E016A41C; Tue, 24 May 2005 02:52:03 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D5FB43D1D; Tue, 24 May 2005 02:52:00 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4O2sRwH025147; Mon, 23 May 2005 20:54:27 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42929680.3000309@samsco.org> Date: Mon, 23 May 2005 20:50:40 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harti Brandt References: <20050523153118.C28521@beagle.kn.op.dlr.de> In-Reply-To: <20050523153118.C28521@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: arch@freebsd.org Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 02:52:03 -0000 Harti Brandt wrote: > > Hi all, > > I think I found a problem in the shell code in make(1), but I'm not sure > whether to fix it or not and how. The problem is as follows: in compat > mode (this is the default mode when make(1) is not called with -j) the > command lines of a target are executed by one shell per line (this is > also how Posix wants it). To reduce the number of shells make does an > optimisation: when the command line does not contain one of a > pre-defined set of meta characters and does not start with one of a > predefined set of shell builtins, make directly exec's the command > instead of using an intermediate shell. The problem is that the current > list of builtins is limited to: > > alias cd eval exec exit read set ulimit unalias umask unset wait > > Obviously this is not the full set of shell builtins and does also not > contain the shell reserved words. > > The result of this is that for one and the same command you can get > different behaviour whether you execute it via make(1) or via sh -c '...'. > As an example take echo(1). When called via the sh -c you get the builtin > echo which supports the -e option, when executed by make(1) you get > /bin/echo which doesn't. If you suddenly include a shell meta character > in the command line: > > foo: > echo "MAKEFLAGS: ${MAKEFLAGS}" > > you suddenly get also the builtin (':' is a meta character). > > For the reserved words the situation is almost the same. With the > following makefile: > > foo: > if > > one gets: > > if:No such file or directory, while > > foo: > if [ -x /bin/sh ] ; then echo hey ; fi > > you get what you expect. > > I think all this may be very confusing. The question is what to do. I > see the following options: > > 1. leave it as it is. > > 2. include the Posix reserved words and builtins into the list. > > 3. include all reserved words and builtins of our shell into the list. > > Option (3) is probably best. With (2) you still get different behaviour > for the two command lines in: > > foo: > bind -h > bind -h * > > (the first line will try to find bind in the path while the second will > execute the shell builtin). > > Opinions? > > harti 4. Separate /bin/sh into a front end and back end (libsh) and include libsh into make. (running and hiding as I hit the 'send' key) Scott From owner-freebsd-arch@FreeBSD.ORG Tue May 24 07:32:11 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CAFE16A41C for ; Tue, 24 May 2005 07:32:11 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8326543D1D for ; Tue, 24 May 2005 07:32:10 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 09:32:09 +0200 Date: Tue, 24 May 2005 09:32:11 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Max Okumoto In-Reply-To: Message-ID: <20050524093101.M50725@beagle.kn.op.dlr.de> References: <20050523153118.C28521@beagle.kn.op.dlr.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 May 2005 07:32:09.0281 (UTC) FILETIME=[B1848310:01C56032] Cc: arch@freebsd.org Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 07:32:11 -0000 On Mon, 23 May 2005, Max Okumoto wrote: MO>Harti Brandt writes: MO> MO>> I think all this may be very confusing. The question is what to do. I MO>> see the following options: MO>> MO>> 1. leave it as it is. MO>> MO>> 2. include the Posix reserved words and builtins into the list. MO>> MO>> 3. include all reserved words and builtins of our shell into the list. MO> MO>4. Extend .SHELL: to allow specifing a list of built-in. And then MO> we should define them in bsd.sys.mk or some other config file. Sure. That code is ready already. The question is what list of builtins do we include per-default? harti From owner-freebsd-arch@FreeBSD.ORG Tue May 24 07:34:54 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7392B16A41F for ; Tue, 24 May 2005 07:34:54 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC1B643D4C for ; Tue, 24 May 2005 07:34:53 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 09:34:52 +0200 Date: Tue, 24 May 2005 09:34:54 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Scott Long In-Reply-To: <42929680.3000309@samsco.org> Message-ID: <20050524093242.R50725@beagle.kn.op.dlr.de> References: <20050523153118.C28521@beagle.kn.op.dlr.de> <42929680.3000309@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 May 2005 07:34:52.0811 (UTC) FILETIME=[12FD35B0:01C56033] Cc: arch@freebsd.org Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 07:34:54 -0000 On Mon, 23 May 2005, Scott Long wrote: SL>Harti Brandt wrote: SL> SL>> SL>> Hi all, SL>> SL>> I think I found a problem in the shell code in make(1), but I'm not sure SL>> whether to fix it or not and how. The problem is as follows: in compat mode SL>> (this is the default mode when make(1) is not called with -j) the command SL>> lines of a target are executed by one shell per line (this is also how SL>> Posix wants it). To reduce the number of shells make does an optimisation: SL>> when the command line does not contain one of a pre-defined set of meta SL>> characters and does not start with one of a predefined set of shell SL>> builtins, make directly exec's the command instead of using an intermediate SL>> shell. The problem is that the current list of builtins is limited to: SL>> SL>> alias cd eval exec exit read set ulimit unalias umask unset wait SL>> SL>> Obviously this is not the full set of shell builtins and does also not SL>> contain the shell reserved words. SL>> SL>> The result of this is that for one and the same command you can get SL>> different behaviour whether you execute it via make(1) or via sh -c '...'. SL>> As an example take echo(1). When called via the sh -c you get the builtin SL>> echo which supports the -e option, when executed by make(1) you get SL>> /bin/echo which doesn't. If you suddenly include a shell meta character in SL>> the command line: SL>> SL>> foo: SL>> echo "MAKEFLAGS: ${MAKEFLAGS}" SL>> SL>> you suddenly get also the builtin (':' is a meta character). SL>> SL>> For the reserved words the situation is almost the same. With the following SL>> makefile: SL>> SL>> foo: SL>> if SL>> SL>> one gets: SL>> SL>> if:No such file or directory, while SL>> SL>> foo: SL>> if [ -x /bin/sh ] ; then echo hey ; fi SL>> SL>> you get what you expect. SL>> SL>> I think all this may be very confusing. The question is what to do. I see SL>> the following options: SL>> SL>> 1. leave it as it is. SL>> SL>> 2. include the Posix reserved words and builtins into the list. SL>> SL>> 3. include all reserved words and builtins of our shell into the list. SL>> SL>> Option (3) is probably best. With (2) you still get different behaviour for SL>> the two command lines in: SL>> SL>> foo: SL>> bind -h SL>> bind -h * SL>> SL>> (the first line will try to find bind in the path while the second will SL>> execute the shell builtin). SL>> SL>> Opinions? SL>> SL>> harti SL> SL>4. Separate /bin/sh into a front end and back end (libsh) and include libsh SL>into make. SL> SL>(running and hiding as I hit the 'send' key) Would there be other uses for this? harti From owner-freebsd-arch@FreeBSD.ORG Tue May 24 07:51:22 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 567B516A41F for ; Tue, 24 May 2005 07:51:22 +0000 (GMT) (envelope-from halil@enderunix.org) Received: from biltens.etika.net (mail.etikaweb.net [65.75.141.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10BF543D1F for ; Tue, 24 May 2005 07:51:21 +0000 (GMT) (envelope-from halil@enderunix.org) Received: from [217.31.230.158] (helo=nitrium) by biltens.etika.net with esmtp (Exim 4.44) id 1DaUBz-0002WW-Oi for freebsd-arch@freebsd.org; Tue, 24 May 2005 10:51:17 +0300 From: Halil Demirezen Organization: Enderunix To: freebsd-arch@freebsd.org Date: Tue, 24 May 2005 10:49:41 +0000 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505241049.42247.halil@enderunix.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biltens.etika.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - enderunix.org X-Source: X-Source-Args: X-Source-Dir: Subject: linksys pcmcia Wireless card X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 07:51:22 -0000 Hi, Is there a driver for Linksys Wireless-G pcmcia Wireless notebook card for FreeBSD 5.3 ? Sincerely From owner-freebsd-arch@FreeBSD.ORG Tue May 24 08:08:21 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91B1316A41C for ; Tue, 24 May 2005 08:08:21 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13A2C43D1D for ; Tue, 24 May 2005 08:08:20 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 10:08:19 +0200 Date: Tue, 24 May 2005 10:08:19 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Max Okumoto In-Reply-To: Message-ID: <20050524100205.W50725@beagle.kn.op.dlr.de> References: <20050523153118.C28521@beagle.kn.op.dlr.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 May 2005 08:08:19.0416 (UTC) FILETIME=[BF04D580:01C56037] Cc: arch@freebsd.org Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 08:08:21 -0000 On Mon, 23 May 2005, Max Okumoto wrote: MO>4. Extend .SHELL: to allow specifing a list of built-in. And then MO> we should define them in bsd.sys.mk or some other config file. We would need to add yet another config file for this because make doesn't read anything if given the -r flag. It would end up having no shell which would be wrong. MO>This will allow people to add keywords for their shells, and MO>remove that stuff from the make source code. Hard coding it MO>in the binary is wrong. The initial shell (/bin/sh) must be in the binary because it must run with -r. I see no sense to add another config file just for the purpose of specifying the shell. What would that give you that you cannot do now? harti From owner-freebsd-arch@FreeBSD.ORG Tue May 24 08:17:05 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5747816A41C; Tue, 24 May 2005 08:17:05 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pastinakel.tue.nl (pastinakel.tue.nl [131.155.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id E52D243D1D; Tue, 24 May 2005 08:17:04 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: by pastinakel.tue.nl (Postfix, from userid 40) id E687914BBDB; Tue, 24 May 2005 10:17:03 +0200 (CEST) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by pastinakel.tue.nl (Postfix) with ESMTP id 9CABC14BC3F; Tue, 24 May 2005 10:17:00 +0200 (CEST) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.13.3/8.13.1/Submit) id j4O8H0tQ027871; Tue, 24 May 2005 10:17:00 +0200 (CEST) (envelope-from stijn) Date: Tue, 24 May 2005 10:17:00 +0200 From: Stijn Hoop To: Harti Brandt Message-ID: <20050524081700.GF95023@pcwin002.win.tue.nl> References: <20050523153118.C28521@beagle.kn.op.dlr.de> <20050524100205.W50725@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WplhKdTI2c8ulnbP" Content-Disposition: inline In-Reply-To: <20050524100205.W50725@beagle.kn.op.dlr.de> User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! X-Spam-DCC: : pastinakel.tue.nl 1074; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pastinakel.tue.nl X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=6.3 tests=BAYES_00 autolearn=ham version=2.64 Cc: arch@freebsd.org, Max Okumoto Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 08:17:05 -0000 --WplhKdTI2c8ulnbP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 24, 2005 at 10:08:19AM +0200, Harti Brandt wrote: > On Mon, 23 May 2005, Max Okumoto wrote: >=20 > MO>4. Extend .SHELL: to allow specifing a list of built-in. And then > MO> we should define them in bsd.sys.mk or some other config file. >=20 > We would need to add yet another config file for this because make > doesn't read anything if given the -r flag. It would end up having > no shell which would be wrong. Or, add a way to query /bin/sh for the list of builtins (sh --show-builtins) and use that in the absence of an explicit .SHELL. > MO>This will allow people to add keywords for their shells, and > MO>remove that stuff from the make source code. Hard coding it > MO>in the binary is wrong. >=20 > The initial shell (/bin/sh) must be in the binary because it must run with > -r. I see no sense to add another config file just for the purpose > of specifying the shell. What would that give you that you cannot do now? I think it's more that hardcoding a list of builtins is undesirable. --Stijn --=20 "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Marcus Brigstocke (http://www.marcusbrigstocke.com/pacman.asp) --WplhKdTI2c8ulnbP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCkuL8Y3r/tLQmfWcRAsSjAKCqPUQFSwSpvMtibQhpHYzQoZP4xgCfZwy5 v3bu21CQ8xEz317dhJBPdCw= =MB+i -----END PGP SIGNATURE----- --WplhKdTI2c8ulnbP-- From owner-freebsd-arch@FreeBSD.ORG Tue May 24 08:28:31 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E98B616A41C for ; Tue, 24 May 2005 08:28:31 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63C2D43D53 for ; Tue, 24 May 2005 08:28:31 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 10:28:29 +0200 Date: Tue, 24 May 2005 10:28:30 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Stijn Hoop In-Reply-To: <20050524081700.GF95023@pcwin002.win.tue.nl> Message-ID: <20050524101903.N50725@beagle.kn.op.dlr.de> References: <20050523153118.C28521@beagle.kn.op.dlr.de> <20050524100205.W50725@beagle.kn.op.dlr.de> <20050524081700.GF95023@pcwin002.win.tue.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 May 2005 08:28:30.0156 (UTC) FILETIME=[90AD18C0:01C5603A] Cc: arch@freebsd.org, Max Okumoto Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 08:28:32 -0000 On Tue, 24 May 2005, Stijn Hoop wrote: SH>On Tue, May 24, 2005 at 10:08:19AM +0200, Harti Brandt wrote: SH>> On Mon, 23 May 2005, Max Okumoto wrote: SH>> SH>> MO>4. Extend .SHELL: to allow specifing a list of built-in. And then SH>> MO> we should define them in bsd.sys.mk or some other config file. SH>> SH>> We would need to add yet another config file for this because make SH>> doesn't read anything if given the -r flag. It would end up having SH>> no shell which would be wrong. SH> SH>Or, add a way to query /bin/sh for the list of builtins (sh SH>--show-builtins) and use that in the absence of an explicit .SHELL. SH> SH>> MO>This will allow people to add keywords for their shells, and SH>> MO>remove that stuff from the make source code. Hard coding it SH>> MO>in the binary is wrong. SH>> SH>> The initial shell (/bin/sh) must be in the binary because it must run with SH>> -r. I see no sense to add another config file just for the purpose SH>> of specifying the shell. What would that give you that you cannot do now? SH> SH>I think it's more that hardcoding a list of builtins is undesirable. That's no problem. We can just hardcode an empty list of builtins. In that case make always uses the shell. We can then put the actual list of builtins into sys.mk (or even retrieve it there from the shell via $(/bin/sh --show-builtins:sh). The question is do we really want to have, for example, 'bind' execute the shell builtin or do we want to execute it a bind somewhere in the path? From the point of makefile portability the later is desirable, because someone could legally have a script called bind in the build directory and call it via make. 'bind' is not in the list of builtins specified by Posix (I hope) so one would not expect to get any problems. On the other hand executing the bind builtin may be less surprising to people writing a makefile specifically for FreeBSD. That way, at an early stage, one may decide not to use bind as the name of a script. harti From owner-freebsd-arch@FreeBSD.ORG Tue May 24 09:32:42 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B111E16A41C; Tue, 24 May 2005 09:32:42 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail20.syd.optusnet.com.au (mail20.syd.optusnet.com.au [211.29.132.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F0C443D48; Tue, 24 May 2005 09:32:41 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mail20.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j4O9WdGL004525 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 May 2005 19:32:40 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j4O9WdRx014307; Tue, 24 May 2005 19:32:39 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j4O9WcM2014306; Tue, 24 May 2005 19:32:39 +1000 (EST) (envelope-from pjeremy) Date: Tue, 24 May 2005 19:32:38 +1000 From: Peter Jeremy To: Harti Brandt Message-ID: <20050524093238.GC12640@cirb503493.alcatel.com.au> References: <20050523153118.C28521@beagle.kn.op.dlr.de> <42929680.3000309@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42929680.3000309@samsco.org> User-Agent: Mutt/1.4.2i Cc: arch@freebsd.org Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 09:32:42 -0000 On Mon, 2005-May-23 20:50:40 -0600, Scott Long wrote: >Harti Brandt wrote: >>The result of this is that for one and the same command you can get >>different behaviour whether you execute it via make(1) or via sh -c '...'. Not to mention the effect of IFS. Does POSIX provide any helpful suggestions on how to efficiently implement the behaviour they specify? >4. Separate /bin/sh into a front end and back end (libsh) and include >libsh into make. And this still won't help people who use .SHELL (or similar) to pick a different shell. 5) Add a "POSIX_ME_HARDER" option that just invokes the shell on every command. In the absence of this option, make(1) is free to directly exec the command if it's simple enough. 6) Add two new magic line markers (to supplement '@', '+' and '-') to require the line be executed using the shell or exec'd directly, superceding the buildin rules. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Tue May 24 10:46:36 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8DF316A41F for ; Tue, 24 May 2005 10:46:36 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5480D43D1F for ; Tue, 24 May 2005 10:46:35 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 12:46:33 +0200 Date: Tue, 24 May 2005 12:46:33 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Peter Jeremy In-Reply-To: <20050524093238.GC12640@cirb503493.alcatel.com.au> Message-ID: <20050524114748.O50725@beagle.kn.op.dlr.de> References: <20050523153118.C28521@beagle.kn.op.dlr.de> <42929680.3000309@samsco.org> <20050524093238.GC12640@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 May 2005 10:46:33.0944 (UTC) FILETIME=[DA32D580:01C5604D] Cc: arch@freebsd.org Subject: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 10:46:37 -0000 On Tue, 24 May 2005, Peter Jeremy wrote: PJ>On Mon, 2005-May-23 20:50:40 -0600, Scott Long wrote: PJ>>Harti Brandt wrote: PJ>>>The result of this is that for one and the same command you can get PJ>>>different behaviour whether you execute it via make(1) or via sh -c '...'. PJ> PJ>Not to mention the effect of IFS. Does POSIX provide any helpful PJ>suggestions on how to efficiently implement the behaviour they specify? POSIX has no .SHELL target - that's pmake's invention. IFS is no problem because in order to specify a different IFS you need to have at least a '=' on the command line. This is a meta character so the command will be executed by the shell. Generally POSIX says that make should execute command lines as if given to system(). System() in turn says that it should behave as if it fork()ed and execl()ed "sh -c ...". The as-if here seems to allow for our optimisation. PJ> PJ>>4. Separate /bin/sh into a front end and back end (libsh) and include PJ>>libsh into make. PJ> PJ>And this still won't help people who use .SHELL (or similar) to pick PJ>a different shell. PJ> PJ>5) Add a "POSIX_ME_HARDER" option that just invokes the shell on every PJ> command. In the absence of this option, make(1) is free to directly PJ> exec the command if it's simple enough. PJ> PJ>6) Add two new magic line markers (to supplement '@', '+' and '-') to PJ> require the line be executed using the shell or exec'd directly, PJ> superceding the buildin rules. You can alway make to execute the shell by putting a meta-character on the command line or by specifying and empty builtin list or an empty meta character list to .SHELL. But what should we do as default? harti From owner-freebsd-arch@FreeBSD.ORG Tue May 24 12:08:47 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEC7A16A41C for ; Tue, 24 May 2005 12:08:47 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6B9643D1F for ; Tue, 24 May 2005 12:08:47 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms076.mailsrvcs.net ([192.168.1.1]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGZ00H9JTQL68B3@vms042.mailsrvcs.net> for arch@freebsd.org; Tue, 24 May 2005 07:08:45 -0500 (CDT) Date: Tue, 24 May 2005 07:08:45 -0500 (CDT) From: Sergey Babkin To: Harti Brandt , Scott Long Message-id: <21970515.1116936525835.JavaMail.root@vms076.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: arch@freebsd.org Subject: Re: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 12:08:47 -0000 >From: Harti Brandt >On Mon, 23 May 2005, Scott Long wrote: > >SL>> Opinions? >SL>> >SL>> harti >SL> >SL>4. Separate /bin/sh into a front end and back end (libsh) and include libsh >SL>into make. >SL> >SL>(running and hiding as I hit the 'send' key) > >Would there be other uses for this? Yes, I think it could be useful for many programs. Or one more option: add a flag to shell that will make it exit after any command returning non-0 status (at the ";" point, as opposed to "&&", "||" and such). Then make could just pass all the commands to the shell in one go. And it would be very useful for all kinds of sysadmin scripts as well where explicitly checking for the results of every command is a pain. Even with make it would be a big improvement, since in the current format a command failing inside a "for" loop won't cause make to stop unless explicitly programmed so, like: target: dependencies for ... ;\ do \ cmd || exit 1; \ done -SB From owner-freebsd-arch@FreeBSD.ORG Tue May 24 12:19:18 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E30716A41C for ; Tue, 24 May 2005 12:19:18 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4B6243D1F for ; Tue, 24 May 2005 12:19:17 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 14:19:15 +0200 Date: Tue, 24 May 2005 14:19:17 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Sergey Babkin In-Reply-To: <21970515.1116936525835.JavaMail.root@vms076.mailsrvcs.net> Message-ID: <20050524141425.A50725@beagle.kn.op.dlr.de> References: <21970515.1116936525835.JavaMail.root@vms076.mailsrvcs.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 May 2005 12:19:15.0834 (UTC) FILETIME=[CD57E5A0:01C5605A] Cc: arch@freebsd.org Subject: Re: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 12:19:18 -0000 On Tue, 24 May 2005, Sergey Babkin wrote: SB>>From: Harti Brandt SB> SB>>On Mon, 23 May 2005, Scott Long wrote: SB>> SB> SB>>SL>> Opinions? SB>>SL>> SB>>SL>> harti SB>>SL> SB>>SL>4. Separate /bin/sh into a front end and back end (libsh) and include libsh SB>>SL>into make. SB>>SL> SB>>SL>(running and hiding as I hit the 'send' key) SB>> SB>>Would there be other uses for this? SB> SB>Yes, I think it could be useful for many programs. Hmm. What program is executing shell lines? SB>Or one more option: add a flag to shell that SB>will make it exit after any command returning non-0 SB>status (at the ";" point, as opposed to "&&", SB>"||" and such). Then make could just pass all SB>the commands to the shell in one go. And it would There is the -e flag which does exactly this. Well, the description in the Posix page is a little bit convoluted, but basically it exits when a program whose exit status is not expclicitely tested exits with a non-zero status (this is not entirely correct, but almost). And currently we actually use sh -ec to execute commands. The problem with this is, that Posix wants sh -c. No -e! I think NetBSD has changed this (and there is a PR with a patch), but I'm somewhat reluctant to do it, because it may break things in unexpected ways. My current plan is to make the default -e normally and without -e in Posix mode. SB>be very useful for all kinds of sysadmin scripts SB>as well where explicitly checking for the results SB>of every command is a pain. Even with make it SB>would be a big improvement, since in the current SB>format a command failing inside a "for" loop SB>won't cause make to stop unless explicitly programmed SB>so, like: SB> SB>target: dependencies SB> for ... ;\ SB> do \ SB> cmd || exit 1; \ SB> done This is the canonical way to write this. Our make, however doesn't need it. harti From owner-freebsd-arch@FreeBSD.ORG Tue May 24 16:42:08 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 787DE16A41C for ; Tue, 24 May 2005 16:42:08 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5286543D1F for ; Tue, 24 May 2005 16:42:08 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms074.mailsrvcs.net ([192.168.1.3]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IH000A9S6E7ONQ4@vms044.mailsrvcs.net> for arch@freebsd.org; Tue, 24 May 2005 11:42:07 -0500 (CDT) Date: Tue, 24 May 2005 11:42:07 -0500 (CDT) From: Sergey Babkin To: Harti Brandt , Sergey Babkin Message-id: <4494552.1116952927843.JavaMail.root@vms074.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: arch@freebsd.org Subject: Re: Re: Re: Handling of shell builtins in make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 16:42:08 -0000 >From: Harti Brandt >SB>>SL>4. Separate /bin/sh into a front end and back end (libsh) and include libsh >SB>>SL>into make. >SB>>SL> >SB>>SL>(running and hiding as I hit the 'send' key) >SB>> >SB>>Would there be other uses for this? >SB> >SB>Yes, I think it could be useful for many programs. > >Hmm. What program is executing shell lines? Anything that allows the user to enter a shell command to execute? Such as more, vi and others. It would be real neat if they could keep the shell variables and such between the commands. >SB>Or one more option: add a flag to shell that >SB>will make it exit after any command returning non-0 >SB>status (at the ";" point, as opposed to "&&", >SB>"||" and such). Then make could just pass all >SB>the commands to the shell in one go. And it would > >There is the -e flag which does exactly this. Well, the description in the Oh, I'm out of date again. -SB From owner-freebsd-arch@FreeBSD.ORG Wed May 25 12:20:47 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02D1016A41C for ; Wed, 25 May 2005 12:20:47 +0000 (GMT) (envelope-from nyan@jp.FreeBSD.org) Received: from watery.cc.kogakuin.ac.jp (watery.cc.kogakuin.ac.jp [133.80.152.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F30F43D54 for ; Wed, 25 May 2005 12:20:46 +0000 (GMT) (envelope-from nyan@jp.FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) by watery.cc.kogakuin.ac.jp (8.13.3/8.13.3) with ESMTP id j4PCKieR061483 for ; Wed, 25 May 2005 21:20:44 +0900 (JST) (envelope-from nyan@jp.FreeBSD.org) Date: Wed, 25 May 2005 21:20:09 +0900 (JST) Message-Id: <20050525.212009.71136852.nyan@jp.FreeBSD.org> To: arch@freebsd.org From: Takahashi Yoshihiro X-Mailer: Mew version 4.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: Subject: [RFC] remove bus_memio.h and bus_pio.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 12:20:47 -0000 The bus_memio.h and bus_pio.h for a micro-optimization depend on the implementation of the bus_space on i386 and amd64, so they are meaningless files on the other archs. I'd like to remove a MD part like this from MI drivers at least. I think that a increasing performance by using this method is very trivial on recent machines. If there is not strong objection, I'll remove bus_{mem,p}io.h and related code from all archs. Comments? --- TAKAHASHI Yoshihiro From owner-freebsd-arch@FreeBSD.ORG Wed May 25 16:54:06 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3E1D16A41C; Wed, 25 May 2005 16:54:06 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from schizoid.village.org (schizoid.village.org [168.103.84.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1133F43D55; Wed, 25 May 2005 16:54:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (duck-pond.village.org [10.200.4.2]) by schizoid.village.org (8.12.9p2/8.12.9) with ESMTP id j4PGrhVY027207; Wed, 25 May 2005 10:53:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 25 May 2005 10:53:42 -0600 (MDT) Message-Id: <20050525.105342.74713758.imp@bsdimp.com> To: bms@spc.org From: "M. Warner Losh" In-Reply-To: <20050522025914.GD1108@empiric.icir.org> References: <428FC00B.3080909@freebsd.org> <1116729865.1917.92.camel@palm> <20050522025914.GD1108@empiric.icir.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-arch@freebsd.org, cperciva@freebsd.org, ups@tree.com Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 16:54:07 -0000 In message: <20050522025914.GD1108@empiric.icir.org> Bruce M Simpson writes: : On Sat, May 21, 2005 at 10:44:25PM -0400, Stephan Uphoff wrote: : > Beside benchmarking - is there any other real use for RDTSC ? : > Is there any use of RDTSC that system requiring the security cannot live : > without? (We could even try to emulate the instruction if we really need : > to) : : A number of ports use RDTSC for high-resolution timing. The most obvious : examples being machine emulators mostly used for gaming (UAE and MAME : spring to mind, possibly also dosbox and others). Which also makes it hard to emulate, since that adds a lot of overhead to the numbers... Warner From owner-freebsd-arch@FreeBSD.ORG Wed May 25 17:19:53 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 538E216A41C for ; Wed, 25 May 2005 17:19:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from schizoid.village.org (schizoid.village.org [168.103.84.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 879BA43D53 for ; Wed, 25 May 2005 17:19:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (duck-pond.village.org [10.200.4.2]) by schizoid.village.org (8.12.9p2/8.12.9) with ESMTP id j4PHJkVY027375; Wed, 25 May 2005 11:19:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 25 May 2005 11:19:45 -0600 (MDT) Message-Id: <20050525.111945.41668351.imp@bsdimp.com> To: nyan@jp.FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20050525.212009.71136852.nyan@jp.FreeBSD.org> References: <20050525.212009.71136852.nyan@jp.FreeBSD.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: arch@freebsd.org Subject: Re: [RFC] remove bus_memio.h and bus_pio.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 17:19:53 -0000 In message: <20050525.212009.71136852.nyan@jp.FreeBSD.org> Takahashi Yoshihiro writes: : The bus_memio.h and bus_pio.h for a micro-optimization depend on the : implementation of the bus_space on i386 and amd64, so they are : meaningless files on the other archs. I'd like to remove a MD part : like this from MI drivers at least. : : I think that a increasing performance by using this method is very : trivial on recent machines. If there is not strong objection, I'll : remove bus_{mem,p}io.h and related code from all archs. : : Comments? Short answer: Great idea. aac and bfe should be tested after the change to see if there is any benefit for them. Other drivers almost certainly will see no benefit from this. Longer, more detailed answer. The original idea was to provide a hint to busspace that this driver only ever used a certain subset of the available mappings so it should assume that subset and agressively optimize the code. The assumption was that one could know at compile time that one would never use certain features. In an i386 centric world, this made good sense, especially since the bus_space_* macros expanded to inb or whatever and nothing else (compiler technology innovations may have changed this over time). You are correct in that other architectures might have more than two kinds of address space, might have other complicating factors. pc98 has, as you know, an indirect vector because devices on the motherboard and cbus are rarely mapped at contiguous locations due to the dual 8-bit bus nature of the internal buses. In that case it makes no sense to do any optimization at all, and these files should be empty for such an implementation. Alpha, sparc64, powerpc and arm all have much more complex bus space implementations due to their greater intra-architectural differences, as well as their large difference with i386. To similarly optimize these architectures, one would need additional MD info to know how to inline things. None of them have chosen to support this level of optimization. It is unclear to me how big a win such optimiztion would be, even on the slower CPUs some of these platforms support. The lowest end of FreeBSD/i386 these days[*] is likely a Pentium II running at 300MHz or a soekris box. The 4510 box is still only 166MHz. However, the only device that it has that are likely to benefit from this is sio. Well, in extreme cases, one could make the case for any pci card or pccard, but I think that's too extreme to consider. Since the soekris box has only one free serial port, we need only keep up with a ppp connection on that serial port, so I'm pretty sure we're OK. A number of drivers include only one of these two include files: ti, bfe, trm, stg, scd, aac, kbd, ie, idt, hfa, gfb, fb, dpt, cnw, aic, aha, ahb, adv and some of the mii phy drivers, plus some other trivial uses. The only ones on the list that stand out are bfe and aac (the dpt optimization is only for EISA cards, and only for the EISA specific portions of the driver). I do not know how much this optimization helps these devices, but they are the only ones that I see might be affected. Simple benchmarks should be easy enough to do on aac and bfe. Warner [*] Yes, I know that slower CPUs are supported, and do still perform decently if you have enough memory. This is an arbitrary cutoff for the cost-benefit analysis. From owner-freebsd-arch@FreeBSD.ORG Wed May 25 17:42:26 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6499016A41C for ; Wed, 25 May 2005 17:42:26 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E0E543D53 for ; Wed, 25 May 2005 17:42:25 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j4PHeNkl001439; Wed, 25 May 2005 10:40:23 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050525.111945.41668351.imp@bsdimp.com> References: <20050525.212009.71136852.nyan@jp.FreeBSD.org> <20050525.111945.41668351.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 25 May 2005 10:40:23 -0700 To: "M. Warner Losh" X-Mailer: Apple Mail (2.622) Cc: arch@freebsd.org, nyan@jp.FreeBSD.org Subject: Re: [RFC] remove bus_memio.h and bus_pio.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 17:42:26 -0000 On May 25, 2005, at 10:19 AM, M. Warner Losh wrote: > Short answer: > > Great idea. Seconded. > Longer, more detailed answer. > > The original idea was to provide a hint to busspace that this driver > only ever used a certain subset of the available mappings so it should > assume that subset and agressively optimize the code. It has also worked against, well, me in the past in that I couldn't figure out why a driver simply didn't want to work with memio while it worked perfectly with pio. Then I spotted the bus_pio.h header at the top and cursed, cursed, cursed. I'm all for performance tuning, but the newbus optimization is just too weird for its own good this way. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Thu May 26 08:35:23 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 240FB16A41C; Thu, 26 May 2005 08:35:23 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40A4B43D70; Thu, 26 May 2005 08:35:15 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.12.11) with ESMTP id j4Q8XovP030875; Thu, 26 May 2005 09:33:50 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Thu, 26 May 2005 09:33:47 +0100 User-Agent: KMail/1.8 References: <20050525.212009.71136852.nyan@jp.FreeBSD.org> <20050525.111945.41668351.imp@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505260933.49013.dfr@nlsystems.com> X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/894/Wed May 25 13:53:16 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: arch@freebsd.org, nyan@jp.FreeBSD.org, Marcel Moolenaar Subject: Re: [RFC] remove bus_memio.h and bus_pio.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 08:35:23 -0000 On Wednesday 25 May 2005 18:40, Marcel Moolenaar wrote: > On May 25, 2005, at 10:19 AM, M. Warner Losh wrote: > > Short answer: > > > > Great idea. > > Seconded. Thirded. > > > Longer, more detailed answer. > > > > The original idea was to provide a hint to busspace that this > > driver only ever used a certain subset of the available mappings so > > it should assume that subset and agressively optimize the code. > > It has also worked against, well, me in the past in that I couldn't > figure out why a driver simply didn't want to work with memio while > it worked perfectly with pio. Then I spotted the bus_pio.h header at > the top and cursed, cursed, cursed. > > I'm all for performance tuning, but the newbus optimization is just > too weird for its own good this way. Hey, don't blame this on newbus - it predates newbus by quite a bit. I seem to remember that this came in with the first import of CAM so you can blame Justin :-) From owner-freebsd-arch@FreeBSD.ORG Thu May 26 08:35:23 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 240FB16A41C; Thu, 26 May 2005 08:35:23 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40A4B43D70; Thu, 26 May 2005 08:35:15 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.12.11) with ESMTP id j4Q8XovP030875; Thu, 26 May 2005 09:33:50 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Thu, 26 May 2005 09:33:47 +0100 User-Agent: KMail/1.8 References: <20050525.212009.71136852.nyan@jp.FreeBSD.org> <20050525.111945.41668351.imp@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505260933.49013.dfr@nlsystems.com> X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/894/Wed May 25 13:53:16 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: arch@freebsd.org, nyan@jp.FreeBSD.org, Marcel Moolenaar Subject: Re: [RFC] remove bus_memio.h and bus_pio.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 08:35:23 -0000 On Wednesday 25 May 2005 18:40, Marcel Moolenaar wrote: > On May 25, 2005, at 10:19 AM, M. Warner Losh wrote: > > Short answer: > > > > Great idea. > > Seconded. Thirded. > > > Longer, more detailed answer. > > > > The original idea was to provide a hint to busspace that this > > driver only ever used a certain subset of the available mappings so > > it should assume that subset and agressively optimize the code. > > It has also worked against, well, me in the past in that I couldn't > figure out why a driver simply didn't want to work with memio while > it worked perfectly with pio. Then I spotted the bus_pio.h header at > the top and cursed, cursed, cursed. > > I'm all for performance tuning, but the newbus optimization is just > too weird for its own good this way. Hey, don't blame this on newbus - it predates newbus by quite a bit. I seem to remember that this came in with the first import of CAM so you can blame Justin :-) From owner-freebsd-arch@FreeBSD.ORG Thu May 26 20:24:26 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45D5516A41C for ; Thu, 26 May 2005 20:24:26 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA90543D1F for ; Thu, 26 May 2005 20:24:25 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.buffalo.edu [128.205.32.4]) by opus.cse.buffalo.edu (8.13.3/8.12.10) with ESMTP id j4QKOPHE083084 for ; Thu, 26 May 2005 16:24:25 -0400 (EDT) From: Ken Smith To: freebsd-arch@freebsd.org Content-Type: text/plain Organization: U. Buffalo CSE Department Date: Thu, 26 May 2005 16:24:25 -0400 Message-Id: <1117139065.82793.20.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 20:24:26 -0000 I started working on this many months ago and just as it seemed like we got to a point the people involved (mostly Bruce Evans...) were satisfied with the proposed solution I got ... sidetracked... The issue is that the standards say a file's access time should be modified when it gets executed. We don't do that. This patch takes care of it by adding a new vnode flag that is used by the kernel to indicate that it has blessed an update of a file's access time. The flag gets set at the point the file get executed and the individual filesystems are expected to handle the details. Some don't store access times so it's a non-issue for them. UFS needs to handle it the same way as it would modifying the access time for a read - it shouldn't block, needs to be careful about whether a snapshot is in progress, bypasses most security checks, etc. This patch is mostly Bruce's work. The final version of what he sent me had more changes in it that weren't directly related to fixing the atime issue that I still need to look over and understand better... :-) Any thoughts before I commit it? The patch itself is pretty small. But given the sections of code it's mucking with combined with it adding a little 'nit' filesystem implementers should be aware of I wanted to run it by as many clueful eyes as possible before doing the final commit. Thanks. Index: sys/kern/kern_exec.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.271 diff -u -r1.271 kern_exec.c --- sys/kern/kern_exec.c 3 May 2005 16:24:59 -0000 1.271 +++ sys/kern/kern_exec.c 26 May 2005 19:11:04 -0000 @@ -284,7 +284,7 @@ register_t *stack_base; int error, len, i; struct image_params image_params, *imgp; - struct vattr attr; + struct vattr atimeattr, attr; int (*img_first)(struct image_params *); struct pargs *oldargs = NULL, *newargs = NULL; struct sigacts *oldsigacts, *newsigacts; @@ -695,6 +695,18 @@ exec_setregs(td, imgp->entry_addr, (u_long)(uintptr_t)stack_base, imgp->ps_strings); + /* + * Here we should update the access time of the file. This must + * be implemented by the underlying filesystem in the same way as + * access timestamps for a VOP_READ() because we want to avoid + * blocking and/or I/O, and have not called vn_start_write(). + */ + if ((imgp->vp->v_mount->mnt_flag & (MNT_NOATIME | MNT_RDONLY)) == 0) { + VATTR_NULL(&atimeattr); + atimeattr.va_vaflags |= VA_EXECVE_ATIME; + (void)VOP_SETATTR(img->vp, &atimeattr, td->td_ucred, td); + } + done1: /* * Free any resources malloc'd earlier that we didn't use. Index: sys/sys/vnode.h =================================================================== RCS file: /home/ncvs/src/sys/sys/vnode.h,v retrieving revision 1.299 diff -u -r1.299 vnode.h --- sys/sys/vnode.h 27 Apr 2005 09:18:10 -0000 1.299 +++ sys/sys/vnode.h 26 May 2005 15:23:37 -0000 @@ -284,6 +284,7 @@ */ #define VA_UTIMES_NULL 0x01 /* utimes argument was NULL */ #define VA_EXCLUSIVE 0x02 /* exclusive create request */ +#define VA_EXECVE_ATIME 0x04 /* setting atime for execve */ /* * Flags for ioflag. (high 16 bits used to ask for read-ahead and Index: sys/ufs/ufs/ufs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v retrieving revision 1.269 diff -u -r1.269 ufs_vnops.c --- sys/ufs/ufs/ufs_vnops.c 18 May 2005 22:18:21 -0000 1.269 +++ sys/ufs/ufs/ufs_vnops.c 26 May 2005 19:31:59 -0000 @@ -443,6 +443,20 @@ ((int)vap->va_bytes != VNOVAL) || (vap->va_gen != VNOVAL)) { return (EINVAL); } + /* + * Update the file's access time when it has been executed. We are + * doing this here to specifically avoid some of the checks done + * below -- this operation is done by request of the kernel and + * should bypass some security checks. Things like read-only + * checks get handled by other levels (e.g., ffs_update()). + */ + if (vap->va_vaflags & VA_EXECVE_ATIME) { + ip->i_flag |= IN_ACCESS; + return (0); + } + /* + * Go through the fields and update iff not VNOVAL. + */ if (vap->va_flags != VNOVAL) { if (vp->v_mount->mnt_flag & MNT_RDONLY) return (EROFS); @@ -493,9 +507,6 @@ } if (ip->i_flags & (IMMUTABLE | APPEND)) return (EPERM); - /* - * Go through the fields and update iff not VNOVAL. - */ if (vap->va_uid != (uid_t)VNOVAL || vap->va_gid != (gid_t)VNOVAL) { if (vp->v_mount->mnt_flag & MNT_RDONLY) return (EROFS); -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-arch@FreeBSD.ORG Fri May 27 09:17:52 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 452B316A41C for ; Fri, 27 May 2005 09:17:52 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6EA043D4C for ; Fri, 27 May 2005 09:17:51 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 60D471F157; Fri, 27 May 2005 11:17:50 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 4218C655D; Fri, 27 May 2005 11:17:50 +0200 (CEST) Date: Fri, 27 May 2005 11:17:50 +0200 From: Marc Olzheim To: Ken Smith Message-ID: <20050527091750.GB91258@stack.nl> References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline In-Reply-To: <1117139065.82793.20.camel@opus.cse.buffalo.edu> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: freebsd-arch@freebsd.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 09:17:52 -0000 --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 26, 2005 at 04:24:25PM -0400, Ken Smith wrote: > Any thoughts before I commit it? The patch itself is pretty small. But > given the sections of code it's mucking with combined with it adding a > little 'nit' filesystem implementers should be aware of I wanted to run > it by as many clueful eyes as possible before doing the final commit. Has this been run through some kind of real world performance test ? I can imagine for instance /bin/sh's vnode is being updated a lot... Would it be eligible to a becoming a mount option ? I don't see any real problems with it, but perhaps people running executables over NFS filesystems that cannot be mounted with noatime might have an issue, like netbooting diskless machines... Marc --61jdw2sOBCFtR2d/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCluW+ezjnobFOgrERAvQ6AJ94j17A3kxbnFee4Q/VpbGqciE9fwCfTBUK X56bUiy+sGLKQkcbpeHq5CE= =d4ZX -----END PGP SIGNATURE----- --61jdw2sOBCFtR2d/-- From owner-freebsd-arch@FreeBSD.ORG Fri May 27 12:07:44 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38EF016A41C for ; Fri, 27 May 2005 12:07:44 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEDD643D49 for ; Fri, 27 May 2005 12:07:43 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.buffalo.edu [128.205.32.4]) by opus.cse.buffalo.edu (8.13.3/8.12.10) with ESMTP id j4RC7ZpW088600; Fri, 27 May 2005 08:07:42 -0400 (EDT) From: Ken Smith To: Marc Olzheim In-Reply-To: <20050527091750.GB91258@stack.nl> References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> <20050527091750.GB91258@stack.nl> Content-Type: text/plain Organization: U. Buffalo CSE Department Date: Fri, 27 May 2005 08:07:35 -0400 Message-Id: <1117195655.88498.9.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 12:07:44 -0000 On Fri, 2005-05-27 at 11:17 +0200, Marc Olzheim wrote: > On Thu, May 26, 2005 at 04:24:25PM -0400, Ken Smith wrote: > > Any thoughts before I commit it? The patch itself is pretty small. But > > given the sections of code it's mucking with combined with it adding a > > little 'nit' filesystem implementers should be aware of I wanted to run > > it by as many clueful eyes as possible before doing the final commit. > > Has this been run through some kind of real world performance test ? I > can imagine for instance /bin/sh's vnode is being updated a lot... Would > it be eligible to a becoming a mount option ? Bruce did some benchmarking and this approach seemed to be the minimal hit on performance of the options we have. The other things that got tested were things like "fake reads". The whole issue started when the exec mechanisms were shifted away from doing file reads in favor of a more mmap based mechanism for starting the executables. >From his tests the hit seemed minimal. The noatime mount option seems to be the most appropriate thing to use for turning it off, and in that case the only cost involved with this addition is the check in exec to see if the file is coming from a filesystem that's either noatime or readonly. > I don't see any real problems with it, but perhaps people running > executables over NFS filesystems that cannot be mounted with noatime > might have an issue, like netbooting diskless machines... I'm not sure why you say NFS filesystems can't be mounted with noatime. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-arch@FreeBSD.ORG Fri May 27 13:10:16 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0F9316A41C for ; Fri, 27 May 2005 13:10:16 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DA3043D1F for ; Fri, 27 May 2005 13:10:16 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 454A11F193; Fri, 27 May 2005 15:10:15 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 1BC3B655D; Fri, 27 May 2005 15:10:15 +0200 (CEST) Date: Fri, 27 May 2005 15:10:14 +0200 From: Marc Olzheim To: Ken Smith Message-ID: <20050527131014.GA93850@stack.nl> References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> <20050527091750.GB91258@stack.nl> <1117195655.88498.9.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <1117195655.88498.9.camel@opus.cse.buffalo.edu> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , freebsd-arch@freebsd.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 13:10:16 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2005 at 08:07:35AM -0400, Ken Smith wrote: > > I don't see any real problems with it, but perhaps people running > > executables over NFS filesystems that cannot be mounted with noatime > > might have an issue, like netbooting diskless machines... >=20 > I'm not sure why you say NFS filesystems can't be mounted with noatime. No, I'm saying that there are filesystems you wouldn't want to mount with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some software depends on the atime being adjusted. But atime over NFS is something you'd usually want to turn off, because it can really hurt performance. Marc --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFClxw2ezjnobFOgrERAqxXAKC7+AFrbbnRugf4YzMCyETehEQuMACeKcyM Q9oerrSRekCtKu6wLYTSO1w= =OIt6 -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-arch@FreeBSD.ORG Fri May 27 16:12:35 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26F0616A41C for ; Fri, 27 May 2005 16:12:35 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id F089D43D1D for ; Fri, 27 May 2005 16:12:34 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms069.mailsrvcs.net ([192.168.1.2]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IH500KJ2P0YNRT6@vms046.mailsrvcs.net> for freebsd-arch@freebsd.org; Fri, 27 May 2005 11:12:34 -0500 (CDT) Date: Fri, 27 May 2005 11:12:34 -0500 (CDT) From: Sergey Babkin To: Marc Olzheim , Ken Smith Message-id: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 16:12:35 -0000 >No, I'm saying that there are filesystems you wouldn't want to mount >with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some >software depends on the atime being adjusted. > >But atime over NFS is something you'd usually want to turn off, because >it can really hurt performance. As a compromise, would it make sense to make the atime granularity adjustable? I.e. instead of the default microsecond granularity use a 1-second granularity. Or a 10-second granularity, so that the atime would be adjusted only once per every 10 seconds. And similarly for mtime, though here you should obviously be more careful. -SB From owner-freebsd-arch@FreeBSD.ORG Fri May 27 16:33:23 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3845816A41C for ; Fri, 27 May 2005 16:33:23 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D753743D1F for ; Fri, 27 May 2005 16:33:22 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.buffalo.edu [128.205.32.4]) by opus.cse.buffalo.edu (8.13.3/8.12.10) with ESMTP id j4RGXLsD000706; Fri, 27 May 2005 12:33:21 -0400 (EDT) From: Ken Smith To: Sergey Babkin In-Reply-To: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> References: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> Content-Type: text/plain Organization: U. Buffalo CSE Department Date: Fri, 27 May 2005 12:33:20 -0400 Message-Id: <1117211600.666.5.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Marc Olzheim , freebsd-arch@freebsd.org Subject: Re: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 16:33:23 -0000 On Fri, 2005-05-27 at 11:12 -0500, Sergey Babkin wrote: > >No, I'm saying that there are filesystems you wouldn't want to mount > >with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some > >software depends on the atime being adjusted. > > > >But atime over NFS is something you'd usually want to turn off, because > >it can really hurt performance. > > As a compromise, would it make sense to make the > atime granularity adjustable? I.e. instead of the > default microsecond granularity use a 1-second > granularity. Or a 10-second granularity, so that the > atime would be adjusted only once per every 10 > seconds. And similarly for mtime, though here > you should obviously be more careful. I'm still a tiny bit confused but that's probably just me. Normally when setting up an environment with diskless clients in it I set things up so that the portions of the server containing executable files are mounted read-only on all the clients. I typically can't trust the client machines enough to grant them write access to something like /usr. So, in that sort of an environment this is a non-issue. As mentioned above there are portions of the environment you can't do that for but none of those directories mentioned above would contain executable files. And the places that do contain executable files (e.g. /usr) are mounted read-only. So there should be no noticable impact from the proposed patch if that sort of setup is normal. Am I way off base? -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-arch@FreeBSD.ORG Fri May 27 18:31:46 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D0DC16A41C; Fri, 27 May 2005 18:31:46 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id B22F343D1F; Fri, 27 May 2005 18:31:42 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j4RIU3E9014448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 May 2005 03:30:07 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 28 May 2005 03:30:02 +0900 Message-ID: From: Hajimu UMEMOTO To: Warner Losh , nectar@FreeBSD.org, des@FreeBSD.org In-Reply-To: <20050509.104234.71141880.imp@bsdimp.com> References: <200505041529.36826.peter@wemm.org> <20050509.104234.71141880.imp@bsdimp.com> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Sat_May_28_03:30:02_2005-1" X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 28 May 2005 03:30:07 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: standards@FreeBSD.org, current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 18:31:46 -0000 --Multipart_Sat_May_28_03:30:02_2005-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Mon, 09 May 2005 10:42:34 -0600 (MDT) >>>>> Warner Losh said: > Are you suggest when to remove padding? Since the major of libc was > bumped already in 6-CURRENT, it may better to wait 7-CURRENT. imp> We've generally not worried compatibility in the 'rough and tumble' imp> world of FreeBSD current. So unless there's a problem in the upgrade imp> path, I think that we safely omit them. I'll commit the attached change to nuke padding. It will break ABI compatibility on 64 bit arch. So, I'm planning bumping major of affected shlibs. Please review it. Sincerely, --Multipart_Sat_May_28_03:30:02_2005-1 Content-Type: text/x-patch; charset=US-ASCII Content-Disposition: attachment; filename="netdb.h-padding-nuke.diff" Content-Transfer-Encoding: 7bit Index: include/netdb.h diff -u include/netdb.h.orig include/netdb.h --- include/netdb.h.orig Sat May 28 01:20:40 2005 +++ include/netdb.h Sat May 28 01:31:52 2005 @@ -63,8 +63,6 @@ #include #include -#include -#include #ifndef _SIZE_T_DECLARED typedef __size_t size_t; @@ -105,28 +103,11 @@ #define h_addr h_addr_list[0] /* address, for backward compatibility */ }; -/* - * Note: n_net used to be an unsigned long integer. - * In XNS5, and subsequently in POSIX-2001 it was changed to an - * uint32_t. - * To accomodate for this while preserving binary compatibility with - * the old interface, we prepend or append 32 bits of padding, - * depending on the (LP64) architecture's endianness. - * - * This should be deleted the next time the libc major number is - * incremented. - */ struct netent { char *n_name; /* official name of net */ char **n_aliases; /* alias list */ int n_addrtype; /* net address type */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _BIG_ENDIAN - uint32_t __n_pad0; /* ABI compatibility */ -#endif uint32_t n_net; /* network # */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _LITTLE_ENDIAN - uint32_t __n_pad0; /* ABI compatibility */ -#endif }; struct servent { @@ -142,29 +123,12 @@ int p_proto; /* protocol # */ }; -/* - * Note: ai_addrlen used to be a size_t, per RFC 2553. - * In XNS5.2, and subsequently in POSIX-2001 and RFC 3493 it was - * changed to a socklen_t. - * To accomodate for this while preserving binary compatibility with the - * old interface, we prepend or append 32 bits of padding, depending on - * the (LP64) architecture's endianness. - * - * This should be deleted the next time the libc major number is - * incremented. - */ struct addrinfo { int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ int ai_family; /* PF_xxx */ int ai_socktype; /* SOCK_xxx */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _BIG_ENDIAN - uint32_t __ai_pad0; /* ABI compatibility */ -#endif socklen_t ai_addrlen; /* length of ai_addr */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _LITTLE_ENDIAN - uint32_t __ai_pad0; /* ABI compatibility */ -#endif char *ai_canonname; /* canonical name for hostname */ struct sockaddr *ai_addr; /* binary address */ struct addrinfo *ai_next; /* next structure in linked list */ @@ -262,11 +226,7 @@ struct hostent *gethostent(void); struct hostent *getipnodebyaddr(const void *, size_t, int, int *); struct hostent *getipnodebyname(const char *, int, int, int *); -#if __LONG_BIT == 64 -struct netent *getnetbyaddr(unsigned long, int); /* ABI compatibility */ -#else struct netent *getnetbyaddr(uint32_t, int); -#endif struct netent *getnetbyname(const char *); struct netent *getnetent(void); int getnetgrent(char **, char **, char **); Index: kerberos5/lib/Makefile.inc diff -u kerberos5/lib/Makefile.inc.orig kerberos5/lib/Makefile.inc --- kerberos5/lib/Makefile.inc.orig Sat Oct 25 18:24:54 2003 +++ kerberos5/lib/Makefile.inc Sat May 28 01:49:00 2005 @@ -1,5 +1,5 @@ # $FreeBSD: src/kerberos5/lib/Makefile.inc,v 1.6 2003/10/09 19:48:45 nectar Exp $ -SHLIB_MAJOR?= 7 +SHLIB_MAJOR?= 8 .include "../Makefile.inc" Index: lib/libbsnmp/Makefile.inc diff -u lib/libbsnmp/Makefile.inc.orig lib/libbsnmp/Makefile.inc --- lib/libbsnmp/Makefile.inc.orig Mon Oct 25 00:32:30 2004 +++ lib/libbsnmp/Makefile.inc Sat May 28 01:39:39 2005 @@ -1,6 +1,6 @@ # $FreeBSD: src/lib/libbsnmp/Makefile.inc,v 1.5 2004/10/24 15:32:30 ru Exp $ -SHLIB_MAJOR= 2 +SHLIB_MAJOR= 3 WARNS?= 6 NO_WERROR= INCSDIR= ${INCLUDEDIR}/bsnmp Index: lib/libc/net/getaddrinfo.c diff -u -p lib/libc/net/getaddrinfo.c.orig lib/libc/net/getaddrinfo.c --- lib/libc/net/getaddrinfo.c.orig Sat May 28 01:38:16 2005 +++ lib/libc/net/getaddrinfo.c Sat May 28 01:33:09 2005 @@ -1352,9 +1352,6 @@ get_ai(pai, afd, addr) memset(ai->ai_addr, 0, (size_t)afd->a_socklen); ai->ai_addr->sa_len = afd->a_socklen; ai->ai_addrlen = afd->a_socklen; -#if __LONG_BIT == 64 - ai->__ai_pad0 = 0; /* ABI compatibility */ -#endif ai->ai_addr->sa_family = ai->ai_family = afd->a_af; p = (char *)(void *)(ai->ai_addr); #ifdef FAITH Index: lib/libc/net/getnetbydns.c diff -u -p lib/libc/net/getnetbydns.c.orig lib/libc/net/getnetbydns.c --- lib/libc/net/getnetbydns.c.orig Sat May 28 01:24:33 2005 +++ lib/libc/net/getnetbydns.c Sat May 28 01:36:52 2005 @@ -259,9 +259,6 @@ getnetanswer(querybuf *answer, int ansle break; } ne->n_aliases++; -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif return 0; } h_errno = TRY_AGAIN; @@ -334,9 +331,6 @@ _dns_getnetbyaddr(void *rval, void *cb_d while ((net & 0xff) == 0 && net != 0) net >>= 8; ne->n_net = net; -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif return NS_SUCCESS; } return NS_NOTFOUND; Index: lib/libc/net/getnetbyht.c diff -u -p lib/libc/net/getnetbyht.c.orig lib/libc/net/getnetbyht.c --- lib/libc/net/getnetbyht.c.orig Sat May 28 01:24:33 2005 +++ lib/libc/net/getnetbyht.c Sat May 28 01:37:13 2005 @@ -122,9 +122,6 @@ again: if (p != NULL) *p++ = '\0'; ne->n_net = inet_network(cp); -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif ne->n_addrtype = AF_INET; q = ne->n_aliases = ned->net_aliases; if (p != NULL) { Index: lib/libc/net/getnetbynis.c diff -u -p lib/libc/net/getnetbynis.c.orig lib/libc/net/getnetbynis.c --- lib/libc/net/getnetbynis.c.orig Sat May 28 01:24:33 2005 +++ lib/libc/net/getnetbynis.c Sat May 28 01:37:35 2005 @@ -99,9 +99,6 @@ _getnetbynis(const char *name, char *map cp++; ne->n_net = inet_network(cp); -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif ne->n_addrtype = AF_INET; q = ne->n_aliases = ned->net_aliases; Index: lib/libc/net/getnetnamadr.c diff -u -p lib/libc/net/getnetnamadr.c.orig lib/libc/net/getnetnamadr.c --- lib/libc/net/getnetnamadr.c.orig Sat May 28 01:35:00 2005 +++ lib/libc/net/getnetnamadr.c Sat May 28 01:35:32 2005 @@ -165,17 +165,13 @@ getnetbyname(const char *name) } struct netent * -#if __LONG_BIT == 64 -getnetbyaddr(u_long addr, int af) /* ABI compatibility */ -#else getnetbyaddr(uint32_t addr, int af) -#endif { struct netdata *nd; if ((nd = __netdata_init()) == NULL) return NULL; - if (getnetbyaddr_r((uint32_t)addr, af, &nd->net, &nd->data) != 0) + if (getnetbyaddr_r(addr, af, &nd->net, &nd->data) != 0) return NULL; return &nd->net; } Index: lib/libfetch/Makefile diff -u lib/libfetch/Makefile.orig lib/libfetch/Makefile --- lib/libfetch/Makefile.orig Thu Jan 27 16:57:04 2005 +++ lib/libfetch/Makefile Sat May 28 01:41:14 2005 @@ -18,7 +18,7 @@ CSTD?= c99 WARNS?= 2 -SHLIB_MAJOR= 3 +SHLIB_MAJOR= 4 ftperr.h: ftp.errors @echo "static struct fetcherr _ftp_errlist[] = {" > ${.TARGET} Index: lib/libftpio/Makefile diff -u lib/libftpio/Makefile.orig lib/libftpio/Makefile --- lib/libftpio/Makefile.orig Sat Oct 25 18:25:46 2003 +++ lib/libftpio/Makefile Sat May 28 01:42:31 2005 @@ -1,7 +1,7 @@ # $FreeBSD: src/lib/libftpio/Makefile,v 1.13 2002/09/28 00:25:29 peter Exp $ LIB= ftpio -SHLIB_MAJOR= 5 +SHLIB_MAJOR= 6 SRCS= ftpio.c ftperr.c INCS= ftpio.h Index: lib/libipsec/Makefile diff -u lib/libipsec/Makefile.orig lib/libipsec/Makefile --- lib/libipsec/Makefile.orig Thu Jan 27 16:57:05 2005 +++ lib/libipsec/Makefile Sat May 28 01:42:52 2005 @@ -29,7 +29,7 @@ LIB= ipsec SHLIBDIR?= /lib -SHLIB_MAJOR= 1 +SHLIB_MAJOR= 2 CFLAGS+=-I. -I${.CURDIR} CFLAGS+=-DIPSEC_DEBUG -DIPSEC .if !defined(NO_INET6) Index: lib/libpam/Makefile.inc diff -u lib/libpam/Makefile.inc.orig lib/libpam/Makefile.inc --- lib/libpam/Makefile.inc.orig Sat May 28 01:45:39 2005 +++ lib/libpam/Makefile.inc Sat May 28 01:45:57 2005 @@ -28,4 +28,4 @@ DEBUG_FLAGS+= -DDEBUG .endif -SHLIB_MAJOR= 2 +SHLIB_MAJOR= 3 Index: lib/libpcap/Makefile diff -u lib/libpcap/Makefile.orig lib/libpcap/Makefile --- lib/libpcap/Makefile.orig Thu Jan 27 16:57:08 2005 +++ lib/libpcap/Makefile Sat May 28 01:43:25 2005 @@ -19,7 +19,7 @@ CFLAGS+=-DINET6 .endif -SHLIB_MAJOR=3 +SHLIB_MAJOR=4 # # Magic to grab sources out of src/contrib Index: lib/libutil/Makefile diff -u lib/libutil/Makefile.orig lib/libutil/Makefile --- lib/libutil/Makefile.orig Thu Jan 27 16:57:16 2005 +++ lib/libutil/Makefile Sat May 28 01:44:45 2005 @@ -2,7 +2,7 @@ # $FreeBSD: src/lib/libutil/Makefile,v 1.56 2004/05/24 22:19:27 pjd Exp $ LIB= util -SHLIB_MAJOR= 4 +SHLIB_MAJOR= 5 SHLIBDIR?= /lib CFLAGS+=-DLIBC_SCCS -I${.CURDIR} -I${.CURDIR}/../libc/gen/ CFLAGS+=-DINET6 Index: lib/libwrap/Makefile diff -u lib/libwrap/Makefile.orig lib/libwrap/Makefile --- lib/libwrap/Makefile.orig Thu Jan 27 16:57:16 2005 +++ lib/libwrap/Makefile Sat May 28 01:45:00 2005 @@ -3,7 +3,7 @@ # LIB= wrap -SHLIB_MAJOR= 3 +SHLIB_MAJOR= 4 INCS= tcpd.h MAN= hosts_access.3 MAN+= hosts_access.5 hosts_options.5 Index: secure/lib/libssh/Makefile diff -u secure/lib/libssh/Makefile.orig secure/lib/libssh/Makefile --- secure/lib/libssh/Makefile.orig Sat May 28 01:47:38 2005 +++ secure/lib/libssh/Makefile Sat May 28 01:47:52 2005 @@ -1,6 +1,8 @@ # $FreeBSD: src/secure/lib/libssh/Makefile,v 1.31 2004/12/21 09:33:45 ru Exp $ LIB= ssh +SHLIB_MAJOR= 3 + SRCS= acss.c authfd.c authfile.c bufaux.c buffer.c \ canohost.c channels.c cipher.c cipher-acss.c cipher-aes.c \ cipher-bf1.c cipher-ctr.c cipher-3des1.c cleanup.c \ --Multipart_Sat_May_28_03:30:02_2005-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Sat_May_28_03:30:02_2005-1-- From owner-freebsd-arch@FreeBSD.ORG Fri May 27 19:19:21 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91C9716A41C for ; Fri, 27 May 2005 19:19:21 +0000 (GMT) (envelope-from des@des.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2311C43D1F for ; Fri, 27 May 2005 19:19:20 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH600C8I3JOHU60@osl1smout1.broadpark.no> for freebsd-arch@freebsd.org; Fri, 27 May 2005 23:26:12 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH500FS5XUFK5R0@osl1sminn1.broadpark.no> for freebsd-arch@freebsd.org; Fri, 27 May 2005 21:23:03 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 5EFF645165; Fri, 27 May 2005 21:19:19 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id D253745157; Fri, 27 May 2005 21:19:15 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id AD9BC33C1C; Fri, 27 May 2005 21:19:15 +0200 (CEST) Date: Fri, 27 May 2005 21:19:15 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050527131014.GA93850@stack.nl> To: Marc Olzheim Message-id: <867jhkiij0.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> <20050527091750.GB91258@stack.nl> <1117195655.88498.9.camel@opus.cse.buffalo.edu> <20050527131014.GA93850@stack.nl> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: Cc: Ken Smith , freebsd-arch@freebsd.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 19:19:21 -0000 Marc Olzheim writes: > No, I'm saying that there are filesystems you wouldn't want to mount > with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some > software depends on the atime being adjusted. Any software that depends on the value of atime is broken by design. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri May 27 23:18:28 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45E3A16A41C for ; Fri, 27 May 2005 23:18:28 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7430143D1D for ; Fri, 27 May 2005 23:18:25 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id CBA011F29D; Sat, 28 May 2005 01:18:24 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id A9905655D; Sat, 28 May 2005 01:18:24 +0200 (CEST) Date: Sat, 28 May 2005 01:18:24 +0200 From: Marc Olzheim To: Ken Smith Message-ID: <20050527231824.GA13477@stack.nl> References: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> <1117211600.666.5.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <1117211600.666.5.camel@opus.cse.buffalo.edu> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , Sergey Babkin , freebsd-arch@freebsd.org Subject: Re: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 23:18:28 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2005 at 12:33:20PM -0400, Ken Smith wrote: > On Fri, 2005-05-27 at 11:12 -0500, Sergey Babkin wrote: > So, in that sort of an environment this is a non-issue. As mentioned > above there are portions of the environment you can't do that for but > none of those directories mentioned above would contain executable > files. And the places that do contain executable files (e.g. /usr) > are mounted read-only. So there should be no noticable impact from > the proposed patch if that sort of setup is normal. >=20 > Am I way off base? No, you've hit the spot. I think my preservations have been taken away. ;-) Zlo --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCl6rAezjnobFOgrERAneWAKCKclL27T/2CPRoNxA/LvrmjCFmCwCgoxI2 WiW69p5yAmMosBVcH+3om+k= =b5VW -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-arch@FreeBSD.ORG Fri May 27 23:31:13 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34F0716A41C for ; Fri, 27 May 2005 23:31:13 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F2443D49 for ; Fri, 27 May 2005 23:31:12 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id C10E81F29D; Sat, 28 May 2005 01:31:11 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id A0531655D; Sat, 28 May 2005 01:31:11 +0200 (CEST) Date: Sat, 28 May 2005 01:31:11 +0200 From: Marc Olzheim To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20050527233111.GA13569@stack.nl> References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> <20050527091750.GB91258@stack.nl> <1117195655.88498.9.camel@opus.cse.buffalo.edu> <20050527131014.GA93850@stack.nl> <867jhkiij0.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <867jhkiij0.fsf@xps.des.no> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , Ken Smith , freebsd-arch@freebsd.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 23:31:13 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2005 at 09:19:15PM +0200, Dag-Erling Smrgrav wrote: > Marc Olzheim writes: > > No, I'm saying that there are filesystems you wouldn't want to mount > > with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some > > software depends on the atime being adjusted. >=20 > Any software that depends on the value of atime is broken by design. I couldn't agree more... Thanks for the moral support. Now, how do you suggest we fix this ? :-P Zlo --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCl62/ezjnobFOgrERAqImAKCAsVkOK/lO2GeT9Qdke8ZsbW7YhQCgrZl9 8qti+1DlWgJvxEUbLduFslc= =ZelR -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-arch@FreeBSD.ORG Sat May 28 02:35:17 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 289AE16A41C for ; Sat, 28 May 2005 02:35:17 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7D3243D1D for ; Sat, 28 May 2005 02:35:16 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j4S2ZEH6018874 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 27 May 2005 22:35:15 -0400 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: arch@FreeBSD.org From: Suleiman Souhlal Date: Fri, 27 May 2005 22:35:03 -0400 X-Mailer: Apple Mail (2.730) Cc: Subject: [PATCH] Stackgap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 02:35:17 -0000 Hi! You can find an implementation of stackgap from OpenBSD at http:// people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff You can control the range of the random stack gap with the kern.stackgap_random sysctl. A value of 0 disables it. Otherwise, it has to be a power of 2 and not too large. The default value is 64K. I've only had the chance to test this on i386. Could anyone test it on other architectures as well? Any comments/objections? -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Sat May 28 04:12:24 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9F2816A41C for ; Sat, 28 May 2005 04:12:24 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54F5443D48 for ; Sat, 28 May 2005 04:12:24 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4S4CJrI008497; Sat, 28 May 2005 14:12:19 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4S4CFMC009070; Sat, 28 May 2005 14:12:16 +1000 Date: Sat, 28 May 2005 14:12:16 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Ken Smith In-Reply-To: <1117195655.88498.9.camel@opus.cse.buffalo.edu> Message-ID: <20050528125326.F81578@delplex.bde.org> References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> <20050527091750.GB91258@stack.nl> <1117195655.88498.9.camel@opus.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marc Olzheim , freebsd-arch@FreeBSD.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 04:12:25 -0000 On Fri, 27 May 2005, Ken Smith wrote: > On Fri, 2005-05-27 at 11:17 +0200, Marc Olzheim wrote: >> On Thu, May 26, 2005 at 04:24:25PM -0400, Ken Smith wrote: >>> Any thoughts before I commit it? The patch itself is pretty small. But >>> given the sections of code it's mucking with combined with it adding a >>> little 'nit' filesystem implementers should be aware of I wanted to run >>> it by as many clueful eyes as possible before doing the final commit. >> >> Has this been run through some kind of real world performance test ? I >> can imagine for instance /bin/sh's vnode is being updated a lot... Would >> it be eligible to a becoming a mount option ? > > Bruce did some benchmarking and this approach seemed to be the minimal > hit on performance of the options we have. The other things that got > tested were things like "fake reads". The whole issue started when the > exec mechanisms were shifted away from doing file reads in favor of a > more mmap based mechanism for starting the executables. The impact is so small that it is hard to see in real world tests. Hence microbenchmarks to increase its effect to 10% or so. >> From his tests the hit seemed minimal. The noatime mount option seems > to be the most appropriate thing to use for turning it off, and in that > case the only cost involved with this addition is the check in exec to > see if the file is coming from a filesystem that's either noatime or > readonly. > >> I don't see any real problems with it, but perhaps people running >> executables over NFS filesystems that cannot be mounted with noatime >> might have an issue, like netbooting diskless machines... [In a reply, you clarified this to say that another flag might be needed to disable this new pess^Wfeature since -noatime might not be available for all file systems.] Well, if -noatime is not available then you may have already lost significantly except on write-mostly or exec-mostly file systems. The new behaviour only loses significantly in the exec-mostly case, and then only when execs mostly don't cause reads as a side effect. For nfs, the -noatime option and atime timestamps generally are horribly broken. This brokenness significantly limits the overheads from the change unless we add to the patch to make atime timestamps on exec actually work for nfs without changing nfs's basic mishandling of atimes. An early version of the patch did make atime timestamps sort of work for nfs. It did this by setting the atime in vattr (where the current code intentionally leaves the atime as VNOVAL so that the VOP_SETATTR() call has no effect fof file systems that haven't been changed to understand VA_EXEWCVE_ATIME). This made VOP_SETATTR() set the atime in the same way as for utimes(2), except there was the VA_EXECVE_ATIME flag to modify the behaviour. A modification is needed to bypass permissions checking. I only implemented the modification for ffs. Thus for nfs, the change had much the same overhead as utimes(2) after every exec and permissions stuff was broken. For ffs, atimes are cached and are written by delayed writes so utimes(2) has a relatively low overhead, but for nfs the timestamps written by utimes(2) are considered much more precious than most other timestamps -- they are synced immediately, and this involves a slow nfs transaction and a synchronous write on the server (modulo sync/normal/async mounts and bugs in these), so everything is slowed down; OTOH, other timestamps in nfs are mostly handled more efficiently by not doing them right. More on broken -noatime mount option and atime timestamps in nfs: - Mounting with -noatime on the client has no effect. It is a general bug in the mount utilities that some flags which don't apply to the particular file system are silently ignored. -noatime is one of the generic flags which could in theory work for all file systems, so it is passed to all sub-mounts and is then confusing for the file systems that don't support it. - Mounting with -noatime on the server has an an effect. It stops normal atime timestamps for reads (only). This is usually what is wanted, but strictly it breaks clients mounted without -noatime. - Reads on the client are mostly cached, and nfs apparently isn't aware that _all_ reads should set atime (unless the client is mounted with -noatime), so it doesn't tell the server anything and most reads don't change the atime on the server. It would be too expensive to tell the server about all atime changes, so a cache on the client is needed. A simple local cache would only work if nothing else looks at the timestamps. The cache must somehow be flushed to the server when necessary. Syncing every second might work OK. The thing to avoid is thousands of transactions every second -- a modern system can easily do thousands of reads and/or execs per second provded they are mostly from a local cache. - Execs on the client involve reads on the server unless the file is cached, since although exec() uses mmap() and not read(), uncached files can only be read using read() on the server. Thus for nfs, nothing needs to be changed for atimes to be set for exec() in the same (wrong) way that they are set for read(). - For utimes(2) and some other metdata changes on the client, the client normally wants to force a synchronous change of the metadata on the server. The client has sufficient control of the details in nfs >=3. However, FreeBSD doesn't implement metadata-only sync, so FreeBSD servers have to fake it by syncing everything for the file. This adds to overheads and defeats the server's policy of not carin much about timestamps except for their efficiency. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat May 28 04:51:49 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B98416A41C for ; Sat, 28 May 2005 04:51:49 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08BB843D1F for ; Sat, 28 May 2005 04:51:48 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4S4pikG001647; Sat, 28 May 2005 14:51:44 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4S4pfMC021087; Sat, 28 May 2005 14:51:42 +1000 Date: Sat, 28 May 2005 14:51:43 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Ken Smith In-Reply-To: <1117211600.666.5.camel@opus.cse.buffalo.edu> Message-ID: <20050528141302.J81578@delplex.bde.org> References: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> <1117211600.666.5.camel@opus.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marc Olzheim , Sergey Babkin , freebsd-arch@FreeBSD.org Subject: Re: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 04:51:49 -0000 On Fri, 27 May 2005, Ken Smith wrote: > On Fri, 2005-05-27 at 11:12 -0500, Sergey Babkin wrote: >>> No, I'm saying that there are filesystems you wouldn't want to mount >>> with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some >>> software depends on the atime being adjusted. >>> >>> But atime over NFS is something you'd usually want to turn off, because >>> it can really hurt performance. Except it cannot really be turned off. It can be turned off on the server but that setting is wrong if some clients really want it on. It cannot be turned off on clients (the mount flag for it has no effect). FreeBSD only has broken clients which mostly don't set it as necessary, so it is normally sort of mostly off by default. If the clients weren't broken then there would be a lot of nfs traffic to sync it. See another reply for more details. >> As a compromise, would it make sense to make the >> atime granularity adjustable? I.e. instead of the >> default microsecond granularity use a 1-second >> granularity. Or a 10-second granularity, so that the >> atime would be adjusted only once per every 10 >> seconds. And similarly for mtime, though here >> you should obviously be more careful. The default granularity for ffs is already much larger than 1 second. The precision is 1 second, but atimes are normally not changed even in memory (they are only marked for update) until many seconds after the even that marked them, when one of the following events occurs: - someone looks at the times using stat(2) or friends - the file is (last-?) closed - the file is synced Even with this, actual updates of atimes can be ridiculously expensive in some (not so usual) case. You can have a few million files cached in few GB of memory. No disk accesses need occur to read() or exec() these files. But then if somone looks at all the files using something like a recursive grep, you have to do millions of writes to sync 8-16 bytes of atime info for each file. 8-16 * millions of bytes might not take long to write, but they do if they are done sparsely in millions of separate writes. I think the right way to implement atimes is to use a contiguous are of disk for them and never sync them until unmount() or memory for them runs out. OTOH, exec()ing millions of different files in a short time seems unlikely. For exec(), the case to worry about is exec()ing the same file repeatedly. The mark-for-update method works well for this in local file systems. Unfortunately, simple implementations of it cannot work for remote file systems. Someone might stat() the file on another client... The 10-second granularity might be useful here. stat() on the other client would still need to sync with local caches/marks for update on other clients, but the other clients and the server can know that there is no need to sync if less than 10 seconds has elapsed since the last tick of the 1/10 Hz clock that gives the time to possibly update (this clock must be synchronized). This wouldn't work for mtimes. The granularity must be much less than 10 seconds for make(1) to work. I'm surprised it mostly works with a granularity of 1 second. > I'm still a tiny bit confused but that's probably just me. Normally > when setting up an environment with diskless clients in it I set things > up so that the portions of the server containing executable files are > mounted read-only on all the clients. I typically can't trust the > client machines enough to grant them write access to something > like /usr. So, in that sort of an environment this is a non-issue. As Yes, this should prevent the client wasting the server's and its own time. > mentioned above there are portions of the environment you can't do that > for but none of those directories mentioned above would contain > executable files. And the places that do contain executable files > (e.g. /usr) are mounted read-only. So there should be no noticable > impact from the proposed patch if that sort of setup is normal. I use non-diskless clients with /usr nfs-mounted, not readonly and sometimes written to, so the client should be asking for atime updates (since it doesn't understand -noatime), but I use -noatime on all local file systems so atimes are effectively off since -noatime works on the server. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat May 28 11:11:32 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4329C16A41C for ; Sat, 28 May 2005 11:11:32 +0000 (GMT) (envelope-from des@des.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9E5B43D48 for ; Sat, 28 May 2005 11:11:31 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH700EDDBMO14C0@osl1smout1.broadpark.no> for freebsd-arch@freebsd.org; Sat, 28 May 2005 15:18:24 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH700HLH5XE2PH0@osl1sminn1.broadpark.no> for freebsd-arch@freebsd.org; Sat, 28 May 2005 13:15:14 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id A64D945165; Sat, 28 May 2005 13:11:29 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id CE54645131; Sat, 28 May 2005 13:11:25 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 97C4533C1C; Sat, 28 May 2005 13:11:25 +0200 (CEST) Date: Sat, 28 May 2005 13:11:25 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050527233111.GA13569@stack.nl> To: Marc Olzheim Message-id: <86zmufhag2.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> <20050527091750.GB91258@stack.nl> <1117195655.88498.9.camel@opus.cse.buffalo.edu> <20050527131014.GA93850@stack.nl> <867jhkiij0.fsf@xps.des.no> <20050527233111.GA13569@stack.nl> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: Cc: Ken Smith , freebsd-arch@freebsd.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 11:11:32 -0000 Marc Olzheim writes: > On Fri, May 27, 2005 at 09:19:15PM +0200, Dag-Erling Smrgrav wrote: > > Any software that depends on the value of atime is broken by design. > I couldn't agree more... Thanks for the moral support. Now, how do you > suggest we fix this ? :-P Fix what? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat May 28 14:01:49 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7444E16A41C; Sat, 28 May 2005 14:01:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3794643D1D; Sat, 28 May 2005 14:01:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id B885646B1E; Sat, 28 May 2005 10:01:48 -0400 (EDT) Date: Sat, 28 May 2005 15:01:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: mux@FreeBSD.org, jeff@FreeBSD.org Message-ID: <20050528144411.F727@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, jbh@FreeBSD.org Subject: Remaining system calls to make MPSAFE -- NTP, VFS, AIO, linux/etc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 14:01:49 -0000 Jeff, Maxime: I spent a bit of time today walking syscalls.master to try and clean up straggling non-MPSAFE system calls. I was able to add the MPSAFE flag in several cases: fhopen(), fhstat(), fhstatfs(), freebsd4_fhstatfs(), quotactl() Add unconditional Giant acquisition/drop to vfs_syscalls.c system call code. This needs refinement to match the conditional Giant use present in other VFS system calls. freebsd4_getfsstat(), olseek(), ostat(), olstat(), otruncate(), oftruncate(), freebsd4_statfs(), freebsd4_fstatfs() The kern_ and non-compat system calls implementing these compatibility system calls was already MPSAFE, so I could simply add the 'M' flag to syscalls.master. After doing this, the following FreeBSD system calls are still not marked MPSAFE: extattr_*() All extended attribute system calls are not marked as MPSAFE. A first step here would be to push Giant into their system call paths, but something a bit more refined would be desirable and should be possible. nfsclnt() I'll take a look through this today and see what I can do. I suspect the dependencies here are easy to clean up. ntp_gettime() Other NTP-related system calls appear safe. I've pinged Poul-Henning and Mark to see if we can get this fixed; I imagine that is fairly straight forward, but don't know. ogetdirentries() This compat call doesn't reuse the current system call code, so needs to be locked down. getdirentries() is probably a reasonable model for a starting point, but this requires a bit of work. mount(), unmount(), nmount() All of the mount-related calls aren't marked MPSAFE. I'm not very informed on this front, but other than possible entanglement in the boot and shutdown paths, things may actually be not too bad here. aio_*(), lio_*() AIO is not MPSAFE, and qute a bit of work is required here. There's probably quite a bit of low-hanging fruit in the compatibility ABI system call tables. In particular, quite a few calls can probably be marked MPSAFE on the basis that they call MPSAFE code and do little or no work. In many cases we are probably unnecessarily acquiring or recursing Giant as things stand. In other places, more work will be required, where the compat code actually implements substantial services or calls, such as additional file system system calls not present in the FreeBSD interface. The motivation behind this revisiting of syscalls.master is that I'm about to change the file format to add the audit event record identifier field for each system call, and I had hoped to simplify makesyscalls.sh before doing so. I think we're not quite close enough to there yet for me to do that before merging the Audit code, but I think we're actually quite close to getting rid of Giant acquisition in the general system call handler, which would be really great. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Sat May 28 14:10:05 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2346C16A41F; Sat, 28 May 2005 14:10:05 +0000 (GMT) (envelope-from ratson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id D03C943D54; Sat, 28 May 2005 14:10:02 +0000 (GMT) (envelope-from ratson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 6F2CA46B3F; Sat, 28 May 2005 10:10:02 -0400 (EDT) Date: Sat, 28 May 2005 15:10:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Suleiman Souhlal In-Reply-To: Message-ID: <20050528150815.X29776@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: [PATCH] Stackgap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 14:10:05 -0000 On Fri, 27 May 2005, Suleiman Souhlal wrote: > You can find an implementation of stackgap from OpenBSD at http:// > people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff > > You can control the range of the random stack gap with the > kern.stackgap_random sysctl. A value of 0 disables it. Otherwise, it has > to be a power of 2 and not too large. The default value is 64K. > > I've only had the chance to test this on i386. Could anyone test it on > other architectures as well? > > Any comments/objections? In the past, substantial performance hits have been measured due to poor stack alignment. Specifically, in combination with less optimal compiler behavior, the results have been pretty nasty. Have you tried micro-benchmarking a series of runs with this stack offset randomness using floating point on stack arguments to see if there's a measurable cost to moving the stack around? Hopefull if all is well, there will be little or no difference, but a small error here could result in a substantial performance hit... Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Sat May 28 17:01:04 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4AC716A420 for ; Sat, 28 May 2005 17:01:04 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 096AC43F3D for ; Sat, 28 May 2005 16:46:30 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout2-sn1.fre.skanova.net (7.2.059.6) id 42930AA9000F3C7D for freebsd-arch@freebsd.org; Sat, 28 May 2005 18:46:30 +0200 From: "Daniel Eriksson" To: Date: Sat, 28 May 2005 18:46:09 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVjje7t9/TFPhyGQFe/PhwTrbhLgQAFYoMg In-Reply-To: <20050528144411.F727@fledge.watson.org> Subject: MPSAFE CAM? (was: RE: Remaining system calls to make MPSAFE -- NTP, VFS, AIO, linux/etc) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 17:01:04 -0000 I'm sorry to hijack your thread Robert, but I just wanted to hear if there is any progress in making CAM (and the individual card drivers) MPSAFE? FreeBSD is mainly used for servers, where SCSI is pretty common. To me it seems like locking down CAM would be beneficial to a large number of FreeBSD users. I don't have the knowledge or time to do any real work on this myself, but I should be able to help test patches. /Daniel Eriksson From owner-freebsd-arch@FreeBSD.ORG Sat May 28 21:32:28 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 301E116A41F for ; Sat, 28 May 2005 21:32:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C3EF43D1F for ; Sat, 28 May 2005 21:32:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4SLXxcI057066; Sat, 28 May 2005 15:33:59 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4298E316.9020303@samsco.org> Date: Sat, 28 May 2005 15:31:02 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-arch@freebsd.org Subject: Re: MPSAFE CAM? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 21:32:28 -0000 Daniel Eriksson wrote: > I'm sorry to hijack your thread Robert, but I just wanted to hear if there > is any progress in making CAM (and the individual card drivers) MPSAFE? > > FreeBSD is mainly used for servers, where SCSI is pretty common. To me it > seems like locking down CAM would be beneficial to a large number of FreeBSD > users. > > I don't have the knowledge or time to do any real work on this myself, but I > should be able to help test patches. > > /Daniel Eriksson > > CAM was originally designed to make _very_ efficient use of SPL synchronization. Simply dropping locks in place of spl's has been tried, and the result is horrible performance. It's going to take a significant rewrite of much of the XPT code to make it efficiently locked. I started on this about a year ago but got sidetracked. It's still very high on my priority list, and I hope that I can get to it this fall. In the mean time, I put in some minimal locking so that xpt_done() can be called from drivers without Giant being held. This means that drivers can lock their interrupt service thread and declare themselves MPSAFE. The top half of the driver will still run with Giant held when it's called from CAM, but the bottom half can run Giant-free. I modified the esp(4) driver a few months ago to demonstrate this, and the results seem to be ok. esp definitely benefits from it since its scsi state machine is in the driver, so 4-5 interrupts get generated for each I/O. For more modern SCSI chips like ahc/ahd and mpt, the benefits might not be as much. If anyone wants to help tackle this, I'd be glad to help them get started. BSD/OS 5.(mumble) did a minimal locking job on CAM that probably works OK for systems with a single SCSI port, but likely gets very inefficient once you go beyond that. They also rewrote the SCSI probe state machine, which in our CAM is a source for quite a bit of lock recursion. The work I did last year focused on addressing this. Scott From owner-freebsd-arch@FreeBSD.ORG Sat May 28 23:41:33 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB0B616A41C for ; Sat, 28 May 2005 23:41:33 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FE5F43D1D for ; Sat, 28 May 2005 23:41:32 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 1089B1F0A0; Sun, 29 May 2005 01:41:31 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id D7DCB6563; Sun, 29 May 2005 01:41:30 +0200 (CEST) Date: Sun, 29 May 2005 01:41:30 +0200 From: Marc Olzheim To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20050528234130.GA34612@stack.nl> References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> <20050527091750.GB91258@stack.nl> <1117195655.88498.9.camel@opus.cse.buffalo.edu> <20050527131014.GA93850@stack.nl> <867jhkiij0.fsf@xps.des.no> <20050527233111.GA13569@stack.nl> <86zmufhag2.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <86zmufhag2.fsf@xps.des.no> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , Ken Smith , freebsd-arch@freebsd.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 23:41:33 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 28, 2005 at 01:11:25PM +0200, Dag-Erling Smrgrav wrote: > > I couldn't agree more... Thanks for the moral support. Now, how do you > > suggest we fix this ? :-P >=20 > Fix what? The software that depends on it, or a way to discriminate between filesystem needs... But nevermind, Bruce clarified that noatime on NFS is already broken enough not to be an issue. Zlo --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCmQGqezjnobFOgrERAls7AJ9YxDgYF5ftqSS94XCwiY3H84p9oQCghaL9 NxESCIpUAghz7x7sXyB6qAs= =I6dn -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3--