From owner-freebsd-arch@FreeBSD.ORG Sun Sep 2 04:17:54 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06FBB16A41B for ; Sun, 2 Sep 2007 04:17:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 893AD13C4CE for ; Sun, 2 Sep 2007 04:17:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l824H2m2011606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Sep 2007 14:17:32 +1000 Date: Sun, 2 Sep 2007 14:17:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jilles Tjoelker In-Reply-To: <20070901224025.GA97796@stack.nl> Message-ID: <20070902131910.H46281@delplex.bde.org> References: <1188600721.1255.11.camel@shumai.marcuscom.com> <20070901112600.GA33832@stack.nl> <1188660782.41727.5.camel@shumai.marcuscom.com> <20070901224025.GA97796@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe Marcus Clarke , freebsd-arch@freebsd.org Subject: Re: Understanding interrupted system calls 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, 02 Sep 2007 04:17:54 -0000 On Sun, 2 Sep 2007, Jilles Tjoelker wrote: > On Sat, Sep 01, 2007 at 11:33:02AM -0400, Joe Marcus Clarke wrote: >> However, I'm curious as to my other point in this thread. Why should >> one need to re-register the default signal handlers to get a syscall to >> return EINTR? Or should ERESTART be caught and turned into EINTR then >> return to the caller (as in kern_connect())? > > It is intended that most blocking system calls are not interrupted by > signals. This saves the programmer some checks on EINTR. Yes, I think this is just the historical default for BSD. Not restarting syscalls is very unusual in BSD, and this was implemented by defaulting ps_sigintr to all unset (?). Before sigaction(2) existed, signal(3) was probably signal(2), and most programs used only signal() and got the default. siginterrupt(3) was more probably siginterrupt(2), and the few programs that understand this stuff and want to change the default had to use it to get EINTR. Now with sigaction(2), the default doesn't apply to userland, since setting up a signal catcher requires using sigaction(2) which sets the ps_sigintr bit to the inverse of the SA_RESTART bit in the sigaction data. However, the default might still affect operation in the kernel for programs that never call sigaction(). I think it shouldn't have any effect except to return to near the syscall entry point to decide what to do. Lower levels should see ERESTART and return to near the syscall entry point. Similarly if sigaction() is used to change the default. > Some system calls, e.g. connect(), read/write/etc that have already > committed some data and under BSD also select/poll/kqueue do not restart > and always return EINTR or partial success. In the kernel code, this > appears as changing ERESTART to EINTR. This translation happens at a high level, but the translation of ps_sigintr happens at the [*]sleep() level. So ps_sigintr has a significant affect at a low level, but only (?) to select between ERESTART and EINTR. >From Jilles' previous reply: >>> The problem seems to be the following code in >>> src/sys/dev/syscons/syscons.c, in case VT_WAITACTIVE in scioctl(): >>> >>> while ((error=tsleep(&scp->smode, PZERO|PCATCH, >>> "waitvt", 0)) == ERESTART) ; >>> >>> If a signal is caught and system call restart is enabled for that >>> signal, this makes it spin in a tight loop, waiting in vain for the >>> signal to go away. The idea of ERESTART is that the syscall function >>> returns it and then the signal handler is entered. If and when the >>> signal handler returns, it will return to the system call instruction, >>> restarting it (perhaps this is optimized to avoid the switch to userland >>> and back). With EINTR, the signal handler would return to directly >>> after the system call instruction. >>> >>> The fixed version would then be >>> >>> error = tsleep(&scp->smode, PZERO|PCATCH, "waitvt", 0); I think this is right. The kernel should never loop on ERESTART like this. Please fix the remaining style bug in it (missing spaces around binary operator). Another problem here is that tty drivers should rarely or never use tsleep(). They should use ttysleep() so as to check for the tty being revoked. After revoke(), ttysleep() returns ERESTART to make lower levels return to near the syscall entry point (where the syscall is normally restarted and fails because the file descriptor has been moved to deadfs) provided there are no broken lower levels that loop on ERESTART like the above. Not using ttysleep() doesn't seem to cause any problems here (it actually avoids the buggy loop). Bruce From owner-freebsd-arch@FreeBSD.ORG Sun Sep 2 11:28:37 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB8FB16A417; Sun, 2 Sep 2007 11:28:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C575613C45D; Sun, 2 Sep 2007 11:28:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8DE9F46D69; Sun, 2 Sep 2007 07:09:21 -0400 (EDT) Date: Sun, 2 Sep 2007 12:09:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David O'Brien In-Reply-To: <20070831220318.GA4861@dragon.NUXI.org> Message-ID: <20070902120655.U35384@fledge.watson.org> References: <20070815233852.X568@10.0.0.1> <200708161056.31494.jhb@freebsd.org> <20070816131327.J568@10.0.0.1> <200708161635.20935.jhb@freebsd.org> <20070831220318.GA4861@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: file locking. 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, 02 Sep 2007 11:28:38 -0000 On Fri, 31 Aug 2007, David O'Brien wrote: > On Thu, Aug 16, 2007 at 04:35:20PM -0400, John Baldwin wrote: >> On Thursday 16 August 2007 04:18:51 pm Jeff Roberson wrote: >>> Do we have an official stance on libkvm? Now that we have sysctl for >>> run-time it's only useful for crashdump debugging. Really in most cases >>> it could be replaced with a reasonable set of gcc scripts. >> >> s/gcc/gdb/. At work we do mostly post-mortem analysis, so having working >> libkvm is still very important for us. xref the way I just fixed netstat >> to work again on coredumps recently. Breaking fstat on coredumps would >> probably be very annoying. > > This applies at Juniper as well. I think post-mortem analysis is a Big > Deal(tm) to those developing commercial products based on FreeBSD. I think it's a given that post-mortem analysis will be more fragile than live analysis due to weaker ABI requirements for in-kernel data structures -- on the other hand, it's also a critical feature. I think keeping libkvm functioning on core dumps is really important -- the ability to run ps, netstat, etc, etc, all on core dumps is remarkably useful in debugging. What I occasionally wish is that all the magic in DDB could also be used on coredumps -- i.e., that we could compile the kernel DDB bits into a user binary to run on matching core dumps in order to more easily extract things like WITNESS data, etc. No doubt a moderate amount of evil would be required to do this... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Sun Sep 2 17:56:31 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5783A16A41A; Sun, 2 Sep 2007 17:56:31 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2A513C467; Sun, 2 Sep 2007 17:56:31 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id EA01B8C2507; Sun, 2 Sep 2007 19:39:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaC65SUfYp00; Sun, 2 Sep 2007 19:39:54 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 710B18C24E9; Sun, 2 Sep 2007 19:39:54 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l82HdssN052719; Sun, 2 Sep 2007 19:39:54 +0200 (CEST) (envelope-from rdivacky) Date: Sun, 2 Sep 2007 19:39:54 +0200 From: Roman Divacky To: arch@freebsd.org Message-ID: <20070902173953.GA52566@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: i386@freebsd.org Subject: PSL_RF inclusion in PSL_USERCHANGE for i386 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, 02 Sep 2007 17:56:31 -0000 hi in i386/i386/machdep.c the set_regs() function sets i386 registers (called by ptrace for example). it checks what eflags are being changed and compares that with a mask of allowed flags to be changed. the mask is defined in psl.h like this: #define PSL_USERCHANGE (PSL_C | PSL_PF | PSL_AF | PSL_Z | PSL_N | PSL_T \ | PSL_D | PSL_V | PSL_NT | PSL_AC | PSL_ID) PSL_RF (Flag to ensure single-step only happens once per instruction.). Can someone tell me why this is omitted? I think its because of having in-kernel debugger. User-mode Linux requires this to be allowed. So I wonder why this is disabled in FreeBSD. (Linux itself does not check the eflags in any way). thanks for answer, and/or pointer to answer Roman Divacky From owner-freebsd-arch@FreeBSD.ORG Mon Sep 3 03:23:45 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEBF616A418 for ; Mon, 3 Sep 2007 03:23:45 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (penna-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 6451513C45A for ; Mon, 3 Sep 2007 03:23:45 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.1/8.14.1) with ESMTP id l833NkxB022271; Sun, 2 Sep 2007 23:23:46 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Bruce Evans In-Reply-To: <20070902131910.H46281@delplex.bde.org> References: <1188600721.1255.11.camel@shumai.marcuscom.com> <20070901112600.GA33832@stack.nl> <1188660782.41727.5.camel@shumai.marcuscom.com> <20070901224025.GA97796@stack.nl> <20070902131910.H46281@delplex.bde.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-e9iPozRu55oGEQ3WZ39A" Organization: FreeBSD, Inc. Date: Sun, 02 Sep 2007 23:23:38 -0400 Message-Id: <1188789818.97969.9.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: Jilles Tjoelker , freebsd-arch@FreeBSD.org Subject: Re: Understanding interrupted system calls 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, 03 Sep 2007 03:23:46 -0000 --=-e9iPozRu55oGEQ3WZ39A Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2007-09-02 at 14:17 +1000, Bruce Evans wrote: > On Sun, 2 Sep 2007, Jilles Tjoelker wrote: >=20 > > On Sat, Sep 01, 2007 at 11:33:02AM -0400, Joe Marcus Clarke wrote: > >> However, I'm curious as to my other point in this thread. Why should > >> one need to re-register the default signal handlers to get a syscall t= o > >> return EINTR? Or should ERESTART be caught and turned into EINTR then > >> return to the caller (as in kern_connect())? > > > > It is intended that most blocking system calls are not interrupted by > > signals. This saves the programmer some checks on EINTR. >=20 > Yes, I think this is just the historical default for BSD. Not > restarting syscalls is very unusual in BSD, and this was implemented > by defaulting ps_sigintr to all unset (?). Before sigaction(2) existed, > signal(3) was probably signal(2), and most programs used only signal() > and got the default. siginterrupt(3) was more probably siginterrupt(2), > and the few programs that understand this stuff and want to change the > default had to use it to get EINTR. Now with sigaction(2), the default > doesn't apply to userland, since setting up a signal catcher requires > using sigaction(2) which sets the ps_sigintr bit to the inverse of the > SA_RESTART bit in the sigaction data. However, the default might still > affect operation in the kernel for programs that never call sigaction(). > I think it shouldn't have any effect except to return to near the > syscall entry point to decide what to do. Lower levels should see > ERESTART and return to near the syscall entry point. Similarly if > sigaction() is used to change the default. Thanks, Bruce and Jilles for the explanation. It is much clearer now. >=20 > > Some system calls, e.g. connect(), read/write/etc that have already > > committed some data and under BSD also select/poll/kqueue do not restar= t > > and always return EINTR or partial success. In the kernel code, this > > appears as changing ERESTART to EINTR. >=20 > This translation happens at a high level, but the translation of ps_sigin= tr > happens at the [*]sleep() level. So ps_sigintr has a significant affect > at a low level, but only (?) to select between ERESTART and EINTR. >=20 > >From Jilles' previous reply: >=20 > >>> The problem seems to be the following code in > >>> src/sys/dev/syscons/syscons.c, in case VT_WAITACTIVE in scioctl(): > >>>=20 > >>> while ((error=3Dtsleep(&scp->smode, PZERO|PCATCH, > >>> "waitvt", 0)) =3D=3D ERESTART) ; > >>>=20 > >>> If a signal is caught and system call restart is enabled for that > >>> signal, this makes it spin in a tight loop, waiting in vain for the > >>> signal to go away. The idea of ERESTART is that the syscall function > >>> returns it and then the signal handler is entered. If and when the > >>> signal handler returns, it will return to the system call instruction= , > >>> restarting it (perhaps this is optimized to avoid the switch to userl= and > >>> and back). With EINTR, the signal handler would return to directly > >>> after the system call instruction. > >>>=20 > >>> The fixed version would then be > >>>=20 > >>> error =3D tsleep(&scp->smode, PZERO|PCATCH, "waitvt", 0); >=20 > I think this is right. The kernel should never loop on ERESTART like thi= s. > Please fix the remaining style bug in it (missing spaces around binary > operator). I think these patches do what you and Jilles suggested. As Jilles said, the pcvt patch only applies to -STABLE as this driver was removed in -CURRENT. Thanks again, guys, for helping me out with this. http://www.marcuscom.com/downloads/syscons.c.diff http://www.marcuscom.com/downloads/pcvt_ext.c.diff Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-e9iPozRu55oGEQ3WZ39A Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG2346b2iPiv4Uz4cRAsJwAKCJacuQMP+LUCxYbiWQed5EV6gJAQCfaTFP cONVTPYttoSv1A3bhmrPGtY= =d8MY -----END PGP SIGNATURE----- --=-e9iPozRu55oGEQ3WZ39A-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 3 23:17:36 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ABEA16A419; Mon, 3 Sep 2007 23:17:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx02.syd.optusnet.com.au (fallbackmx02.syd.optusnet.com.au [211.29.133.72]) by mx1.freebsd.org (Postfix) with ESMTP id E9B5C13C459; Mon, 3 Sep 2007 23:17:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by fallbackmx02.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l831JCan001016; Mon, 3 Sep 2007 11:19:12 +1000 Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l831Ib07017221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Sep 2007 11:18:44 +1000 Date: Mon, 3 Sep 2007 11:18:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Roman Divacky In-Reply-To: <20070902173953.GA52566@freebsd.org> Message-ID: <20070903105130.L48985@delplex.bde.org> References: <20070902173953.GA52566@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, i386@freebsd.org Subject: Re: PSL_RF inclusion in PSL_USERCHANGE for i386 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, 03 Sep 2007 23:17:36 -0000 On Sun, 2 Sep 2007, Roman Divacky wrote: > in i386/i386/machdep.c the set_regs() function sets i386 registers (called > by ptrace for example). it checks what eflags are being changed and compares > that with a mask of allowed flags to be changed. the mask is defined in psl.h > like this: > > #define PSL_USERCHANGE (PSL_C | PSL_PF | PSL_AF | PSL_Z | PSL_N | PSL_T \ > | PSL_D | PSL_V | PSL_NT | PSL_AC | PSL_ID) > > PSL_RF (Flag to ensure single-step only happens once per instruction.). Can someone > tell me why this is omitted? I think its because of having in-kernel debugger. I think it is just because user mode cannot set this flag directly, except probably in vm86 mode (vm86 support code already has special cases for it). (Old) docs say that it can be set by popfl and iret, but popfl doesn't set it for me now and user mode cannot execute iret (?). > User-mode Linux requires this to be allowed. So I wonder why this is disabled in FreeBSD. > (Linux itself does not check the eflags in any way). > > thanks for answer, and/or pointer to answer FreeBSD allows setting or at least preserving it in sigreturn(). See my large comment in sigreturn(). The comment has been copied ad nauseum into 3 versions of sigreturn(), so removing this special case would be a large cleanup. According to the comment, for user mode it is the CPU that sets PSL_RF for faults (for all faults or only for debug faults, so that faults can be restarted without interference from debuggers. I think the CPU also automatically clears PSL_RF after executing 1 instruction, so it is hard to observe it as set and hard to see how setting it in set_regs() could have any effect. Well, set_regs() is just an easier way to set registers than sigreturn(). sigreturn() omits PSL_RF from its security check, so there there is no possibility of a _new_ security hole from omitting the check in set_regs() too. (But better put PSL_RF in PSL_USERCHANGE and remove all the special cases). After return to user mode with PSL_RF set, I think PSL_RF affects only the first instruction in user mode, so any changes in effects would be observable only there. Please check that something reasonable happens. The user mode code is something like: int $0x80 # syscall xxx # some instruction -- what happens for # hardware breakpoints, etc., on this # instruction. I vaguely remember problems (perhaps under another OS) with debugging the first instruction after a syscall returns. Perhaps they are still there and are caused by precisely the resume flag, if the resume flag is set automatically by int $N or if the kernel sets it. Allowing set_regs() to set the resume flag might cause the same problem for just the ptrace/procfs calls that use set_regs() if it doesn't affect all syscalls. It's hard to see how this problem could actually be a feature. To use it as a feature, userland would have to ensure that the xxx in the above is a certain instruction that benefits from this behaviour. Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Sep 4 04:41:34 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A11B16A419; Tue, 4 Sep 2007 04:41:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 1624913C48A; Tue, 4 Sep 2007 04:41:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ISPTP-000Ezm-MC; Tue, 04 Sep 2007 06:53:16 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l843r6W2077910; Tue, 4 Sep 2007 06:53:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l843r6bZ077903; Tue, 4 Sep 2007 06:53:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Sep 2007 06:53:06 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20070904035306.GB53667@deviant.kiev.zoral.com.ua> References: <20070902173953.GA52566@freebsd.org> <20070903105130.L48985@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <20070903105130.L48985@delplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: efe3bc1504fa577d936f03857ce6b673 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1428 [September 3 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: arch@freebsd.org, Roman Divacky , i386@freebsd.org Subject: Re: PSL_RF inclusion in PSL_USERCHANGE for i386 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, 04 Sep 2007 04:41:34 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 03, 2007 at 11:18:37AM +1000, Bruce Evans wrote: >=20 > On Sun, 2 Sep 2007, Roman Divacky wrote: >=20 > >in i386/i386/machdep.c the set_regs() function sets i386 registers (call= ed > >by ptrace for example). it checks what eflags are being changed and=20 > >compares > >that with a mask of allowed flags to be changed. the mask is defined in= =20 > >psl.h > >like this: > > > >#define PSL_USERCHANGE (PSL_C | PSL_PF | PSL_AF | PSL_Z | PSL_N | PSL_T \ > > | PSL_D | PSL_V | PSL_NT | PSL_AC | PSL_ID) > > > >PSL_RF (Flag to ensure single-step only happens once per instruction.).= =20 > >Can someone > >tell me why this is omitted? I think its because of having in-kernel=20 > >debugger. >=20 > I think it is just because user mode cannot set this flag directly, > except probably in vm86 mode (vm86 support code already has special > cases for it). (Old) docs say that it can be set by popfl and iret, > but popfl doesn't set it for me now and user mode cannot execute iret (?). It can. It would result in exception when the normal privilege checks trigg= ers, but would execute as expected otherwise. For instance, #include .text .globl main .type main, @function main: pushl $12 /* _exit() code */ pushfl pushl %cs pushl $2f iretl 1: movl $SYS_exit, %eax pushl %eax int $0x80 2: pushl $hello call printf popl %eax jmp 1b .size main, . - main hello: .asciz "Hello from iret\n" --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG3NahC3+MBN1Mb4gRArvYAJ463KcW7Ryhk9Q70RpLY1hqKuUFoQCeO9Xw v4RdylW+Gp4TNzhrLNA1Gwo= =0i/3 -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 4 13:21:20 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEA5616A41A for ; Tue, 4 Sep 2007 13:21:20 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 4042713C478 for ; Tue, 4 Sep 2007 13:21:18 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l84DLH15090271 for ; Tue, 4 Sep 2007 17:21:17 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l84DLGFe090266 for arch@freebsd.org; Tue, 4 Sep 2007 17:21:17 +0400 (MSD) (envelope-from yar) Date: Tue, 4 Sep 2007 17:21:16 +0400 From: Yar Tikhiy To: arch@freebsd.org Message-ID: <20070904132116.GS30502@comp.chem.msu.su> References: <20070824.172212.74696955.imp@bsdimp.com> <20070824.213615.146406398.imp@bsdimp.com> <20070828005654.GA50401@dragon.NUXI.org> <20070828014748.GV21352@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070828014748.GV21352@comp.chem.msu.su> User-Agent: Mutt/1.5.9i Cc: Subject: Re: ABI and install tools (was Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.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: Tue, 04 Sep 2007 13:21:20 -0000 On Tue, Aug 28, 2007 at 05:47:49AM +0400, Yar Tikhiy wrote: > [Redirecting this branch to -arch] > > On Mon, Aug 27, 2007 at 05:56:54PM -0700, David O'Brien wrote: > > On Fri, Aug 24, 2007 at 09:36:15PM -0600, M. Warner Losh wrote: > > > In message: > > > Daniel Eischen writes: > > > : I guess the build system should be more tolerant of this, but > > > : there are bound to be problems regardless. I don't see why > > > : the install tools can't also either have their own set of > > > : libraries (utilizing LD_LIBRARY_PATH) or be built static. > > > > > > There's much resistance to building everything that the build system > > > might be used being build static. It adds too much time and > > > complexity to the build system, the opponents say. > > > > I've never heard an argument against building these bits static. > > What's the issue? > > FWIW, here's a patch implementing the opposite approach: If we're > going to install world over this system (installworld with DESTDIR > unset or empty), first install the new versions of necessary tools > to a scratch directory and then switch to the new tools. The kernel > must be capable of running the new tools with the new libraries, > which is an already existing requirement. > > With the patch, the build system can tolerate ABI breakage in libc > and, according to audit(4), it runs no binaries from the old system > in the sensitive part of installworld. > > For easier and safer testing, INSTALL_TESTING can be set so that > the new way is chosen even if DESTDIR is set. Of course, make sure > that the new tools are for the same platform as the machine runs. > Usually you cannot select a different platform w/o setting DESTDIR. > > Comments are welcome. Thanks! For the record: Ruslan Ermilov has objected privately to the proposed approach with quite reasonable arguments, the most important one being that using new binaries if DESTDIR is unset would mean using different tool sets for different install types, which will make debugging other people's installworld problems harder. Therefore we've started to work on the opposite approach, i.e., saving old libs along with old tools for installworld to use. It has proved rather elegant and not depending on any ifs, unlike the former approach. And, with an extra bit of magic around ld.so, it allows for installing world built for a different arch, e.g., amd64 over i386, which is fun. :-) The current state of the task can be seen there: http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/user/yar/hack/Makefile.inc1 -- Yar From owner-freebsd-arch@FreeBSD.ORG Tue Sep 4 13:57:28 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB6616A469; Tue, 4 Sep 2007 13:57:28 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id A692813C45A; Tue, 4 Sep 2007 13:57:28 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l84DvOi3056953; Tue, 4 Sep 2007 06:57:28 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l84DvOwG056952; Tue, 4 Sep 2007 06:57:24 -0700 (PDT) (envelope-from obrien) Date: Tue, 4 Sep 2007 06:57:23 -0700 From: "David O'Brien" To: Robert Watson Message-ID: <20070904135723.GA56892@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Robert Watson , John Baldwin , freebsd-arch@freebsd.org References: <20070815233852.X568@10.0.0.1> <200708161056.31494.jhb@freebsd.org> <20070816131327.J568@10.0.0.1> <200708161635.20935.jhb@freebsd.org> <20070831220318.GA4861@dragon.NUXI.org> <20070902120655.U35384@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070902120655.U35384@fledge.watson.org> X-Operating-System: FreeBSD 7.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.11 Cc: John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: file locking. 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: Tue, 04 Sep 2007 13:57:28 -0000 On Sun, Sep 02, 2007 at 12:09:21PM +0100, Robert Watson wrote: > What I occasionally wish is that all the magic in DDB could also be used on > coredumps -- i.e., that we could compile the kernel DDB bits into a user > binary to run on matching core dumps in order to more easily extract things > like WITNESS data, etc. No doubt a moderate amount of evil would be > required to do this... \me too! :-) Now, that would *certainly* be useful! :-) -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Sep 6 23:45:27 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D186616A41B for ; Thu, 6 Sep 2007 23:45:27 +0000 (UTC) (envelope-from canada2007@megaquebec.net) Received: from megaquebec.net (mtl-pppoe-adsl697.securenet.net [66.38.238.188]) by mx1.freebsd.org (Postfix) with SMTP id 642F313C467 for ; Thu, 6 Sep 2007 23:45:27 +0000 (UTC) (envelope-from canada2007@megaquebec.net) From: "Csd 2007" To: Sender: "Csd 2007" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 6 Sep 2007 19:45:10 -0400 Content-Transfer-Encoding: 8bit Message-Id: <20070906234527.642F313C467@mx1.freebsd.org> Subject: Available; canadian subsidies grants and loans 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, 06 Sep 2007 23:45:27 -0000 PRESS RELEASE Subsidy directory 2007 (Legal Deposit-National-Library) The 2007 edition is now available. A guide containing more than 3200 programs from: Federal & provincial governments, associations & foundations. Including; Organisation names Program names Program descriptions Addresses Telephones Organization Url's (web sites) and program Url's (web sites) CD-Rom (.pdf) or printed (430 pages) Cd-Rom......................$69.95 Printed....................$149.95 To obtain a copy please call toll free: 1-866-322-3376 Remove freebsd-arch@freebsd.org at delete2007@mailcan.com From owner-freebsd-arch@FreeBSD.ORG Fri Sep 7 13:14:33 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3974716A419 for ; Fri, 7 Sep 2007 13:14:33 +0000 (UTC) (envelope-from dumbbell@freebsd.org) Received: from mail.ilius.net (mail.ilius.net [62.23.30.92]) by mx1.freebsd.org (Postfix) with ESMTP id B1BF513C45E for ; Fri, 7 Sep 2007 13:14:32 +0000 (UTC) (envelope-from dumbbell@freebsd.org) Received: from viking.ilius.fr [192.168.192.55] by mail.ilius.net with ESMTP (SMTPD-9.21) id AC2C0340; Fri, 07 Sep 2007 15:03:40 +0200 Message-ID: <46E14C1A.1060606@freebsd.org> Date: Fri, 07 Sep 2007 15:03:22 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Thunderbird 2.0.0.6 (X11/20070817) MIME-Version: 1.0 To: freebsd-arch@freebsd.org X-Enigmail-Version: 0.95.2 Content-Type: multipart/mixed; boundary="------------060407030105010800010608" Subject: Pipe direct write and pipeselwakeup() 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, 07 Sep 2007 13:14:33 -0000 This is a multi-part message in MIME format. --------------060407030105010800010608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm investigating a problem with select/poll/kevent not triggered when writing to a pipe. Here I explain what I understood and, at the end of this mail, I propose a patch. I would like to have feedback about this solution. The problem comes from the way pipes are implemented. The kernel uses two ways to write data on a pipe: o buffered write. This is done when there is less than 8192 bytes (PIPE_MINDIRECT) in the _current_ iov. Data from _all_ iov are uiomove()'d to an internal buffer until there's no more data or the buffer is full. o direct write. This is done when there is at least 8192 bytes in the current iov. Both techniques can't be mixed. So during a single call to writev(2), if there's a need to switch from one to the other, the kernel must wake reader processes and select/poll/kqueue up before the write continues. But when switching from direct write to buffered write, the kernel only wakes reader processes up, not select/poll/kqueue. Someone provided me with a testcase to reproduce the bug. I attached the sources to this mail ("rd.c" and "wr.c"). Use it like this: ./rd ./wr Here's is what's going on with this testcase: 1. the first iov is smaller than 8192 bytes (1 or 2 bytes), so buffered write is selected. 2. the kernel internal buffer is 65536 bytes long, so uiomove() will fill it completly with the data (73727 or 73728 bytes). At the end, 8191 or 8192 bytes remain, depending on TRIGGER_WRITEV_BUG in "wr.c". 3a. with 8191 bytes remaining, buffered write is still selected but the buffer is full: readers and selects are awaken. Everything's fine. 3b. with 8192 bytes remaining, direct write is selected. It sees that the internal buffer is in use: readers are awaken (so the buffer can be flushed) but not selects. Here, the select/poll/kevent times out. There are 3 cases where only readers are awaken. The attached patch add calls to pipeselwakeup(). This fixes the testcase but I'd like to know if there was a good reason to not call pipeselwakeup() in this 3 specific cases? Also, in the third case, the PIPE_WANTW flag isn't set either. I think it should be set too. What do you think? Thanks for any feedback! - -- Jean-Sébastien Pédron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4UwZa+xGJsFYOlMRAqKBAJwLx+9WoQmPs4pa8VEPOzT2b5r3VQCfarLY giS8UUEYvNuUQGBqtJ4jhJU= =Rato -----END PGP SIGNATURE----- --------------060407030105010800010608 Content-Type: text/plain; name="rd.c" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="rd.c" Ci8qICJnY2MgLVdhbGwgLW8gcmQgcmQuYyIgKi8KLyogImdjYyAtRF9SRUVOVFJBTlQgLVdh bGwgLW8gcmQgcmQuYyAtbGNfciIgKi8KI2luY2x1ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDxz eXMvdHlwZXMuaD4KI2luY2x1ZGUgPHN5cy9ldmVudC5oPgojaW5jbHVkZSA8c3lzL3RpbWUu aD4KI2luY2x1ZGUgPHN5cy91aW8uaD4KI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxz dGRsaWIuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8c3RyaW5nLmg+CiNpbmNs dWRlIDxlcnJuby5oPgojaW5jbHVkZSA8cG9sbC5oPgojaW5jbHVkZSA8c3lzL3NlbGVjdC5o PgoKI2lmIDEKI2RlZmluZSBVU0VfS1EKI2VsaWYgMQojZGVmaW5lIFVTRV9QT0xMCiNlbmRp ZgoKI2RlZmluZSBFVl9USU1FT1VUIDEwCgppbnQKbWFpbihpbnQgYXJnYywgY2hhciAqYXJn dltdKQp7CiAgICBpbnQgZmRzWzJdOwogICAgaW50IHJlczsKCiAgICBpZiAoYXJnYyAhPSAy KSB7CglmcHJpbnRmKHN0ZGVyciwgIlVzYWdlOiByZCA8cGF0aCB0byB3cml0ZXI+XG4iKTsK CWV4aXQoMSk7CiAgICB9CgogICAgaWYgKHBpcGUoZmRzKSA8IDApIHsKCXBlcnJvcigicGlw ZSgpIGZhaWxlZCIpOwoJZXhpdCgxKTsKICAgIH0KCiAgICBmcHJpbnRmKHN0ZGVyciwgInBp cGUgZmRzPXslZCwgJWR9XG4iLCBmZHNbMF0sIGZkc1sxXSk7CgogICAgZnByaW50ZihzdGRl cnIsICJzZXR0aW5nICVkIGluIG5vbi1ibG9ja2luZyBtb2RlXG4iLCBmZHNbMF0pOwogICAg ZmNudGwoZmRzWzBdLCBGX1NFVEZMLCBmY250bChmZHNbMF0sIEZfR0VURkwsIDApIHwgT19O T05CTE9DSyk7CgogICAgcmVzID0gZm9yaygpOwogICAgaWYgKHJlcyA8IDApIHsKCXBlcnJv cigiZm9yaygpIGZhaWxlZFxuIik7CglleGl0KDEpOwogICAgfQogICAgZWxzZSBpZiAocmVz ID09IDApIHsKCWNsb3NlKDEpOwoJZHVwKGZkc1sxXSk7CgljbG9zZShmZHNbMF0pOwoJY2xv c2UoZmRzWzFdKTsKCWV4ZWNsKGFyZ3ZbMV0sIGFyZ3ZbMV0sIE5VTEwpOwoJcGVycm9yKCJl eGVjbCgpIGZhaWxlZFxuIik7CglleGl0KDEpOwogICAgfQoKICAgIGNsb3NlKGZkc1sxXSk7 CgojaWZkZWYgVVNFX0tRCiAgICB7CglpbnQga3E7CglpbnQgaTsKCXN0cnVjdCBrZXZlbnQg ZXZbMTBdOwoJc3RydWN0IHRpbWVzcGVjIHR2ID0gezAsIDB9OwoJc3RydWN0IGtldmVudCBj aGdbMV07CgoJa3EgPSBrcXVldWUoKTsKCWlmIChrcSA8IDApIHsKCSAgICBwZXJyb3IoImtx dWV1ZSgpIGZhaWxlZCIpOwoJICAgIGV4aXQoMSk7Cgl9CgkKCWZwcmludGYoc3RkZXJyLCAi c2V0dGluZyBFVkZJTFRfUkVBRCBvbiAlZFxuIiwgZmRzWzBdKTsKCUVWX1NFVCgmY2hnWzBd LCBmZHNbMF0sIEVWRklMVF9SRUFELCBFVl9BREQsIDAsIDAsICh2b2lkICopIDIpOwoJcmVz ID0ga2V2ZW50KGtxLCAmY2hnWzBdLCAxLCBOVUxMLCAwLCAmdHYpOwoJaWYgKHJlcyA8IDAp IHsKCSAgICBwZXJyb3IoImtldmVudCgpIGZhaWxlZFxuIik7CgkgICAgZXhpdCgxKTsKCX0K CWVsc2UgewoJICAgIGZwcmludGYoc3RkZXJyLCAia2V2ZW50KCkgcmV0dXJuZWQgPSAlZFxu IiwgcmVzKTsKCX0KCXR2LnR2X3NlYyA9IEVWX1RJTUVPVVQ7Cgl0di50dl9uc2VjID0gMDsK CWZwcmludGYoc3RkZXJyLCAia2V2ZW50IHdhaXRpbmcgZm9yICVkIHNlY3MgZm9yIGV2ZW50 cy4uLlxuIiwKCQlFVl9USU1FT1VUKTsKCXJlcyA9IGtldmVudChrcSwgTlVMTCwgMCwgJmV2 WzBdLCAxMCwgJnR2KTsKCWlmIChyZXMgPCAwKSB7CgkgICAgcGVycm9yKCJrZXZlbnQgZmFp bGVkXG4iKTsKCSAgICBleGl0KDEpOwoJfQoJZWxzZSBpZiAocmVzID09IDApIHsKCSAgICBm cHJpbnRmKHN0ZGVyciwgImtldmVudCB0aW1lZCBvdXRcbiIpOwoJICAgIGV4aXQoMSk7Cgl9 CglmcHJpbnRmKHN0ZGVyciwgImtldmVudCByZXR1cm5lZCA9ICVkXG4iLCByZXMpOwoKCWZv ciAoaSA9IDA7IGkgPCAxMCAmJiBpIDwgcmVzOyBpKyspIHsKCSAgICBmcHJpbnRmKHN0ZGVy ciwgInJlc3VsdCBldmVudCAlZDogZmQ9JWQ6ICIsIGksIChpbnQpZXZbaV0uaWRlbnQpOwoJ ICAgIGlmIChldltpXS5mbGFncyAmIEVWX0VSUk9SKSB7CgkJZnByaW50ZihzdGRlcnIsICJF Vl9FUlJPUjogJXMgIiwgc3RyZXJyb3IoZXZbaV0uZGF0YSkpOwoJICAgIH0KCSAgICBlbHNl IHsKCQlpZiAoZXZbaV0uZmlsdGVyID09IEVWRklMVF9SRUFEKQoJCSAgICBmcHJpbnRmKHN0 ZGVyciwgIkVWRklMVF9SRUFEICIpOwoJCWlmIChldltpXS5maWx0ZXIgPT0gRVZGSUxUX1dS SVRFKQoJCSAgICBmcHJpbnRmKHN0ZGVyciwgIkVWRklMVF9XUklURSAiKTsKCSAgICB9Cgkg ICAgZnByaW50ZihzdGRlcnIsICJcbiIpOwoJfQogICAgfQoKI2VsaWYgZGVmaW5lZChVU0Vf UE9MTCkKICAgIHsKCXN0cnVjdCBwb2xsZmQgcGZkc1sxXTsKCQoJcGZkc1swXS5mZCA9IGZk c1swXTsKCXBmZHNbMF0uZXZlbnRzID0gKFBPTExJTnxQT0xMUkROT1JNKTsKCXBmZHNbMF0u cmV2ZW50cyA9IDA7CgoJZnByaW50ZihzdGRlcnIsICJwZmRzWzBdLmZkID0gJWQgcGZkc1sw XS5ldmVudHMgPSBQT0xMSU58UE9MTFJETk9STVxuIiwKCQlwZmRzWzBdLmZkKTsKCSAgICAK CglmcHJpbnRmKHN0ZGVyciwgInBvbGwgd2FpdGluZyBmb3IgJWQgc2VjcyBmb3IgZXZlbnRz Li4uXG4iLAoJCUVWX1RJTUVPVVQpOwoJcmVzID0gcG9sbCgmcGZkc1swXSwgMSwgRVZfVElN RU9VVCoxMDAwKTsKCWlmIChyZXMgPCAwKSB7CgkgICAgcGVycm9yKCJwb2xsIGZhaWxlZFxu Iik7CgkgICAgZXhpdCgxKTsKCX0KCWVsc2UgaWYgKHJlcyA9PSAwKSB7CgkgICAgZnByaW50 ZihzdGRlcnIsICJwb2xsIHRpbWVkIG91dFxuIik7CgkgICAgZXhpdCgxKTsKCX0KCWZwcmlu dGYoc3RkZXJyLCAicG9sbCByZXR1cm5lZCA9ICVkXG4iLCByZXMpOwoJZnByaW50ZihzdGRl cnIsICJmZD0lZCAiLCBwZmRzWzBdLmZkKTsKCWlmIChwZmRzWzBdLnJldmVudHMgJiBQT0xM SU4pCgkgICAgZnByaW50ZihzdGRlcnIsICJQT0xMSU4gIik7CglpZiAocGZkc1swXS5yZXZl bnRzICYgUE9MTFJETk9STSkKCSAgICBmcHJpbnRmKHN0ZGVyciwgIlBPTExSRE5PUk0gIik7 CglpZiAocGZkc1swXS5yZXZlbnRzICYgUE9MTE9VVCkKCSAgICBmcHJpbnRmKHN0ZGVyciwg IlBPTExPVVQgIik7CglmcHJpbnRmKHN0ZGVyciwgIlxuIik7CiAgICB9CiNlbHNlIC8qIHVz ZSBzZWxlY3QgKi8KICAgIHsKCWZkX3NldCByZWFkZmRzOwoJc3RydWN0IHRpbWV2YWwgc3R2 ID0ge0VWX1RJTUVPVVQsIDB9OwoJRkRfWkVSTygmcmVhZGZkcyk7CglGRF9TRVQoZmRzWzBd LCAmcmVhZGZkcyk7CgoJZnByaW50ZihzdGRlcnIsICJzZWxlY3RpbmcgZmQgPSAlZFxuIiwg ZmRzWzBdKTsKCSAgICAKCglmcHJpbnRmKHN0ZGVyciwgInNlbGVjdCB3YWl0aW5nIGZvciAl ZCBzZWNzIGZvciBldmVudHMuLi5cbiIsCgkJRVZfVElNRU9VVCk7CglyZXMgPSBzZWxlY3Qo ZmRzWzBdKzEsICZyZWFkZmRzLCBOVUxMLCBOVUxMLCAmc3R2KTsKCWlmIChyZXMgPCAwKSB7 CgkgICAgcGVycm9yKCJzZWxlY3QgZmFpbGVkXG4iKTsKCSAgICBleGl0KDEpOwoJfQoJZWxz ZSBpZiAocmVzID09IDApIHsKCSAgICBmcHJpbnRmKHN0ZGVyciwgInNlbGVjdCB0aW1lZCBv dXRcbiIpOwoJICAgIGV4aXQoMSk7Cgl9CglmcHJpbnRmKHN0ZGVyciwgInNlbGVjdCByZXR1 cm5lZCA9ICVkXG4iLCByZXMpOwoJZnByaW50ZihzdGRlcnIsICJmZD0lZCAiLCBmZHNbMF0p OwoJaWYgKEZEX0lTU0VUKGZkc1swXSwgJnJlYWRmZHMpKQoJICAgIGZwcmludGYoc3RkZXJy LCAiZmQgaXMgc2V0ICIpOwoJZnByaW50ZihzdGRlcnIsICJcbiIpOwogICAgfQojZW5kaWYK ICAgIGNsb3NlKGZkc1swXSk7CiAgICByZXR1cm4gMDsKfQoKCgoKCgo= --------------060407030105010800010608 Content-Type: text/plain; name="wr.c" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="wr.c" Ci8qICJnY2MgLVdhbGwgLW8gd3Igd3IuYyIgYnVnZ3kgKi8KLyogImdjYyAtRF9SRUVOVFJB TlQgLVdhbGwgLW8gd3Igd3IuYyAtbGNfciIgbm90IGJ1Z2d5ISAqLwoKCiNkZWZpbmUgVFJJ R0dFUl9XUklURVZfQlVHIDEKCgojaW5jbHVkZSA8c3lzL3R5cGVzLmg+CiNpbmNsdWRlIDxz eXMvdWlvLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KI2luY2x1ZGUgPHN0ZGlvLmg+CgojaWZu ZGVmIFBBR0VfU0laRQojZGVmaW5lIFBBR0VfU0laRSA0MDk2CiNlbmRpZgoKLyogVGhlIGZv bGxvd2luZyAicGlwZSBkZWZpbmVzIiBjdXQgZnJvbSBzeXMvcGlwZS5oICovCgojaWZuZGVm IFBJUEVfU0laRQojZGVmaW5lIFBJUEVfU0laRSAgICAgICAxNjM4NAojZW5kaWYKCiNpZm5k ZWYgQklHX1BJUEVfU0laRQojZGVmaW5lIEJJR19QSVBFX1NJWkUgICAoNjQqMTAyNCkKI2Vu ZGlmCgojaWZuZGVmIFNNQUxMX1BJUEVfU0laRQojZGVmaW5lIFNNQUxMX1BJUEVfU0laRSBQ QUdFX1NJWkUKI2VuZGlmCgojaWZuZGVmIFBJUEVfTUlORElSRUNUCiNkZWZpbmUgUElQRV9N SU5ESVJFQ1QgIDgxOTIKI2VuZGlmCgojaWZuZGVmIFBJUEVOUEFHRVMKI2RlZmluZSBQSVBF TlBBR0VTICAgICAgKEJJR19QSVBFX1NJWkUgLyBQQUdFX1NJWkUgKyAxKQojZW5kaWYKCiNp ZiBUUklHR0VSX1dSSVRFVl9CVUcKI2RlZmluZSBCVUYwX1NaIDIKI2Vsc2UKI2RlZmluZSBC VUYwX1NaIDEKI2VuZGlmCiNkZWZpbmUgQlVGMV9TWiBQQUdFX1NJWkUKI2RlZmluZSBCVUYy X1NaIChQSVBFTlBBR0VTICogUEFHRV9TSVpFIC0gMikKCnN0YXRpYyBjaGFyIGJ1ZltCVUYw X1NaICsgQlVGMV9TWiArIEJVRjJfU1pdOwoKCmludCBtYWluKHZvaWQpCnsKICAgIGludCB3 cjsKICAgIHN0cnVjdCBpb3ZlYyBpb3ZbM107CgogICAgc2xlZXAoMSk7CgogICAgZnByaW50 ZihzdGRlcnIsICJQSVBFTlBBR0VTPSVkXG5QQUdFX1NJWkU9JWRcbiIsCgkgICAgUElQRU5Q QUdFUywgUEFHRV9TSVpFKTsKICAgIGZwcmludGYoc3RkZXJyLCAiQlVGMF9TWj0lZCwgQlVG MV9TWj0lZCwgQlVGMl9TWj0lZFxuIiwKCSAgICBCVUYwX1NaLCBCVUYxX1NaLCBCVUYyX1Na KTsKCiAgICBpb3ZbMF0uaW92X2Jhc2UgPQojaWYgQlVGMF9TWiA9PSAwCglOVUxMCiNlbHNl CgkmYnVmWzBdCiNlbmRpZgoJOwogICAgaW92WzBdLmlvdl9sZW4gPSBCVUYwX1NaOwoKCiAg ICBpb3ZbMV0uaW92X2Jhc2UgPQojaWYgQlVGMV9TWiA9PSAwCglOVUxMCiNlbHNlCgkmYnVm W0JVRjBfU1pdCiNlbmRpZgoJOwogICAgaW92WzFdLmlvdl9sZW4gPSBCVUYxX1NaOwoKCiAg ICBpb3ZbMl0uaW92X2Jhc2UgPQojaWYgQlVGMl9TWiA9PSAwCglOVUxMCiNlbHNlCgkmYnVm W0JVRjBfU1orQlVGMV9TWl0KI2VuZGlmCgk7CiAgICBpb3ZbMl0uaW92X2xlbiA9IEJVRjJf U1o7CgkJCiAgICB3ciA9IHdyaXRldigxLCAmaW92WzBdLCAzKTsKICAgIGZwcmludGYoc3Rk ZXJyLCAid3JpdGUgcmV0dXJuZWQ6ICVkXG4iLCB3cik7CiAgICByZXR1cm4gMDsKfQoKCgoK --------------060407030105010800010608 Content-Type: text/plain; name="sys-kern-sys_pipe.c-pipeselwakeup_with_directwrite-a.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename*0="sys-kern-sys_pipe.c-pipeselwakeup_with_directwrite-a.patch" SW5kZXg6IHN5cy9rZXJuL3N5c19waXBlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hv bWUvZHVtYmJlbGwvcHJvamVjdHMvZnJlZWJzZC9jdnMtbWlycm9yL3NyYy9zeXMva2Vybi9z eXNfcGlwZS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE5MQpkaWZmIC11IC1yMS4xOTEg c3lzX3BpcGUuYwotLS0gc3lzL2tlcm4vc3lzX3BpcGUuYwkyNyBNYXkgMjAwNyAxNzozMzox MCAtMDAwMAkxLjE5MQorKysgc3lzL2tlcm4vc3lzX3BpcGUuYwk2IFNlcCAyMDA3IDEzOjI4 OjIxIC0wMDAwCkBAIC04ODEsNiArODgxLDcgQEAKIAkJCXdha2V1cCh3cGlwZSk7CiAJCX0K IAkJd3BpcGUtPnBpcGVfc3RhdGUgfD0gUElQRV9XQU5UVzsKKwkJcGlwZXNlbHdha2V1cCh3 cGlwZSk7CiAJCXBpcGV1bmxvY2sod3BpcGUpOwogCQllcnJvciA9IG1zbGVlcCh3cGlwZSwg UElQRV9NVFgod3BpcGUpLAogCQkgICAgUFJJQklPIHwgUENBVENILCAicGlwZHd3IiwgMCk7 CkBAIC04OTYsNiArODk3LDcgQEAKIAkJCXdha2V1cCh3cGlwZSk7CiAJCX0KIAkJd3BpcGUt PnBpcGVfc3RhdGUgfD0gUElQRV9XQU5UVzsKKwkJcGlwZXNlbHdha2V1cCh3cGlwZSk7CiAJ CXBpcGV1bmxvY2sod3BpcGUpOwogCQllcnJvciA9IG1zbGVlcCh3cGlwZSwgUElQRV9NVFgo d3BpcGUpLAogCQkgICAgUFJJQklPIHwgUENBVENILCAicGlwZHdjIiwgMCk7CkBAIC0xMDgw LDYgKzEwODIsNyBAQAogCQkJCXdwaXBlLT5waXBlX3N0YXRlICY9IH5QSVBFX1dBTlRSOwog CQkJCXdha2V1cCh3cGlwZSk7CiAJCQl9CisJCQlwaXBlc2Vsd2FrZXVwKHdwaXBlKTsKIAkJ CXBpcGV1bmxvY2sod3BpcGUpOwogCQkJZXJyb3IgPSBtc2xlZXAod3BpcGUsIFBJUEVfTVRY KHJwaXBlKSwgUFJJQklPIHwgUENBVENILAogCQkJICAgICJwaXBid3ciLCAwKTsK --------------060407030105010800010608--