From owner-svn-src-all@FreeBSD.ORG Sat Mar 29 04:31:11 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C6C7B98; Sat, 29 Mar 2014 04:31:11 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05A3D220; Sat, 29 Mar 2014 04:31:11 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2T4V6f2058504; Sat, 29 Mar 2014 04:31:08 GMT (envelope-from davidxu@freebsd.org) Message-ID: <53364C88.5080706@freebsd.org> Date: Sat, 29 Mar 2014 12:31:04 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: svn commit: r263755 - head/sys/kern References: <53351627.9000703@freebsd.org> <201403281613.s2SGDKpk010871@gw.catspoiler.org> <20140329025602.GB29296@dft-labs.eu> <5336396E.7000801@freebsd.org> <20140329032513.GC29296@dft-labs.eu> <53364369.10500@freebsd.org> <20140329041441.GD29296@dft-labs.eu> In-Reply-To: <20140329041441.GD29296@dft-labs.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, mjg@FreeBSD.org, Don Lewis , svn-src-head@FreeBSD.org, kostikbel@gmail.com, svn-src-all@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 04:31:11 -0000 On 2014/03/29 12:14, Mateusz Guzik wrote: > I asked if multpiple concurrent calls to fsetown(.., &pointer) could > result in some corruption in the kernel - if they could, we would have > a problem in the future. I decided to read the code once more and > fsetown seems to be safe in this regard after all and with that in > mind the patch looks good to me. This thread is too long already, so > I'm stepping down on this one in case there are some futher concerns. This thread is really long, but things must be clarified, so it was not long enough. :-) Previously I supposed you had read the fsetown code, if not, I was wrong, lol.