From owner-freebsd-arch@FreeBSD.ORG Sun Nov 9 15:27:24 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC56D2EE for ; Sun, 9 Nov 2014 15:27:24 +0000 (UTC) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7943B39D for ; Sun, 9 Nov 2014 15:27:24 +0000 (UTC) Received: by mail-yh0-f43.google.com with SMTP id a41so1438998yho.30 for ; Sun, 09 Nov 2014 07:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OpSNI+fhcjTp2QoT0EoRzMnyR4UZsU4T1cegouJfi1g=; b=Y3ohH3Lrgh+oGd8xPeuIWFG155TPOCSgomBB2X2E+ZWzxNjZm79QF5Qo1GGLkOygTH +mzK0fZhFhqSuZhsEBBPA2C6fOUVLzXASwa7RNrQYZhO1VKuQRalslb5m97gBwWMMYuO bhXwePt7uZxeCzKDI6q7M0jAX6EkFtloF3X5FrGbWS3UNEs+qqSIi/yPRicxFW7qUkzX fQoVptg/ESfDeDm83EneFEL8hhjO/pSwjekyUgOtVXiKM15DxNlryKQf6msJ5+Mmt5PT Vcd6F25AIlWhsRDWis8fKrzXs4BdmHXEUDIMMrtfILPVJ3FxMk/dnOhwqQFY+F6BAsIt l0Dw== MIME-Version: 1.0 X-Received: by 10.236.30.227 with SMTP id k63mr24374032yha.28.1415546843295; Sun, 09 Nov 2014 07:27:23 -0800 (PST) Received: by 10.170.84.133 with HTTP; Sun, 9 Nov 2014 07:27:23 -0800 (PST) Date: Sun, 9 Nov 2014 07:27:23 -0800 Message-ID: Subject: Lack of informative files in FreeBSD svn From: Mehmet Erol Sanliturk To: FreeBSD Arch Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-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, 09 Nov 2014 15:27:24 -0000 Dears All , When the FreeBSD svn is studied , one of the most important problems seems to be missing ReadMe or other informative files in many directories . The assumption at present seems to be that such a study will ALWAYS be performed by persons who know the FreeBSD very well . This structure is , in my opinion , an important obstacle in front of the persons wishing to study and understand the FreeBSD structure very well and then try to make contributions . As an example , consider https://svnweb.freebsd.org/base/user/ directory . In that directory , there are work in progress projects ( I assume like that ) . There is a guidelines text , but not a ReadMe file or any other named file to list names and their project subjects . Also there is no any html file which contains links to related off site pages such as FreeBSD wiki . And also no one of the directories contain a ReadMe file about the tasks studied . It may be said that , no one of the directory is related to the general public other than its owner . Such an idea is very contrary to ideas specified in status reports and open projects pages and in some other messages that saying there is an important man power requirement . Another disadvantage is that when a person wishes to make an improvement she/he is not able to study existing works and if possible to join to such groups . There remains a possibility , mostly , to start from scratch in isolation. Many points are documented in FreeBSD wiki . In the svn , I did not see any html file that presents links to such pages ( there may exist some but seems that they are very rare ) . I am sorry to be very negative , but I think there is no any other choice to explain above ideas . For example , I am studying https://svnweb.freebsd.org/base/head/contrib/expat/ In it , there is a directory https://svnweb.freebsd.org/base/head/contrib/expat/tests/ it contains https://svnweb.freebsd.org/base/head/contrib/expat/tests/README.txt?view=markup but it does not contain any link to information how to use new kyua testing facility for these tests . It may be said that "You should know !" , but my problem is "How ?" . I do NOT expect that all of the directories can be populated with such informative files immediately . In some very distant places , there may be many informative pages , but how I can know where they are . It may be said "Search " , but "What ?" . My suggestion is to start such a convention with the goal that such informative files will attract more people to make contributions and also will be a good documentation about FreeBSD maintenance . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Mon Nov 10 01:33:50 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07A437CE; Mon, 10 Nov 2014 01:33:50 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 773EBF2B; Mon, 10 Nov 2014 01:33:49 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id pn19so6829428lab.4 for ; Sun, 09 Nov 2014 17:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NU2X8LRXWxqU+NH7LLOpMPR++tS3nvPhyI0SvzKZvMo=; b=v3Zf5bIJC8J/j1YjD8wKzQntmXvVQuiTimGfa5Sg6LaL/qb/1PMEV8PzIXgorTXbWn g2OqVzJYGoDKhf7IhW0CfUOfBbhC6RkcuqHZkktZsWEfvdLstFnPpljVJs1Y/rSmmCh+ as08q5S8pkd5AfwYampA6/a37ElIbQ3x0xo3jxy8H2kbmAwL4IrybtT73OgHW2uRNxJf r11n0C6kElU1ONpndN6qFMIkjrauIaCuZBm7Zaj7Ur2p3BTAKSkEJ9cBg6EKlWHbsLQF Xa1RUdr42HNxNecvfhDJFCUrgvFrGUASwQm0IGDgEZyy0hu2HY2quQy0ewAFyqr0vP2W kR9Q== MIME-Version: 1.0 X-Received: by 10.152.37.104 with SMTP id x8mr6484542laj.74.1415583227074; Sun, 09 Nov 2014 17:33:47 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Sun, 9 Nov 2014 17:33:46 -0800 (PST) In-Reply-To: <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> Date: Sun, 9 Nov 2014 17:33:46 -0800 X-Google-Sender-Auth: hIDLToTb1ol9m0GH421ObSESjlQ Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 01:33:50 -0000 On Sun, Oct 12, 2014 at 6:07 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > > > > Can you provide a pointer to your Perforce branch? > > //depot/user/bz/vimage/src/... > > Hi, Since I am more familiar with git than Perforce, I converted your Perforce branch to git and put it on github: https://github.com/rodrigc/bz-vimage I took a look at the history of that branch, and it looks like you merged quite a lot of changes in this branch back to FreeBSD. There were a few places where it looks like the code in your branch diverged from FreeBSD (in carp area, for example). Offhand, can you remember any VIMAGE related memory leaks you might have fixed in this branch which you did not merge back? This one looks pretty simple by removing UMA_ZONE_NOFREE in a few places: https://github.com/rodrigc/bz-vimage/commit/ebe7e4c5e7e5b3dbfc442a25f10ca8681c605c89 In this one, you added dom_pr_register() and dom_pr_unregister() hooks: https://github.com/rodrigc/bz-vimage/commit/a1d5c8bc2f4484e58594ca8fad793aa339a5ef29 but I'm not sure if you wanted to merge this back to FreeBSD or not. Can you think of anything else in this branch that we need for VIMAGE? Thanks. -- Craig From owner-freebsd-arch@FreeBSD.ORG Mon Nov 10 04:32:46 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F267ED09 for ; Mon, 10 Nov 2014 04:32:46 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C945234C for ; Mon, 10 Nov 2014 04:32:46 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAA4WiJD092599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2014 20:32:45 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAA4Wilu092598; Sun, 9 Nov 2014 20:32:44 -0800 (PST) (envelope-from jmg) Date: Sun, 9 Nov 2014 20:32:44 -0800 From: John-Mark Gurney To: Mehmet Erol Sanliturk Subject: Re: Lack of informative files in FreeBSD svn Message-ID: <20141110043244.GN24601@funkthat.com> Mail-Followup-To: Mehmet Erol Sanliturk , FreeBSD Arch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 09 Nov 2014 20:32:45 -0800 (PST) Cc: FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 04:32:47 -0000 Mehmet Erol Sanliturk wrote this message on Sun, Nov 09, 2014 at 07:27 -0800: > When the FreeBSD svn is studied , one of the most important problems seems > to be missing ReadMe or other informative files in many directories . If we put a README in every directory, we'd end up w/ over 6k READMEs, and that's just for base... We'd end up w/ 100 times more if we did that for all of projects and users in svn... The svn tree isn't a stand alone product... Did you download the doc svn repo too? > The assumption at present seems to be that such a study will ALWAYS be > performed by persons who know the FreeBSD very well . I'd disagree... the Developers Handbook mentioned below is an example of that... > This structure is , in my opinion , an important obstacle in front of the > persons wishing to study and understand the FreeBSD structure very well and > then try to make contributions . > > > As an example , consider > > https://svnweb.freebsd.org/base/user/ > > directory . > > In that directory , there are work in progress projects ( I assume like > that ) . > There is a guidelines text , but not a ReadMe file or any other named file > to list names and their project subjects . You need to talk to each user to which the repo belongs... Most of these are not for public consumption, unless the user calls for testing... > Also there is no any html file which contains links to related off site > pages such as FreeBSD wiki . > > And also no one of the directories contain a ReadMe file about the tasks > studied . > > > It may be said that , no one of the directory is related to the general > public other than its owner . > > Such an idea is very contrary to ideas specified in status reports and open > projects pages and in some other messages that saying there is an important > man power requirement . > > Another disadvantage is that when a person wishes to make an improvement > she/he is not able to study existing works and if possible to join to such > groups . There remains a possibility , mostly , to start from scratch in > isolation. This stands for all projects... Not everyone makes all of their work available, nor do they necessarily have it in a clean enough state that it is even usable... For finding out about the project, post to one of the mailing lists, or look at the svn history to see who is recently most active and drop them an email... Most projects require some reading of documentation available before you can meaningfully contribute to a project.. > Many points are documented in FreeBSD wiki . In the svn , I did not see any > html file that presents links to such pages ( there may exist some but > seems that they are very rare ) . Did you read any of the handbooks on https://www.FreeBSD.org? There is more information there than on the wiki... > I am sorry to be very negative , but I think there is no any other choice > to explain above ideas . > > For example , I am studying > > https://svnweb.freebsd.org/base/head/contrib/expat/ > > In it , there is a directory > > https://svnweb.freebsd.org/base/head/contrib/expat/tests/ > > it contains > > https://svnweb.freebsd.org/base/head/contrib/expat/tests/README.txt?view=markup > > but it does not contain any link to information how to use new kyua testing > facility for these tests . > > It may be said that "You should know !" , but my problem is "How ?" . By reading the documentation... Though the use of kyua is very new, so I'm not sure how well the documentation is for that... > I do NOT expect that all of the directories can be populated with such > informative files immediately . In some very distant places , there may be > many informative pages , but how I can know where they are . It may be said > "Search " , but "What ?" . Read the various handbooks, like: https://www.freebsd.org/doc/en/books/developers-handbook/introduction-layout.html which is part of the Developers Handbook at: https://www.freebsd.org/doc/en/books/developers-handbook/index.html > My suggestion is to start such a convention with the goal that such > informative files will attract more people to make contributions and also > will be a good documentation about FreeBSD maintenance . If you don't think the handbook describes enough, or any of the other documentation is enough at: https://www.freebsd.org/docs.html Please let us know exactly what can help... The project has a lot of documentation, probably too much, but yes, some times it's hard to find.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Nov 10 08:57:01 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D64BA8D for ; Mon, 10 Nov 2014 08:57:01 +0000 (UTC) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55D7D1CD for ; Mon, 10 Nov 2014 08:57:01 +0000 (UTC) Received: by mail-yk0-f179.google.com with SMTP id 131so3966493ykp.10 for ; Mon, 10 Nov 2014 00:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=D78xe30yoNquvy/lk3yDEQsqKjZYP9PqpTIugS6KdEs=; b=Z64R/CgUkeGAhQkSe7mAzUhMG/3F2BdihcrH4Aam/RAdQegoKRltmKl50a3mDZLLFw WsVBOOGAlfYt5qc8+7wJfWsGqxK4FyhULZRJKW88nl0q506DAthZbqy2IImlKQJvanX5 +v1xVU9dgPeUUGqdMZbX5yFKbmD4nrWkXHlRN2/+CNqniLyfAfAIb7lk/GdEKxhNHfpi hJrAmWwttaSIYkcpQ6kq+XAMQcWV8nddYWu1g7VebNhVW5m6u7j4/qFuqu0EYg+lc9aH WstTc/8BGfgMsWpknUfcelTZaT2/z1+2w2L65g9trf+CF8+10Ua1f9gW6U+D20h8Zs33 m6zg== MIME-Version: 1.0 X-Received: by 10.170.196.72 with SMTP id n69mr31939739yke.41.1415609820457; Mon, 10 Nov 2014 00:57:00 -0800 (PST) Received: by 10.170.84.133 with HTTP; Mon, 10 Nov 2014 00:57:00 -0800 (PST) In-Reply-To: <20141110043244.GN24601@funkthat.com> References: <20141110043244.GN24601@funkthat.com> Date: Mon, 10 Nov 2014 00:57:00 -0800 Message-ID: Subject: Re: Lack of informative files in FreeBSD svn From: Mehmet Erol Sanliturk To: Mehmet Erol Sanliturk , FreeBSD Arch Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 08:57:01 -0000 On Sun, Nov 9, 2014 at 8:32 PM, John-Mark Gurney wrote: > Mehmet Erol Sanliturk wrote this message on Sun, Nov 09, 2014 at 07:27 > -0800: > > When the FreeBSD svn is studied , one of the most important problems > seems > > to be missing ReadMe or other informative files in many directories . > > If we put a README in every directory, we'd end up w/ over 6k READMEs, > and that's just for base... We'd end up w/ 100 times more if we did > that for all of projects and users in svn... The svn tree isn't > a stand alone product... Did you download the doc svn repo too? > > > The assumption at present seems to be that such a study will ALWAYS be > > performed by persons who know the FreeBSD very well . > > I'd disagree... the Developers Handbook mentioned below is an example > of that... > > > This structure is , in my opinion , an important obstacle in front of the > > persons wishing to study and understand the FreeBSD structure very well > and > > then try to make contributions . > > > > > > As an example , consider > > > > https://svnweb.freebsd.org/base/user/ > > > > directory . > > > > In that directory , there are work in progress projects ( I assume like > > that ) . > > There is a guidelines text , but not a ReadMe file or any other named > file > > to list names and their project subjects . > > You need to talk to each user to which the repo belongs... Most of > these are not for public consumption, unless the user calls for > testing... > > > Also there is no any html file which contains links to related off site > > pages such as FreeBSD wiki . > > > > And also no one of the directories contain a ReadMe file about the tasks > > studied . > > > > > > It may be said that , no one of the directory is related to the general > > public other than its owner . > > > > Such an idea is very contrary to ideas specified in status reports and > open > > projects pages and in some other messages that saying there is an > important > > man power requirement . > > > > Another disadvantage is that when a person wishes to make an improvement > > she/he is not able to study existing works and if possible to join to > such > > groups . There remains a possibility , mostly , to start from scratch in > > isolation. > > This stands for all projects... Not everyone makes all of their work > available, nor do they necessarily have it in a clean enough state that > it is even usable... For finding out about the project, post to one > of the mailing lists, or look at the svn history to see who is recently > most active and drop them an email... Most projects require some > reading of documentation available before you can meaningfully > contribute to a project.. > > > Many points are documented in FreeBSD wiki . In the svn , I did not see > any > > html file that presents links to such pages ( there may exist some but > > seems that they are very rare ) . > > Did you read any of the handbooks on https://www.FreeBSD.org? There is > more information there than on the wiki... > > > I am sorry to be very negative , but I think there is no any other choice > > to explain above ideas . > > > > For example , I am studying > > > > https://svnweb.freebsd.org/base/head/contrib/expat/ > > > > In it , there is a directory > > > > https://svnweb.freebsd.org/base/head/contrib/expat/tests/ > > > > it contains > > > > > https://svnweb.freebsd.org/base/head/contrib/expat/tests/README.txt?view=markup > > > > but it does not contain any link to information how to use new kyua > testing > > facility for these tests . > > > > It may be said that "You should know !" , but my problem is "How ?" . > > By reading the documentation... Though the use of kyua is very new, > so I'm not sure how well the documentation is for that... > > > I do NOT expect that all of the directories can be populated with such > > informative files immediately . In some very distant places , there may > be > > many informative pages , but how I can know where they are . It may be > said > > "Search " , but "What ?" . > > Read the various handbooks, like: > > https://www.freebsd.org/doc/en/books/developers-handbook/introduction-layout.html > > which is part of the Developers Handbook at: > https://www.freebsd.org/doc/en/books/developers-handbook/index.html > > > My suggestion is to start such a convention with the goal that such > > informative files will attract more people to make contributions and > also > > will be a good documentation about FreeBSD maintenance . > > If you don't think the handbook describes enough, or any of the other > documentation is enough at: https://www.freebsd.org/docs.html > > Please let us know exactly what can help... The project has a lot of > documentation, probably too much, but yes, some times it's hard to find.. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > (1) Assume the other main directories are containing files such as https://svnweb.freebsd.org/base/head/README?view=markup with information about their contents . (2) Assume directory : https://svnweb.freebsd.org/base/head/usr.sbin/pkg/ A small html file containing links to some related pages , such as : https://github.com/freebsd/pkg https://wiki.freebsd.org/pkgng http://jenkins.mouf.net/job/pkg/ With such files , related information will be connected to each other and traversing them will be very easy . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Mon Nov 10 09:30:30 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AE9B184; Mon, 10 Nov 2014 09:30:30 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F9F8750; Mon, 10 Nov 2014 09:30:30 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id im17so465395vcb.41 for ; Mon, 10 Nov 2014 01:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RTfCTeIcpIkN67rd52RVDCU/QbfGdmyV22ZFj+9h4jQ=; b=E8V6GfwXbQElZGTLKhpsedNtn6LxAZtT7hUuMqSsXlLitRYtibq9JB/r8YQYoBaSPN fxTDP1x/so5HrQaIrKuTuul+fOeYarJpGyzfYgAWOULsF70k5TLTjfksbsitMfAoD/03 ch+y0rUg5b4Z/DPfRwZ3neG62f7XNGuYhprjq/YFjt5NTeFnUgz0cMwxVNmYybB0gdtS K0tfsQjRnV3q72E6oOP/lC79Wn55dhl8B1yZGSi3K7EB4+w4W6t/ACr6K5Ja0nukK/To bilHIG87Y/7IgfLmh77nrktEV7DZqF37os4UBbV+bDCW2mDtKHkZCbPPkCrAkSqrumM2 LnVg== MIME-Version: 1.0 X-Received: by 10.52.9.37 with SMTP id w5mr1487067vda.38.1415611829334; Mon, 10 Nov 2014 01:30:29 -0800 (PST) Received: by 10.220.168.199 with HTTP; Mon, 10 Nov 2014 01:30:29 -0800 (PST) In-Reply-To: References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> Date: Mon, 10 Nov 2014 10:30:29 +0100 Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Nikolay Denev To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: "Bjoern A. Zeeb" , freebsd-arch , "freebsd-virtualization@freebsd.org" , FreeBSD Net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 09:30:30 -0000 On Mon, Nov 10, 2014 at 2:33 AM, Craig Rodrigues wrote: > On Sun, Oct 12, 2014 at 6:07 PM, Bjoern A. Zeeb < > bzeeb-lists@lists.zabbadoz.net> wrote: > >> >> >> > Can you provide a pointer to your Perforce branch? >> >> //depot/user/bz/vimage/src/... >> >> > Hi, > > Since I am more familiar with git than Perforce, I converted > your Perforce branch to git and put it on github: > > https://github.com/rodrigc/bz-vimage > > I took a look at the history of that branch, and it looks like you > merged quite a lot of changes in this branch back to FreeBSD. > There were a few places where it looks like the code in your branch > diverged from FreeBSD (in carp area, for example). > > Offhand, can you remember any VIMAGE related memory leaks > you might have fixed in this branch which you did not merge back? > > This one looks pretty simple by removing UMA_ZONE_NOFREE in a few > places: > > https://github.com/rodrigc/bz-vimage/commit/ebe7e4c5e7e5b3dbfc442a25f10ca8681c605c89 > > > In this one, you added dom_pr_register() and dom_pr_unregister() hooks: > > https://github.com/rodrigc/bz-vimage/commit/a1d5c8bc2f4484e58594ca8fad793aa339a5ef29 > > but I'm not sure if you wanted to merge this back to FreeBSD or not. > > Can you think of anything else in this branch that we need for VIMAGE? > > Thanks. > > -- > Craig > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" I haven't checked if this is fixed in CURRENT, but at least on 10.0-STABLE r270295M, gif(4) does not seem to play well with VIMAGE. I've just noticed that gif(4) interface unit numbers seem to be unique per machine, regardless of the vnet (I guess unit numbering not properly virtualized), so that if I create gif0 in one vnet jail and try the same in another vnet jail I get "ifconfig: SIOCIFCREATE2: File exists" What's even worse is that once the jail is destroyed, the gif(4) tunnel interface disappears from the system (no longer shows in ifconfig), but you can't reuse the unit number, so I continue to get SIOCIFCREATE2: File exists for gif0 on the host or other vnet jails. --Nikolay From owner-freebsd-arch@FreeBSD.ORG Mon Nov 10 14:14:34 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4E422F2; Mon, 10 Nov 2014 14:14:33 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB13098F; Mon, 10 Nov 2014 14:14:33 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sAAEEP7R053048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 10 Nov 2014 06:14:28 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5460C839.7060404@freebsd.org> Date: Mon, 10 Nov 2014 22:14:17 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nikolay Denev , Craig Rodrigues Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 14:14:34 -0000 On 11/10/14, 5:30 PM, Nikolay Denev wrote: > On Mon, Nov 10, 2014 at 2:33 AM, Craig Rodrigues wrote: >> On Sun, Oct 12, 2014 at 6:07 PM, Bjoern A. Zeeb < >> bzeeb-lists@lists.zabbadoz.net> wrote: >> >>> >>>> Can you provide a pointer to your Perforce branch? >>> //depot/user/bz/vimage/src/... >>> >>> >> Hi, >> >> Since I am more familiar with git than Perforce, I converted >> your Perforce branch to git and put it on github: >> >> https://github.com/rodrigc/bz-vimage >> >> I took a look at the history of that branch, and it looks like you >> merged quite a lot of changes in this branch back to FreeBSD. >> There were a few places where it looks like the code in your branch >> diverged from FreeBSD (in carp area, for example). >> >> Offhand, can you remember any VIMAGE related memory leaks >> you might have fixed in this branch which you did not merge back? >> >> This one looks pretty simple by removing UMA_ZONE_NOFREE in a few >> places: >> >> https://github.com/rodrigc/bz-vimage/commit/ebe7e4c5e7e5b3dbfc442a25f10ca8681c605c89 >> >> >> In this one, you added dom_pr_register() and dom_pr_unregister() hooks: >> >> https://github.com/rodrigc/bz-vimage/commit/a1d5c8bc2f4484e58594ca8fad793aa339a5ef29 >> >> but I'm not sure if you wanted to merge this back to FreeBSD or not. >> >> Can you think of anything else in this branch that we need for VIMAGE? >> >> Thanks. >> >> -- >> Craig >> _______________________________________________ >> freebsd-virtualization@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" > I haven't checked if this is fixed in CURRENT, but at least on > 10.0-STABLE r270295M, > gif(4) does not seem to play well with VIMAGE. > > I've just noticed that gif(4) interface unit numbers seem to be unique > per machine, regardless of the vnet (I guess unit numbering not > properly virtualized), > so that if I create gif0 in one vnet jail and try the same in another > vnet jail I get "ifconfig: SIOCIFCREATE2: File exists" > > What's even worse is that once the jail is destroyed, the gif(4) > tunnel interface disappears from the system (no longer shows in > ifconfig), but you can't reuse the unit number, so > I continue to get SIOCIFCREATE2: File exists for gif0 on the host or > other vnet jails. yes there are some parts of the system where the design is not compatible with virtualization. for example.. if a single /dev entry controls stuff.. which kind of complicates things.. > > --Nikolay > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 06:55:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 387A781C for ; Tue, 11 Nov 2014 06:55:02 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 071A0D1E for ; Tue, 11 Nov 2014 06:55:02 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id bj1so10019100pad.17 for ; Mon, 10 Nov 2014 22:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=Cd9rrLZVp5oYvdlFN935iRNZWOTm5NUO9/nGIf2YXZE=; b=RBFYLpACuFxCJ6Dko+jiAzZCoetZZBAxpRgBWxPOsEbls3ewuZscsXUaCmuoZZlUCi 5mxSJo88lvDDC85uTmxMQXZoU8Qp+m8ZOn6lethmn2BH9Z8EXvOo0Y0aTERGY2yI6EM0 v5T/hWio20THNlpDslM2dchjvq03XTyp4+vuW1LCcuOnHpwSI2T+OxgkIgUkFKVCTs67 U75w+lGzTKob6WXYIX0nwQGPwRsGOyW8SrkHlH9lGtZlbZkYm4gUF7r9q+QGRFKISl3g Rj4U9tj0ziHymNb3MHnM6uOakx18KBCZJIB/JFVvkByZCChcDK2LwN4CcfIL+8nQERoS xffA== X-Received: by 10.68.113.164 with SMTP id iz4mr9886991pbb.137.1415688901599; Mon, 10 Nov 2014 22:55:01 -0800 (PST) Received: from raichu ([198.244.104.6]) by mx.google.com with ESMTPSA id fv6sm18307078pdb.83.2014.11.10.22.55.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2014 22:55:00 -0800 (PST) Sender: Mark Johnston Date: Mon, 10 Nov 2014 22:54:51 -0800 From: Mark Johnston To: freebsd-arch@freebsd.org Subject: [RFC] core dump compression Message-ID: <20141111065451.GA9757@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 06:55:02 -0000 Hello, It's possible to have the kernel write out userland core dumps as gzip files, provided that the COMPRESS_USER_CORES option is present in the kernel. Currently this feature doesn't work properly because of some locking changes introduced in r272535. It's easy to fix this directly by adding IO_RANGELOCKED to the flags of the vn_rdwr_inchunks() calls in kern_gzio.c, but this approach seems somewhat hacky - kern_gzio.c is ostensibly a general-purpose interface (it's enabled by "device gzio" in the kernel config), so modifying the flags is wrong. I rewrote kern_gzio.c to provide a small callback-based interface to the in-kernel zlib, and changed the userland core dump code to use it. Together with this is a patch which optionally enables the kernel to compress its own core dumps as they're written out to the dump device. The idea is to make it more likely that we'll be able to fit a core on the dump device (which is often the swap partition for the system). The patches are available at: https://people.freebsd.org/~markj/patches/core-compression/20141110-kern_gzio.diff and https://people.freebsd.org/~markj/patches/core-compression/20141110-kern_dump.diff The first fixes userland core dump compression. It replaces the gzio device and COMPRESS_USER_CORES option with a GZIO option. When the kernel is compiled with this option, the kern.compress_user_cores sysctl determines whether userland core dumps will be compressed (defaulting to off). The second patch adds kern_dump.c, which provides a small interface for use by the MD kernel core dump code (i.e. dumpsys() and minidumpsys()). Its purpose is to hide the details of where the dump gets written on the dump device. Normally, dumpsys/minidumpsys computes the total size of the dump ahead of time, and writes it out so that the end of the dump coincides with the end of the device. With compression this isn't possible, since we can't know the final size ahead of time. The approach I've taken is to write the dump starting at the same offset an uncompressed dump would use. Once that's done, the headers are written to the beginning of the dump and the end of the device, and savecore(8) has been taught to detect compressed dumps and recover them. With the patch, kern_dump.c becomes responsible for writing the headers and for keeping track of the current offset within the dump; this lets us remove quite a bit of duplicated code from the various dumpsys/minidumpsys implementations without introducing any complexity in the !compressed case. For core dump compression, kern_dump.c uses the GZIO interface; the callback just calls dump_write() to write the compressed data to disk. With the second patch, kernel core dump compression is enabled using the kern.compress_kernel_dumps sysctl/tunable. At the moment it can only be set as a tunable, but I'll fix this soon. In practice, the compression factor that we get is between 6 and 14, with worse compression for larger cores. On the several amd64 systems that I've tested, the time required to actually write a core is increased slightly; on the other hand, a savecore(8) for a compressed dump is obviously much faster, so the boot following a crash will complete more quickly. The patches are still a bit rough, but I was hoping for some feedback on the approach and the new interfaces defined in kern_dump.c and kern_gzio.c. I've tested on a number of physical systems and VMs without any problems - further testing is very welcome, particularly on non-x86 systems. Thanks! -Mark From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 19:28:58 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B511322 for ; Tue, 11 Nov 2014 19:28:58 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 639B0FBD for ; Tue, 11 Nov 2014 19:28:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 39618B9A0; Tue, 11 Nov 2014 14:28:57 -0500 (EST) From: John Baldwin To: Mateusz Guzik Subject: Re: refcount_release_take_##lock Date: Tue, 11 Nov 2014 14:27:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141025184448.GA19066@dft-labs.eu> <201410281413.58414.jhb@freebsd.org> <20141028193404.GB12014@dft-labs.eu> In-Reply-To: <20141028193404.GB12014@dft-labs.eu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201411111427.15407.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Nov 2014 14:28:57 -0500 (EST) Cc: John-Mark Gurney , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:28:58 -0000 On Tuesday, October 28, 2014 3:34:04 pm Mateusz Guzik wrote: > On Tue, Oct 28, 2014 at 02:13:58PM -0400, John Baldwin wrote: > > On Tuesday, October 28, 2014 1:44:28 pm Mateusz Guzik wrote: > > > diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c > > > index f8ae0e6..e94ccde 100644 > > > --- a/sys/kern/kern_jail.c > > > +++ b/sys/kern/kern_jail.c > > > > The diff looks good to me. Just need to update refcount.9 as well. > > > > diff --git a/share/man/man9/refcount.9 b/share/man/man9/refcount.9 > index e7702a2..61b9b51 100644 FYI, it's often easier to review manpage changes if a rendered version is included. > --- a/share/man/man9/refcount.9 > +++ b/share/man/man9/refcount.9 > @@ -26,7 +26,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd January 20, 2009 > +.Dd October 28, 2014 > .Dt REFCOUNT 9 > .Os > .Sh NAME Need to add the new functions to the .Nm list > @@ -44,6 +44,15 @@ > .Fn refcount_acquire "volatile u_int *count" > .Ft int > .Fn refcount_release "volatile u_int *count" > +.In sys/mutex.h > +.Fn refcount_release_lock_mtx "volatile u_int *count, struct mtx *lock" > +.In sys/rmlock.h > +.Fn refcount_release_lock_rmlock "volatile u_int *count, struct rmlock *lock" > +.In sys/rwlock.h > +.Fn refcount_release_lock_rwlock "volatile u_int *count, struct rwlock *lock" > +.In sys/lock.h > +.In sys/sx.h > +.Fn refcount_release_lock_sx "volatile u_int *count, struct sx *lock" Hmm, should also be required for the other three and not just sx? > .Sh DESCRIPTION > The > .Nm > @@ -77,6 +86,13 @@ The function returns a non-zero value if the reference being released was > the last reference; > otherwise, it returns zero. > .Pp > +.Fn refcount_release_lock_* Even though it is tedious, most manpages tend to spell out the list of functions (e.g. I did so in callout recently with all the callout_init_*() variants, etc.). I believe I broke this rule in atomic(9), but I think if the list of functions isn't too unreasonable, it's better to explicitly list them (and I think 4 functions isn't unreasonable). > +functions release an existing reference holding the lock if it is the last Perhaps: functions release an existing reference similar to .Fn refcount_release . If the reference being released is the last reference, the .Fa lock is exclusively acquired before the reference is dropped and remains held when the function returns. These functions return a non-zero value if the reference being released was the last reference; otherwise, they return zero. > @@ -91,6 +107,18 @@ The > .Nm refcount_release > function returns non-zero when releasing the last reference and zero when > releasing any other reference. > +.Pp > +.Nm refcount_release_lock_* > +functions return with the lock held and non-zero value when releasing the last > +reference, zero without the lock held when releasing any other reference. This this is just about return values, I would instead just update the previous sentence to add the additional functions. I.e.: The .Fn refcount_release , # this is probably my fault, should be Fn .Fn refcount_release_lock_mtx , ... and .Fn refcount_release_lock sx functions return non-zero ... > .Sh HISTORY > -These functions were introduced in The .Fn refcount_init , ... > +.Fn refcount_init , > +.Fn refcount_acquire > +and > +.Fn refcount_release > +functions were introduced in > .Fx 6.0 . > +.Pp > +.Fn refcount_release_lock_* > +functions were introduced in > +.Fx 10.2 . .Pp The .Fn refcount_release_lock_mtx , .Fn refcount_release_lock_rmlock , ... -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 13:25:11 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BA012FD; Wed, 12 Nov 2014 13:25:11 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62244F29; Wed, 12 Nov 2014 13:25:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sACDOqIS008619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 15:24:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sACDOqIS008619 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sACDOq5H008618; Wed, 12 Nov 2014 15:24:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 12 Nov 2014 15:24:52 +0200 From: Konstantin Belousov To: arch@freebsd.org, fs@freebsd.org Subject: Removal of kern_xxx() no-at variants. Message-ID: <20141112132451.GM17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 13:25:11 -0000 We have 'fat' KPI for kern_open() and other vfs syscall helpers, after the at-version of the syscalls was added somewhere at 8-CURRENT. For instance, we provide kern_open() and kern_openat(). But more, we provide kern_stat() kern_lstat() kern_statat() kern_statat_vhook() first three being a trivial wrapper around kern_statat_vhook(). More, existence of two or (sometimes) three layers around basic syscall helper causes issues like r271655 making the argument validation split. Kepping the compat layer was reasonable in 8-CURRENT time when the at variants were experimental and patch to add the syscalls was already large and error-prone. Now, I think we should shave the extra call indirections, it costs nothing at callers and sometimes even improves the code. diff --git a/sys/cddl/compat/opensolaris/sys/vnode.h b/sys/cddl/compat/opensolaris/sys/vnode.h index 4e5b1c9..22256cf 100644 --- a/sys/cddl/compat/opensolaris/sys/vnode.h +++ b/sys/cddl/compat/opensolaris/sys/vnode.h @@ -282,7 +282,7 @@ vn_rename(char *from, char *to, enum uio_seg seg) ASSERT(seg == UIO_SYSSPACE); - return (kern_rename(curthread, from, to, seg)); + return (kern_renameat(curthread, AT_FDCWD, from, AT_FDCWD, to, seg)); } static __inline int @@ -292,7 +292,7 @@ vn_remove(char *fnamep, enum uio_seg seg, enum rm dirflag) ASSERT(seg == UIO_SYSSPACE); ASSERT(dirflag == RMFILE); - return (kern_unlink(curthread, fnamep, seg)); + return (kern_unlinkat(curthread, AT_FDCWD, fnamep, seg, 0)); } #endif /* _KERNEL */ diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/freebsd32_misc.c index 5ea062e..9323138 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -1235,7 +1235,8 @@ freebsd32_utimes(struct thread *td, struct freebsd32_utimes_args *uap) sp = s; } else sp = NULL; - return (kern_utimes(td, uap->path, UIO_USERSPACE, sp, UIO_SYSSPACE)); + return (kern_utimesat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + sp, UIO_SYSSPACE)); } int @@ -1723,7 +1724,8 @@ freebsd32_stat(struct thread *td, struct freebsd32_stat_args *uap) struct stat32 sb32; int error; - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, + &sb, NULL); if (error) return (error); copy_stat(&sb, &sb32); @@ -1739,7 +1741,8 @@ ofreebsd32_stat(struct thread *td, struct ofreebsd32_stat_args *uap) struct ostat32 sb32; int error; - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, + &sb, NULL); if (error) return (error); copy_ostat(&sb, &sb32); @@ -1787,7 +1790,8 @@ freebsd32_fstatat(struct thread *td, struct freebsd32_fstatat_args *uap) struct stat32 ub32; int error; - error = kern_statat(td, uap->flag, uap->fd, uap->path, UIO_USERSPACE, &ub); + error = kern_statat(td, uap->flag, uap->fd, uap->path, UIO_USERSPACE, + &ub, NULL); if (error) return (error); copy_stat(&ub, &ub32); @@ -1802,7 +1806,8 @@ freebsd32_lstat(struct thread *td, struct freebsd32_lstat_args *uap) struct stat32 sb32; int error; - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, + UIO_USERSPACE, &sb, NULL); if (error) return (error); copy_stat(&sb, &sb32); @@ -1818,7 +1823,8 @@ ofreebsd32_lstat(struct thread *td, struct ofreebsd32_lstat_args *uap) struct ostat32 sb32; int error; - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, + UIO_USERSPACE, &sb, NULL); if (error) return (error); copy_ostat(&sb, &sb32); diff --git a/sys/compat/linux/linux_file.c b/sys/compat/linux/linux_file.c index e56e61f..88303b9 100644 --- a/sys/compat/linux/linux_file.c +++ b/sys/compat/linux/linux_file.c @@ -82,8 +82,8 @@ linux_creat(struct thread *td, struct linux_creat_args *args) if (ldebug(creat)) printf(ARGS(creat, "%s, %d"), path, args->mode); #endif - error = kern_open(td, path, UIO_SYSSPACE, O_WRONLY | O_CREAT | O_TRUNC, - args->mode); + error = kern_openat(td, AT_FDCWD, path, UIO_SYSSPACE, + O_WRONLY | O_CREAT | O_TRUNC, args->mode); LFREEPATH(path); return (error); } @@ -572,7 +572,8 @@ linux_access(struct thread *td, struct linux_access_args *args) if (ldebug(access)) printf(ARGS(access, "%s, %d"), path, args->amode); #endif - error = kern_access(td, path, UIO_SYSSPACE, args->amode); + error = kern_accessat(td, AT_FDCWD, path, UIO_SYSSPACE, 0, + args->amode); LFREEPATH(path); return (error); @@ -619,12 +620,15 @@ linux_unlink(struct thread *td, struct linux_unlink_args *args) printf(ARGS(unlink, "%s"), path); #endif - error = kern_unlink(td, path, UIO_SYSSPACE); - if (error == EPERM) + error = kern_unlinkat(td, AT_FDCWD, path, UIO_SYSSPACE, 0); + if (error == EPERM) { /* Introduce POSIX noncompliant behaviour of Linux */ - if (kern_stat(td, path, UIO_SYSSPACE, &st) == 0) + if (kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, + NULL) == 0) { if (S_ISDIR(st.st_mode)) error = EISDIR; + } + } LFREEPATH(path); return (error); } @@ -654,7 +658,7 @@ linux_unlinkat(struct thread *td, struct linux_unlinkat_args *args) if (error == EPERM && !(args->flag & LINUX_AT_REMOVEDIR)) { /* Introduce POSIX noncompliant behaviour of Linux */ if (kern_statat(td, AT_SYMLINK_NOFOLLOW, dfd, path, - UIO_SYSSPACE, &st) == 0 && S_ISDIR(st.st_mode)) + UIO_SYSSPACE, &st, NULL) == 0 && S_ISDIR(st.st_mode)) error = EISDIR; } LFREEPATH(path); @@ -689,7 +693,8 @@ linux_chmod(struct thread *td, struct linux_chmod_args *args) if (ldebug(chmod)) printf(ARGS(chmod, "%s, %d"), path, args->mode); #endif - error = kern_chmod(td, path, UIO_SYSSPACE, args->mode); + error = kern_fchmodat(td, AT_FDCWD, path, UIO_SYSSPACE, + args->mode, 0); LFREEPATH(path); return (error); } @@ -725,7 +730,7 @@ linux_mkdir(struct thread *td, struct linux_mkdir_args *args) if (ldebug(mkdir)) printf(ARGS(mkdir, "%s, %d"), path, args->mode); #endif - error = kern_mkdir(td, path, UIO_SYSSPACE, args->mode); + error = kern_mkdirat(td, AT_FDCWD, path, UIO_SYSSPACE, args->mode); LFREEPATH(path); return (error); } @@ -760,7 +765,7 @@ linux_rmdir(struct thread *td, struct linux_rmdir_args *args) if (ldebug(rmdir)) printf(ARGS(rmdir, "%s"), path); #endif - error = kern_rmdir(td, path, UIO_SYSSPACE); + error = kern_rmdirat(td, AT_FDCWD, path, UIO_SYSSPACE); LFREEPATH(path); return (error); } @@ -783,7 +788,7 @@ linux_rename(struct thread *td, struct linux_rename_args *args) if (ldebug(rename)) printf(ARGS(rename, "%s, %s"), from, to); #endif - error = kern_rename(td, from, to, UIO_SYSSPACE); + error = kern_renameat(td, AT_FDCWD, from, AT_FDCWD, to, UIO_SYSSPACE); LFREEPATH(from); LFREEPATH(to); return (error); @@ -833,7 +838,7 @@ linux_symlink(struct thread *td, struct linux_symlink_args *args) if (ldebug(symlink)) printf(ARGS(symlink, "%s, %s"), path, to); #endif - error = kern_symlink(td, path, to, UIO_SYSSPACE); + error = kern_symlinkat(td, path, AT_FDCWD, to, UIO_SYSSPACE); LFREEPATH(path); LFREEPATH(to); return (error); @@ -878,8 +883,8 @@ linux_readlink(struct thread *td, struct linux_readlink_args *args) printf(ARGS(readlink, "%s, %p, %d"), name, (void *)args->buf, args->count); #endif - error = kern_readlink(td, name, UIO_SYSSPACE, args->buf, UIO_USERSPACE, - args->count); + error = kern_readlinkat(td, AT_FDCWD, name, UIO_SYSSPACE, + args->buf, UIO_USERSPACE, args->count); LFREEPATH(name); return (error); } @@ -972,7 +977,8 @@ linux_link(struct thread *td, struct linux_link_args *args) if (ldebug(link)) printf(ARGS(link, "%s, %s"), path, to); #endif - error = kern_link(td, path, to, UIO_SYSSPACE); + error = kern_linkat(td, AT_FDCWD, AT_FDCWD, path, to, UIO_SYSSPACE, + FOLLOW); LFREEPATH(path); LFREEPATH(to); return (error); @@ -1487,7 +1493,8 @@ linux_chown(struct thread *td, struct linux_chown_args *args) if (ldebug(chown)) printf(ARGS(chown, "%s, %d, %d"), path, args->uid, args->gid); #endif - error = kern_chown(td, path, UIO_SYSSPACE, args->uid, args->gid); + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, args->uid, + args->gid, 0); LFREEPATH(path); return (error); } @@ -1529,7 +1536,8 @@ linux_lchown(struct thread *td, struct linux_lchown_args *args) if (ldebug(lchown)) printf(ARGS(lchown, "%s, %d, %d"), path, args->uid, args->gid); #endif - error = kern_lchown(td, path, UIO_SYSSPACE, args->uid, args->gid); + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, args->uid, + args->gid, AT_SYMLINK_NOFOLLOW); LFREEPATH(path); return (error); } diff --git a/sys/compat/linux/linux_misc.c b/sys/compat/linux/linux_misc.c index ff5e8a2..4433e18 100644 --- a/sys/compat/linux/linux_misc.c +++ b/sys/compat/linux/linux_misc.c @@ -777,7 +777,8 @@ linux_utime(struct thread *td, struct linux_utime_args *args) } else tvp = NULL; - error = kern_utimes(td, fname, UIO_SYSSPACE, tvp, UIO_SYSSPACE); + error = kern_utimesat(td, AT_FDCWD, fname, UIO_SYSSPACE, tvp, + UIO_SYSSPACE); LFREEPATH(fname); return (error); } @@ -809,7 +810,8 @@ linux_utimes(struct thread *td, struct linux_utimes_args *args) tvp = tv; } - error = kern_utimes(td, fname, UIO_SYSSPACE, tvp, UIO_SYSSPACE); + error = kern_utimesat(td, AT_FDCWD, fname, UIO_SYSSPACE, + tvp, UIO_SYSSPACE); LFREEPATH(fname); return (error); } @@ -914,13 +916,14 @@ linux_mknod(struct thread *td, struct linux_mknod_args *args) switch (args->mode & S_IFMT) { case S_IFIFO: case S_IFSOCK: - error = kern_mkfifo(td, path, UIO_SYSSPACE, args->mode); + error = kern_mkfifoat(td, AT_FDCWD, path, UIO_SYSSPACE, + args->mode); break; case S_IFCHR: case S_IFBLK: - error = kern_mknod(td, path, UIO_SYSSPACE, args->mode, - args->dev); + error = kern_mknodat(td, AT_FDCWD, path, UIO_SYSSPACE, + args->mode, args->dev); break; case S_IFDIR: @@ -931,7 +934,7 @@ linux_mknod(struct thread *td, struct linux_mknod_args *args) args->mode |= S_IFREG; /* FALLTHROUGH */ case S_IFREG: - error = kern_open(td, path, UIO_SYSSPACE, + error = kern_openat(td, AT_FDCWD, path, UIO_SYSSPACE, O_WRONLY | O_CREAT | O_TRUNC, args->mode); if (error == 0) kern_close(td, td->td_retval[0]); diff --git a/sys/compat/linux/linux_socket.c b/sys/compat/linux/linux_socket.c index 43b255d..61b786f 100644 --- a/sys/compat/linux/linux_socket.c +++ b/sys/compat/linux/linux_socket.c @@ -731,7 +731,7 @@ linux_bind(struct thread *td, struct linux_bind_args *args) if (error) return (error); - error = kern_bind(td, args->s, sa); + error = kern_bindat(td, AT_FDCWD, args->s, sa); free(sa, M_SONAME); if (error == EADDRNOTAVAIL && args->namelen != sizeof(struct sockaddr_in)) return (EINVAL); @@ -759,7 +759,7 @@ linux_connect(struct thread *td, struct linux_connect_args *args) if (error) return (error); - error = kern_connect(td, args->s, sa); + error = kern_connectat(td, AT_FDCWD, args->s, sa); free(sa, M_SONAME); if (error != EISCONN) return (error); diff --git a/sys/compat/linux/linux_stats.c b/sys/compat/linux/linux_stats.c index 2e05c85..b6dd86d 100644 --- a/sys/compat/linux/linux_stats.c +++ b/sys/compat/linux/linux_stats.c @@ -77,7 +77,7 @@ linux_kern_statat(struct thread *td, int flag, int fd, char *path, enum uio_seg pathseg, struct stat *sbp) { - return (kern_statat_vnhook(td, flag, fd, path, pathseg, sbp, + return (kern_statat(td, flag, fd, path, pathseg, sbp, translate_vnhook_major_minor)); } diff --git a/sys/compat/linux/linux_uid16.c b/sys/compat/linux/linux_uid16.c index c5bf2dd..61f3030 100644 --- a/sys/compat/linux/linux_uid16.c +++ b/sys/compat/linux/linux_uid16.c @@ -121,8 +121,8 @@ linux_chown16(struct thread *td, struct linux_chown16_args *args) args->gid); LIN_SDT_PROBE1(uid16, linux_chown16, conv_path, path); - error = kern_chown(td, path, UIO_SYSSPACE, CAST_NOCHG(args->uid), - CAST_NOCHG(args->gid)); + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, + CAST_NOCHG(args->uid), CAST_NOCHG(args->gid), 0); LFREEPATH(path); LIN_SDT_PROBE1(uid16, linux_chown16, return, error); @@ -146,8 +146,8 @@ linux_lchown16(struct thread *td, struct linux_lchown16_args *args) args->gid); LIN_SDT_PROBE1(uid16, linux_lchown16, conv_path, path); - error = kern_lchown(td, path, UIO_SYSSPACE, CAST_NOCHG(args->uid), - CAST_NOCHG(args->gid)); + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, + CAST_NOCHG(args->uid), CAST_NOCHG(args->gid), AT_SYMLINK_NOFOLLOW); LFREEPATH(path); LIN_SDT_PROBE1(uid16, linux_lchown16, return, error); diff --git a/sys/compat/svr4/svr4_fcntl.c b/sys/compat/svr4/svr4_fcntl.c index c604675..edcfcc107 100644 --- a/sys/compat/svr4/svr4_fcntl.c +++ b/sys/compat/svr4/svr4_fcntl.c @@ -390,7 +390,8 @@ svr4_sys_open(td, uap) CHECKALTEXIST(td, uap->path, &newpath); bsd_flags = svr4_to_bsd_flags(uap->flags); - error = kern_open(td, newpath, UIO_SYSSPACE, bsd_flags, uap->mode); + error = kern_openat(td, AT_FDCWD, newpath, UIO_SYSSPACE, bsd_flags, + uap->mode); free(newpath, M_TEMP); if (error) { @@ -450,8 +451,8 @@ svr4_sys_creat(td, uap) CHECKALTEXIST(td, uap->path, &newpath); - error = kern_open(td, newpath, UIO_SYSSPACE, O_WRONLY | O_CREAT | - O_TRUNC, uap->mode); + error = kern_openat(td, AT_FDCWD, newpath, UIO_SYSSPACE, + O_WRONLY | O_CREAT | O_TRUNC, uap->mode); free(newpath, M_TEMP); return (error); } @@ -494,7 +495,8 @@ svr4_sys_access(td, uap) int error; CHECKALTEXIST(td, uap->path, &newpath); - error = kern_access(td, newpath, UIO_SYSSPACE, uap->amode); + error = kern_accessat(td, AT_FDCWD, newpath, UIO_SYSSPACE, + 0, uap->amode); free(newpath, M_TEMP); return (error); } diff --git a/sys/compat/svr4/svr4_misc.c b/sys/compat/svr4/svr4_misc.c index 0db5453..9e9b020 100644 --- a/sys/compat/svr4/svr4_misc.c +++ b/sys/compat/svr4/svr4_misc.c @@ -653,10 +653,13 @@ svr4_mknod(td, retval, path, mode, dev) CHECKALTEXIST(td, path, &newpath); - if (S_ISFIFO(mode)) - error = kern_mkfifo(td, newpath, UIO_SYSSPACE, mode); - else - error = kern_mknod(td, newpath, UIO_SYSSPACE, mode, dev); + if (S_ISFIFO(mode)) { + error = kern_mkfifoat(td, AT_FDCWD, newpath, UIO_SYSSPACE, + mode); + } else { + error = kern_mknodat(td, AT_FDCWD, newpath, UIO_SYSSPACE, + mode, dev); + } free(newpath, M_TEMP); return (error); } diff --git a/sys/compat/svr4/svr4_stat.c b/sys/compat/svr4/svr4_stat.c index b686642..6ed9873 100644 --- a/sys/compat/svr4/svr4_stat.c +++ b/sys/compat/svr4/svr4_stat.c @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -170,7 +171,7 @@ svr4_sys_stat(td, uap) CHECKALTEXIST(td, uap->path, &path); - error = kern_stat(td, path, UIO_SYSSPACE, &st); + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, NULL); free(path, M_TEMP); if (error) return (error); @@ -195,7 +196,8 @@ svr4_sys_lstat(td, uap) CHECKALTEXIST(td, uap->path, &path); - error = kern_lstat(td, path, UIO_SYSSPACE, &st); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, + UIO_SYSSPACE, &st, NULL); free(path, M_TEMP); if (error) return (error); @@ -238,7 +240,7 @@ svr4_sys_xstat(td, uap) CHECKALTEXIST(td, uap->path, &path); - error = kern_stat(td, path, UIO_SYSSPACE, &st); + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, NULL); free(path, M_TEMP); if (error) return (error); @@ -265,7 +267,8 @@ svr4_sys_lxstat(td, uap) CHECKALTEXIST(td, uap->path, &path); - error = kern_lstat(td, path, UIO_SYSSPACE, &st); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, + UIO_SYSSPACE, &st, NULL); free(path, M_TEMP); if (error) return (error); @@ -309,7 +312,7 @@ svr4_sys_stat64(td, uap) CHECKALTEXIST(td, uap->path, &path); - error = kern_stat(td, path, UIO_SYSSPACE, &st); + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, NULL); free(path, M_TEMP); if (error) return (error); @@ -335,7 +338,8 @@ svr4_sys_lstat64(td, uap) CHECKALTEXIST(td, uap->path, &path); - error = kern_lstat(td, path, UIO_SYSSPACE, &st); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, + UIO_SYSSPACE, &st, NULL); free(path, M_TEMP); if (error) return (error); @@ -582,7 +586,8 @@ svr4_sys_utime(td, uap) tp = NULL; CHECKALTEXIST(td, uap->path, &path); - error = kern_utimes(td, path, UIO_SYSSPACE, tp, UIO_SYSSPACE); + error = kern_utimesat(td, AT_FDCWD, path, UIO_SYSSPACE, + tp, UIO_SYSSPACE); free(path, M_TEMP); return (error); } @@ -597,7 +602,8 @@ svr4_sys_utimes(td, uap) int error; CHECKALTEXIST(td, uap->path, &path); - error = kern_utimes(td, path, UIO_SYSSPACE, uap->tptr, UIO_USERSPACE); + error = kern_utimesat(td, AT_FDCWD, path, UIO_SYSSPACE, + uap->tptr, UIO_USERSPACE); free(path, M_TEMP); return (error); } diff --git a/sys/compat/svr4/svr4_stream.c b/sys/compat/svr4/svr4_stream.c index 91c393f..d287d5d 100644 --- a/sys/compat/svr4/svr4_stream.c +++ b/sys/compat/svr4/svr4_stream.c @@ -282,7 +282,8 @@ clean_pipe(td, path) struct stat st; int error; - error = kern_lstat(td, path, UIO_SYSSPACE, &st); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, + UIO_SYSSPACE, &st, NULL); /* * Make sure we are dealing with a mode 0 named pipe. @@ -293,7 +294,7 @@ clean_pipe(td, path) if ((st.st_mode & ALLPERMS) != 0) return (0); - error = kern_unlink(td, path, UIO_SYSSPACE); + error = kern_unlinkat(td, AT_FDCWD, path, UIO_SYSSPACE, 0); if (error) DPRINTF(("clean_pipe: unlink failed %d\n", error)); return (error); @@ -812,7 +813,7 @@ ti_bind(fp, fd, ioc, td) DPRINTF(("TI_BIND: fileno %d\n", fd)); - if ((error = kern_bind(td, fd, skp)) != 0) { + if ((error = kern_bindat(td, AT_FDCWD, fd, skp)) != 0) { DPRINTF(("TI_BIND: bind failed %d\n", error)); return error; } @@ -1586,7 +1587,7 @@ svr4_do_putmsg(td, uap, fp) case SVR4_TI_CONNECT_REQUEST: /* connect */ { - return (kern_connect(td, uap->fd, sa)); + return (kern_connectat(td, AT_FDCWD, uap->fd, sa)); } case SVR4_TI_SENDTO_REQUEST: /* sendto */ diff --git a/sys/dev/streams/streams.c b/sys/dev/streams/streams.c index 42265a4..6a9219e 100644 --- a/sys/dev/streams/streams.c +++ b/sys/dev/streams/streams.c @@ -302,7 +302,8 @@ svr4_ptm_alloc(td) ptyname[8] = ttyletters[l]; ptyname[9] = ttynumbers[n]; - error = kern_open(td, ptyname, UIO_SYSSPACE, O_RDWR, 0); + error = kern_openat(td, AT_FDCWD, ptyname, UIO_SYSSPACE, + O_RDWR, 0); switch (error) { case ENOENT: case ENXIO: diff --git a/sys/i386/ibcs2/ibcs2_fcntl.c b/sys/i386/ibcs2/ibcs2_fcntl.c index d2489df..5d06d4d 100644 --- a/sys/i386/ibcs2/ibcs2_fcntl.c +++ b/sys/i386/ibcs2/ibcs2_fcntl.c @@ -189,7 +189,7 @@ ibcs2_open(td, uap) CHECKALTCREAT(td, uap->path, &path); else CHECKALTEXIST(td, uap->path, &path); - ret = kern_open(td, path, UIO_SYSSPACE, flags, uap->mode); + ret = kern_openat(td, AT_FDCWD, path, UIO_SYSSPACE, flags, uap->mode); #ifdef SPX_HACK if (ret == ENXIO) { @@ -230,8 +230,8 @@ ibcs2_creat(td, uap) int error; CHECKALTCREAT(td, uap->path, &path); - error = kern_open(td, path, UIO_SYSSPACE, O_WRONLY | O_CREAT | O_TRUNC, - uap->mode); + error = kern_openat(td, AT_FDCWD, path, UIO_SYSSPACE, + O_WRONLY | O_CREAT | O_TRUNC, uap->mode); free(path, M_TEMP); return (error); } @@ -245,7 +245,7 @@ ibcs2_access(td, uap) int error; CHECKALTEXIST(td, uap->path, &path); - error = kern_access(td, path, UIO_SYSSPACE, uap->amode); + error = kern_accessat(td, AT_FDCWD, path, UIO_SYSSPACE, 0, uap->amode); free(path, M_TEMP); return (error); } diff --git a/sys/i386/ibcs2/ibcs2_misc.c b/sys/i386/ibcs2/ibcs2_misc.c index 42bc4b7..d81cfee 100644 --- a/sys/i386/ibcs2/ibcs2_misc.c +++ b/sys/i386/ibcs2/ibcs2_misc.c @@ -646,10 +646,13 @@ ibcs2_mknod(td, uap) int error; CHECKALTCREAT(td, uap->path, &path); - if (S_ISFIFO(uap->mode)) - error = kern_mkfifo(td, path, UIO_SYSSPACE, uap->mode); - else - error = kern_mknod(td, path, UIO_SYSSPACE, uap->mode, uap->dev); + if (S_ISFIFO(uap->mode)) { + error = kern_mkfifoat(td, AT_FDCWD, path, + UIO_SYSSPACE, uap->mode); + } else { + error = kern_mknodat(td, AT_FDCWD, path, UIO_SYSSPACE, + uap->mode, uap->dev); + } free(path, M_TEMP); return (error); } @@ -938,7 +941,8 @@ ibcs2_utime(td, uap) tp = NULL; CHECKALTEXIST(td, uap->path, &path); - error = kern_utimes(td, path, UIO_SYSSPACE, tp, UIO_SYSSPACE); + error = kern_utimesat(td, AT_FDCWD, path, UIO_SYSSPACE, + tp, UIO_SYSSPACE); free(path, M_TEMP); return (error); } @@ -1119,7 +1123,7 @@ ibcs2_unlink(td, uap) int error; CHECKALTEXIST(td, uap->path, &path); - error = kern_unlink(td, path, UIO_SYSSPACE); + error = kern_unlinkat(td, AT_FDCWD, path, UIO_SYSSPACE, 0); free(path, M_TEMP); return (error); } @@ -1147,7 +1151,7 @@ ibcs2_chmod(td, uap) int error; CHECKALTEXIST(td, uap->path, &path); - error = kern_chmod(td, path, UIO_SYSSPACE, uap->mode); + error = kern_fchmodat(td, AT_FDCWD, path, UIO_SYSSPACE, uap->mode, 0); free(path, M_TEMP); return (error); } @@ -1161,7 +1165,8 @@ ibcs2_chown(td, uap) int error; CHECKALTEXIST(td, uap->path, &path); - error = kern_chown(td, path, UIO_SYSSPACE, uap->uid, uap->gid); + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, uap->uid, + uap->gid, 0); free(path, M_TEMP); return (error); } @@ -1175,7 +1180,7 @@ ibcs2_rmdir(td, uap) int error; CHECKALTEXIST(td, uap->path, &path); - error = kern_rmdir(td, path, UIO_SYSSPACE); + error = kern_rmdirat(td, AT_FDCWD, path, UIO_SYSSPACE); free(path, M_TEMP); return (error); } @@ -1189,7 +1194,7 @@ ibcs2_mkdir(td, uap) int error; CHECKALTEXIST(td, uap->path, &path); - error = kern_mkdir(td, path, UIO_SYSSPACE, uap->mode); + error = kern_mkdirat(td, AT_FDCWD, path, UIO_SYSSPACE, uap->mode); free(path, M_TEMP); return (error); } @@ -1213,7 +1218,7 @@ ibcs2_symlink(td, uap) free(path, M_TEMP); return (error); } - error = kern_symlink(td, path, link, UIO_SYSSPACE); + error = kern_symlinkat(td, path, AT_FDCWD, link, UIO_SYSSPACE); free(path, M_TEMP); free(link, M_TEMP); return (error); @@ -1238,7 +1243,7 @@ ibcs2_rename(td, uap) free(from, M_TEMP); return (error); } - error = kern_rename(td, from, to, UIO_SYSSPACE); + error = kern_renameat(td, AT_FDCWD, from, AT_FDCWD, to, UIO_SYSSPACE); free(from, M_TEMP); free(to, M_TEMP); return (error); @@ -1253,8 +1258,8 @@ ibcs2_readlink(td, uap) int error; CHECKALTEXIST(td, uap->path, &path); - error = kern_readlink(td, path, UIO_SYSSPACE, uap->buf, UIO_USERSPACE, - uap->count); + error = kern_readlinkat(td, AT_FDCWD, path, UIO_SYSSPACE, + uap->buf, UIO_USERSPACE, uap->count); free(path, M_TEMP); return (error); } diff --git a/sys/i386/ibcs2/ibcs2_other.c b/sys/i386/ibcs2/ibcs2_other.c index f688661..b49e605 100644 --- a/sys/i386/ibcs2/ibcs2_other.c +++ b/sys/i386/ibcs2/ibcs2_other.c @@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include #include @@ -107,7 +108,7 @@ spx_open(struct thread *td) sun.sun_len = sizeof(struct sockaddr_un) - sizeof(sun.sun_path) + strlen(sun.sun_path) + 1; - error = kern_connect(td, fd, (struct sockaddr *)&sun); + error = kern_connectat(td, AT_FDCWD, fd, (struct sockaddr *)&sun); if (error) { kern_close(td, fd); return error; diff --git a/sys/i386/ibcs2/ibcs2_stat.c b/sys/i386/ibcs2/ibcs2_stat.c index c1097a3..55d14af 100644 --- a/sys/i386/ibcs2/ibcs2_stat.c +++ b/sys/i386/ibcs2/ibcs2_stat.c @@ -32,6 +32,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -145,7 +146,7 @@ ibcs2_stat(td, uap) CHECKALTEXIST(td, uap->path, &path); - error = kern_stat(td, path, UIO_SYSSPACE, &st); + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, NULL); free(path, M_TEMP); if (error) return (error); @@ -166,7 +167,8 @@ ibcs2_lstat(td, uap) CHECKALTEXIST(td, uap->path, &path); - error = kern_lstat(td, path, UIO_SYSSPACE, &st); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, + UIO_SYSSPACE, &st, NULL); free(path, M_TEMP); if (error) return (error); diff --git a/sys/i386/ibcs2/ibcs2_xenix.c b/sys/i386/ibcs2/ibcs2_xenix.c index c5416fb..829f6ab 100644 --- a/sys/i386/ibcs2/ibcs2_xenix.c +++ b/sys/i386/ibcs2/ibcs2_xenix.c @@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include #include @@ -209,7 +210,8 @@ xenix_eaccess(struct thread *td, struct xenix_eaccess_args *uap) bsd_flags |= X_OK; CHECKALTEXIST(td, uap->path, &path); - error = kern_eaccess(td, path, UIO_SYSSPACE, bsd_flags); + error = kern_accessat(td, AT_FDCWD, path, UIO_SYSSPACE, + AT_EACCESS, bsd_flags); free(path, M_TEMP); return (error); } diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 32c837c..7f88a6c 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -2215,8 +2215,8 @@ fdcheckstd(struct thread *td) if (devnull != -1) { error = do_dup(td, DUP_FIXED, devnull, i); } else { - error = kern_open(td, "/dev/null", UIO_SYSSPACE, - O_RDWR, 0); + error = kern_openat(td, AT_FDCWD, "/dev/null", + UIO_SYSSPACE, O_RDWR, 0); if (error == 0) { devnull = td->td_retval[0]; KASSERT(devnull == i, ("we didn't get our fd")); diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c index 6d423ba..24a4436 100644 --- a/sys/kern/uipc_syscalls.c +++ b/sys/kern/uipc_syscalls.c @@ -283,13 +283,13 @@ sys_bind(td, uap) error = getsockaddr(&sa, uap->name, uap->namelen); if (error == 0) { - error = kern_bind(td, uap->s, sa); + error = kern_bindat(td, AT_FDCWD, uap->s, sa); free(sa, M_SONAME); } return (error); } -static int +int kern_bindat(struct thread *td, int dirfd, int fd, struct sockaddr *sa) { struct socket *so; @@ -323,13 +323,6 @@ kern_bindat(struct thread *td, int dirfd, int fd, struct sockaddr *sa) return (error); } -int -kern_bind(struct thread *td, int fd, struct sockaddr *sa) -{ - - return (kern_bindat(td, AT_FDCWD, fd, sa)); -} - /* ARGSUSED */ int sys_bindat(td, uap) @@ -636,13 +629,13 @@ sys_connect(td, uap) error = getsockaddr(&sa, uap->name, uap->namelen); if (error == 0) { - error = kern_connect(td, uap->s, sa); + error = kern_connectat(td, AT_FDCWD, uap->s, sa); free(sa, M_SONAME); } return (error); } -static int +int kern_connectat(struct thread *td, int dirfd, int fd, struct sockaddr *sa) { struct socket *so; @@ -705,13 +698,6 @@ done1: return (error); } -int -kern_connect(struct thread *td, int fd, struct sockaddr *sa) -{ - - return (kern_connectat(td, AT_FDCWD, fd, sa)); -} - /* ARGSUSED */ int sys_connectat(td, uap) diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c index 2816e1b..a050099 100644 --- a/sys/kern/vfs_mountroot.c +++ b/sys/kern/vfs_mountroot.c @@ -238,7 +238,7 @@ vfs_mountroot_devfs(struct thread *td, struct mount **mpp) *mpp = mp; set_rootvnode(); - error = kern_symlink(td, "/", "dev", UIO_SYSSPACE); + error = kern_symlinkat(td, "/", AT_FDCWD, "dev", UIO_SYSSPACE); if (error) printf("kern_symlink /dev -> / returns %d\n", error); @@ -350,7 +350,8 @@ vfs_mountroot_shuffle(struct thread *td, struct mount *mpdevfs) if (mporoot == mpdevfs) { vfs_unbusy(mpdevfs); /* Unlink the no longer needed /dev/dev -> / symlink */ - error = kern_unlink(td, "/dev/dev", UIO_SYSSPACE); + error = kern_unlinkat(td, AT_FDCWD, "/dev/dev", + UIO_SYSSPACE, 0); if (error && bootverbose) printf("mountroot: unable to unlink /dev/dev " "(error %d)\n", error); @@ -524,12 +525,13 @@ parse_dir_md(char **conf) free(tok, M_TEMP); /* Get file status. */ - error = kern_stat(td, path, UIO_SYSSPACE, &sb); + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &sb, NULL); if (error) goto out; /* Open /dev/mdctl so that we can attach/detach. */ - error = kern_open(td, "/dev/" MDCTL_NAME, UIO_SYSSPACE, O_RDWR, 0); + error = kern_openat(td, AT_FDCWD, "/dev/" MDCTL_NAME, UIO_SYSSPACE, + O_RDWR, 0); if (error) goto out; diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 04c1c7b..f6a8ae0 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -1017,7 +1017,8 @@ sys_open(td, uap) } */ *uap; { - return (kern_open(td, uap->path, UIO_USERSPACE, uap->flags, uap->mode)); + return (kern_openat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + uap->flags, uap->mode)); } #ifndef _SYS_SYSPROTO_H_ @@ -1037,14 +1038,6 @@ sys_openat(struct thread *td, struct openat_args *uap) } int -kern_open(struct thread *td, char *path, enum uio_seg pathseg, int flags, - int mode) -{ - - return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode)); -} - -int kern_openat(struct thread *td, int fd, char *path, enum uio_seg pathseg, int flags, int mode) { @@ -1202,7 +1195,7 @@ ocreat(td, uap) } */ *uap; { - return (kern_open(td, uap->path, UIO_USERSPACE, + return (kern_openat(td, AT_FDCWD, uap->path, UIO_USERSPACE, O_WRONLY | O_CREAT | O_TRUNC, uap->mode)); } #endif /* COMPAT_43 */ @@ -1227,7 +1220,8 @@ sys_mknod(td, uap) } */ *uap; { - return (kern_mknod(td, uap->path, UIO_USERSPACE, uap->mode, uap->dev)); + return (kern_mknodat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + uap->mode, uap->dev)); } #ifndef _SYS_SYSPROTO_H_ @@ -1247,14 +1241,6 @@ sys_mknodat(struct thread *td, struct mknodat_args *uap) } int -kern_mknod(struct thread *td, char *path, enum uio_seg pathseg, int mode, - int dev) -{ - - return (kern_mknodat(td, AT_FDCWD, path, pathseg, mode, dev)); -} - -int kern_mknodat(struct thread *td, int fd, char *path, enum uio_seg pathseg, int mode, int dev) { @@ -1373,7 +1359,8 @@ sys_mkfifo(td, uap) } */ *uap; { - return (kern_mkfifo(td, uap->path, UIO_USERSPACE, uap->mode)); + return (kern_mkfifoat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + uap->mode)); } #ifndef _SYS_SYSPROTO_H_ @@ -1392,13 +1379,6 @@ sys_mkfifoat(struct thread *td, struct mkfifoat_args *uap) } int -kern_mkfifo(struct thread *td, char *path, enum uio_seg pathseg, int mode) -{ - - return (kern_mkfifoat(td, AT_FDCWD, path, pathseg, mode)); -} - -int kern_mkfifoat(struct thread *td, int fd, char *path, enum uio_seg pathseg, int mode) { @@ -1470,7 +1450,8 @@ sys_link(td, uap) } */ *uap; { - return (kern_link(td, uap->path, uap->link, UIO_USERSPACE)); + return (kern_linkat(td, AT_FDCWD, AT_FDCWD, uap->path, uap->link, + UIO_USERSPACE, FOLLOW)); } #ifndef _SYS_SYSPROTO_H_ @@ -1535,13 +1516,6 @@ can_hardlink(struct vnode *vp, struct ucred *cred) } int -kern_link(struct thread *td, char *path, char *link, enum uio_seg segflg) -{ - - return (kern_linkat(td, AT_FDCWD, AT_FDCWD, path,link, segflg, FOLLOW)); -} - -int kern_linkat(struct thread *td, int fd1, int fd2, char *path1, char *path2, enum uio_seg segflg, int follow) { @@ -1643,7 +1617,8 @@ sys_symlink(td, uap) } */ *uap; { - return (kern_symlink(td, uap->path, uap->link, UIO_USERSPACE)); + return (kern_symlinkat(td, uap->path, AT_FDCWD, uap->link, + UIO_USERSPACE)); } #ifndef _SYS_SYSPROTO_H_ @@ -1662,13 +1637,6 @@ sys_symlinkat(struct thread *td, struct symlinkat_args *uap) } int -kern_symlink(struct thread *td, char *path, char *link, enum uio_seg segflg) -{ - - return (kern_symlinkat(td, path, AT_FDCWD, link, segflg)); -} - -int kern_symlinkat(struct thread *td, char *path1, int fd, char *path2, enum uio_seg segflg) { @@ -1796,7 +1764,7 @@ sys_unlink(td, uap) } */ *uap; { - return (kern_unlink(td, uap->path, UIO_USERSPACE)); + return (kern_unlinkat(td, AT_FDCWD, uap->path, UIO_USERSPACE, 0)); } #ifndef _SYS_SYSPROTO_H_ @@ -1823,13 +1791,6 @@ sys_unlinkat(struct thread *td, struct unlinkat_args *uap) } int -kern_unlink(struct thread *td, char *path, enum uio_seg pathseg) -{ - - return (kern_unlinkat(td, AT_FDCWD, path, pathseg, 0)); -} - -int kern_unlinkat(struct thread *td, int fd, char *path, enum uio_seg pathseg, ino_t oldinum) { @@ -2032,7 +1993,8 @@ sys_access(td, uap) } */ *uap; { - return (kern_access(td, uap->path, UIO_USERSPACE, uap->amode)); + return (kern_accessat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + 0, uap->amode)); } #ifndef _SYS_SYSPROTO_H_ @@ -2047,20 +2009,11 @@ int sys_faccessat(struct thread *td, struct faccessat_args *uap) { - if (uap->flag & ~AT_EACCESS) - return (EINVAL); return (kern_accessat(td, uap->fd, uap->path, UIO_USERSPACE, uap->flag, uap->amode)); } int -kern_access(struct thread *td, char *path, enum uio_seg pathseg, int amode) -{ - - return (kern_accessat(td, AT_FDCWD, path, pathseg, 0, amode)); -} - -int kern_accessat(struct thread *td, int fd, char *path, enum uio_seg pathseg, int flag, int amode) { @@ -2070,6 +2023,8 @@ kern_accessat(struct thread *td, int fd, char *path, enum uio_seg pathseg, cap_rights_t rights; int error; + if (flag & ~AT_EACCESS) + return (EINVAL); if (amode != F_OK && (amode & ~(R_OK | W_OK | X_OK)) != 0) return (EINVAL); @@ -2124,14 +2079,8 @@ sys_eaccess(td, uap) } */ *uap; { - return (kern_eaccess(td, uap->path, UIO_USERSPACE, uap->amode)); -} - -int -kern_eaccess(struct thread *td, char *path, enum uio_seg pathseg, int amode) -{ - - return (kern_accessat(td, AT_FDCWD, path, pathseg, AT_EACCESS, amode)); + return (kern_accessat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + AT_EACCESS, uap->amode)); } #if defined(COMPAT_43) @@ -2156,7 +2105,8 @@ ostat(td, uap) struct ostat osb; int error; - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, + &sb, NULL); if (error != 0) return (error); cvtstat(&sb, &osb); @@ -2184,7 +2134,8 @@ olstat(td, uap) struct ostat osb; int error; - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, + UIO_USERSPACE, &sb, NULL); if (error != 0) return (error); cvtstat(&sb, &osb); @@ -2241,7 +2192,8 @@ sys_stat(td, uap) struct stat sb; int error; - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, + &sb, NULL); if (error == 0) error = copyout(&sb, uap->ub, sizeof (sb)); return (error); @@ -2262,29 +2214,14 @@ sys_fstatat(struct thread *td, struct fstatat_args *uap) int error; error = kern_statat(td, uap->flag, uap->fd, uap->path, - UIO_USERSPACE, &sb); + UIO_USERSPACE, &sb, NULL); if (error == 0) error = copyout(&sb, uap->buf, sizeof (sb)); return (error); } int -kern_stat(struct thread *td, char *path, enum uio_seg pathseg, struct stat *sbp) -{ - - return (kern_statat(td, 0, AT_FDCWD, path, pathseg, sbp)); -} - -int kern_statat(struct thread *td, int flag, int fd, char *path, - enum uio_seg pathseg, struct stat *sbp) -{ - - return (kern_statat_vnhook(td, flag, fd, path, pathseg, sbp, NULL)); -} - -int -kern_statat_vnhook(struct thread *td, int flag, int fd, char *path, enum uio_seg pathseg, struct stat *sbp, void (*hook)(struct vnode *vp, struct stat *sbp)) { @@ -2342,20 +2279,13 @@ sys_lstat(td, uap) struct stat sb; int error; - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, + UIO_USERSPACE, &sb, NULL); if (error == 0) error = copyout(&sb, uap->ub, sizeof (sb)); return (error); } -int -kern_lstat(struct thread *td, char *path, enum uio_seg pathseg, struct stat *sbp) -{ - - return (kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, pathseg, - sbp)); -} - /* * Implementation of the NetBSD [l]stat() functions. */ @@ -2402,7 +2332,8 @@ sys_nstat(td, uap) struct nstat nsb; int error; - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, + &sb, NULL); if (error != 0) return (error); cvtnstat(&sb, &nsb); @@ -2430,7 +2361,8 @@ sys_nlstat(td, uap) struct nstat nsb; int error; - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, + UIO_USERSPACE, &sb, NULL); if (error != 0) return (error); cvtnstat(&sb, &nsb); @@ -2519,8 +2451,8 @@ sys_readlink(td, uap) } */ *uap; { - return (kern_readlink(td, uap->path, UIO_USERSPACE, uap->buf, - UIO_USERSPACE, uap->count)); + return (kern_readlinkat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + uap->buf, UIO_USERSPACE, uap->count)); } #ifndef _SYS_SYSPROTO_H_ struct readlinkat_args { @@ -2539,15 +2471,6 @@ sys_readlinkat(struct thread *td, struct readlinkat_args *uap) } int -kern_readlink(struct thread *td, char *path, enum uio_seg pathseg, char *buf, - enum uio_seg bufseg, size_t count) -{ - - return (kern_readlinkat(td, AT_FDCWD, path, pathseg, buf, bufseg, - count)); -} - -int kern_readlinkat(struct thread *td, int fd, char *path, enum uio_seg pathseg, char *buf, enum uio_seg bufseg, size_t count) { @@ -2655,7 +2578,8 @@ sys_chflags(td, uap) } */ *uap; { - return (kern_chflags(td, uap->path, UIO_USERSPACE, uap->flags)); + return (kern_chflagsat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + uap->flags, 0)); } #ifndef _SYS_SYSPROTO_H_ @@ -2680,14 +2604,6 @@ sys_chflagsat(struct thread *td, struct chflagsat_args *uap) return (kern_chflagsat(td, fd, path, UIO_USERSPACE, flags, atflag)); } -static int -kern_chflags(struct thread *td, const char *path, enum uio_seg pathseg, - u_long flags) -{ - - return (kern_chflagsat(td, AT_FDCWD, path, pathseg, flags, 0)); -} - /* * Same as chflags() but doesn't follow symlinks. */ @@ -2808,7 +2724,8 @@ sys_chmod(td, uap) } */ *uap; { - return (kern_chmod(td, uap->path, UIO_USERSPACE, uap->mode)); + return (kern_fchmodat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + uap->mode, 0)); } #ifndef _SYS_SYSPROTO_H_ @@ -2833,13 +2750,6 @@ sys_fchmodat(struct thread *td, struct fchmodat_args *uap) return (kern_fchmodat(td, fd, path, UIO_USERSPACE, mode, flag)); } -int -kern_chmod(struct thread *td, char *path, enum uio_seg pathseg, int mode) -{ - - return (kern_fchmodat(td, AT_FDCWD, path, pathseg, mode, 0)); -} - /* * Change mode of a file given path name (don't follow links.) */ @@ -2961,7 +2871,8 @@ sys_chown(td, uap) } */ *uap; { - return (kern_chown(td, uap->path, UIO_USERSPACE, uap->uid, uap->gid)); + return (kern_fchownat(td, 0, uap->path, UIO_USERSPACE, uap->uid, + uap->gid, 0)); } #ifndef _SYS_SYSPROTO_H_ @@ -2987,14 +2898,6 @@ sys_fchownat(struct thread *td, struct fchownat_args *uap) } int -kern_chown(struct thread *td, char *path, enum uio_seg pathseg, int uid, - int gid) -{ - - return (kern_fchownat(td, AT_FDCWD, path, pathseg, uid, gid, 0)); -} - -int kern_fchownat(struct thread *td, int fd, char *path, enum uio_seg pathseg, int uid, int gid, int flag) { @@ -3035,16 +2938,8 @@ sys_lchown(td, uap) } */ *uap; { - return (kern_lchown(td, uap->path, UIO_USERSPACE, uap->uid, uap->gid)); -} - -int -kern_lchown(struct thread *td, char *path, enum uio_seg pathseg, int uid, - int gid) -{ - - return (kern_fchownat(td, AT_FDCWD, path, pathseg, uid, gid, - AT_SYMLINK_NOFOLLOW)); + return (kern_fchownat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + uap->uid, uap->gid, AT_SYMLINK_NOFOLLOW)); } /* @@ -3174,8 +3069,8 @@ sys_utimes(td, uap) } */ *uap; { - return (kern_utimes(td, uap->path, UIO_USERSPACE, uap->tptr, - UIO_USERSPACE)); + return (kern_utimesat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + uap->tptr, UIO_USERSPACE)); } #ifndef _SYS_SYSPROTO_H_ @@ -3194,14 +3089,6 @@ sys_futimesat(struct thread *td, struct futimesat_args *uap) } int -kern_utimes(struct thread *td, char *path, enum uio_seg pathseg, - struct timeval *tptr, enum uio_seg tptrseg) -{ - - return (kern_utimesat(td, AT_FDCWD, path, pathseg, tptr, tptrseg)); -} - -int kern_utimesat(struct thread *td, int fd, char *path, enum uio_seg pathseg, struct timeval *tptr, enum uio_seg tptrseg) { @@ -3500,7 +3387,8 @@ sys_rename(td, uap) } */ *uap; { - return (kern_rename(td, uap->from, uap->to, UIO_USERSPACE)); + return (kern_renameat(td, AT_FDCWD, uap->from, AT_FDCWD, + uap->to, UIO_USERSPACE)); } #ifndef _SYS_SYSPROTO_H_ @@ -3520,13 +3408,6 @@ sys_renameat(struct thread *td, struct renameat_args *uap) } int -kern_rename(struct thread *td, char *from, char *to, enum uio_seg pathseg) -{ - - return (kern_renameat(td, AT_FDCWD, from, AT_FDCWD, to, pathseg)); -} - -int kern_renameat(struct thread *td, int oldfd, char *old, int newfd, char *new, enum uio_seg pathseg) { @@ -3675,7 +3556,8 @@ sys_mkdir(td, uap) } */ *uap; { - return (kern_mkdir(td, uap->path, UIO_USERSPACE, uap->mode)); + return (kern_mkdirat(td, AT_FDCWD, uap->path, UIO_USERSPACE, + uap->mode)); } #ifndef _SYS_SYSPROTO_H_ @@ -3693,13 +3575,6 @@ sys_mkdirat(struct thread *td, struct mkdirat_args *uap) } int -kern_mkdir(struct thread *td, char *path, enum uio_seg segflg, int mode) -{ - - return (kern_mkdirat(td, AT_FDCWD, path, segflg, mode)); -} - -int kern_mkdirat(struct thread *td, int fd, char *path, enum uio_seg segflg, int mode) { @@ -3777,14 +3652,7 @@ sys_rmdir(td, uap) } */ *uap; { - return (kern_rmdir(td, uap->path, UIO_USERSPACE)); -} - -int -kern_rmdir(struct thread *td, char *path, enum uio_seg pathseg) -{ - - return (kern_rmdirat(td, AT_FDCWD, path, pathseg)); + return (kern_rmdirat(td, AT_FDCWD, uap->path, UIO_USERSPACE)); } int diff --git a/sys/sys/syscallsubr.h b/sys/sys/syscallsubr.h index 7098c43..266c619 100644 --- a/sys/sys/syscallsubr.h +++ b/sys/sys/syscallsubr.h @@ -62,22 +62,16 @@ int kern_accept(struct thread *td, int s, struct sockaddr **name, socklen_t *namelen, struct file **fp); int kern_accept4(struct thread *td, int s, struct sockaddr **name, socklen_t *namelen, int flags, struct file **fp); -int kern_access(struct thread *td, char *path, enum uio_seg pathseg, - int flags); int kern_accessat(struct thread *td, int fd, char *path, enum uio_seg pathseg, int flags, int mode); int kern_adjtime(struct thread *td, struct timeval *delta, struct timeval *olddelta); int kern_alternate_path(struct thread *td, const char *prefix, const char *path, enum uio_seg pathseg, char **pathbuf, int create, int dirfd); -int kern_bind(struct thread *td, int fd, struct sockaddr *sa); +int kern_bindat(struct thread *td, int dirfd, int fd, struct sockaddr *sa); int kern_cap_ioctls_limit(struct thread *td, int fd, u_long *cmds, size_t ncmds); int kern_chdir(struct thread *td, char *path, enum uio_seg pathseg); -int kern_chmod(struct thread *td, char *path, enum uio_seg pathseg, - int mode); -int kern_chown(struct thread *td, char *path, enum uio_seg pathseg, int uid, - int gid); int kern_clock_getcpuclockid2(struct thread *td, id_t id, int which, clockid_t *clk_id); int kern_clock_getres(struct thread *td, clockid_t clock_id, @@ -87,9 +81,8 @@ int kern_clock_gettime(struct thread *td, clockid_t clock_id, int kern_clock_settime(struct thread *td, clockid_t clock_id, struct timespec *ats); int kern_close(struct thread *td, int fd); -int kern_connect(struct thread *td, int fd, struct sockaddr *sa); -int kern_eaccess(struct thread *td, char *path, enum uio_seg pathseg, - int flags); +int kern_connectat(struct thread *td, int dirfd, int fd, + struct sockaddr *sa); int kern_execve(struct thread *td, struct image_args *args, struct mac *mac_p); int kern_fchmodat(struct thread *td, int fd, char *path, @@ -127,26 +120,14 @@ int kern_kevent(struct thread *td, int fd, int nchanges, int nevents, int kern_kldload(struct thread *td, const char *file, int *fileid); int kern_kldstat(struct thread *td, int fileid, struct kld_file_stat *stat); int kern_kldunload(struct thread *td, int fileid, int flags); -int kern_lchown(struct thread *td, char *path, enum uio_seg pathseg, - int uid, int gid); -int kern_link(struct thread *td, char *path, char *link, - enum uio_seg segflg); int kern_linkat(struct thread *td, int fd1, int fd2, char *path1, char *path2, enum uio_seg segflg, int follow); -int kern_lstat(struct thread *td, char *path, enum uio_seg pathseg, - struct stat *sbp); int kern_lutimes(struct thread *td, char *path, enum uio_seg pathseg, struct timeval *tptr, enum uio_seg tptrseg); -int kern_mkdir(struct thread *td, char *path, enum uio_seg segflg, - int mode); int kern_mkdirat(struct thread *td, int fd, char *path, enum uio_seg segflg, int mode); -int kern_mkfifo(struct thread *td, char *path, enum uio_seg pathseg, - int mode); int kern_mkfifoat(struct thread *td, int fd, char *path, enum uio_seg pathseg, int mode); -int kern_mknod(struct thread *td, char *path, enum uio_seg pathseg, - int mode, int dev); int kern_mknodat(struct thread *td, int fd, char *path, enum uio_seg pathseg, int mode, int dev); int kern_msgctl(struct thread *, int, int, struct msqid_ds *); @@ -156,8 +137,6 @@ int kern_nanosleep(struct thread *td, struct timespec *rqt, struct timespec *rmt); int kern_ogetdirentries(struct thread *td, struct ogetdirentries_args *uap, long *ploff); -int kern_open(struct thread *td, char *path, enum uio_seg pathseg, - int flags, int mode); int kern_openat(struct thread *td, int fd, char *path, enum uio_seg pathseg, int flags, int mode); int kern_pathconf(struct thread *td, char *path, enum uio_seg pathseg, @@ -176,18 +155,13 @@ int kern_pselect(struct thread *td, int nd, fd_set *in, fd_set *ou, int kern_ptrace(struct thread *td, int req, pid_t pid, void *addr, int data); int kern_pwritev(struct thread *td, int fd, struct uio *auio, off_t offset); -int kern_readlink(struct thread *td, char *path, enum uio_seg pathseg, - char *buf, enum uio_seg bufseg, size_t count); int kern_readlinkat(struct thread *td, int fd, char *path, enum uio_seg pathseg, char *buf, enum uio_seg bufseg, size_t count); int kern_readv(struct thread *td, int fd, struct uio *auio); int kern_recvit(struct thread *td, int s, struct msghdr *mp, enum uio_seg fromseg, struct mbuf **controlp); -int kern_rename(struct thread *td, char *from, char *to, - enum uio_seg pathseg); int kern_renameat(struct thread *td, int oldfd, char *old, int newfd, char *new, enum uio_seg pathseg); -int kern_rmdir(struct thread *td, char *path, enum uio_seg pathseg); int kern_rmdirat(struct thread *td, int fd, char *path, enum uio_seg pathseg); int kern_sched_rr_get_interval(struct thread *td, pid_t pid, @@ -220,17 +194,11 @@ int kern_sigprocmask(struct thread *td, int how, int kern_sigsuspend(struct thread *td, sigset_t mask); int kern_sigtimedwait(struct thread *td, sigset_t waitset, struct ksiginfo *ksi, struct timespec *timeout); -int kern_stat(struct thread *td, char *path, enum uio_seg pathseg, - struct stat *sbp); int kern_statat(struct thread *td, int flag, int fd, char *path, - enum uio_seg pathseg, struct stat *sbp); -int kern_statat_vnhook(struct thread *td, int flag, int fd, char *path, enum uio_seg pathseg, struct stat *sbp, void (*hook)(struct vnode *vp, struct stat *sbp)); int kern_statfs(struct thread *td, char *path, enum uio_seg pathseg, struct statfs *buf); -int kern_symlink(struct thread *td, char *path, char *link, - enum uio_seg segflg); int kern_symlinkat(struct thread *td, char *path1, int fd, char *path2, enum uio_seg segflg); int kern_ktimer_create(struct thread *td, clockid_t clock_id, @@ -245,11 +213,8 @@ int kern_thr_new(struct thread *td, struct thr_param *param); int kern_thr_suspend(struct thread *td, struct timespec *tsp); int kern_truncate(struct thread *td, char *path, enum uio_seg pathseg, off_t length); -int kern_unlink(struct thread *td, char *path, enum uio_seg pathseg); int kern_unlinkat(struct thread *td, int fd, char *path, enum uio_seg pathseg, ino_t oldinum); -int kern_utimes(struct thread *td, char *path, enum uio_seg pathseg, - struct timeval *tptr, enum uio_seg tptrseg); int kern_utimesat(struct thread *td, int fd, char *path, enum uio_seg pathseg, struct timeval *tptr, enum uio_seg tptrseg); int kern_wait(struct thread *td, pid_t pid, int *status, int options, From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 15:58:46 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C57324B4; Wed, 12 Nov 2014 15:58:46 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A042E23D; Wed, 12 Nov 2014 15:58:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 22EDBB94F; Wed, 12 Nov 2014 10:58:45 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Removal of kern_xxx() no-at variants. Date: Wed, 12 Nov 2014 10:14:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141112132451.GM17068@kib.kiev.ua> In-Reply-To: <20141112132451.GM17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411121014.04482.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 12 Nov 2014 10:58:45 -0500 (EST) Cc: Konstantin Belousov , arch@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 15:58:46 -0000 On Wednesday, November 12, 2014 8:24:52 am Konstantin Belousov wrote: > We have 'fat' KPI for kern_open() and other vfs syscall helpers, after > the at-version of the syscalls was added somewhere at 8-CURRENT. > For instance, we provide > kern_open() and kern_openat(). > But more, we provide > kern_stat() > kern_lstat() > kern_statat() > kern_statat_vhook() > first three being a trivial wrapper around kern_statat_vhook(). > More, existence of two or (sometimes) three layers around basic > syscall helper causes issues like r271655 making the argument > validation split. > > Kepping the compat layer was reasonable in 8-CURRENT time when the > at variants were experimental and patch to add the syscalls was > already large and error-prone. Now, I think we should shave the > extra call indirections, it costs nothing at callers and sometimes > even improves the code. The idea sounds fine to me. Note that I only did a glance over the diff rather than a thorough review. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 16:09:20 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09B1A8F9 for ; Wed, 12 Nov 2014 16:09:20 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C1457384 for ; Wed, 12 Nov 2014 16:09:19 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 7ABD9AA0E; Wed, 12 Nov 2014 16:09:18 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 4C3B4179C; Wed, 12 Nov 2014 17:09:18 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mehmet Erol Sanliturk Subject: Re: Lack of informative files in FreeBSD svn References: Date: Wed, 12 Nov 2014 17:09:18 +0100 In-Reply-To: (Mehmet Erol Sanliturk's message of "Sun, 9 Nov 2014 07:27:23 -0800") Message-ID: <86d28s4d01.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 16:09:20 -0000 Mehmet Erol Sanliturk writes: > For example , I am studying > > https://svnweb.freebsd.org/base/head/contrib/expat/ > > In it , there is a directory > > https://svnweb.freebsd.org/base/head/contrib/expat/tests/ > > it contains > > https://svnweb.freebsd.org/base/head/contrib/expat/tests/README.txt?view= =3Dmarkup > > but it does not contain any link to information how to use new kyua testi= ng > facility for these tests . Everything under contrib is third-party code with minimal modifications, if any. That README file contains information on how to run those tests with the test framework used by the upstream vendor. If you want to know how to run them with Kyua, you're first going to have to port them to TAP or ATF and hook them up to the build (under lib/libexpat). By the time you're done, you won't need a README file. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 19:51:50 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED74B226; Wed, 12 Nov 2014 19:51:50 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FF8EE8C; Wed, 12 Nov 2014 19:51:49 +0000 (UTC) X-AuditID: 1209190e-f79d46d000003643-12-5463ba4e9337 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 3F.B0.13891.E4AB3645; Wed, 12 Nov 2014 14:51:42 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id sACJpflK009081; Wed, 12 Nov 2014 14:51:41 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sACJpdUr031128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Nov 2014 14:51:40 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sACJpctC005479; Wed, 12 Nov 2014 14:51:38 -0500 (EST) Date: Wed, 12 Nov 2014 14:51:38 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Konstantin Belousov Subject: Re: Removal of kern_xxx() no-at variants. In-Reply-To: <201411121014.04482.jhb@freebsd.org> Message-ID: References: <20141112132451.GM17068@kib.kiev.ua> <201411121014.04482.jhb@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0fXblRxi0NYnYrFkxjxmi9nTpzFZ HH7iYrH3yHVmi4Zpj9kcWD1mfJrP4rFz1l32AKYoLpuU1JzMstQifbsEroy3T3awFPRwVqye 9ouxgXEWexcjB4eEgInEjPXhXYycQKaYxIV769m6GLk4hARmM0ks/fODGcLZyCjxsGc6C0iV kMAhJom31wMhEg2MEj1n1jCBJFgEtCUmXZjHCmKzCahJPN7bzAoxVlFi86lJzCC2iICuxMcF e8BsZoF0iVuXL7GB2MICRhJ7rv8Eq+cUMJTYM+8+WA2vgKPE7DsXWUEuFRIIlbg3MwAkLCqg I7F6/xQWiBJBiZMzn7BAjNSSWD59G8sERqFZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7M y0st0jXWy80s0UtNKd3ECAptTkm+HYxfDyodYhTgYFTi4eVYlRQixJpYVlyZe4hRkoNJSZT3 0frkECG+pPyUyozE4oz4otKc1OJDjBIczEoivGxLgHK8KYmVValF+TApaQ4WJXHeTT/4QoQE 0hNLUrNTUwtSi2CyMhwcShK8FjuBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGf9oBMry4IDG3ODMd In+KUVFKnHc2SEIAJJFRmgfXC0s9rxjFgV4R5tUFWcEDTFtw3a+ABjMBDf4WngQyuCQRISXV wOi/aXWwgdjnK+smewZO+7/K3KFCKFNjlm6rt9IsMXtprbx7bwWz0mQq9bruNSn2HbeL0d/i Ene1TPmE307zlY+T/8SHTLX/l7TIYeJFqciS0v3fS/cJuGcsEr678liKmUr9bx3V+ky9yupL F1yPb1YyFJZ4K+X1bJrbmwcLZrWd8eP79vQwmxJLcUaioRZzUXEiAJDMi+4YAwAA Cc: arch@freebsd.org, fs@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:51:51 -0000 On Wed, 12 Nov 2014, John Baldwin wrote: > On Wednesday, November 12, 2014 8:24:52 am Konstantin Belousov wrote: > > We have 'fat' KPI for kern_open() and other vfs syscall helpers, after > > the at-version of the syscalls was added somewhere at 8-CURRENT. > > For instance, we provide > > kern_open() and kern_openat(). > > But more, we provide > > kern_stat() > > kern_lstat() > > kern_statat() > > kern_statat_vhook() > > first three being a trivial wrapper around kern_statat_vhook(). > > More, existence of two or (sometimes) three layers around basic > > syscall helper causes issues like r271655 making the argument > > validation split. > > > > Kepping the compat layer was reasonable in 8-CURRENT time when the > > at variants were experimental and patch to add the syscalls was > > already large and error-prone. Now, I think we should shave the > > extra call indirections, it costs nothing at callers and sometimes > > even improves the code. > > The idea sounds fine to me. Note that I only did a glance over the diff > rather than a thorough review. Please do bump __FreeBSD_version along with the change. -Ben From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 20:23:39 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AACBF17; Wed, 12 Nov 2014 20:23:39 +0000 (UTC) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E425227E; Wed, 12 Nov 2014 20:23:38 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id sACKNTm7087881; Wed, 12 Nov 2014 12:23:29 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201411122023.sACKNTm7087881@chez.mckusick.com> To: Konstantin Belousov Subject: Re: Removal of kern_xxx() no-at variants. In-reply-to: <20141112132451.GM17068@kib.kiev.ua> Date: Wed, 12 Nov 2014 12:23:29 -0800 From: Kirk McKusick Cc: arch@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:23:39 -0000 On Wednesday, November 12, 2014 8:24:52 am Konstantin Belousov wrote: > We have 'fat' KPI for kern_open() and other vfs syscall helpers, after > the at-version of the syscalls was added somewhere at 8-CURRENT. > For instance, we provide > kern_open() and kern_openat(). > But more, we provide > kern_stat() > kern_lstat() > kern_statat() > kern_statat_vhook() > first three being a trivial wrapper around kern_statat_vhook(). > More, existence of two or (sometimes) three layers around basic > syscall helper causes issues like r271655 making the argument > validation split. > > Kepping the compat layer was reasonable in 8-CURRENT time when the > at variants were experimental and patch to add the syscalls was > already large and error-prone. Now, I think we should shave the > extra call indirections, it costs nothing at callers and sometimes > even improves the code. I think this is an excellent idea and helps maintain the FreeBSD philosophy of keeping its code base clean. I have reviewed the diffs and they all look good. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 20:31:26 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AF14534; Wed, 12 Nov 2014 20:31:26 +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 55E3F3A6; Wed, 12 Nov 2014 20:31:26 +0000 (UTC) Received: from janderson.engr.mun.ca (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id sACKVOXf000285; Wed, 12 Nov 2014 20:31:24 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <5463C39C.2010204@FreeBSD.org> Date: Wed, 12 Nov 2014 17:01:24 -0330 From: Jonathan Anderson User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: Removal of kern_xxx() no-at variants. References: <20141112132451.GM17068@kib.kiev.ua> <201411121014.04482.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , arch@freebsd.org, fs@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:31:26 -0000 A thought: If we're only going to have one of {kern_open,kern_openat}, might it make sense to keep the shorter name rather than the longer one? kern_openat as a name seems meaningful to me only if we're trying to disambiguate it from an also-existent-but-different-meaning kern_open. Jon > Benjamin Kaduk > 12 November 2014 at 16:21 > > Please do bump __FreeBSD_version along with the change. > > -Ben > _______________________________________________ > 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" > John Baldwin > 12 November 2014 at 11:44 > > The idea sounds fine to me. Note that I only did a glance over the diff > rather than a thorough review. > > Konstantin Belousov > 12 November 2014 at 9:54 > We have 'fat' KPI for kern_open() and other vfs syscall helpers, after > the at-version of the syscalls was added somewhere at 8-CURRENT. > For instance, we provide > kern_open() and kern_openat(). > But more, we provide > kern_stat() > kern_lstat() > kern_statat() > kern_statat_vhook() > first three being a trivial wrapper around kern_statat_vhook(). > More, existence of two or (sometimes) three layers around basic > syscall helper causes issues like r271655 making the argument > validation split. > > Kepping the compat layer was reasonable in 8-CURRENT time when the > at variants were experimental and patch to add the syscalls was > already large and error-prone. Now, I think we should shave the > extra call indirections, it costs nothing at callers and sometimes > even improves the code. > > diff --git a/sys/cddl/compat/opensolaris/sys/vnode.h > b/sys/cddl/compat/opensolaris/sys/vnode.h > index 4e5b1c9..22256cf 100644 > --- a/sys/cddl/compat/opensolaris/sys/vnode.h > +++ b/sys/cddl/compat/opensolaris/sys/vnode.h > @@ -282,7 +282,7 @@ vn_rename(char *from, char *to, enum uio_seg seg) > > ASSERT(seg == UIO_SYSSPACE); > > - return (kern_rename(curthread, from, to, seg)); > + return (kern_renameat(curthread, AT_FDCWD, from, AT_FDCWD, to, seg)); > } > > static __inline int > @@ -292,7 +292,7 @@ vn_remove(char *fnamep, enum uio_seg seg, enum rm > dirflag) > ASSERT(seg == UIO_SYSSPACE); > ASSERT(dirflag == RMFILE); > > - return (kern_unlink(curthread, fnamep, seg)); > + return (kern_unlinkat(curthread, AT_FDCWD, fnamep, seg, 0)); > } > > #endif /* _KERNEL */ > diff --git a/sys/compat/freebsd32/freebsd32_misc.c > b/sys/compat/freebsd32/freebsd32_misc.c > index 5ea062e..9323138 100644 > --- a/sys/compat/freebsd32/freebsd32_misc.c > +++ b/sys/compat/freebsd32/freebsd32_misc.c > @@ -1235,7 +1235,8 @@ freebsd32_utimes(struct thread *td, struct > freebsd32_utimes_args *uap) > sp = s; > } else > sp = NULL; > - return (kern_utimes(td, uap->path, UIO_USERSPACE, sp, UIO_SYSSPACE)); > + return (kern_utimesat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + sp, UIO_SYSSPACE)); > } > > int > @@ -1723,7 +1724,8 @@ freebsd32_stat(struct thread *td, struct > freebsd32_stat_args *uap) > struct stat32 sb32; > int error; > > - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, > + &sb, NULL); > if (error) > return (error); > copy_stat(&sb, &sb32); > @@ -1739,7 +1741,8 @@ ofreebsd32_stat(struct thread *td, struct > ofreebsd32_stat_args *uap) > struct ostat32 sb32; > int error; > > - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, > + &sb, NULL); > if (error) > return (error); > copy_ostat(&sb, &sb32); > @@ -1787,7 +1790,8 @@ freebsd32_fstatat(struct thread *td, struct > freebsd32_fstatat_args *uap) > struct stat32 ub32; > int error; > > - error = kern_statat(td, uap->flag, uap->fd, uap->path, > UIO_USERSPACE, &ub); > + error = kern_statat(td, uap->flag, uap->fd, uap->path, UIO_USERSPACE, > + &ub, NULL); > if (error) > return (error); > copy_stat(&ub, &ub32); > @@ -1802,7 +1806,8 @@ freebsd32_lstat(struct thread *td, struct > freebsd32_lstat_args *uap) > struct stat32 sb32; > int error; > > - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, > + UIO_USERSPACE, &sb, NULL); > if (error) > return (error); > copy_stat(&sb, &sb32); > @@ -1818,7 +1823,8 @@ ofreebsd32_lstat(struct thread *td, struct > ofreebsd32_lstat_args *uap) > struct ostat32 sb32; > int error; > > - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, > + UIO_USERSPACE, &sb, NULL); > if (error) > return (error); > copy_ostat(&sb, &sb32); > diff --git a/sys/compat/linux/linux_file.c b/sys/compat/linux/linux_file.c > index e56e61f..88303b9 100644 > --- a/sys/compat/linux/linux_file.c > +++ b/sys/compat/linux/linux_file.c > @@ -82,8 +82,8 @@ linux_creat(struct thread *td, struct > linux_creat_args *args) > if (ldebug(creat)) > printf(ARGS(creat, "%s, %d"), path, args->mode); > #endif > - error = kern_open(td, path, UIO_SYSSPACE, O_WRONLY | O_CREAT | O_TRUNC, > - args->mode); > + error = kern_openat(td, AT_FDCWD, path, UIO_SYSSPACE, > + O_WRONLY | O_CREAT | O_TRUNC, args->mode); > LFREEPATH(path); > return (error); > } > @@ -572,7 +572,8 @@ linux_access(struct thread *td, struct > linux_access_args *args) > if (ldebug(access)) > printf(ARGS(access, "%s, %d"), path, args->amode); > #endif > - error = kern_access(td, path, UIO_SYSSPACE, args->amode); > + error = kern_accessat(td, AT_FDCWD, path, UIO_SYSSPACE, 0, > + args->amode); > LFREEPATH(path); > > return (error); > @@ -619,12 +620,15 @@ linux_unlink(struct thread *td, struct > linux_unlink_args *args) > printf(ARGS(unlink, "%s"), path); > #endif > > - error = kern_unlink(td, path, UIO_SYSSPACE); > - if (error == EPERM) > + error = kern_unlinkat(td, AT_FDCWD, path, UIO_SYSSPACE, 0); > + if (error == EPERM) { > /* Introduce POSIX noncompliant behaviour of Linux */ > - if (kern_stat(td, path, UIO_SYSSPACE, &st) == 0) > + if (kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, > + NULL) == 0) { > if (S_ISDIR(st.st_mode)) > error = EISDIR; > + } > + } > LFREEPATH(path); > return (error); > } > @@ -654,7 +658,7 @@ linux_unlinkat(struct thread *td, struct > linux_unlinkat_args *args) > if (error == EPERM && !(args->flag & LINUX_AT_REMOVEDIR)) { > /* Introduce POSIX noncompliant behaviour of Linux */ > if (kern_statat(td, AT_SYMLINK_NOFOLLOW, dfd, path, > - UIO_SYSSPACE, &st) == 0 && S_ISDIR(st.st_mode)) > + UIO_SYSSPACE, &st, NULL) == 0 && S_ISDIR(st.st_mode)) > error = EISDIR; > } > LFREEPATH(path); > @@ -689,7 +693,8 @@ linux_chmod(struct thread *td, struct > linux_chmod_args *args) > if (ldebug(chmod)) > printf(ARGS(chmod, "%s, %d"), path, args->mode); > #endif > - error = kern_chmod(td, path, UIO_SYSSPACE, args->mode); > + error = kern_fchmodat(td, AT_FDCWD, path, UIO_SYSSPACE, > + args->mode, 0); > LFREEPATH(path); > return (error); > } > @@ -725,7 +730,7 @@ linux_mkdir(struct thread *td, struct > linux_mkdir_args *args) > if (ldebug(mkdir)) > printf(ARGS(mkdir, "%s, %d"), path, args->mode); > #endif > - error = kern_mkdir(td, path, UIO_SYSSPACE, args->mode); > + error = kern_mkdirat(td, AT_FDCWD, path, UIO_SYSSPACE, args->mode); > LFREEPATH(path); > return (error); > } > @@ -760,7 +765,7 @@ linux_rmdir(struct thread *td, struct > linux_rmdir_args *args) > if (ldebug(rmdir)) > printf(ARGS(rmdir, "%s"), path); > #endif > - error = kern_rmdir(td, path, UIO_SYSSPACE); > + error = kern_rmdirat(td, AT_FDCWD, path, UIO_SYSSPACE); > LFREEPATH(path); > return (error); > } > @@ -783,7 +788,7 @@ linux_rename(struct thread *td, struct > linux_rename_args *args) > if (ldebug(rename)) > printf(ARGS(rename, "%s, %s"), from, to); > #endif > - error = kern_rename(td, from, to, UIO_SYSSPACE); > + error = kern_renameat(td, AT_FDCWD, from, AT_FDCWD, to, UIO_SYSSPACE); > LFREEPATH(from); > LFREEPATH(to); > return (error); > @@ -833,7 +838,7 @@ linux_symlink(struct thread *td, struct > linux_symlink_args *args) > if (ldebug(symlink)) > printf(ARGS(symlink, "%s, %s"), path, to); > #endif > - error = kern_symlink(td, path, to, UIO_SYSSPACE); > + error = kern_symlinkat(td, path, AT_FDCWD, to, UIO_SYSSPACE); > LFREEPATH(path); > LFREEPATH(to); > return (error); > @@ -878,8 +883,8 @@ linux_readlink(struct thread *td, struct > linux_readlink_args *args) > printf(ARGS(readlink, "%s, %p, %d"), name, (void *)args->buf, > args->count); > #endif > - error = kern_readlink(td, name, UIO_SYSSPACE, args->buf, UIO_USERSPACE, > - args->count); > + error = kern_readlinkat(td, AT_FDCWD, name, UIO_SYSSPACE, > + args->buf, UIO_USERSPACE, args->count); > LFREEPATH(name); > return (error); > } > @@ -972,7 +977,8 @@ linux_link(struct thread *td, struct > linux_link_args *args) > if (ldebug(link)) > printf(ARGS(link, "%s, %s"), path, to); > #endif > - error = kern_link(td, path, to, UIO_SYSSPACE); > + error = kern_linkat(td, AT_FDCWD, AT_FDCWD, path, to, UIO_SYSSPACE, > + FOLLOW); > LFREEPATH(path); > LFREEPATH(to); > return (error); > @@ -1487,7 +1493,8 @@ linux_chown(struct thread *td, struct > linux_chown_args *args) > if (ldebug(chown)) > printf(ARGS(chown, "%s, %d, %d"), path, args->uid, args->gid); > #endif > - error = kern_chown(td, path, UIO_SYSSPACE, args->uid, args->gid); > + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, args->uid, > + args->gid, 0); > LFREEPATH(path); > return (error); > } > @@ -1529,7 +1536,8 @@ linux_lchown(struct thread *td, struct > linux_lchown_args *args) > if (ldebug(lchown)) > printf(ARGS(lchown, "%s, %d, %d"), path, args->uid, args->gid); > #endif > - error = kern_lchown(td, path, UIO_SYSSPACE, args->uid, args->gid); > + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, args->uid, > + args->gid, AT_SYMLINK_NOFOLLOW); > LFREEPATH(path); > return (error); > } > diff --git a/sys/compat/linux/linux_misc.c b/sys/compat/linux/linux_misc.c > index ff5e8a2..4433e18 100644 > --- a/sys/compat/linux/linux_misc.c > +++ b/sys/compat/linux/linux_misc.c > @@ -777,7 +777,8 @@ linux_utime(struct thread *td, struct > linux_utime_args *args) > } else > tvp = NULL; > > - error = kern_utimes(td, fname, UIO_SYSSPACE, tvp, UIO_SYSSPACE); > + error = kern_utimesat(td, AT_FDCWD, fname, UIO_SYSSPACE, tvp, > + UIO_SYSSPACE); > LFREEPATH(fname); > return (error); > } > @@ -809,7 +810,8 @@ linux_utimes(struct thread *td, struct > linux_utimes_args *args) > tvp = tv; > } > > - error = kern_utimes(td, fname, UIO_SYSSPACE, tvp, UIO_SYSSPACE); > + error = kern_utimesat(td, AT_FDCWD, fname, UIO_SYSSPACE, > + tvp, UIO_SYSSPACE); > LFREEPATH(fname); > return (error); > } > @@ -914,13 +916,14 @@ linux_mknod(struct thread *td, struct > linux_mknod_args *args) > switch (args->mode & S_IFMT) { > case S_IFIFO: > case S_IFSOCK: > - error = kern_mkfifo(td, path, UIO_SYSSPACE, args->mode); > + error = kern_mkfifoat(td, AT_FDCWD, path, UIO_SYSSPACE, > + args->mode); > break; > > case S_IFCHR: > case S_IFBLK: > - error = kern_mknod(td, path, UIO_SYSSPACE, args->mode, > - args->dev); > + error = kern_mknodat(td, AT_FDCWD, path, UIO_SYSSPACE, > + args->mode, args->dev); > break; > > case S_IFDIR: > @@ -931,7 +934,7 @@ linux_mknod(struct thread *td, struct > linux_mknod_args *args) > args->mode |= S_IFREG; > /* FALLTHROUGH */ > case S_IFREG: > - error = kern_open(td, path, UIO_SYSSPACE, > + error = kern_openat(td, AT_FDCWD, path, UIO_SYSSPACE, > O_WRONLY | O_CREAT | O_TRUNC, args->mode); > if (error == 0) > kern_close(td, td->td_retval[0]); > diff --git a/sys/compat/linux/linux_socket.c > b/sys/compat/linux/linux_socket.c > index 43b255d..61b786f 100644 > --- a/sys/compat/linux/linux_socket.c > +++ b/sys/compat/linux/linux_socket.c > @@ -731,7 +731,7 @@ linux_bind(struct thread *td, struct > linux_bind_args *args) > if (error) > return (error); > > - error = kern_bind(td, args->s, sa); > + error = kern_bindat(td, AT_FDCWD, args->s, sa); > free(sa, M_SONAME); > if (error == EADDRNOTAVAIL && args->namelen != sizeof(struct sockaddr_in)) > return (EINVAL); > @@ -759,7 +759,7 @@ linux_connect(struct thread *td, struct > linux_connect_args *args) > if (error) > return (error); > > - error = kern_connect(td, args->s, sa); > + error = kern_connectat(td, AT_FDCWD, args->s, sa); > free(sa, M_SONAME); > if (error != EISCONN) > return (error); > diff --git a/sys/compat/linux/linux_stats.c > b/sys/compat/linux/linux_stats.c > index 2e05c85..b6dd86d 100644 > --- a/sys/compat/linux/linux_stats.c > +++ b/sys/compat/linux/linux_stats.c > @@ -77,7 +77,7 @@ linux_kern_statat(struct thread *td, int flag, int > fd, char *path, > enum uio_seg pathseg, struct stat *sbp) > { > > - return (kern_statat_vnhook(td, flag, fd, path, pathseg, sbp, > + return (kern_statat(td, flag, fd, path, pathseg, sbp, > translate_vnhook_major_minor)); > } > > diff --git a/sys/compat/linux/linux_uid16.c > b/sys/compat/linux/linux_uid16.c > index c5bf2dd..61f3030 100644 > --- a/sys/compat/linux/linux_uid16.c > +++ b/sys/compat/linux/linux_uid16.c > @@ -121,8 +121,8 @@ linux_chown16(struct thread *td, struct > linux_chown16_args *args) > args->gid); > LIN_SDT_PROBE1(uid16, linux_chown16, conv_path, path); > > - error = kern_chown(td, path, UIO_SYSSPACE, CAST_NOCHG(args->uid), > - CAST_NOCHG(args->gid)); > + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, > + CAST_NOCHG(args->uid), CAST_NOCHG(args->gid), 0); > LFREEPATH(path); > > LIN_SDT_PROBE1(uid16, linux_chown16, return, error); > @@ -146,8 +146,8 @@ linux_lchown16(struct thread *td, struct > linux_lchown16_args *args) > args->gid); > LIN_SDT_PROBE1(uid16, linux_lchown16, conv_path, path); > > - error = kern_lchown(td, path, UIO_SYSSPACE, CAST_NOCHG(args->uid), > - CAST_NOCHG(args->gid)); > + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, > + CAST_NOCHG(args->uid), CAST_NOCHG(args->gid), AT_SYMLINK_NOFOLLOW); > LFREEPATH(path); > > LIN_SDT_PROBE1(uid16, linux_lchown16, return, error); > diff --git a/sys/compat/svr4/svr4_fcntl.c b/sys/compat/svr4/svr4_fcntl.c > index c604675..edcfcc107 100644 > --- a/sys/compat/svr4/svr4_fcntl.c > +++ b/sys/compat/svr4/svr4_fcntl.c > @@ -390,7 +390,8 @@ svr4_sys_open(td, uap) > CHECKALTEXIST(td, uap->path, &newpath); > > bsd_flags = svr4_to_bsd_flags(uap->flags); > - error = kern_open(td, newpath, UIO_SYSSPACE, bsd_flags, uap->mode); > + error = kern_openat(td, AT_FDCWD, newpath, UIO_SYSSPACE, bsd_flags, > + uap->mode); > free(newpath, M_TEMP); > > if (error) { > @@ -450,8 +451,8 @@ svr4_sys_creat(td, uap) > > CHECKALTEXIST(td, uap->path, &newpath); > > - error = kern_open(td, newpath, UIO_SYSSPACE, O_WRONLY | O_CREAT | > - O_TRUNC, uap->mode); > + error = kern_openat(td, AT_FDCWD, newpath, UIO_SYSSPACE, > + O_WRONLY | O_CREAT | O_TRUNC, uap->mode); > free(newpath, M_TEMP); > return (error); > } > @@ -494,7 +495,8 @@ svr4_sys_access(td, uap) > int error; > > CHECKALTEXIST(td, uap->path, &newpath); > - error = kern_access(td, newpath, UIO_SYSSPACE, uap->amode); > + error = kern_accessat(td, AT_FDCWD, newpath, UIO_SYSSPACE, > + 0, uap->amode); > free(newpath, M_TEMP); > return (error); > } > diff --git a/sys/compat/svr4/svr4_misc.c b/sys/compat/svr4/svr4_misc.c > index 0db5453..9e9b020 100644 > --- a/sys/compat/svr4/svr4_misc.c > +++ b/sys/compat/svr4/svr4_misc.c > @@ -653,10 +653,13 @@ svr4_mknod(td, retval, path, mode, dev) > > CHECKALTEXIST(td, path, &newpath); > > - if (S_ISFIFO(mode)) > - error = kern_mkfifo(td, newpath, UIO_SYSSPACE, mode); > - else > - error = kern_mknod(td, newpath, UIO_SYSSPACE, mode, dev); > + if (S_ISFIFO(mode)) { > + error = kern_mkfifoat(td, AT_FDCWD, newpath, UIO_SYSSPACE, > + mode); > + } else { > + error = kern_mknodat(td, AT_FDCWD, newpath, UIO_SYSSPACE, > + mode, dev); > + } > free(newpath, M_TEMP); > return (error); > } > diff --git a/sys/compat/svr4/svr4_stat.c b/sys/compat/svr4/svr4_stat.c > index b686642..6ed9873 100644 > --- a/sys/compat/svr4/svr4_stat.c > +++ b/sys/compat/svr4/svr4_stat.c > @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -170,7 +171,7 @@ svr4_sys_stat(td, uap) > > CHECKALTEXIST(td, uap->path, &path); > > - error = kern_stat(td, path, UIO_SYSSPACE, &st); > + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, NULL); > free(path, M_TEMP); > if (error) > return (error); > @@ -195,7 +196,8 @@ svr4_sys_lstat(td, uap) > > CHECKALTEXIST(td, uap->path, &path); > > - error = kern_lstat(td, path, UIO_SYSSPACE, &st); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, > + UIO_SYSSPACE, &st, NULL); > free(path, M_TEMP); > if (error) > return (error); > @@ -238,7 +240,7 @@ svr4_sys_xstat(td, uap) > > CHECKALTEXIST(td, uap->path, &path); > > - error = kern_stat(td, path, UIO_SYSSPACE, &st); > + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, NULL); > free(path, M_TEMP); > if (error) > return (error); > @@ -265,7 +267,8 @@ svr4_sys_lxstat(td, uap) > > CHECKALTEXIST(td, uap->path, &path); > > - error = kern_lstat(td, path, UIO_SYSSPACE, &st); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, > + UIO_SYSSPACE, &st, NULL); > free(path, M_TEMP); > if (error) > return (error); > @@ -309,7 +312,7 @@ svr4_sys_stat64(td, uap) > > CHECKALTEXIST(td, uap->path, &path); > > - error = kern_stat(td, path, UIO_SYSSPACE, &st); > + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, NULL); > free(path, M_TEMP); > if (error) > return (error); > @@ -335,7 +338,8 @@ svr4_sys_lstat64(td, uap) > > CHECKALTEXIST(td, uap->path, &path); > > - error = kern_lstat(td, path, UIO_SYSSPACE, &st); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, > + UIO_SYSSPACE, &st, NULL); > free(path, M_TEMP); > if (error) > return (error); > @@ -582,7 +586,8 @@ svr4_sys_utime(td, uap) > tp = NULL; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_utimes(td, path, UIO_SYSSPACE, tp, UIO_SYSSPACE); > + error = kern_utimesat(td, AT_FDCWD, path, UIO_SYSSPACE, > + tp, UIO_SYSSPACE); > free(path, M_TEMP); > return (error); > } > @@ -597,7 +602,8 @@ svr4_sys_utimes(td, uap) > int error; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_utimes(td, path, UIO_SYSSPACE, uap->tptr, UIO_USERSPACE); > + error = kern_utimesat(td, AT_FDCWD, path, UIO_SYSSPACE, > + uap->tptr, UIO_USERSPACE); > free(path, M_TEMP); > return (error); > } > diff --git a/sys/compat/svr4/svr4_stream.c b/sys/compat/svr4/svr4_stream.c > index 91c393f..d287d5d 100644 > --- a/sys/compat/svr4/svr4_stream.c > +++ b/sys/compat/svr4/svr4_stream.c > @@ -282,7 +282,8 @@ clean_pipe(td, path) > struct stat st; > int error; > > - error = kern_lstat(td, path, UIO_SYSSPACE, &st); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, > + UIO_SYSSPACE, &st, NULL); > > /* > * Make sure we are dealing with a mode 0 named pipe. > @@ -293,7 +294,7 @@ clean_pipe(td, path) > if ((st.st_mode & ALLPERMS) != 0) > return (0); > > - error = kern_unlink(td, path, UIO_SYSSPACE); > + error = kern_unlinkat(td, AT_FDCWD, path, UIO_SYSSPACE, 0); > if (error) > DPRINTF(("clean_pipe: unlink failed %d\n", error)); > return (error); > @@ -812,7 +813,7 @@ ti_bind(fp, fd, ioc, td) > > DPRINTF(("TI_BIND: fileno %d\n", fd)); > > - if ((error = kern_bind(td, fd, skp)) != 0) { > + if ((error = kern_bindat(td, AT_FDCWD, fd, skp)) != 0) { > DPRINTF(("TI_BIND: bind failed %d\n", error)); > return error; > } > @@ -1586,7 +1587,7 @@ svr4_do_putmsg(td, uap, fp) > case SVR4_TI_CONNECT_REQUEST: /* connect */ > { > > - return (kern_connect(td, uap->fd, sa)); > + return (kern_connectat(td, AT_FDCWD, uap->fd, sa)); > } > > case SVR4_TI_SENDTO_REQUEST: /* sendto */ > diff --git a/sys/dev/streams/streams.c b/sys/dev/streams/streams.c > index 42265a4..6a9219e 100644 > --- a/sys/dev/streams/streams.c > +++ b/sys/dev/streams/streams.c > @@ -302,7 +302,8 @@ svr4_ptm_alloc(td) > ptyname[8] = ttyletters[l]; > ptyname[9] = ttynumbers[n]; > > - error = kern_open(td, ptyname, UIO_SYSSPACE, O_RDWR, 0); > + error = kern_openat(td, AT_FDCWD, ptyname, UIO_SYSSPACE, > + O_RDWR, 0); > switch (error) { > case ENOENT: > case ENXIO: > diff --git a/sys/i386/ibcs2/ibcs2_fcntl.c b/sys/i386/ibcs2/ibcs2_fcntl.c > index d2489df..5d06d4d 100644 > --- a/sys/i386/ibcs2/ibcs2_fcntl.c > +++ b/sys/i386/ibcs2/ibcs2_fcntl.c > @@ -189,7 +189,7 @@ ibcs2_open(td, uap) > CHECKALTCREAT(td, uap->path, &path); > else > CHECKALTEXIST(td, uap->path, &path); > - ret = kern_open(td, path, UIO_SYSSPACE, flags, uap->mode); > + ret = kern_openat(td, AT_FDCWD, path, UIO_SYSSPACE, flags, uap->mode); > > #ifdef SPX_HACK > if (ret == ENXIO) { > @@ -230,8 +230,8 @@ ibcs2_creat(td, uap) > int error; > > CHECKALTCREAT(td, uap->path, &path); > - error = kern_open(td, path, UIO_SYSSPACE, O_WRONLY | O_CREAT | O_TRUNC, > - uap->mode); > + error = kern_openat(td, AT_FDCWD, path, UIO_SYSSPACE, > + O_WRONLY | O_CREAT | O_TRUNC, uap->mode); > free(path, M_TEMP); > return (error); > } > @@ -245,7 +245,7 @@ ibcs2_access(td, uap) > int error; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_access(td, path, UIO_SYSSPACE, uap->amode); > + error = kern_accessat(td, AT_FDCWD, path, UIO_SYSSPACE, 0, uap->amode); > free(path, M_TEMP); > return (error); > } > diff --git a/sys/i386/ibcs2/ibcs2_misc.c b/sys/i386/ibcs2/ibcs2_misc.c > index 42bc4b7..d81cfee 100644 > --- a/sys/i386/ibcs2/ibcs2_misc.c > +++ b/sys/i386/ibcs2/ibcs2_misc.c > @@ -646,10 +646,13 @@ ibcs2_mknod(td, uap) > int error; > > CHECKALTCREAT(td, uap->path, &path); > - if (S_ISFIFO(uap->mode)) > - error = kern_mkfifo(td, path, UIO_SYSSPACE, uap->mode); > - else > - error = kern_mknod(td, path, UIO_SYSSPACE, uap->mode, uap->dev); > + if (S_ISFIFO(uap->mode)) { > + error = kern_mkfifoat(td, AT_FDCWD, path, > + UIO_SYSSPACE, uap->mode); > + } else { > + error = kern_mknodat(td, AT_FDCWD, path, UIO_SYSSPACE, > + uap->mode, uap->dev); > + } > free(path, M_TEMP); > return (error); > } > @@ -938,7 +941,8 @@ ibcs2_utime(td, uap) > tp = NULL; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_utimes(td, path, UIO_SYSSPACE, tp, UIO_SYSSPACE); > + error = kern_utimesat(td, AT_FDCWD, path, UIO_SYSSPACE, > + tp, UIO_SYSSPACE); > free(path, M_TEMP); > return (error); > } > @@ -1119,7 +1123,7 @@ ibcs2_unlink(td, uap) > int error; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_unlink(td, path, UIO_SYSSPACE); > + error = kern_unlinkat(td, AT_FDCWD, path, UIO_SYSSPACE, 0); > free(path, M_TEMP); > return (error); > } > @@ -1147,7 +1151,7 @@ ibcs2_chmod(td, uap) > int error; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_chmod(td, path, UIO_SYSSPACE, uap->mode); > + error = kern_fchmodat(td, AT_FDCWD, path, UIO_SYSSPACE, uap->mode, 0); > free(path, M_TEMP); > return (error); > } > @@ -1161,7 +1165,8 @@ ibcs2_chown(td, uap) > int error; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_chown(td, path, UIO_SYSSPACE, uap->uid, uap->gid); > + error = kern_fchownat(td, AT_FDCWD, path, UIO_SYSSPACE, uap->uid, > + uap->gid, 0); > free(path, M_TEMP); > return (error); > } > @@ -1175,7 +1180,7 @@ ibcs2_rmdir(td, uap) > int error; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_rmdir(td, path, UIO_SYSSPACE); > + error = kern_rmdirat(td, AT_FDCWD, path, UIO_SYSSPACE); > free(path, M_TEMP); > return (error); > } > @@ -1189,7 +1194,7 @@ ibcs2_mkdir(td, uap) > int error; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_mkdir(td, path, UIO_SYSSPACE, uap->mode); > + error = kern_mkdirat(td, AT_FDCWD, path, UIO_SYSSPACE, uap->mode); > free(path, M_TEMP); > return (error); > } > @@ -1213,7 +1218,7 @@ ibcs2_symlink(td, uap) > free(path, M_TEMP); > return (error); > } > - error = kern_symlink(td, path, link, UIO_SYSSPACE); > + error = kern_symlinkat(td, path, AT_FDCWD, link, UIO_SYSSPACE); > free(path, M_TEMP); > free(link, M_TEMP); > return (error); > @@ -1238,7 +1243,7 @@ ibcs2_rename(td, uap) > free(from, M_TEMP); > return (error); > } > - error = kern_rename(td, from, to, UIO_SYSSPACE); > + error = kern_renameat(td, AT_FDCWD, from, AT_FDCWD, to, UIO_SYSSPACE); > free(from, M_TEMP); > free(to, M_TEMP); > return (error); > @@ -1253,8 +1258,8 @@ ibcs2_readlink(td, uap) > int error; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_readlink(td, path, UIO_SYSSPACE, uap->buf, UIO_USERSPACE, > - uap->count); > + error = kern_readlinkat(td, AT_FDCWD, path, UIO_SYSSPACE, > + uap->buf, UIO_USERSPACE, uap->count); > free(path, M_TEMP); > return (error); > } > diff --git a/sys/i386/ibcs2/ibcs2_other.c b/sys/i386/ibcs2/ibcs2_other.c > index f688661..b49e605 100644 > --- a/sys/i386/ibcs2/ibcs2_other.c > +++ b/sys/i386/ibcs2/ibcs2_other.c > @@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$"); > > #include > #include > +#include > #include > #include > #include > @@ -107,7 +108,7 @@ spx_open(struct thread *td) > sun.sun_len = sizeof(struct sockaddr_un) - sizeof(sun.sun_path) + > strlen(sun.sun_path) + 1; > > - error = kern_connect(td, fd, (struct sockaddr *)&sun); > + error = kern_connectat(td, AT_FDCWD, fd, (struct sockaddr *)&sun); > if (error) { > kern_close(td, fd); > return error; > diff --git a/sys/i386/ibcs2/ibcs2_stat.c b/sys/i386/ibcs2/ibcs2_stat.c > index c1097a3..55d14af 100644 > --- a/sys/i386/ibcs2/ibcs2_stat.c > +++ b/sys/i386/ibcs2/ibcs2_stat.c > @@ -32,6 +32,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -145,7 +146,7 @@ ibcs2_stat(td, uap) > > CHECKALTEXIST(td, uap->path, &path); > > - error = kern_stat(td, path, UIO_SYSSPACE, &st); > + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &st, NULL); > free(path, M_TEMP); > if (error) > return (error); > @@ -166,7 +167,8 @@ ibcs2_lstat(td, uap) > > CHECKALTEXIST(td, uap->path, &path); > > - error = kern_lstat(td, path, UIO_SYSSPACE, &st); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, > + UIO_SYSSPACE, &st, NULL); > free(path, M_TEMP); > if (error) > return (error); > diff --git a/sys/i386/ibcs2/ibcs2_xenix.c b/sys/i386/ibcs2/ibcs2_xenix.c > index c5416fb..829f6ab 100644 > --- a/sys/i386/ibcs2/ibcs2_xenix.c > +++ b/sys/i386/ibcs2/ibcs2_xenix.c > @@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$"); > > #include > #include > +#include > #include > #include > #include > @@ -209,7 +210,8 @@ xenix_eaccess(struct thread *td, struct > xenix_eaccess_args *uap) > bsd_flags |= X_OK; > > CHECKALTEXIST(td, uap->path, &path); > - error = kern_eaccess(td, path, UIO_SYSSPACE, bsd_flags); > + error = kern_accessat(td, AT_FDCWD, path, UIO_SYSSPACE, > + AT_EACCESS, bsd_flags); > free(path, M_TEMP); > return (error); > } > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 32c837c..7f88a6c 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -2215,8 +2215,8 @@ fdcheckstd(struct thread *td) > if (devnull != -1) { > error = do_dup(td, DUP_FIXED, devnull, i); > } else { > - error = kern_open(td, "/dev/null", UIO_SYSSPACE, > - O_RDWR, 0); > + error = kern_openat(td, AT_FDCWD, "/dev/null", > + UIO_SYSSPACE, O_RDWR, 0); > if (error == 0) { > devnull = td->td_retval[0]; > KASSERT(devnull == i, ("we didn't get our fd")); > diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c > index 6d423ba..24a4436 100644 > --- a/sys/kern/uipc_syscalls.c > +++ b/sys/kern/uipc_syscalls.c > @@ -283,13 +283,13 @@ sys_bind(td, uap) > > error = getsockaddr(&sa, uap->name, uap->namelen); > if (error == 0) { > - error = kern_bind(td, uap->s, sa); > + error = kern_bindat(td, AT_FDCWD, uap->s, sa); > free(sa, M_SONAME); > } > return (error); > } > > -static int > +int > kern_bindat(struct thread *td, int dirfd, int fd, struct sockaddr *sa) > { > struct socket *so; > @@ -323,13 +323,6 @@ kern_bindat(struct thread *td, int dirfd, int fd, > struct sockaddr *sa) > return (error); > } > > -int > -kern_bind(struct thread *td, int fd, struct sockaddr *sa) > -{ > - > - return (kern_bindat(td, AT_FDCWD, fd, sa)); > -} > - > /* ARGSUSED */ > int > sys_bindat(td, uap) > @@ -636,13 +629,13 @@ sys_connect(td, uap) > > error = getsockaddr(&sa, uap->name, uap->namelen); > if (error == 0) { > - error = kern_connect(td, uap->s, sa); > + error = kern_connectat(td, AT_FDCWD, uap->s, sa); > free(sa, M_SONAME); > } > return (error); > } > > -static int > +int > kern_connectat(struct thread *td, int dirfd, int fd, struct sockaddr *sa) > { > struct socket *so; > @@ -705,13 +698,6 @@ done1: > return (error); > } > > -int > -kern_connect(struct thread *td, int fd, struct sockaddr *sa) > -{ > - > - return (kern_connectat(td, AT_FDCWD, fd, sa)); > -} > - > /* ARGSUSED */ > int > sys_connectat(td, uap) > diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c > index 2816e1b..a050099 100644 > --- a/sys/kern/vfs_mountroot.c > +++ b/sys/kern/vfs_mountroot.c > @@ -238,7 +238,7 @@ vfs_mountroot_devfs(struct thread *td, struct > mount **mpp) > *mpp = mp; > set_rootvnode(); > > - error = kern_symlink(td, "/", "dev", UIO_SYSSPACE); > + error = kern_symlinkat(td, "/", AT_FDCWD, "dev", UIO_SYSSPACE); > if (error) > printf("kern_symlink /dev -> / returns %d\n", error); > > @@ -350,7 +350,8 @@ vfs_mountroot_shuffle(struct thread *td, struct > mount *mpdevfs) > if (mporoot == mpdevfs) { > vfs_unbusy(mpdevfs); > /* Unlink the no longer needed /dev/dev -> / symlink */ > - error = kern_unlink(td, "/dev/dev", UIO_SYSSPACE); > + error = kern_unlinkat(td, AT_FDCWD, "/dev/dev", > + UIO_SYSSPACE, 0); > if (error && bootverbose) > printf("mountroot: unable to unlink /dev/dev " > "(error %d)\n", error); > @@ -524,12 +525,13 @@ parse_dir_md(char **conf) > free(tok, M_TEMP); > > /* Get file status. */ > - error = kern_stat(td, path, UIO_SYSSPACE, &sb); > + error = kern_statat(td, 0, AT_FDCWD, path, UIO_SYSSPACE, &sb, NULL); > if (error) > goto out; > > /* Open /dev/mdctl so that we can attach/detach. */ > - error = kern_open(td, "/dev/" MDCTL_NAME, UIO_SYSSPACE, O_RDWR, 0); > + error = kern_openat(td, AT_FDCWD, "/dev/" MDCTL_NAME, UIO_SYSSPACE, > + O_RDWR, 0); > if (error) > goto out; > > diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c > index 04c1c7b..f6a8ae0 100644 > --- a/sys/kern/vfs_syscalls.c > +++ b/sys/kern/vfs_syscalls.c > @@ -1017,7 +1017,8 @@ sys_open(td, uap) > } */ *uap; > { > > - return (kern_open(td, uap->path, UIO_USERSPACE, uap->flags, uap->mode)); > + return (kern_openat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + uap->flags, uap->mode)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -1037,14 +1038,6 @@ sys_openat(struct thread *td, struct > openat_args *uap) > } > > int > -kern_open(struct thread *td, char *path, enum uio_seg pathseg, int flags, > - int mode) > -{ > - > - return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode)); > -} > - > -int > kern_openat(struct thread *td, int fd, char *path, enum uio_seg pathseg, > int flags, int mode) > { > @@ -1202,7 +1195,7 @@ ocreat(td, uap) > } */ *uap; > { > > - return (kern_open(td, uap->path, UIO_USERSPACE, > + return (kern_openat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > O_WRONLY | O_CREAT | O_TRUNC, uap->mode)); > } > #endif /* COMPAT_43 */ > @@ -1227,7 +1220,8 @@ sys_mknod(td, uap) > } */ *uap; > { > > - return (kern_mknod(td, uap->path, UIO_USERSPACE, uap->mode, uap->dev)); > + return (kern_mknodat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + uap->mode, uap->dev)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -1247,14 +1241,6 @@ sys_mknodat(struct thread *td, struct > mknodat_args *uap) > } > > int > -kern_mknod(struct thread *td, char *path, enum uio_seg pathseg, int mode, > - int dev) > -{ > - > - return (kern_mknodat(td, AT_FDCWD, path, pathseg, mode, dev)); > -} > - > -int > kern_mknodat(struct thread *td, int fd, char *path, enum uio_seg pathseg, > int mode, int dev) > { > @@ -1373,7 +1359,8 @@ sys_mkfifo(td, uap) > } */ *uap; > { > > - return (kern_mkfifo(td, uap->path, UIO_USERSPACE, uap->mode)); > + return (kern_mkfifoat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + uap->mode)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -1392,13 +1379,6 @@ sys_mkfifoat(struct thread *td, struct > mkfifoat_args *uap) > } > > int > -kern_mkfifo(struct thread *td, char *path, enum uio_seg pathseg, int > mode) > -{ > - > - return (kern_mkfifoat(td, AT_FDCWD, path, pathseg, mode)); > -} > - > -int > kern_mkfifoat(struct thread *td, int fd, char *path, enum uio_seg pathseg, > int mode) > { > @@ -1470,7 +1450,8 @@ sys_link(td, uap) > } */ *uap; > { > > - return (kern_link(td, uap->path, uap->link, UIO_USERSPACE)); > + return (kern_linkat(td, AT_FDCWD, AT_FDCWD, uap->path, uap->link, > + UIO_USERSPACE, FOLLOW)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -1535,13 +1516,6 @@ can_hardlink(struct vnode *vp, struct ucred *cred) > } > > int > -kern_link(struct thread *td, char *path, char *link, enum uio_seg segflg) > -{ > - > - return (kern_linkat(td, AT_FDCWD, AT_FDCWD, path,link, segflg, FOLLOW)); > -} > - > -int > kern_linkat(struct thread *td, int fd1, int fd2, char *path1, char *path2, > enum uio_seg segflg, int follow) > { > @@ -1643,7 +1617,8 @@ sys_symlink(td, uap) > } */ *uap; > { > > - return (kern_symlink(td, uap->path, uap->link, UIO_USERSPACE)); > + return (kern_symlinkat(td, uap->path, AT_FDCWD, uap->link, > + UIO_USERSPACE)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -1662,13 +1637,6 @@ sys_symlinkat(struct thread *td, struct > symlinkat_args *uap) > } > > int > -kern_symlink(struct thread *td, char *path, char *link, enum uio_seg > segflg) > -{ > - > - return (kern_symlinkat(td, path, AT_FDCWD, link, segflg)); > -} > - > -int > kern_symlinkat(struct thread *td, char *path1, int fd, char *path2, > enum uio_seg segflg) > { > @@ -1796,7 +1764,7 @@ sys_unlink(td, uap) > } */ *uap; > { > > - return (kern_unlink(td, uap->path, UIO_USERSPACE)); > + return (kern_unlinkat(td, AT_FDCWD, uap->path, UIO_USERSPACE, 0)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -1823,13 +1791,6 @@ sys_unlinkat(struct thread *td, struct > unlinkat_args *uap) > } > > int > -kern_unlink(struct thread *td, char *path, enum uio_seg pathseg) > -{ > - > - return (kern_unlinkat(td, AT_FDCWD, path, pathseg, 0)); > -} > - > -int > kern_unlinkat(struct thread *td, int fd, char *path, enum uio_seg pathseg, > ino_t oldinum) > { > @@ -2032,7 +1993,8 @@ sys_access(td, uap) > } */ *uap; > { > > - return (kern_access(td, uap->path, UIO_USERSPACE, uap->amode)); > + return (kern_accessat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + 0, uap->amode)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -2047,20 +2009,11 @@ int > sys_faccessat(struct thread *td, struct faccessat_args *uap) > { > > - if (uap->flag & ~AT_EACCESS) > - return (EINVAL); > return (kern_accessat(td, uap->fd, uap->path, UIO_USERSPACE, uap->flag, > uap->amode)); > } > > int > -kern_access(struct thread *td, char *path, enum uio_seg pathseg, int > amode) > -{ > - > - return (kern_accessat(td, AT_FDCWD, path, pathseg, 0, amode)); > -} > - > -int > kern_accessat(struct thread *td, int fd, char *path, enum uio_seg pathseg, > int flag, int amode) > { > @@ -2070,6 +2023,8 @@ kern_accessat(struct thread *td, int fd, char > *path, enum uio_seg pathseg, > cap_rights_t rights; > int error; > > + if (flag & ~AT_EACCESS) > + return (EINVAL); > if (amode != F_OK && (amode & ~(R_OK | W_OK | X_OK)) != 0) > return (EINVAL); > > @@ -2124,14 +2079,8 @@ sys_eaccess(td, uap) > } */ *uap; > { > > - return (kern_eaccess(td, uap->path, UIO_USERSPACE, uap->amode)); > -} > - > -int > -kern_eaccess(struct thread *td, char *path, enum uio_seg pathseg, int > amode) > -{ > - > - return (kern_accessat(td, AT_FDCWD, path, pathseg, AT_EACCESS, amode)); > + return (kern_accessat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + AT_EACCESS, uap->amode)); > } > > #if defined(COMPAT_43) > @@ -2156,7 +2105,8 @@ ostat(td, uap) > struct ostat osb; > int error; > > - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, > + &sb, NULL); > if (error != 0) > return (error); > cvtstat(&sb, &osb); > @@ -2184,7 +2134,8 @@ olstat(td, uap) > struct ostat osb; > int error; > > - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, > + UIO_USERSPACE, &sb, NULL); > if (error != 0) > return (error); > cvtstat(&sb, &osb); > @@ -2241,7 +2192,8 @@ sys_stat(td, uap) > struct stat sb; > int error; > > - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, > + &sb, NULL); > if (error == 0) > error = copyout(&sb, uap->ub, sizeof (sb)); > return (error); > @@ -2262,29 +2214,14 @@ sys_fstatat(struct thread *td, struct > fstatat_args *uap) > int error; > > error = kern_statat(td, uap->flag, uap->fd, uap->path, > - UIO_USERSPACE, &sb); > + UIO_USERSPACE, &sb, NULL); > if (error == 0) > error = copyout(&sb, uap->buf, sizeof (sb)); > return (error); > } > > int > -kern_stat(struct thread *td, char *path, enum uio_seg pathseg, struct > stat *sbp) > -{ > - > - return (kern_statat(td, 0, AT_FDCWD, path, pathseg, sbp)); > -} > - > -int > kern_statat(struct thread *td, int flag, int fd, char *path, > - enum uio_seg pathseg, struct stat *sbp) > -{ > - > - return (kern_statat_vnhook(td, flag, fd, path, pathseg, sbp, NULL)); > -} > - > -int > -kern_statat_vnhook(struct thread *td, int flag, int fd, char *path, > enum uio_seg pathseg, struct stat *sbp, > void (*hook)(struct vnode *vp, struct stat *sbp)) > { > @@ -2342,20 +2279,13 @@ sys_lstat(td, uap) > struct stat sb; > int error; > > - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, > + UIO_USERSPACE, &sb, NULL); > if (error == 0) > error = copyout(&sb, uap->ub, sizeof (sb)); > return (error); > } > > -int > -kern_lstat(struct thread *td, char *path, enum uio_seg pathseg, > struct stat *sbp) > -{ > - > - return (kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, path, pathseg, > - sbp)); > -} > - > /* > * Implementation of the NetBSD [l]stat() functions. > */ > @@ -2402,7 +2332,8 @@ sys_nstat(td, uap) > struct nstat nsb; > int error; > > - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE, > + &sb, NULL); > if (error != 0) > return (error); > cvtnstat(&sb, &nsb); > @@ -2430,7 +2361,8 @@ sys_nlstat(td, uap) > struct nstat nsb; > int error; > > - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); > + error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path, > + UIO_USERSPACE, &sb, NULL); > if (error != 0) > return (error); > cvtnstat(&sb, &nsb); > @@ -2519,8 +2451,8 @@ sys_readlink(td, uap) > } */ *uap; > { > > - return (kern_readlink(td, uap->path, UIO_USERSPACE, uap->buf, > - UIO_USERSPACE, uap->count)); > + return (kern_readlinkat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + uap->buf, UIO_USERSPACE, uap->count)); > } > #ifndef _SYS_SYSPROTO_H_ > struct readlinkat_args { > @@ -2539,15 +2471,6 @@ sys_readlinkat(struct thread *td, struct > readlinkat_args *uap) > } > > int > -kern_readlink(struct thread *td, char *path, enum uio_seg pathseg, > char *buf, > - enum uio_seg bufseg, size_t count) > -{ > - > - return (kern_readlinkat(td, AT_FDCWD, path, pathseg, buf, bufseg, > - count)); > -} > - > -int > kern_readlinkat(struct thread *td, int fd, char *path, enum uio_seg > pathseg, > char *buf, enum uio_seg bufseg, size_t count) > { > @@ -2655,7 +2578,8 @@ sys_chflags(td, uap) > } */ *uap; > { > > - return (kern_chflags(td, uap->path, UIO_USERSPACE, uap->flags)); > + return (kern_chflagsat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + uap->flags, 0)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -2680,14 +2604,6 @@ sys_chflagsat(struct thread *td, struct > chflagsat_args *uap) > return (kern_chflagsat(td, fd, path, UIO_USERSPACE, flags, atflag)); > } > > -static int > -kern_chflags(struct thread *td, const char *path, enum uio_seg pathseg, > - u_long flags) > -{ > - > - return (kern_chflagsat(td, AT_FDCWD, path, pathseg, flags, 0)); > -} > - > /* > * Same as chflags() but doesn't follow symlinks. > */ > @@ -2808,7 +2724,8 @@ sys_chmod(td, uap) > } */ *uap; > { > > - return (kern_chmod(td, uap->path, UIO_USERSPACE, uap->mode)); > + return (kern_fchmodat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + uap->mode, 0)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -2833,13 +2750,6 @@ sys_fchmodat(struct thread *td, struct > fchmodat_args *uap) > return (kern_fchmodat(td, fd, path, UIO_USERSPACE, mode, flag)); > } > > -int > -kern_chmod(struct thread *td, char *path, enum uio_seg pathseg, int mode) > -{ > - > - return (kern_fchmodat(td, AT_FDCWD, path, pathseg, mode, 0)); > -} > - > /* > * Change mode of a file given path name (don't follow links.) > */ > @@ -2961,7 +2871,8 @@ sys_chown(td, uap) > } */ *uap; > { > > - return (kern_chown(td, uap->path, UIO_USERSPACE, uap->uid, uap->gid)); > + return (kern_fchownat(td, 0, uap->path, UIO_USERSPACE, uap->uid, > + uap->gid, 0)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -2987,14 +2898,6 @@ sys_fchownat(struct thread *td, struct > fchownat_args *uap) > } > > int > -kern_chown(struct thread *td, char *path, enum uio_seg pathseg, int uid, > - int gid) > -{ > - > - return (kern_fchownat(td, AT_FDCWD, path, pathseg, uid, gid, 0)); > -} > - > -int > kern_fchownat(struct thread *td, int fd, char *path, enum uio_seg pathseg, > int uid, int gid, int flag) > { > @@ -3035,16 +2938,8 @@ sys_lchown(td, uap) > } */ *uap; > { > > - return (kern_lchown(td, uap->path, UIO_USERSPACE, uap->uid, uap->gid)); > -} > - > -int > -kern_lchown(struct thread *td, char *path, enum uio_seg pathseg, int uid, > - int gid) > -{ > - > - return (kern_fchownat(td, AT_FDCWD, path, pathseg, uid, gid, > - AT_SYMLINK_NOFOLLOW)); > + return (kern_fchownat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + uap->uid, uap->gid, AT_SYMLINK_NOFOLLOW)); > } > > /* > @@ -3174,8 +3069,8 @@ sys_utimes(td, uap) > } */ *uap; > { > > - return (kern_utimes(td, uap->path, UIO_USERSPACE, uap->tptr, > - UIO_USERSPACE)); > + return (kern_utimesat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + uap->tptr, UIO_USERSPACE)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -3194,14 +3089,6 @@ sys_futimesat(struct thread *td, struct > futimesat_args *uap) > } > > int > -kern_utimes(struct thread *td, char *path, enum uio_seg pathseg, > - struct timeval *tptr, enum uio_seg tptrseg) > -{ > - > - return (kern_utimesat(td, AT_FDCWD, path, pathseg, tptr, tptrseg)); > -} > - > -int > kern_utimesat(struct thread *td, int fd, char *path, enum uio_seg pathseg, > struct timeval *tptr, enum uio_seg tptrseg) > { > @@ -3500,7 +3387,8 @@ sys_rename(td, uap) > } */ *uap; > { > > - return (kern_rename(td, uap->from, uap->to, UIO_USERSPACE)); > + return (kern_renameat(td, AT_FDCWD, uap->from, AT_FDCWD, > + uap->to, UIO_USERSPACE)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -3520,13 +3408,6 @@ sys_renameat(struct thread *td, struct > renameat_args *uap) > } > > int > -kern_rename(struct thread *td, char *from, char *to, enum uio_seg > pathseg) > -{ > - > - return (kern_renameat(td, AT_FDCWD, from, AT_FDCWD, to, pathseg)); > -} > - > -int > kern_renameat(struct thread *td, int oldfd, char *old, int newfd, char > *new, > enum uio_seg pathseg) > { > @@ -3675,7 +3556,8 @@ sys_mkdir(td, uap) > } */ *uap; > { > > - return (kern_mkdir(td, uap->path, UIO_USERSPACE, uap->mode)); > + return (kern_mkdirat(td, AT_FDCWD, uap->path, UIO_USERSPACE, > + uap->mode)); > } > > #ifndef _SYS_SYSPROTO_H_ > @@ -3693,13 +3575,6 @@ sys_mkdirat(struct thread *td, struct > mkdirat_args *uap) > } > > int > -kern_mkdir(struct thread *td, char *path, enum uio_seg segflg, int mode) > -{ > - > - return (kern_mkdirat(td, AT_FDCWD, path, segflg, mode)); > -} > - > -int > kern_mkdirat(struct thread *td, int fd, char *path, enum uio_seg segflg, > int mode) > { > @@ -3777,14 +3652,7 @@ sys_rmdir(td, uap) > } */ *uap; > { > > - return (kern_rmdir(td, uap->path, UIO_USERSPACE)); > -} > - > -int > -kern_rmdir(struct thread *td, char *path, enum uio_seg pathseg) > -{ > - > - return (kern_rmdirat(td, AT_FDCWD, path, pathseg)); > + return (kern_rmdirat(td, AT_FDCWD, uap->path, UIO_USERSPACE)); > } > > int > diff --git a/sys/sys/syscallsubr.h b/sys/sys/syscallsubr.h > index 7098c43..266c619 100644 > --- a/sys/sys/syscallsubr.h > +++ b/sys/sys/syscallsubr.h > @@ -62,22 +62,16 @@ int kern_accept(struct thread *td, int s, struct > sockaddr **name, > socklen_t *namelen, struct file **fp); > int kern_accept4(struct thread *td, int s, struct sockaddr **name, > socklen_t *namelen, int flags, struct file **fp); > -int kern_access(struct thread *td, char *path, enum uio_seg pathseg, > - int flags); > int kern_accessat(struct thread *td, int fd, char *path, > enum uio_seg pathseg, int flags, int mode); > int kern_adjtime(struct thread *td, struct timeval *delta, > struct timeval *olddelta); > int kern_alternate_path(struct thread *td, const char *prefix, const > char *path, > enum uio_seg pathseg, char **pathbuf, int create, int dirfd); > -int kern_bind(struct thread *td, int fd, struct sockaddr *sa); > +int kern_bindat(struct thread *td, int dirfd, int fd, struct sockaddr > *sa); > int kern_cap_ioctls_limit(struct thread *td, int fd, u_long *cmds, > size_t ncmds); > int kern_chdir(struct thread *td, char *path, enum uio_seg pathseg); > -int kern_chmod(struct thread *td, char *path, enum uio_seg pathseg, > - int mode); > -int kern_chown(struct thread *td, char *path, enum uio_seg pathseg, > int uid, > - int gid); > int kern_clock_getcpuclockid2(struct thread *td, id_t id, int which, > clockid_t *clk_id); > int kern_clock_getres(struct thread *td, clockid_t clock_id, > @@ -87,9 +81,8 @@ int kern_clock_gettime(struct thread *td, clockid_t > clock_id, > int kern_clock_settime(struct thread *td, clockid_t clock_id, > struct timespec *ats); > int kern_close(struct thread *td, int fd); > -int kern_connect(struct thread *td, int fd, struct sockaddr *sa); > -int kern_eaccess(struct thread *td, char *path, enum uio_seg pathseg, > - int flags); > +int kern_connectat(struct thread *td, int dirfd, int fd, > + struct sockaddr *sa); > int kern_execve(struct thread *td, struct image_args *args, > struct mac *mac_p); > int kern_fchmodat(struct thread *td, int fd, char *path, > @@ -127,26 +120,14 @@ int kern_kevent(struct thread *td, int fd, int > nchanges, int nevents, > int kern_kldload(struct thread *td, const char *file, int *fileid); > int kern_kldstat(struct thread *td, int fileid, struct kld_file_stat > *stat); > int kern_kldunload(struct thread *td, int fileid, int flags); > -int kern_lchown(struct thread *td, char *path, enum uio_seg pathseg, > - int uid, int gid); > -int kern_link(struct thread *td, char *path, char *link, > - enum uio_seg segflg); > int kern_linkat(struct thread *td, int fd1, int fd2, char *path1, > char *path2, enum uio_seg segflg, int follow); > -int kern_lstat(struct thread *td, char *path, enum uio_seg pathseg, > - struct stat *sbp); > int kern_lutimes(struct thread *td, char *path, enum uio_seg pathseg, > struct timeval *tptr, enum uio_seg tptrseg); > -int kern_mkdir(struct thread *td, char *path, enum uio_seg segflg, > - int mode); > int kern_mkdirat(struct thread *td, int fd, char *path, > enum uio_seg segflg, int mode); > -int kern_mkfifo(struct thread *td, char *path, enum uio_seg pathseg, > - int mode); > int kern_mkfifoat(struct thread *td, int fd, char *path, > enum uio_seg pathseg, int mode); > -int kern_mknod(struct thread *td, char *path, enum uio_seg pathseg, > - int mode, int dev); > int kern_mknodat(struct thread *td, int fd, char *path, > enum uio_seg pathseg, int mode, int dev); > int kern_msgctl(struct thread *, int, int, struct msqid_ds *); > @@ -156,8 +137,6 @@ int kern_nanosleep(struct thread *td, struct > timespec *rqt, > struct timespec *rmt); > int kern_ogetdirentries(struct thread *td, struct ogetdirentries_args > *uap, > long *ploff); > -int kern_open(struct thread *td, char *path, enum uio_seg pathseg, > - int flags, int mode); > int kern_openat(struct thread *td, int fd, char *path, > enum uio_seg pathseg, int flags, int mode); > int kern_pathconf(struct thread *td, char *path, enum uio_seg pathseg, > @@ -176,18 +155,13 @@ int kern_pselect(struct thread *td, int nd, > fd_set *in, fd_set *ou, > int kern_ptrace(struct thread *td, int req, pid_t pid, void *addr, > int data); > int kern_pwritev(struct thread *td, int fd, struct uio *auio, off_t > offset); > -int kern_readlink(struct thread *td, char *path, enum uio_seg pathseg, > - char *buf, enum uio_seg bufseg, size_t count); > int kern_readlinkat(struct thread *td, int fd, char *path, > enum uio_seg pathseg, char *buf, enum uio_seg bufseg, size_t count); > int kern_readv(struct thread *td, int fd, struct uio *auio); > int kern_recvit(struct thread *td, int s, struct msghdr *mp, > enum uio_seg fromseg, struct mbuf **controlp); > -int kern_rename(struct thread *td, char *from, char *to, > - enum uio_seg pathseg); > int kern_renameat(struct thread *td, int oldfd, char *old, int newfd, > char *new, enum uio_seg pathseg); > -int kern_rmdir(struct thread *td, char *path, enum uio_seg pathseg); > int kern_rmdirat(struct thread *td, int fd, char *path, > enum uio_seg pathseg); > int kern_sched_rr_get_interval(struct thread *td, pid_t pid, > @@ -220,17 +194,11 @@ int kern_sigprocmask(struct thread *td, int how, > int kern_sigsuspend(struct thread *td, sigset_t mask); > int kern_sigtimedwait(struct thread *td, sigset_t waitset, > struct ksiginfo *ksi, struct timespec *timeout); > -int kern_stat(struct thread *td, char *path, enum uio_seg pathseg, > - struct stat *sbp); > int kern_statat(struct thread *td, int flag, int fd, char *path, > - enum uio_seg pathseg, struct stat *sbp); > -int kern_statat_vnhook(struct thread *td, int flag, int fd, char *path, > enum uio_seg pathseg, struct stat *sbp, > void (*hook)(struct vnode *vp, struct stat *sbp)); > int kern_statfs(struct thread *td, char *path, enum uio_seg pathseg, > struct statfs *buf); > -int kern_symlink(struct thread *td, char *path, char *link, > - enum uio_seg segflg); > int kern_symlinkat(struct thread *td, char *path1, int fd, char *path2, > enum uio_seg segflg); > int kern_ktimer_create(struct thread *td, clockid_t clock_id, > @@ -245,11 +213,8 @@ int kern_thr_new(struct thread *td, struct > thr_param *param); > int kern_thr_suspend(struct thread *td, struct timespec *tsp); > int kern_truncate(struct thread *td, char *path, enum uio_seg pathseg, > off_t length); > -int kern_unlink(struct thread *td, char *path, enum uio_seg pathseg); > int kern_unlinkat(struct thread *td, int fd, char *path, > enum uio_seg pathseg, ino_t oldinum); > -int kern_utimes(struct thread *td, char *path, enum uio_seg pathseg, > - struct timeval *tptr, enum uio_seg tptrseg); > int kern_utimesat(struct thread *td, int fd, char *path, > enum uio_seg pathseg, struct timeval *tptr, enum uio_seg tptrseg); > int kern_wait(struct thread *td, pid_t pid, int *status, int options, > _______________________________________________ > 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" -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 22:31:48 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76CE0AB0; Wed, 12 Nov 2014 22:31:48 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AD462FB; Wed, 12 Nov 2014 22:31:48 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 2A8F33592DE; Wed, 12 Nov 2014 23:31:45 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 18C8F28494; Wed, 12 Nov 2014 23:31:45 +0100 (CET) Date: Wed, 12 Nov 2014 23:31:45 +0100 From: Jilles Tjoelker To: Jonathan Anderson Subject: Re: Removal of kern_xxx() no-at variants. Message-ID: <20141112223144.GA90037@stack.nl> References: <20141112132451.GM17068@kib.kiev.ua> <201411121014.04482.jhb@freebsd.org> <5463C39C.2010204@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5463C39C.2010204@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , Benjamin Kaduk , freebsd-arch@freebsd.org, fs@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:31:48 -0000 On Wed, Nov 12, 2014 at 05:01:24PM -0330, Jonathan Anderson wrote: > A thought: > If we're only going to have one of {kern_open,kern_openat}, might it > make sense to keep the shorter name rather than the longer one? > kern_openat as a name seems meaningful to me only if we're trying to > disambiguate it from an also-existent-but-different-meaning kern_open. The name kern_openat makes sense in that the functionality is like the openat() system call. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 02:13:57 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBBB3C4B for ; Thu, 13 Nov 2014 02:13:57 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70E78BEA for ; Thu, 13 Nov 2014 02:13:57 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id b13so15691530wgh.40 for ; Wed, 12 Nov 2014 18:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=zoA9XYvg8iavRLC0byKYEwbPEGLYvv8OrqkQgsBNoVs=; b=MiqWGLBHdaeufIrjqM6TWa9CUnVpVJ1OAFsfdBk4u30NN/LqEnB2eunGKVgvo+d3UZ XtNgDzQXo63HRHZQgk20nsH8bqDHuK6ITQe4QAfAqNef3hbzRTzl64kkqY0U3aHi52AU wMMBB++xj/rcSAE/RnPq3EWR4rj7Te/N4huWHZY5N4cKw3byV6hjzSU1LPW2tgySqSzp eRM4Y0clIxS5dFy2m+5CGzVQ5tqSB2QkifB9452VHmKnJq6oiEw36CcDaWIRPcE2XBzw xGFqekQxLXM89W3ngN9O9gbhsZvgOvGDV2x6g4kmAiCiz8j8p1/WWomwXgwYg+v7kDhG JQ/Q== MIME-Version: 1.0 X-Received: by 10.180.87.33 with SMTP id u1mr53972178wiz.20.1415844835816; Wed, 12 Nov 2014 18:13:55 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 12 Nov 2014 18:13:55 -0800 (PST) Date: Wed, 12 Nov 2014 18:13:55 -0800 X-Google-Sender-Auth: EKReAbnRxz_sJ9uJVR2K3Rb3Wgs Message-ID: Subject: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 02:13:57 -0000 Hi, I have a bit of an odd case here. I'm getting panics in the net80211/ath code, "sleeping thread (X) owns non-sleepable lock." show alllocks just showed one lock held - the net80211 comlock. It's a recursive mutex, that's supposed to be sleepable. The two threads in question look like this: thread X: net80211_newstate_cb (grabs IEEE80211_LOCK()) ath_newstate callout_drain - which grabs the ATH_LOCK as part of the callout drain side of things that enters sleepq_wait() and goes to sleep, waiting for whatever's running the callout to finish thread Y: rx_path in if_ath_rx_edma ath_rx_pkt -> sta_input -> ath_recv_mgmt -> sta_recv_mgmt (grabs IEEE80211_LOCK()) -> panics Thread Y doesn't hold any other locks. It's just trying to grab the IEEE80211_LOCK that is being held by thread X. But thread X is asleep waiting for whatever callout to finish so it can continue. The code in propagate_priority() sees that thread X is sleeping and panics. So, what's really going on? I don't mind (well, "don't mind") having to take another deep dive through all of this to sort it out so it doesn't tickle the callout / turnstile code in this particular fashion, but I'd first like to ensure that it's not some corner case that isn't handled by the check in propagate_priority(). Thanks, -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 02:26:21 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25922E67; Thu, 13 Nov 2014 02:26:21 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDB12CBE; Thu, 13 Nov 2014 02:26:20 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id m20so10369482qcx.16 for ; Wed, 12 Nov 2014 18:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=JFeuz8bZ0zxb4U17uSmuFV0B7FRBiba1SWYWNT9fFgs=; b=tpqTBw8uT35DewjBWffv2d/pDCthDd9IuxzLCbDea98U2WXXj/lJrdlURzMEYeNnhi GYs7dun1YXfLmQoBTSGUYnppFTCUZ+Mf/dxHOZsVBiDtgxblLfczMo8phk9/IxjDkPps +SMtS4d1AtdsBBCzsrzXiW467HYX1f33bdpqmXashnDgasVpu7jBBRta2mQ00KRcREBo xelR0I9fxPkPtpJ1PHXzHO2hlczGOOCItOE9srW+wq+OdLqN7cnhf/yzqP2hlbc0z1An DfpZySpriuABF8V4hZ6bgk62pqYrwWJ+yUD5NG1sg1fLJJXIcnInx4wTedoi8sMc5hh4 iI7g== X-Received: by 10.140.44.36 with SMTP id f33mr62379255qga.105.1415845579944; Wed, 12 Nov 2014 18:26:19 -0800 (PST) Received: from kan ([2601:6:6780:7e0:226:18ff:fe00:232e]) by mx.google.com with ESMTPSA id z32sm22748232qgd.40.2014.11.12.18.26.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Nov 2014 18:26:19 -0800 (PST) Date: Wed, 12 Nov 2014 21:26:13 -0500 From: Alexander Kabaev To: Adrian Chadd Subject: Re: Questions about locking; turnstiles and sleeping threads Message-ID: <20141112212613.21037929@kan> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Xb6osdN4Oqbwi=eEkl3Fapy"; protocol="application/pgp-signature" Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 02:26:21 -0000 --Sig_/Xb6osdN4Oqbwi=eEkl3Fapy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 12 Nov 2014 18:13:55 -0800 Adrian Chadd wrote: > Hi, >=20 > I have a bit of an odd case here. >=20 > I'm getting panics in the net80211/ath code, "sleeping thread (X) owns > non-sleepable lock." >=20 > show alllocks just showed one lock held - the net80211 comlock. It's a > recursive mutex, that's supposed to be sleepable. >=20 > The two threads in question look like this: >=20 > thread X: net80211_newstate_cb (grabs IEEE80211_LOCK()) > ath_newstate > callout_drain - which grabs the ATH_LOCK as part of the callout > drain side of things > that enters sleepq_wait() and goes to sleep, waiting for > whatever's running the callout to > finish >=20 > thread Y: > rx_path in if_ath_rx_edma > ath_rx_pkt -> sta_input -> ath_recv_mgmt -> sta_recv_mgmt (grabs > IEEE80211_LOCK()) -> panics >=20 > Thread Y doesn't hold any other locks. It's just trying to grab the > IEEE80211_LOCK that is being held by thread X. But thread X is asleep > waiting for whatever callout to finish so it can continue. The code in > propagate_priority() sees that thread X is sleeping and panics. >=20 > So, what's really going on? I don't mind (well, "don't mind") having > to take another deep dive through all of this to sort it out so it > doesn't tickle the callout / turnstile code in this particular > fashion, but I'd first like to ensure that it's not some corner case > that isn't handled by the check in propagate_priority(). >=20 > Thanks, >=20 >=20 > -adrian > _______________________________________________ Hi, mutexes are blocking and not sleepable primitives, so doing any unbounded sleep with mutex locked, such as one you are attempting by calling callout_drain is illegal. In other words, you are getting an expected assert and the code in question is wrong. --=20 Alexander Kabaev --Sig_/Xb6osdN4Oqbwi=eEkl3Fapy Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iD8DBQFUZBbKQ6z1jMm+XZYRAlweAJwNJIf8jm8HQineNZpI5O0mF9prVACeKWUM a/Fbvs0x7U/dY6itBVE7w2E= =bOf1 -----END PGP SIGNATURE----- --Sig_/Xb6osdN4Oqbwi=eEkl3Fapy-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 03:39:52 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AD2ABDC for ; Thu, 13 Nov 2014 03:39:52 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27AF8607 for ; Thu, 13 Nov 2014 03:39:52 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so15816917wgg.32 for ; Wed, 12 Nov 2014 19:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rX2tmEdy7oJT681mwgrId+ouGepdPkmX6LzEjWAV+Qc=; b=z5Ab24ZEZdzi38x3PIugXSSHztZmqkIZ2oauR200U7jHXGifxlDRLeW/Pl1rEnUvkg fS6i/pLmAtzedhy+QozrMUnx+xhErZAzRRQe1CuVRQGY2hvFNZcZAwZJ3X/U6/oduICz dRJGfJAmc9Xix5o16QP9M3dCfw7hC0tXkS4HJXa00qbghkBx+Ku8lqSvv6Z1/I0m3Gnm C1VHPR+7XYUuw2PLAZipzFhZOmaf7XbQQCrBKGB+UTTn0mZyc22MF4zOieG0ZV3OOsUQ tbA79RIrpJU6e/mGQSyQO9uPJB0JMsz8SY/61vNlouf6Uiqg0KK1C53e49vDwhAp/goF TYKQ== MIME-Version: 1.0 X-Received: by 10.180.92.169 with SMTP id cn9mr35711234wib.26.1415849990527; Wed, 12 Nov 2014 19:39:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 12 Nov 2014 19:39:50 -0800 (PST) In-Reply-To: <20141112212613.21037929@kan> References: <20141112212613.21037929@kan> Date: Wed, 12 Nov 2014 19:39:50 -0800 X-Google-Sender-Auth: _0o7ZBoTZgZjNivDyMU2uTfWdM8 Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Alexander Kabaev Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 03:39:52 -0000 On 12 November 2014 18:26, Alexander Kabaev wrote: > On Wed, 12 Nov 2014 18:13:55 -0800 > Adrian Chadd wrote: > >> Hi, >> >> I have a bit of an odd case here. >> >> I'm getting panics in the net80211/ath code, "sleeping thread (X) owns >> non-sleepable lock." >> >> show alllocks just showed one lock held - the net80211 comlock. It's a >> recursive mutex, that's supposed to be sleepable. >> >> The two threads in question look like this: >> >> thread X: net80211_newstate_cb (grabs IEEE80211_LOCK()) >> ath_newstate >> callout_drain - which grabs the ATH_LOCK as part of the callout >> drain side of things >> that enters sleepq_wait() and goes to sleep, waiting for >> whatever's running the callout to >> finish >> >> thread Y: >> rx_path in if_ath_rx_edma >> ath_rx_pkt -> sta_input -> ath_recv_mgmt -> sta_recv_mgmt (grabs >> IEEE80211_LOCK()) -> panics >> >> Thread Y doesn't hold any other locks. It's just trying to grab the >> IEEE80211_LOCK that is being held by thread X. But thread X is asleep >> waiting for whatever callout to finish so it can continue. The code in >> propagate_priority() sees that thread X is sleeping and panics. >> >> So, what's really going on? I don't mind (well, "don't mind") having >> to take another deep dive through all of this to sort it out so it >> doesn't tickle the callout / turnstile code in this particular >> fashion, but I'd first like to ensure that it's not some corner case >> that isn't handled by the check in propagate_priority(). >> >> Thanks, >> >> >> -adrian >> _______________________________________________ > > Hi, > > mutexes are blocking and not sleepable primitives, so doing any > unbounded sleep with mutex locked, such as one you are attempting by > calling callout_drain is illegal. In other words, you are getting an > expected assert and the code in question is wrong. Hi, Right. That isn't mentioned in the manpage. The manpage says: The function callout_drain() is identical to callout_stop() except that it will wait for the callout to be completed if it is already in progress. This function MUST NOT be called while holding any locks on which the callout might block, or deadlock will result. Note that if the callout subsystem has already begun processing this callout, then the callout function may be invoked during the execution of callout_drain(). However, the callout subsystem does guarantee that the callout will be fully stopped before callout_drain() returns. The callout isn't going to block here, but another thread may block. This is good to know. I'll see if I can come up with an addition to the manpage about this. I'm going to have to do another pass over all of the wifi drivers and stack to see where this is happening. Ugh. :( Thanks! -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 03:48:49 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF3AFE35 for ; Thu, 13 Nov 2014 03:48:49 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B9BF6EA for ; Thu, 13 Nov 2014 03:48:49 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so6918675wiv.8 for ; Wed, 12 Nov 2014 19:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WmGCOkLotlShEycCdSC8TW4YbwmG5heyo4GcExjOQy4=; b=rW74BtqUuKsQNS5vDwp3OORBCTqL7kIe3MWurjMLKA7u35870lHq7zEAO+gKewGIzX 5Jjxhw/hruk3Z3uJoPaiQOB5w0lW6MtOAsOe3pqRkxnw8Z/cTSjARc/RtmEHg83/EDvB H7/wwwwRpNXYaEx2FfkC8iggp+1THwxE3bTzRhW6UEqOMN6JVu1/IPRguQtNvmg7VTVI FEav4x//68c4GgnE4lr+Vkjd66nEl79YeitBguLkJjiu5Vd/I9nU0NWBTrbnne77PWjF WyClIj4mBT1lbyzZbJ43i1Kvr79FBIeEuTN426JEYW84DfCORDpttFeHhF3j2HuXQmhR UJig== MIME-Version: 1.0 X-Received: by 10.180.99.105 with SMTP id ep9mr10686366wib.26.1415850527580; Wed, 12 Nov 2014 19:48:47 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 12 Nov 2014 19:48:47 -0800 (PST) In-Reply-To: References: <20141112212613.21037929@kan> Date: Wed, 12 Nov 2014 19:48:47 -0800 X-Google-Sender-Auth: HKYgmQIMzIreEQi9h6JX7TnL-EE Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Alexander Kabaev Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 03:48:49 -0000 kan pointed out that we should likely do a WITNESS_WARN() in the relevant spots in the callout code so we catch these before it happens. I'll see what we can add to -HEAD to be pro-active about it. Thanks, -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 07:25:15 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53DCC9B7 for ; Thu, 13 Nov 2014 07:25:15 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6DD7C2E for ; Thu, 13 Nov 2014 07:25:14 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id n3so7290971wiv.6 for ; Wed, 12 Nov 2014 23:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CmHB52tcThdH8ZYPIsIa4DeBZR7WGLtoDfnDYWd2AM8=; b=c0PUPwXNm8fht16rCZa8t4F3VurLpf53Lbl4+LLGIJCkYp8ciLhBX8el7V6x5yoGAd XYOmbB1PRhi1PkJ1bcnff9EXwlHw1yDzWOa7FKciiN4cS3VkiDsQYv/PWEspHIZsSijg YJe/ED66Q0WjzMhCPOVme+gInWSy/QogrkR06RPInNaD46LxtUOvgnX/hmQ0PpI89/ow f9dVyt0Bd8X9B8qa5AEZgTqmtwsV5/Hjupp8SNniyUhg9N/5w5Hm6HF94AL7x9A96Iu+ wDY9SA8y/GkNFSypgi3t38qTVAlGZbFaJOAugALaK/BBwmoDiwtL5CAbW3lEmLHDCdEX YSKA== MIME-Version: 1.0 X-Received: by 10.180.108.35 with SMTP id hh3mr981404wib.59.1415863513337; Wed, 12 Nov 2014 23:25:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 12 Nov 2014 23:25:13 -0800 (PST) In-Reply-To: References: <20141112212613.21037929@kan> Date: Wed, 12 Nov 2014 23:25:13 -0800 X-Google-Sender-Auth: cO4_loOEFi56lfZWfqrHPIc-k6c Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Alexander Kabaev Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 07:25:15 -0000 On 12 November 2014 19:48, Adrian Chadd wrote: > kan pointed out that we should likely do a WITNESS_WARN() in the > relevant spots in the callout code so we catch these before it > happens. > > I'll see what we can add to -HEAD to be pro-active about it. Amusingly, I tried adding it and it made my laptop turn to soup very quickly - among other things, the TCP timer callouts are all setup with non sleep locks held. -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 08:59:08 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86F94205; Thu, 13 Nov 2014 08:59:08 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 72332860; Thu, 13 Nov 2014 08:59:08 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 2BAE7341F854; Thu, 13 Nov 2014 00:59:08 -0800 (PST) Message-ID: <546472DA.3080006@freebsd.org> Date: Thu, 13 Nov 2014 00:59:06 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org, Adrian Chadd Subject: Re: Questions about locking; turnstiles and sleeping threads References: <20141112212613.21037929@kan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 08:59:08 -0000 On 11/12/14, 11:25 PM, Adrian Chadd wrote: > On 12 November 2014 19:48, Adrian Chadd wrote: >> kan pointed out that we should likely do a WITNESS_WARN() in the >> relevant spots in the callout code so we catch these before it >> happens. >> >> I'll see what we can add to -HEAD to be pro-active about it. > Amusingly, I tried adding it and it made my laptop turn to soup very > quickly - among other things, the TCP timer callouts are all setup > with non sleep locks held. > Howso? You only have to worry about callout_drain(), most other callout functions should be safe-ish.... -Alfred From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 09:09:45 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52CD8601; Thu, 13 Nov 2014 09:09:45 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D65DE962; Thu, 13 Nov 2014 09:09:44 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id n12so16276009wgh.27 for ; Thu, 13 Nov 2014 01:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZSljn1TJZUwncX6VR4JJNBFoxgY/9cHAQ15WuJYDprs=; b=0/c78VaM3d+wI/ep38oNU0gcQY+a7PwrxZvkaCUiflIW61IDs39Q9NeXgBdeiVSKIa 2rkOx4LXIJXU/NC/S4W/+UdPIFT1h5BngDx9XSACkT4Og4OEIV7SQiS42+y7Nxd/uzpd ntVsfCUuGzyDYK4AjgSMvniurUN4K5LyUl8rjAbZuOW0fUVdcWZsati07GQJQStVyEeo NZIOdpOGuVNzut8z9y5sELrhwdVG2octPudQ+8rldk0iC50GgruXFmMY0etEWobOA6tH 9/KJvTMYqnnZbb8jClz3A/PyRTW3xZzdJRmJsmNaohCk7Ax6BA8+hHst8kMATLw1T8go 1CJg== MIME-Version: 1.0 X-Received: by 10.180.188.102 with SMTP id fz6mr1719451wic.59.1415869783298; Thu, 13 Nov 2014 01:09:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 13 Nov 2014 01:09:43 -0800 (PST) In-Reply-To: <546472DA.3080006@freebsd.org> References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> Date: Thu, 13 Nov 2014 01:09:43 -0800 X-Google-Sender-Auth: 6uZop6itgP-DTdGVz-KWlyU2KMQ Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 09:09:45 -0000 On 13 November 2014 00:59, Alfred Perlstein wrote: > > On 11/12/14, 11:25 PM, Adrian Chadd wrote: >> >> On 12 November 2014 19:48, Adrian Chadd wrote: >>> >>> kan pointed out that we should likely do a WITNESS_WARN() in the >>> relevant spots in the callout code so we catch these before it >>> happens. >>> >>> I'll see what we can add to -HEAD to be pro-active about it. >> >> Amusingly, I tried adding it and it made my laptop turn to soup very >> quickly - among other things, the TCP timer callouts are all setup >> with non sleep locks held. >> > > Howso? You only have to worry about callout_drain(), most other callout > functions should be safe-ish.... yeah, except for all the places where they drain the timer once something happens so it doesn't fire. :) -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 09:13:51 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9D0B7E1; Thu, 13 Nov 2014 09:13:51 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C3BB4A47; Thu, 13 Nov 2014 09:13:51 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id D4652341F844; Thu, 13 Nov 2014 01:13:50 -0800 (PST) Message-ID: <5464764E.9080308@freebsd.org> Date: Thu, 13 Nov 2014 01:13:50 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Questions about locking; turnstiles and sleeping threads References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 09:13:51 -0000 On 11/13/14, 1:09 AM, Adrian Chadd wrote: > On 13 November 2014 00:59, Alfred Perlstein wrote: >> On 11/12/14, 11:25 PM, Adrian Chadd wrote: >>> On 12 November 2014 19:48, Adrian Chadd wrote: >>>> kan pointed out that we should likely do a WITNESS_WARN() in the >>>> relevant spots in the callout code so we catch these before it >>>> happens. >>>> >>>> I'll see what we can add to -HEAD to be pro-active about it. >>> Amusingly, I tried adding it and it made my laptop turn to soup very >>> quickly - among other things, the TCP timer callouts are all setup >>> with non sleep locks held. >>> >> Howso? You only have to worry about callout_drain(), most other callout >> functions should be safe-ish.... > yeah, except for all the places where they drain the timer once > something happens so it doesn't fire. > > :) What is the backtrace...? From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 09:38:33 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89FB8E58; Thu, 13 Nov 2014 09:38:33 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CEBDCA2; Thu, 13 Nov 2014 09:38:33 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id a1so16412461wgh.34 for ; Thu, 13 Nov 2014 01:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wntqBGuWdvav0aCjACtVxdh1XpfQJBCGJg6iJI/AwtA=; b=PaMPpZEZDvG3KJIR90BvDPF0BIKq24WJ7xOSUKWkpWD2oki9jpbNrLK7vruFYJoNJO CjaxLEOw75bNO1yC3v4q+Dszu+glK6Gv6ygKgVKuPsReyyI8qZuunCDd168EmCYevywA C+Vz2KTRZYFE6jBvB511CrQeFA7ajyw4llOr1m6R/XfnBt5ljaf0uJySCK7WPw5sESK5 wIK0oML2qoj0Zy/n/PIzKPUXWN+Y7yGcCK+1e4/9cOD9LJul8CBUmgzhaHKjzlAMAFH0 1MuFytXa2AYCX6m2/ojJ8LcQqaSh+vNIdL7Q4k1zD0xnp11Hc4J8Dvn6ObkenqHe9uiZ A0jQ== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr2176667wjn.68.1415871511518; Thu, 13 Nov 2014 01:38:31 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 13 Nov 2014 01:38:31 -0800 (PST) In-Reply-To: <5464764E.9080308@freebsd.org> References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> <5464764E.9080308@freebsd.org> Date: Thu, 13 Nov 2014 01:38:31 -0800 X-Google-Sender-Auth: 3mNnIBUBkZ65LoLVAEE1Bvq8xrU Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 09:38:33 -0000 It looks like the initial firings are because the check I put in didn't check to see if it's MPSAFE. eg: ip6_input -> tcp6_input -> tcp_input -> tcp_do_segment -> tcp_timer_active -> callout_stop_safe; called with tcpinp held. closefp() -> closef() -> fdrop -> soclose() -> sofree() -> tcp_usr_detach() -> tcp_discardcb() -> callout_stop_safe() with the tcpinp and tcp locks held. ioctl -> sys_ioctl-> devfs_ioctl_f -> acpi_ackSleepState -> callout_stop_safe; with ACPI global lock held; suspend path -> hdaa_suspend -> callout_stop_safe() with HDA driver mutex held So we can't just put the simple witness check from _sleep() in _callout_stop_safe(), it looks like it's mis-firing on MPSAFE callouts (which the tcp timers all are) and that won't go via the sleepq. It looks like the acpi callout is also mpsafe, as well as the HDA jack callout. However, I did pick up this: detach path -> usbd_transfer_drain() -> usbd_transfer_stop() -> ehci_device_intr_close() -> usbd_transfer_done() -> callout_stop_safe() with USB HUB mutex held The usbd_transfer_done() callout is initialised with a mutex, but the witness code should've detected it wasn't callout->c_lock and thus warned. -adrian On 13 November 2014 01:13, Alfred Perlstein wrote: > > On 11/13/14, 1:09 AM, Adrian Chadd wrote: >> >> On 13 November 2014 00:59, Alfred Perlstein wrote: >>> >>> On 11/12/14, 11:25 PM, Adrian Chadd wrote: >>>> >>>> On 12 November 2014 19:48, Adrian Chadd wrote: >>>>> >>>>> kan pointed out that we should likely do a WITNESS_WARN() in the >>>>> relevant spots in the callout code so we catch these before it >>>>> happens. >>>>> >>>>> I'll see what we can add to -HEAD to be pro-active about it. >>>> >>>> Amusingly, I tried adding it and it made my laptop turn to soup very >>>> quickly - among other things, the TCP timer callouts are all setup >>>> with non sleep locks held. >>>> >>> Howso? You only have to worry about callout_drain(), most other callout >>> functions should be safe-ish.... >> >> yeah, except for all the places where they drain the timer once >> something happens so it doesn't fire. >> >> :) > > > What is the backtrace...? > > From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 09:38:58 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95EA1EFB; Thu, 13 Nov 2014 09:38:58 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0642BCA6; Thu, 13 Nov 2014 09:38:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAD9cquY099473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 11:38:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAD9cquY099473 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAD9cqM9099472; Thu, 13 Nov 2014 11:38:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 13 Nov 2014 11:38:52 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: Removal of kern_xxx() no-at variants. Message-ID: <20141113093852.GU17068@kib.kiev.ua> References: <20141112132451.GM17068@kib.kiev.ua> <201411121014.04482.jhb@freebsd.org> <5463C39C.2010204@FreeBSD.org> <20141112223144.GA90037@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141112223144.GA90037@stack.nl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Benjamin Kaduk , freebsd-arch@freebsd.org, fs@freebsd.org, Jonathan Anderson , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 09:38:58 -0000 On Wed, Nov 12, 2014 at 11:31:45PM +0100, Jilles Tjoelker wrote: > On Wed, Nov 12, 2014 at 05:01:24PM -0330, Jonathan Anderson wrote: > > A thought: > > > If we're only going to have one of {kern_open,kern_openat}, might it > > make sense to keep the shorter name rather than the longer one? > > kern_openat as a name seems meaningful to me only if we're trying to > > disambiguate it from an also-existent-but-different-meaning kern_open. > > The name kern_openat makes sense in that the functionality is like the > openat() system call. I like the proposal, but think that it is premature, unfortunately. Issue is the MFC to stable branches, which still have old functions used in code. I do not mean merge of this change to stable, but other merges which intersect with the at/no-at modifications. Having kern_open() as different functions in HEAD and stable is too confusing without real value IMO. Note that it is possible to partially MFC the commit into stable, leaving the removal of the no-at variants out of the patch. From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 09:42:55 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FB581D8; Thu, 13 Nov 2014 09:42:55 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 66EA2D6F; Thu, 13 Nov 2014 09:42:55 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 33212341F84E; Thu, 13 Nov 2014 01:42:55 -0800 (PST) Message-ID: <54647D1E.9010904@freebsd.org> Date: Thu, 13 Nov 2014 01:42:54 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Questions about locking; turnstiles and sleeping threads References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> <5464764E.9080308@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 09:42:55 -0000 OK that makes more sense. I've cc'd Hans for the usb issue. On 11/13/14, 1:38 AM, Adrian Chadd wrote: > It looks like the initial firings are because the check I put in > didn't check to see if it's MPSAFE. > > eg: > > ip6_input -> tcp6_input -> tcp_input -> tcp_do_segment -> > tcp_timer_active -> callout_stop_safe; called with tcpinp held. > closefp() -> closef() -> fdrop -> soclose() -> sofree() -> > tcp_usr_detach() -> tcp_discardcb() -> callout_stop_safe() with the > tcpinp and tcp locks held. > ioctl -> sys_ioctl-> devfs_ioctl_f -> acpi_ackSleepState -> > callout_stop_safe; with ACPI global lock held; > suspend path -> hdaa_suspend -> callout_stop_safe() with HDA driver mutex held > > So we can't just put the simple witness check from _sleep() in > _callout_stop_safe(), it looks like it's mis-firing on MPSAFE callouts > (which the tcp timers all are) and that won't go via the sleepq. > It looks like the acpi callout is also mpsafe, as well as the HDA jack callout. > > However, I did pick up this: > > detach path -> usbd_transfer_drain() -> usbd_transfer_stop() -> > ehci_device_intr_close() -> usbd_transfer_done() -> > callout_stop_safe() with USB HUB mutex held > > The usbd_transfer_done() callout is initialised with a mutex, but the > witness code should've detected it wasn't callout->c_lock and thus > warned. > > > > -adrian > > On 13 November 2014 01:13, Alfred Perlstein wrote: >> On 11/13/14, 1:09 AM, Adrian Chadd wrote: >>> On 13 November 2014 00:59, Alfred Perlstein wrote: >>>> On 11/12/14, 11:25 PM, Adrian Chadd wrote: >>>>> On 12 November 2014 19:48, Adrian Chadd wrote: >>>>>> kan pointed out that we should likely do a WITNESS_WARN() in the >>>>>> relevant spots in the callout code so we catch these before it >>>>>> happens. >>>>>> >>>>>> I'll see what we can add to -HEAD to be pro-active about it. >>>>> Amusingly, I tried adding it and it made my laptop turn to soup very >>>>> quickly - among other things, the TCP timer callouts are all setup >>>>> with non sleep locks held. >>>>> >>>> Howso? You only have to worry about callout_drain(), most other callout >>>> functions should be safe-ish.... >>> yeah, except for all the places where they drain the timer once >>> something happens so it doesn't fire. >>> >>> :) >> >> What is the backtrace...? >> >> > _______________________________________________ > 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 Thu Nov 13 09:52:52 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E023483; Thu, 13 Nov 2014 09:52:52 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A2C5EB0; Thu, 13 Nov 2014 09:52:52 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so16643931wgg.19 for ; Thu, 13 Nov 2014 01:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zghHcdYlYyirQMi3dXPjo6qAxQk+1a+RzJMmRvDHgu0=; b=bT8fiR1h6BlU7AvmRXtyCt0uuLeCSt1rYn6njCIgkFaACLj1ud2CFuNHvIRwRMGvBY dfi2RU+MRMz0348f+iYTlQRRHGiej5UDAgwv7LZGAViUnTIvMmGpcKGlvVmNcazElAPP f/VgXOcoKQTcAoUa2qJEdk/Qj2O6/It0tW9yNaI0wkOS8kzzm94hjZm8inbyWGUNW8m4 bzes5GeE4td2dgnQHoylUTHXKcGF8WhFiFuNiOLBqv2WGvrEwLK5dei79+d+7Pbp73UU RzoUbcGUiAU6VvSEVc3C1DD7W3tnnnd+4Kl3KrifafwKg3KDRG5hk4Rd6onfiYkwRuVS 0o6A== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr2429878wjz.20.1415872370440; Thu, 13 Nov 2014 01:52:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 13 Nov 2014 01:52:50 -0800 (PST) In-Reply-To: <54647D1E.9010904@freebsd.org> References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> <5464764E.9080308@freebsd.org> <54647D1E.9010904@freebsd.org> Date: Thu, 13 Nov 2014 01:52:50 -0800 X-Google-Sender-Auth: MXuuXbVAppHEhEieRbE4bsCdYJQ Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 09:52:52 -0000 Hm, the more I dig into this, the more I realise it's not a 1:45am question to ask. Specifically, callout_stop_safe() takes 'safe', which says "are we waiting around for this callout to finish if it started". Ie, callout_drain() is callout_stop_safe(c, 1) ; callout_stop() is callout_stop_safe(c, 0). If safe is 1, then it'll potentially put the current thread to sleep in order to wait for it to synchronise with the callout that's running. It's sleeping with cc_lock which is the per-callwheel lock and it's doing that with whatever other locks are held. That's the situation which is tripping things up. The manpage says that no locks should be held that the callout may block on, which isn't the case here at all - I'm trying to grab a lock in another thread that the caller _into_ the callout subsystem holds. The manpage doesn't mention anything about this. Sniffle. -adrian On 13 November 2014 01:42, Alfred Perlstein wrote: > OK that makes more sense. > > I've cc'd Hans for the usb issue. > > > On 11/13/14, 1:38 AM, Adrian Chadd wrote: >> >> It looks like the initial firings are because the check I put in >> didn't check to see if it's MPSAFE. >> >> eg: >> >> ip6_input -> tcp6_input -> tcp_input -> tcp_do_segment -> >> tcp_timer_active -> callout_stop_safe; called with tcpinp held. >> closefp() -> closef() -> fdrop -> soclose() -> sofree() -> >> tcp_usr_detach() -> tcp_discardcb() -> callout_stop_safe() with the >> tcpinp and tcp locks held. >> ioctl -> sys_ioctl-> devfs_ioctl_f -> acpi_ackSleepState -> >> callout_stop_safe; with ACPI global lock held; >> suspend path -> hdaa_suspend -> callout_stop_safe() with HDA driver mutex >> held >> >> So we can't just put the simple witness check from _sleep() in >> _callout_stop_safe(), it looks like it's mis-firing on MPSAFE callouts >> (which the tcp timers all are) and that won't go via the sleepq. >> It looks like the acpi callout is also mpsafe, as well as the HDA jack >> callout. >> >> However, I did pick up this: >> >> detach path -> usbd_transfer_drain() -> usbd_transfer_stop() -> >> ehci_device_intr_close() -> usbd_transfer_done() -> >> callout_stop_safe() with USB HUB mutex held >> >> The usbd_transfer_done() callout is initialised with a mutex, but the >> witness code should've detected it wasn't callout->c_lock and thus >> warned. >> >> >> >> -adrian >> >> On 13 November 2014 01:13, Alfred Perlstein wrote: >>> >>> On 11/13/14, 1:09 AM, Adrian Chadd wrote: >>>> >>>> On 13 November 2014 00:59, Alfred Perlstein wrote: >>>>> >>>>> On 11/12/14, 11:25 PM, Adrian Chadd wrote: >>>>>> >>>>>> On 12 November 2014 19:48, Adrian Chadd wrote: >>>>>>> >>>>>>> kan pointed out that we should likely do a WITNESS_WARN() in the >>>>>>> relevant spots in the callout code so we catch these before it >>>>>>> happens. >>>>>>> >>>>>>> I'll see what we can add to -HEAD to be pro-active about it. >>>>>> >>>>>> Amusingly, I tried adding it and it made my laptop turn to soup very >>>>>> quickly - among other things, the TCP timer callouts are all setup >>>>>> with non sleep locks held. >>>>>> >>>>> Howso? You only have to worry about callout_drain(), most other >>>>> callout >>>>> functions should be safe-ish.... >>>> >>>> yeah, except for all the places where they drain the timer once >>>> something happens so it doesn't fire. >>>> >>>> :) >>> >>> >>> What is the backtrace...? >>> >>> >> _______________________________________________ >> 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 Thu Nov 13 10:14:28 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5AFBA93; Thu, 13 Nov 2014 10:14:28 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9BECE1AB; Thu, 13 Nov 2014 10:14:28 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 00D9D341F84E; Thu, 13 Nov 2014 02:14:27 -0800 (PST) Message-ID: <54648483.5060107@freebsd.org> Date: Thu, 13 Nov 2014 02:14:27 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Questions about locking; turnstiles and sleeping threads References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> <5464764E.9080308@freebsd.org> <54647D1E.9010904@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 10:14:28 -0000 Would need more context to help on this. I can't tell based on your description which thread is holding which lock. If A is waiting for callout C to stop AND there exists a thread B that is contending against C for a lock, you should be fine so long as there is no lock cycle against A. Would be best if you pointed at some code and gave descriptions. -Alfred On 11/13/14, 1:52 AM, Adrian Chadd wrote: > Hm, the more I dig into this, the more I realise it's not a 1:45am > question to ask. > > Specifically, callout_stop_safe() takes 'safe', which says "are we > waiting around for this callout to finish if it started". Ie, > callout_drain() is callout_stop_safe(c, 1) ; callout_stop() is > callout_stop_safe(c, 0). > > If safe is 1, then it'll potentially put the current thread to sleep > in order to wait for it to synchronise with the callout that's > running. It's sleeping with cc_lock which is the per-callwheel lock > and it's doing that with whatever other locks are held. That's the > situation which is tripping things up. > > The manpage says that no locks should be held that the callout may > block on, which isn't the case here at all - I'm trying to grab a lock > in another thread that the caller _into_ the callout subsystem holds. > The manpage doesn't mention anything about this. Sniffle. > > > > -adrian > > On 13 November 2014 01:42, Alfred Perlstein wrote: >> OK that makes more sense. >> >> I've cc'd Hans for the usb issue. >> >> >> On 11/13/14, 1:38 AM, Adrian Chadd wrote: >>> It looks like the initial firings are because the check I put in >>> didn't check to see if it's MPSAFE. >>> >>> eg: >>> >>> ip6_input -> tcp6_input -> tcp_input -> tcp_do_segment -> >>> tcp_timer_active -> callout_stop_safe; called with tcpinp held. >>> closefp() -> closef() -> fdrop -> soclose() -> sofree() -> >>> tcp_usr_detach() -> tcp_discardcb() -> callout_stop_safe() with the >>> tcpinp and tcp locks held. >>> ioctl -> sys_ioctl-> devfs_ioctl_f -> acpi_ackSleepState -> >>> callout_stop_safe; with ACPI global lock held; >>> suspend path -> hdaa_suspend -> callout_stop_safe() with HDA driver mutex >>> held >>> >>> So we can't just put the simple witness check from _sleep() in >>> _callout_stop_safe(), it looks like it's mis-firing on MPSAFE callouts >>> (which the tcp timers all are) and that won't go via the sleepq. >>> It looks like the acpi callout is also mpsafe, as well as the HDA jack >>> callout. >>> >>> However, I did pick up this: >>> >>> detach path -> usbd_transfer_drain() -> usbd_transfer_stop() -> >>> ehci_device_intr_close() -> usbd_transfer_done() -> >>> callout_stop_safe() with USB HUB mutex held >>> >>> The usbd_transfer_done() callout is initialised with a mutex, but the >>> witness code should've detected it wasn't callout->c_lock and thus >>> warned. >>> >>> >>> >>> -adrian >>> >>> On 13 November 2014 01:13, Alfred Perlstein wrote: >>>> On 11/13/14, 1:09 AM, Adrian Chadd wrote: >>>>> On 13 November 2014 00:59, Alfred Perlstein wrote: >>>>>> On 11/12/14, 11:25 PM, Adrian Chadd wrote: >>>>>>> On 12 November 2014 19:48, Adrian Chadd wrote: >>>>>>>> kan pointed out that we should likely do a WITNESS_WARN() in the >>>>>>>> relevant spots in the callout code so we catch these before it >>>>>>>> happens. >>>>>>>> >>>>>>>> I'll see what we can add to -HEAD to be pro-active about it. >>>>>>> Amusingly, I tried adding it and it made my laptop turn to soup very >>>>>>> quickly - among other things, the TCP timer callouts are all setup >>>>>>> with non sleep locks held. >>>>>>> >>>>>> Howso? You only have to worry about callout_drain(), most other >>>>>> callout >>>>>> functions should be safe-ish.... >>>>> yeah, except for all the places where they drain the timer once >>>>> something happens so it doesn't fire. >>>>> >>>>> :) >>>> >>>> What is the backtrace...? >>>> >>>> >>> _______________________________________________ >>> 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" >>> > _______________________________________________ > 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 Thu Nov 13 12:40:31 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A34D8BB5; Thu, 13 Nov 2014 12:40:31 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 810E9383; Thu, 13 Nov 2014 12:40:30 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sADCeI3h065602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 13 Nov 2014 04:40:22 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5464A6AB.5060006@freebsd.org> Date: Thu, 13 Nov 2014 20:40:11 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd , Alexander Kabaev Subject: Re: Questions about locking; turnstiles and sleeping threads References: <20141112212613.21037929@kan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 12:40:31 -0000 On 11/13/14, 11:39 AM, Adrian Chadd wrote: > On 12 November 2014 18:26, Alexander Kabaev wrote: >> On Wed, 12 Nov 2014 18:13:55 -0800 >> Adrian Chadd wrote: >> >>> Hi, >>> >>> I have a bit of an odd case here. >>> >>> I'm getting panics in the net80211/ath code, "sleeping thread (X) owns >>> non-sleepable lock." >>> >>> show alllocks just showed one lock held - the net80211 comlock. It's a >>> recursive mutex, that's supposed to be sleepable. >>> >>> The two threads in question look like this: >>> >>> thread X: net80211_newstate_cb (grabs IEEE80211_LOCK()) >>> ath_newstate >>> callout_drain - which grabs the ATH_LOCK as part of the callout >>> drain side of things >>> that enters sleepq_wait() and goes to sleep, waiting for >>> whatever's running the callout to >>> finish >>> >>> thread Y: >>> rx_path in if_ath_rx_edma >>> ath_rx_pkt -> sta_input -> ath_recv_mgmt -> sta_recv_mgmt (grabs >>> IEEE80211_LOCK()) -> panics >>> >>> Thread Y doesn't hold any other locks. It's just trying to grab the >>> IEEE80211_LOCK that is being held by thread X. But thread X is asleep >>> waiting for whatever callout to finish so it can continue. The code in >>> propagate_priority() sees that thread X is sleeping and panics. >>> >>> So, what's really going on? I don't mind (well, "don't mind") having >>> to take another deep dive through all of this to sort it out so it >>> doesn't tickle the callout / turnstile code in this particular >>> fashion, but I'd first like to ensure that it's not some corner case >>> that isn't handled by the check in propagate_priority(). >>> >>> Thanks, >>> >>> >>> -adrian >>> _______________________________________________ >> Hi, >> >> mutexes are blocking and not sleepable primitives, so doing any >> unbounded sleep with mutex locked, such as one you are attempting by >> calling callout_drain is illegal. In other words, you are getting an >> expected assert and the code in question is wrong. > Hi, > > Right. That isn't mentioned in the manpage. The manpage says: > > The function callout_drain() is identical to callout_stop() except that > it will wait for the callout to be completed if it is already in > progress. This function MUST NOT be called while holding any locks on > which the callout might block, or deadlock will result. Note that if the > callout subsystem has already begun processing this callout, then the > callout function may be invoked during the execution of callout_drain(). > However, the callout subsystem does guarantee that the callout will be > fully stopped before callout_drain() returns. also look at 'man locking' > > The callout isn't going to block here, but another thread may block. > > This is good to know. I'll see if I can come up with an addition to > the manpage about this. > > I'm going to have to do another pass over all of the wifi drivers and > stack to see where this is happening. Ugh. :( > > Thanks! > > > > -adrian > _______________________________________________ > 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 Thu Nov 13 15:26:12 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D681FF0; Thu, 13 Nov 2014 15:26:12 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 651A39CC; Thu, 13 Nov 2014 15:26:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D40B9B978; Thu, 13 Nov 2014 10:26:10 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Questions about locking; turnstiles and sleeping threads Date: Thu, 13 Nov 2014 09:48:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <54647D1E.9010904@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411130948.23785.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 13 Nov 2014 10:26:10 -0500 (EST) Cc: Hans Petter Selasky , Adrian Chadd , Alfred Perlstein X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 15:26:12 -0000 On Thursday, November 13, 2014 4:52:50 am Adrian Chadd wrote: > Hm, the more I dig into this, the more I realise it's not a 1:45am > question to ask. > > Specifically, callout_stop_safe() takes 'safe', which says "are we > waiting around for this callout to finish if it started". Ie, > callout_drain() is callout_stop_safe(c, 1) ; callout_stop() is > callout_stop_safe(c, 0). > > If safe is 1, then it'll potentially put the current thread to sleep > in order to wait for it to synchronise with the callout that's > running. It's sleeping with cc_lock which is the per-callwheel lock > and it's doing that with whatever other locks are held. That's the > situation which is tripping things up. > > The manpage says that no locks should be held that the callout may > block on, which isn't the case here at all - I'm trying to grab a lock > in another thread that the caller _into_ the callout subsystem holds. > The manpage doesn't mention anything about this. Sniffle. It should just say "no sleepable locks at all". And yes, callout_stop() is perfectly fine to call with locks held. It is only callout_drain() that should not be called, same as with bus_teardown_intr() and taskqueue_drain() (other routines that can sleep while ensuring that an asynchronous task run by another thread is stopped). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 16:33:20 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1FA916A for ; Thu, 13 Nov 2014 16:33:20 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C57EF283 for ; Thu, 13 Nov 2014 16:33:20 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.07,378,1413270000"; d="scan'208";a="167252752" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx11-out.netapp.com with ESMTP; 13 Nov 2014 08:33:19 -0800 Received: from HIOEXCMBX04-PRD.hq.netapp.com (10.122.105.37) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 13 Nov 2014 08:33:19 -0800 Received: from HIOEXCMBX04-PRD.hq.netapp.com ([::1]) by hioexcmbx04-prd.hq.netapp.com ([fe80::21b0:30f8:e5e7:1628%21]) with mapi id 15.00.0995.031; Thu, 13 Nov 2014 08:33:19 -0800 From: "Grier, James" To: "freebsd-arch@freebsd.org" Subject: missing DTrace FBT return probes Thread-Topic: missing DTrace FBT return probes Thread-Index: AQHP/1+HfG5PV5P3T0K171xqbKlAsQ== Date: Thu, 13 Nov 2014 16:33:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 16:33:21 -0000 T24gV2VkLCBKdW4gNSwgMjAxMyBhdCA1OjUwIFBNLCBOYXZkZWVwIFBhcmhhciA8bnAgYXQgZnJl ZWJzZC5vcmc+IHdyb3RlOiA+IEEgbGFyZ2UgbnVtYmVyIG9mIGtlcm5lbCBmdW5jdGlvbnMgaGF2 ZSBhbiBGQlQgZW50cnkgcHJvYmUgYnV0IG5vIHJldHVybiANCj4gcHJvYmUuIEkgYmVsaWV2ZSB0 aGlzIGlzIGR1ZSB0byB0YWlsIGNhbGwgb3B0aW1pemF0aW9uIGJ5IHRoZSBjb21waWxlci4gDQo+ IFNob3VsZCB3ZSBkaXNhYmxlIHRoaXMgb3B0aW1pemF0aW9uIGZvciBrZXJuZWwgY29uZmlncyB0 aGF0IGhhdmUgRFRyYWNlIA0KPiBzdXBwb3J0PyBUaGUgbWlzc2luZyByZXR1cm4gcHJvYmVzIG1h a2UgaXQgdmVyeSBkaWZmaWN1bHQgdG8gd3JpdGUgDQo+IERUcmFjZSBzY3JpcHRzIHRoYXQgd2Fu dCB0byBzZXQgZmxhZ3MgZXRjLiBhdCBmdW5jdGlvbiBlbnRyeSBhbmQgdGhlbiANCj4gY2xlYW4g dGhlbSB1cCBvbiByZXR1cm4uIA0KPg0KPiBBIHF1aWNrIHNhbXBsZSBmcm9tIGEgcmVjZW50IEhF QUQgc2hvd3MgfjQwMDAgb3V0IG9mIH4yNzAwMCBmdW5jdGlvbnMgDQo+IGFyZSBtaXNzaW5nIHJl dHVybiBwcm9iZXMuIFNlZSB0aGUgbGlzdCBvZiBmdW5jdGlvbnMgaW4gdGhlc2UgZmlsZXMgDQo+ ICh0aGUgb25lcyBsaXN0ZWQgaW4gZW50cnktb25seS50eHQgZG8gbm90IGhhdmUgcmV0dXJuIHBy b2JlcykuIA0KPg0KPiBodHRwOi8vcGVvcGxlLmZyZWVic2Qub3JnL35ucC9lbnRyeS1vbmx5LnR4 dA0KPiBodHRwOi8vcGVvcGxlLmZyZWVic2Qub3JnL35ucC9lbnRyeS50eHQNCj4gaHR0cDovL3Bl b3BsZS5mcmVlYnNkLm9yZy9+bnAvcmV0dXJuLnR4dA0KPg0KPiBSZWdhcmRzLCANCj4gTmF2ZGVl cCANCg0KQnkgdHJpYWwgYW5kIGVycm9yLCBJIGRpc2NvdmVyZWQgdGhhdCBpdOKAmXMg4oCYLWZ1 bml0LWF0LWEtdGltZeKAmSB0aGF0IGRvZXMgdGhlIGRpcnR5IHdvcmssIHNvDQp1c2luZyDigJgt Zm5vLXVuaXQtYXQtYS10aW1l4oCZIHdpdGggLU8yIHdlIGdldCBhbGwgdGhlIHJldHVybiBmYnQg cHJvYmVzLiBJIGhhdmVu4oCZdCBkZXRlcm1pbmVkDQp0aGUgcGVyZm9ybWFuY2UgaW1wYWN0IG9m IHRoaXMuDQoNCg== From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 17:31:41 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D0976A5; Thu, 13 Nov 2014 17:31:41 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18230B67; Thu, 13 Nov 2014 17:31:41 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id b13so17494796wgh.12 for ; Thu, 13 Nov 2014 09:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WMUQxXyKgzJR8dxW5YPni21SELfVwsePu9xAPBYRrNA=; b=D/XU8/Ae3tYu6Q9k3DwH4hoUyVYqQFP957lqfr6VfYpN4a5gQqQDEa2wd8BQLueBQR CdZ/6QE9nKCkmtkjcwodwV2ZECpH4vRGHFx781zQC/HoSRvGnTo31BKvoijG93cn6Ohe 8sDsIb9QNUgK8E6hHow1OanLme4vcdVQccKac3qFOjlU7LXlHTbn0f5hMz3VSqsZT5MU YCd8LxRsUaKJIjv4CBZ20l4Uv2nxMjefjvewf0HNJZwMGQr/HMz+jNeUhtwb6smTdgX0 irxt5uZCyvzDbBQ83fw5mTGFLbRtTPOre+ZVD36tM2vdnX7qdhQR7Pa0uOj6fuOmPYk5 C9yg== MIME-Version: 1.0 X-Received: by 10.180.87.33 with SMTP id u1mr392066wiz.20.1415899899486; Thu, 13 Nov 2014 09:31:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 13 Nov 2014 09:31:39 -0800 (PST) In-Reply-To: <54648483.5060107@freebsd.org> References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> <5464764E.9080308@freebsd.org> <54647D1E.9010904@freebsd.org> <54648483.5060107@freebsd.org> Date: Thu, 13 Nov 2014 09:31:39 -0800 X-Google-Sender-Auth: NNe0Rpb6admvFeEe_aGwTbRWm6Q Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 17:31:41 -0000 On 13 November 2014 02:14, Alfred Perlstein wrote: > Would need more context to help on this. > > I can't tell based on your description which thread is holding which lock. > > If A is waiting for callout C to stop AND there exists a thread B that is > contending against C for a lock, you should be fine so long as there is no > lock cycle against A. > > Would be best if you pointed at some code and gave descriptions. I haven't dug into the USB side of things ,but on the atheros side I gave the description above. Thread A grabs lock X and tries to drain callout, which involves grabbing lock Y to do the dirty work. Lock Y isn't held at this point - the callout is about to run or is running, so it enters the sleepq call to finish the drain. Thread B wants to grab lock X, but can't because thread A holds lock X and is in a sleepq due to callout_drain(). Hence panic. I'll poke people on IRC today and see if I can get a better description of what/where the WITNESS_WARN() should be placed in callout_drain(). Then we'll see what's left triggering it. -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 17:32:16 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65A5C76D; Thu, 13 Nov 2014 17:32:16 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06CC2B75; Thu, 13 Nov 2014 17:32:16 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so17516159wgg.32 for ; Thu, 13 Nov 2014 09:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1d4Etc2EKwk9xH3/Ymn6pgYv7kHgLK4GQN7g+GRsh5E=; b=e5+xyvrl/aF6nnnq5ZTmudn4IAs1PuoRS8hOmyhPZ96odhC946fC8x57+ag4BxGAyr kX4ECfolJU0ZLRcrDiGHFnMwkpOoVKQrjRu7FkAEQl2agrlF2nw8YZIjoiARsfB3aEqS QI4bKrUNvX6iW7d2Ncoogrrbii8m1qiY9KC6QSxqO2wh6O1fwcX1zcmjVy3DTWmYTFe2 Fnjscy33Yp9S2OQm43Nw7Faj2GYX/kJygISAXrFWKE7nFpHkbtS5s50Cqu4QQbZt/7wf C1aITsMdWddPLo8vCRfoP0QvzKjZhCdqqLVGpF5qOXuAuySv875U6SMk3byoveUHz8kG 5RtA== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr6392364wjz.20.1415899934503; Thu, 13 Nov 2014 09:32:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 13 Nov 2014 09:32:14 -0800 (PST) In-Reply-To: <201411130948.23785.jhb@freebsd.org> References: <54647D1E.9010904@freebsd.org> <201411130948.23785.jhb@freebsd.org> Date: Thu, 13 Nov 2014 09:32:14 -0800 X-Google-Sender-Auth: vclANLH5MH5sDqDuN4Hi9l5_NQw Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , Alfred Perlstein , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 17:32:16 -0000 On 13 November 2014 06:48, John Baldwin wrote: > On Thursday, November 13, 2014 4:52:50 am Adrian Chadd wrote: >> Hm, the more I dig into this, the more I realise it's not a 1:45am >> question to ask. >> >> Specifically, callout_stop_safe() takes 'safe', which says "are we >> waiting around for this callout to finish if it started". Ie, >> callout_drain() is callout_stop_safe(c, 1) ; callout_stop() is >> callout_stop_safe(c, 0). >> >> If safe is 1, then it'll potentially put the current thread to sleep >> in order to wait for it to synchronise with the callout that's >> running. It's sleeping with cc_lock which is the per-callwheel lock >> and it's doing that with whatever other locks are held. That's the >> situation which is tripping things up. >> >> The manpage says that no locks should be held that the callout may >> block on, which isn't the case here at all - I'm trying to grab a lock >> in another thread that the caller _into_ the callout subsystem holds. >> The manpage doesn't mention anything about this. Sniffle. > > It should just say "no sleepable locks at all". And yes, callout_stop() is > perfectly fine to call with locks held. It is only callout_drain() that > should not be called, same as with bus_teardown_intr() and taskqueue_drain() > (other routines that can sleep while ensuring that an asynchronous task run > by another thread is stopped). so, we should add WITNESS_WARN() to those as well? -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 17:56:10 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1D0764E; Thu, 13 Nov 2014 17:56:10 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79AD2DBB; Thu, 13 Nov 2014 17:56:10 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id v10so14901929pde.18 for ; Thu, 13 Nov 2014 09:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=+PvCPtId+UyNkrwKyVBhmiEjZy6ZJRO8OPEuba/RwOI=; b=QqZAAhPT1N2VAtZRZ8gLfAwNYRwFLyOWuz448TzPHqobeSxyLNQE6usUs55q/SC73m VSnpMF6Gf5TMdBclYUz+g6510us7v1M9JwbUFumriezPsDN9xa/IY0d8dPfjv5x4qCwE GAYRKQZscxV9oZOCcrEHWfNRinix2g/Aj/Y9ZSjyQ5iQ65q3UPm2HUDI5PeeuY+ww00q TwQp9TsUFC+sRjzwNh86BKojdr00vW/tpWrkRW2UJVvGXTNujPyO7IJGiKtBD5N83ZVH wdXJ6CvQ1Z3w2tbXHpB0hGR0eRCHhPcYhENe0xZKIuOBbZigjNaNJJkNvKyPHVugaQDw BBkA== X-Received: by 10.68.68.137 with SMTP id w9mr4283010pbt.71.1415901368371; Thu, 13 Nov 2014 09:56:08 -0800 (PST) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id ae4sm18950454pad.16.2014.11.13.09.56.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 09:56:07 -0800 (PST) References: <54647D1E.9010904@freebsd.org> <201411130948.23785.jhb@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: Questions about locking; turnstiles and sleeping threads Date: Thu, 13 Nov 2014 09:56:06 -0800 To: Adrian Chadd Cc: Hans Petter Selasky , Alfred Perlstein , Steve Kargl , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 17:56:10 -0000 > On Nov 13, 2014, at 09:32, Adrian Chadd wrote: >=20 >> On 13 November 2014 06:48, John Baldwin wrote: >>> On Thursday, November 13, 2014 4:52:50 am Adrian Chadd wrote: >>> Hm, the more I dig into this, the more I realise it's not a 1:45am >>> question to ask. >>>=20 >>> Specifically, callout_stop_safe() takes 'safe', which says "are we >>> waiting around for this callout to finish if it started". Ie, >>> callout_drain() is callout_stop_safe(c, 1) ; callout_stop() is >>> callout_stop_safe(c, 0). >>>=20 >>> If safe is 1, then it'll potentially put the current thread to sleep >>> in order to wait for it to synchronise with the callout that's >>> running. It's sleeping with cc_lock which is the per-callwheel lock >>> and it's doing that with whatever other locks are held. That's the >>> situation which is tripping things up. >>>=20 >>> The manpage says that no locks should be held that the callout may >>> block on, which isn't the case here at all - I'm trying to grab a lock >>> in another thread that the caller _into_ the callout subsystem holds. >>> The manpage doesn't mention anything about this. Sniffle. >>=20 >> It should just say "no sleepable locks at all". And yes, callout_stop() i= s >> perfectly fine to call with locks held. It is only callout_drain() that >> should not be called, same as with bus_teardown_intr() and taskqueue_drai= n() >> (other routines that can sleep while ensuring that an asynchronous task r= un >> by another thread is stopped). >=20 > so, we should add WITNESS_WARN() to those as well? This might be related to the issue Steve Kargl brought up in the thread "shu= tdown or ACPI problem" on -current@.= From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 18:44:19 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 599DB958 for ; Thu, 13 Nov 2014 18:44:19 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24E59378 for ; Thu, 13 Nov 2014 18:44:19 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id y13so15011514pdi.6 for ; Thu, 13 Nov 2014 10:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1WMrlrwSsNse1iW/LQMH/enyga9GmNquUGpNGvBbY6E=; b=fq1pMA0vupS0lasbSGi7Xz+kDzQtW/7D6XWVVblIQrX0PyZ5uJlyn0PGUE2p1frP5K Jvl7Ut9IOXZhVhVg9uuWCVapBic6LsiDpJp706Ac59etI0oJTwb65fzdQ684M+1srKJe uJtVWZLwiDKtcMgLSZDrxApQdPl/EiDq3RcxqG/kz1yC/4+iDUuVsh8gDl8J6QwZt3kD Mg/46ae9u8wmJMC5WswA5WZGB3ZelfzdyaehoBLk9eHcP5IwaOS6mbgwSubPmu69Jj/A sFExA7KHS4LVqplUdJ92n8z51PKEPELZ1+71/K0U7zqm/8E92zlwWnyCIV+CnBjaMu9s JAXg== X-Received: by 10.70.89.41 with SMTP id bl9mr4609739pdb.55.1415904258344; Thu, 13 Nov 2014 10:44:18 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id ev8sm25549929pdb.28.2014.11.13.10.44.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Nov 2014 10:44:17 -0800 (PST) Sender: Navdeep Parhar Message-ID: <5464FBFF.6020200@FreeBSD.org> Date: Thu, 13 Nov 2014 10:44:15 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Grier, James" , "freebsd-arch@freebsd.org" Subject: Re: missing DTrace FBT return probes References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 18:44:19 -0000 On 11/13/14 08:33, Grier, James wrote: > On Wed, Jun 5, 2013 at 5:50 PM, Navdeep Parhar wrot= e: > A large number of kernel functions have an FBT entry probe but no re= turn >> probe. I believe this is due to tail call optimization by the compiler= =2E >> Should we disable this optimization for kernel configs that have DTrac= e >> support? The missing return probes make it very difficult to write >> DTrace scripts that want to set flags etc. at function entry and then >> clean them up on return. >> >> A quick sample from a recent HEAD shows ~4000 out of ~27000 functions >> are missing return probes. See the list of functions in these files >> (the ones listed in entry-only.txt do not have return probes). >> >> http://people.freebsd.org/~np/entry-only.txt >> http://people.freebsd.org/~np/entry.txt >> http://people.freebsd.org/~np/return.txt >> >> Regards, >> Navdeep > > By trial and error, I discovered that it=E2=80=99s =E2=80=98-funit-at-a= -time=E2=80=99 that does the dirty work, so > using =E2=80=98-fno-unit-at-a-time=E2=80=99 with -O2 we get all the ret= urn fbt probes. I haven=E2=80=99t determined > the performance impact of this. Hmm, I thought it was -fno-optimize-sibling-calls that controlled this=20 particular optimization. These days I compile my debug kernels with -O0. There is a very=20 significant performance impact but it makes kgdb and DTrace very happy. Regards, Navdeep From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 23:01:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21FF6339; Thu, 13 Nov 2014 23:01:18 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8050391; Thu, 13 Nov 2014 23:01:17 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id h11so1091960wiw.9 for ; Thu, 13 Nov 2014 15:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vWat8BEJ8BNCUd8yhf13BFYL0VNS5CK8pV/GKTGzDKs=; b=QoK+Ycs4zwbrMW5XokV914Zf6jh4aSaZeQqK7p7af4Rbpr4Eg1CUl3VgeR7NQcwkhj VFqqxl4h79z8pcMHoyaPLeXVWAQmK5TY08msdSKCTT5VvTbEpmg4v451gSLjjaegSK/j wRXHJznlWPJJ7umr+A2/XP16XLBBO9qjuXEu1NRgz5DQ/5snrqMsIs3Kzb9FZ0ruoaAY fiqiebxNVc5UgKNOP04tzLKVMhgPm0/o0QdIPJicYWRnGJvj3XcVBuLKmNnLckhVAnio NAtRi7rnxwEuYvMGMSWnkQh7b6fNNI4i0GABHyGo4el/14I6pp4nPjVWV7Xu7Cb+Mr/2 G+Bg== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr8207426wjn.68.1415919676192; Thu, 13 Nov 2014 15:01:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 13 Nov 2014 15:01:16 -0800 (PST) In-Reply-To: References: <54647D1E.9010904@freebsd.org> <201411130948.23785.jhb@freebsd.org> Date: Thu, 13 Nov 2014 15:01:16 -0800 X-Google-Sender-Auth: J6BLBk6yX_KDWyI5Jbn3o0Vj_Zw Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , Alfred Perlstein , Steve Kargl , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:01:18 -0000 I'd like to try and add WITNESS_WARN() where appropriate. How's this look? Index: kern_timeout.c =================================================================== --- kern_timeout.c (revision 274304) +++ kern_timeout.c (working copy) @@ -1096,7 +1096,22 @@ struct lock_class *class; int direct, sq_locked, use_lock; + /* XXX GIANTOK? c_lock can be NULL? */ + /* + * If safe is clear then we're not going to drop into the + * sleepq wait routines. So, we don't have to check + * for the witness warning here. + * + * If safe is set then we may drop into the sleep routines + * so do the check. + */ + if (safe) { + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, c->c_lock, + "calling %s", __func__); + } + + /* * Some old subsystems don't hold Giant while running a callout_stop(), * so just discard this check for the moment. */ -adrian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 01:22:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1753B138; Fri, 14 Nov 2014 01:22:17 +0000 (UTC) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFFC612; Fri, 14 Nov 2014 01:22:16 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id CE1041040A39; Fri, 14 Nov 2014 12:22:10 +1100 (AEDT) Date: Fri, 14 Nov 2014 12:22:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Navdeep Parhar Subject: Re: missing DTrace FBT return probes In-Reply-To: <5464FBFF.6020200@FreeBSD.org> Message-ID: <20141114115632.J1286@besplex.bde.org> References: <5464FBFF.6020200@FreeBSD.org> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=BdjhjNd2 c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=nlC_4_pT8q9DhB4Ho9EA:9 a=cz2ZRIgtxKwA:10 a=wJWlkF7cXJYA:10 a=6I5d2MoRAAAA:8 a=IbOoWMm4W4JsMnJ5gfIA:9 a=45ClL6m2LaAA:10 a=fgf5PR_cwQYA:10 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Grier, James" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 01:22:17 -0000 On Thu, 13 Nov 2014, Navdeep Parhar wrote: > On 11/13/14 08:33, Grier, James wrote: >> On Wed, Jun 5, 2013 at 5:50 PM, Navdeep Parhar wrote= : >=20 >> A large number of kernel functions have an FBT entry probe but no return >>> probe. I believe this is due to tail call optimization by the compiler. >>> Should we disable this optimization for kernel configs that have DTrace >>> support? The missing return probes make it very difficult to write >>> DTrace scripts that want to set flags etc. at function entry and then >>> clean them up on return. >>>=20 >>> A quick sample from a recent HEAD shows ~4000 out of ~27000 functions >>> are missing return probes. See the list of functions in these files >>> (the ones listed in entry-only.txt do not have return probes). >>>=20 >>> http://people.freebsd.org/~np/entry-only.txt >>> http://people.freebsd.org/~np/entry.txt >>> http://people.freebsd.org/~np/return.txt >>=20 >> By trial and error, I discovered that it=E2=80=99s =E2=80=98-funit-at-a-= time=E2=80=99 that=20 >> does the dirty work, so >> using =E2=80=98-fno-unit-at-a-time=E2=80=99 with -O2 we get all the retu= rn fbt probes.=20 >> I haven=E2=80=99t determined >> the performance impact of this. > > Hmm, I thought it was -fno-optimize-sibling-calls that controlled this=20 > particular optimization. Perhaps it is all of these, plus -fno-inline-functions-called-once. Inlining functions when not requested to do so gives undebuggable code. -funit-at-a-time exposes even static functions that are defined after they are used to inlining. > These days I compile my debug kernels with -O0. There is a very signific= ant=20 > performance impact but it makes kgdb and DTrace very happy. But -O0 means that you are not testing what will be used on production systems. gcc used to promise that -g not disturb anything and that -O not make debugging impossible. Lots of flags that were under -O2 in gcc-3 crept into -O in gcc-4. clang is worse -- its -O is more agressive than gcc-4's -O2, and its -O2 is little different from its -O. Apart from kgdb and DTrace, this breaks: - profiling - kernel stack traces from ddb - ddb generally. With no debugging symbol support, it is even harder to find where args and local variables are if they are optimized away. (In userland, they often cannot be found even with debugging symbol support.) ddb's heuristic for finding args never worked for amd64 and is now under #if !1 with a comment that dwarf2 is needed. Thus, stack traces never showed any args correctly on amd64. I recently noticed a case where gcc without many optimizations on i386 messed up the arg printing because the function was static and gcc "optimized" it by passing an arg in %eax instead of on the stack. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 01:55:30 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB146812; Fri, 14 Nov 2014 01:55:30 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DE6094B; Fri, 14 Nov 2014 01:55:30 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id y20so179475ier.0 for ; Thu, 13 Nov 2014 17:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OAuWdS4dmVFXMZ0gdjxpYWjaqa36yqtAKFjmj8tcR8M=; b=MWa8Whoz4AT4F/0UEoNbcS7rLL+yj5U/JzeLZYv6cEkvmemGxxlNEIIg2+UNu6U6qf 16QMvWPXznvNyDqYEArmdDiRn8l50fwYffpRkuIl1N2k+rL7ubiwsskbhuzYsgeKyC0O 7GnXe1/O6XP+4+aCzjvIbj9GGP68/CC+qrrAh68JVfL3d/tphwSySXhh7ZqrRLv0PILL znwcc6QV4PBg8BruIvcy/Q1SOtD4ynlJ39i+gJ6ES588xnHNVciTEQDgUMMUMj9loGay Yi/UdxEuGVfabGengUBUbzCiQCaWB9jGFPA9VXUfRX9HB/dOflk0dmwVOzFID5VJH4xu CPCw== MIME-Version: 1.0 X-Received: by 10.107.13.6 with SMTP id 6mr6562099ion.68.1415930129975; Thu, 13 Nov 2014 17:55:29 -0800 (PST) Received: by 10.50.235.49 with HTTP; Thu, 13 Nov 2014 17:55:29 -0800 (PST) In-Reply-To: References: <54647D1E.9010904@freebsd.org> <201411130948.23785.jhb@freebsd.org> Date: Thu, 13 Nov 2014 17:55:29 -0800 Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: NGie Cooper To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , Alfred Perlstein , Steve Kargl , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 01:55:30 -0000 On Thu, Nov 13, 2014 at 3:01 PM, Adrian Chadd wrote: > I'd like to try and add WITNESS_WARN() where appropriate. > > How's this look? > > Index: kern_timeout.c > =================================================================== > --- kern_timeout.c (revision 274304) > +++ kern_timeout.c (working copy) > @@ -1096,7 +1096,22 @@ > struct lock_class *class; > int direct, sq_locked, use_lock; > > + /* XXX GIANTOK? c_lock can be NULL? */ > + > /* > + * If safe is clear then we're not going to drop into the > + * sleepq wait routines. So, we don't have to check > + * for the witness warning here. > + * > + * If safe is set then we may drop into the sleep routines > + * so do the check. > + */ > + if (safe) { > + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, c->c_lock, > + "calling %s", __func__); > + } > + > + /* > * Some old subsystems don't hold Giant while running a callout_stop(), > * so just discard this check for the moment. > */ - This should have WITNESS #ifdef guards (for clarity... it would probably be optimized out by the compiler if -O0 wasn't specified, but some folks seem to use -O0 lately, like np@). - Should this have __predict_{false,true} applied to the if (safe) check? Thanks! From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 09:31:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D52BD81F; Fri, 14 Nov 2014 09:31:17 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id BAC69A3D; Fri, 14 Nov 2014 09:31:17 +0000 (UTC) Received: from [10.0.1.20] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 7411B341F877; Fri, 14 Nov 2014 01:31:17 -0800 (PST) Subject: Re: Questions about locking; turnstiles and sleeping threads Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alfred Perlstein In-Reply-To: Date: Fri, 14 Nov 2014 01:31:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> <5464764E.9080308@freebsd.org> <54647D1E.9010904@freebsd.org> <54648483.5060107@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1283) Cc: Hans Petter Selasky , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 09:31:17 -0000 On Nov 13, 2014, at 9:31 AM, Adrian Chadd wrote: > On 13 November 2014 02:14, Alfred Perlstein = wrote: >> Would need more context to help on this. >>=20 >> I can't tell based on your description which thread is holding which = lock. >>=20 >> If A is waiting for callout C to stop AND there exists a thread B = that is >> contending against C for a lock, you should be fine so long as there = is no >> lock cycle against A. >>=20 >> Would be best if you pointed at some code and gave descriptions. >=20 > I haven't dug into the USB side of things ,but on the atheros side I > gave the description above. >=20 > Thread A grabs lock X and tries to drain callout, which involves > grabbing lock Y to do the dirty work. Lock Y isn't held at this point > - the callout is about to run or is running, so it enters the sleepq > call to finish the drain. >=20 > Thread B wants to grab lock X, but can't because thread A holds lock X > and is in a sleepq due to callout_drain(). Hence panic. >=20 > I'll poke people on IRC today and see if I can get a better > description of what/where the WITNESS_WARN() should be placed in > callout_drain(). Then we'll see what's left triggering it. Yes, this is exactly how one is not supposed to use callout_drain(). =46rom the context of the caller of callout_drain() you are better off = doing a stop() under the lock, then dropping the lock and doing the = drain. Typically one sets a "dying" or "going away" type flag in the = softc to prevent more callouts from being scheduled. -Alfred From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 15:43:22 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E2D71C8; Fri, 14 Nov 2014 15:43:22 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05E71889; Fri, 14 Nov 2014 15:43:22 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id k14so438762wgh.38 for ; Fri, 14 Nov 2014 07:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Ejs9ELS6cCx/RacLAXHRPXhcpd8Km/Q187crGTIpGxc=; b=CtrJP+8xizvZiJ63WV0BgfGQ2Fizyy8PJopHljmLPT3XAfVeV1WBGNh6mIexbxdEgo UsZEWNYWuDW9cSrTpFceTQJCjyY1p9IQOjVXY2YGZu9+mMOf7SNWnSpduYvLj3FemIzK G5WJ0JqpuINHVgt95cpPh5vanx8CkxF5Fzv8t/VG1DFO4eLhOxVDIv6Gjw+6fyibSjvF SGkl108UdalXsl3vDI9GhZgLDo/7X3+7jI/ssg6cBiy8qMmdgOKVfhSgFPVw0AIVlVfP QH88gX2toWC37L80N2EVAxhMc+mjuH/WIZEFjK1Ijob9VYiJ5Dv1LTdfs8HknJbvKdj3 sDDg== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr14871422wjn.68.1415979800361; Fri, 14 Nov 2014 07:43:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 14 Nov 2014 07:43:20 -0800 (PST) In-Reply-To: References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> <5464764E.9080308@freebsd.org> <54647D1E.9010904@freebsd.org> <54648483.5060107@freebsd.org> Date: Fri, 14 Nov 2014 07:43:20 -0800 X-Google-Sender-Auth: ILC4sPA1NBG8pxmAGIZcmTlhHVk Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hans Petter Selasky , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 15:43:22 -0000 On 14 November 2014 01:31, Alfred Perlstein wrote: > > On Nov 13, 2014, at 9:31 AM, Adrian Chadd wrote: > >> On 13 November 2014 02:14, Alfred Perlstein wrote: >>> Would need more context to help on this. >>> >>> I can't tell based on your description which thread is holding which lo= ck. >>> >>> If A is waiting for callout C to stop AND there exists a thread B that = is >>> contending against C for a lock, you should be fine so long as there is= no >>> lock cycle against A. >>> >>> Would be best if you pointed at some code and gave descriptions. >> >> I haven't dug into the USB side of things ,but on the atheros side I >> gave the description above. >> >> Thread A grabs lock X and tries to drain callout, which involves >> grabbing lock Y to do the dirty work. Lock Y isn't held at this point >> - the callout is about to run or is running, so it enters the sleepq >> call to finish the drain. >> >> Thread B wants to grab lock X, but can't because thread A holds lock X >> and is in a sleepq due to callout_drain(). Hence panic. >> >> I'll poke people on IRC today and see if I can get a better >> description of what/where the WITNESS_WARN() should be placed in >> callout_drain(). Then we'll see what's left triggering it. > > > Yes, this is exactly how one is not supposed to use callout_drain(). > > From the context of the caller of callout_drain() you are better off doin= g a stop() under the lock, then dropping the lock and doing the drain. Typ= ically one sets a "dying" or "going away" type flag in the softc to prevent= more callouts from being scheduled. Right. Well, I'll see about getting a WITNESS check inserted there so no other badly behaving code creeps in. -adrian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 21:11:46 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6912E47C; Fri, 14 Nov 2014 21:11:46 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 28B631FC; Fri, 14 Nov 2014 21:11:44 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA20584; Fri, 14 Nov 2014 23:13:35 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XpO9d-000NDa-TB; Fri, 14 Nov 2014 23:11:41 +0200 Message-ID: <54666FD5.6080705@FreeBSD.org> Date: Fri, 14 Nov 2014 23:10:45 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Konstantin Belousov , John Baldwin Subject: suspending threads before devices [Was: svn commit: r233249 - head/sys/amd64/acpica] References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org> <20120322141436.GC2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120322141436.GC2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "src-committers@freebsd.org" , Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 21:11:46 -0000 On 22/03/2012 16:14, Konstantin Belousov wrote: > I already noted this to Jung-uk, I think that current suspend handling > is (somewhat) wrong. We shall not stop other CPUs for suspension when > they are executing some random kernel code. Rather, CPUs should be safely > stopped at the kernel->user boundary, or at sleep point, or at designated > suspend point like idle loop. > > We already are engaged into somewhat doubtful actions like restoring of %cr2, > since we might, for instance, preemt page fault handler with suspend IPI. I recently revisited this issue in the context of some suspend+resume problems that I am having with radeonkms driver. What surprised me is that the driver's suspend code has no synchronization whatsoever with its other code paths. So, I looked first at the Linux code and then at the illumos code to see how suspend is implemented there. As far as I can see, those kernels do exactly what you suggest that we do. Before suspending devices they first suspend all threads except for one that initiates the suspend. For userland threads a signal-like mechanism is used to put them in a state similar to SIGSTOP-ed one. With the kernel threads mechanisms are different between the kernels. Also, illumos freezes kernel threads after suspending the devices, not before. I think that we could start with only the userland threads initially. Do you think the SIGSTOP-like approach would be hard to implement for us? References: http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/cpr/cpr_main.c#425 http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/cpr/cpr_uthread.c#80 http://lxr.free-electrons.com/source/kernel/power/suspend.c#L388 http://lxr.free-electrons.com/source/kernel/power/suspend.c#L207 http://lxr.free-electrons.com/source/kernel/power/power.h#L235 http://lxr.free-electrons.com/source/kernel/power/process.c#L118 http://lxr.free-electrons.com/source/kernel/power/process.c#L27 http://lxr.free-electrons.com/source/kernel/freezer.c#L115 -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 23:19:32 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2521975D; Fri, 14 Nov 2014 23:19:32 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0A96C4; Fri, 14 Nov 2014 23:19:31 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 314DEB97F; Fri, 14 Nov 2014 18:19:30 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: Questions about locking; turnstiles and sleeping threads Date: Fri, 14 Nov 2014 18:18:55 -0500 Message-ID: <1473017.e3PtKgPIoc@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <201411130948.23785.jhb@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 14 Nov 2014 18:19:30 -0500 (EST) Cc: Hans Petter Selasky , Alfred Perlstein , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 23:19:32 -0000 On Thursday, November 13, 2014 09:32:14 AM Adrian Chadd wrote: > On 13 November 2014 06:48, John Baldwin wrote: > > On Thursday, November 13, 2014 4:52:50 am Adrian Chadd wrote: > >> Hm, the more I dig into this, the more I realise it's not a 1:45am > >> question to ask. > >> > >> Specifically, callout_stop_safe() takes 'safe', which says "are we > >> waiting around for this callout to finish if it started". Ie, > >> callout_drain() is callout_stop_safe(c, 1) ; callout_stop() is > >> callout_stop_safe(c, 0). > >> > >> If safe is 1, then it'll potentially put the current thread to sleep > >> in order to wait for it to synchronise with the callout that's > >> running. It's sleeping with cc_lock which is the per-callwheel lock > >> and it's doing that with whatever other locks are held. That's the > >> situation which is tripping things up. > >> > >> The manpage says that no locks should be held that the callout may > >> block on, which isn't the case here at all - I'm trying to grab a lock > >> in another thread that the caller _into_ the callout subsystem holds. > >> The manpage doesn't mention anything about this. Sniffle. > > > > It should just say "no sleepable locks at all". And yes, callout_stop() > > is > > perfectly fine to call with locks held. It is only callout_drain() that > > should not be called, same as with bus_teardown_intr() and > > taskqueue_drain() (other routines that can sleep while ensuring that an > > asynchronous task run by another thread is stopped). > > so, we should add WITNESS_WARN() to those as well? Sure. For bus_teardown_intr() the right place to do it is in the intr_event_*() that eventually gets called in kern_intr.c. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 10:58:26 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48EE5D8B; Sat, 15 Nov 2014 10:58:26 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DFE1D9B1; Sat, 15 Nov 2014 10:58:25 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAFAwJF3044371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2014 12:58:19 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAFAwJF3044371 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAFAwJVR044370; Sat, 15 Nov 2014 12:58:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 15 Nov 2014 12:58:19 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: suspending threads before devices [Was: svn commit: r233249 - head/sys/amd64/acpica] Message-ID: <20141115105819.GJ17068@kib.kiev.ua> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org> <20120322141436.GC2358@deviant.kiev.zoral.com.ua> <54666FD5.6080705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54666FD5.6080705@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "src-committers@freebsd.org" , Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 10:58:26 -0000 On Fri, Nov 14, 2014 at 11:10:45PM +0200, Andriy Gapon wrote: > On 22/03/2012 16:14, Konstantin Belousov wrote: > > I already noted this to Jung-uk, I think that current suspend handling > > is (somewhat) wrong. We shall not stop other CPUs for suspension when > > they are executing some random kernel code. Rather, CPUs should be safely > > stopped at the kernel->user boundary, or at sleep point, or at designated > > suspend point like idle loop. > > > > We already are engaged into somewhat doubtful actions like restoring of %cr2, > > since we might, for instance, preemt page fault handler with suspend IPI. > > I recently revisited this issue in the context of some suspend+resume problems > that I am having with radeonkms driver. What surprised me is that the driver's > suspend code has no synchronization whatsoever with its other code paths. So, I > looked first at the Linux code and then at the illumos code to see how suspend > is implemented there. > As far as I can see, those kernels do exactly what you suggest that we do. > Before suspending devices they first suspend all threads except for one that > initiates the suspend. For userland threads a signal-like mechanism is used to > put them in a state similar to SIGSTOP-ed one. With the kernel threads > mechanisms are different between the kernels. Also, illumos freezes kernel > threads after suspending the devices, not before. > > I think that we could start with only the userland threads initially. Do you > think the SIGSTOP-like approach would be hard to implement for us? We have most, if not all, parts of the stopping code already implemented. I mean the single-threading code, see thread_single(SINGLE_BOUNDARY). The code ensures that other threads in the current process are stopped either at the kernel->user boundary, or at the safe kernel sleep point. This is not immediately applicable, since the caller is supposed to be a thread in the suspended process, but modifications to allow external process to do the same are really small comparing with the complexity of the code. I suspect that all what is needed is change of while/if (remaining != 1) to while/if ((p == curproc && remaining != 1) || (p != curproc && remaining != 0)) together with explicit passing of struct proc *p to thread_single. > > References: > > http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/cpr/cpr_main.c#425 > http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/cpr/cpr_uthread.c#80 > > http://lxr.free-electrons.com/source/kernel/power/suspend.c#L388 > http://lxr.free-electrons.com/source/kernel/power/suspend.c#L207 > http://lxr.free-electrons.com/source/kernel/power/power.h#L235 > http://lxr.free-electrons.com/source/kernel/power/process.c#L118 > http://lxr.free-electrons.com/source/kernel/power/process.c#L27 > http://lxr.free-electrons.com/source/kernel/freezer.c#L115 > > -- > Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 15:06:11 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22AE1DD4; Sat, 15 Nov 2014 15:06:11 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E922A17E; Sat, 15 Nov 2014 15:06:09 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA03762; Sat, 15 Nov 2014 17:08:00 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XpevO-000P6i-U3; Sat, 15 Nov 2014 17:06:06 +0200 Message-ID: <54676BA6.7000202@FreeBSD.org> Date: Sat, 15 Nov 2014 17:05:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: suspending threads before devices References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org> <20120322141436.GC2358@deviant.kiev.zoral.com.ua> <54666FD5.6080705@FreeBSD.org> <20141115105819.GJ17068@kib.kiev.ua> In-Reply-To: <20141115105819.GJ17068@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 15:06:11 -0000 On 15/11/2014 12:58, Konstantin Belousov wrote: > On Fri, Nov 14, 2014 at 11:10:45PM +0200, Andriy Gapon wrote: >> On 22/03/2012 16:14, Konstantin Belousov wrote: >>> I already noted this to Jung-uk, I think that current suspend handling >>> is (somewhat) wrong. We shall not stop other CPUs for suspension when >>> they are executing some random kernel code. Rather, CPUs should be safely >>> stopped at the kernel->user boundary, or at sleep point, or at designated >>> suspend point like idle loop. >>> >>> We already are engaged into somewhat doubtful actions like restoring of %cr2, >>> since we might, for instance, preemt page fault handler with suspend IPI. >> >> I recently revisited this issue in the context of some suspend+resume problems >> that I am having with radeonkms driver. What surprised me is that the driver's >> suspend code has no synchronization whatsoever with its other code paths. So, I >> looked first at the Linux code and then at the illumos code to see how suspend >> is implemented there. >> As far as I can see, those kernels do exactly what you suggest that we do. >> Before suspending devices they first suspend all threads except for one that >> initiates the suspend. For userland threads a signal-like mechanism is used to >> put them in a state similar to SIGSTOP-ed one. With the kernel threads >> mechanisms are different between the kernels. Also, illumos freezes kernel >> threads after suspending the devices, not before. >> >> I think that we could start with only the userland threads initially. Do you >> think the SIGSTOP-like approach would be hard to implement for us? > We have most, if not all, parts of the stopping code > already implemented. I mean the single-threading code, see > thread_single(SINGLE_BOUNDARY). The code ensures that other threads in > the current process are stopped either at the kernel->user boundary, or > at the safe kernel sleep point. > > This is not immediately applicable, since the caller is supposed to be > a thread in the suspended process, but modifications to allow external > process to do the same are really small comparing with the complexity > of the code. I suspect that all what is needed is change of > while/if (remaining != 1) > to > while/if ((p == curproc && remaining != 1) || > (p != curproc && remaining != 0)) > together with explicit passing of struct proc *p to thread_single. Thank you for the pointer! I think that maybe even more changes are required for that code to be usable for suspending. E.g. maybe a different p_flag bit should be used, because I think that we would like to avoid interaction between the process level suspend and the global suspend. I.e. the global suspend might encounter a multi-threaded process in a single thread mode and would need to suspend its remaining thread. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 16:41:39 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A23B98B1; Sat, 15 Nov 2014 16:41:39 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31D42BAB; Sat, 15 Nov 2014 16:41:39 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y19so2405992wgg.28 for ; Sat, 15 Nov 2014 08:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cpyv0RVQK1oWDg+A4n7fqrJMlFn1oABJASb8vqARERQ=; b=Rr199YCD6gLzzuXOTRl4DqP/q186cgnRNdx0RUoxraeGKExDpC6tILtvbPiYMCejn5 a9euPMlzrh3pGXCH6epopIEs0HGUs7jQuJz8Y91mBAZY484nhErsKXpa1hMSBM0IAzBG 8avJxqC8eESsvV73WmB+e6wLcK4dZA/YQnL2FAKsNlHzGEhV/albf/vnb4lLpNgmWLOg gg45JfTGXLarRGwlgSgtRho8fGDH9HUlS1K3a0F/mhZuzMXRCZatidsS2PCVFicJNap7 dyzwT/DhUTGFM28FAwOcoWnXeeAxSZCwZ0nul8Wii+Pu9QnNa1xTY3hvv/TyOYJtbsP7 SUMg== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr23931263wjn.68.1416069697662; Sat, 15 Nov 2014 08:41:37 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 15 Nov 2014 08:41:37 -0800 (PST) In-Reply-To: <54676BA6.7000202@FreeBSD.org> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org> <20120322141436.GC2358@deviant.kiev.zoral.com.ua> <54666FD5.6080705@FreeBSD.org> <20141115105819.GJ17068@kib.kiev.ua> <54676BA6.7000202@FreeBSD.org> Date: Sat, 15 Nov 2014 08:41:37 -0800 X-Google-Sender-Auth: S5TIxPA5gvXL2pFbs6s3eS9Ugm4 Message-ID: Subject: Re: suspending threads before devices From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 16:41:39 -0000 [snip] Hm, would just creating a suspend kernel thread make it easier? Ie, instead of you doing the suspend in the context of the calling process, just have it signal to a kernel thread, so the userland thread doing the suspend can also be suspended? -adrian From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 17:04:08 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04600E2B; Sat, 15 Nov 2014 17:04:08 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B7221DF2; Sat, 15 Nov 2014 17:04:07 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 8CC85A445; Sat, 15 Nov 2014 17:04:06 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 16ECC19F1; Sat, 15 Nov 2014 18:04:04 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Adrian Chadd Subject: Re: suspending threads before devices References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org> <20120322141436.GC2358@deviant.kiev.zoral.com.ua> <54666FD5.6080705@FreeBSD.org> <20141115105819.GJ17068@kib.kiev.ua> <54676BA6.7000202@FreeBSD.org> Date: Sat, 15 Nov 2014 18:04:03 +0100 In-Reply-To: (Adrian Chadd's message of "Sat, 15 Nov 2014 08:41:37 -0800") Message-ID: <86ppcocs58.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Konstantin Belousov , Jung-uk Kim , Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 17:04:08 -0000 Adrian Chadd writes: > Hm, would just creating a suspend kernel thread make it easier? > Ie, instead of you doing the suspend in the context of the calling > process, just have it signal to a kernel thread, so the userland > thread doing the suspend can also be suspended? My immediate reaction was "the process might want to know that the system actually suspended (and resumed)" but this can be addressed by having it sleep on a condvar which is awoken when either a) suspend fails or b) the system resumes. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 17:48:30 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 778E7C52; Sat, 15 Nov 2014 17:48:30 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 646741B8; Sat, 15 Nov 2014 17:48:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA05434; Sat, 15 Nov 2014 19:50:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XphSN-000PF6-TQ; Sat, 15 Nov 2014 19:48:19 +0200 Message-ID: <546791AA.5060204@FreeBSD.org> Date: Sat, 15 Nov 2014 19:47:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: suspending threads before devices References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org> <20120322141436.GC2358@deviant.kiev.zoral.com.ua> <54666FD5.6080705@FreeBSD.org> <20141115105819.GJ17068@kib.kiev.ua> <54676BA6.7000202@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 17:48:30 -0000 On 15/11/2014 18:41, Adrian Chadd wrote: > [snip] > > Hm, would just creating a suspend kernel thread make it easier? > > Ie, instead of you doing the suspend in the context of the calling > process, just have it signal to a kernel thread, so the userland > thread doing the suspend can also be suspended? I do not see any significant difference between the two approaches. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 18:00:21 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FA26ED5; Sat, 15 Nov 2014 18:00:21 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD0EB2AA; Sat, 15 Nov 2014 18:00:20 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAFI0FMX045012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2014 20:00:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAFI0FMX045012 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAFI0FHm045011; Sat, 15 Nov 2014 20:00:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 15 Nov 2014 20:00:15 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: suspending threads before devices Message-ID: <20141115180014.GK17068@kib.kiev.ua> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org> <20120322141436.GC2358@deviant.kiev.zoral.com.ua> <54666FD5.6080705@FreeBSD.org> <20141115105819.GJ17068@kib.kiev.ua> <54676BA6.7000202@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54676BA6.7000202@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 18:00:21 -0000 On Sat, Nov 15, 2014 at 05:05:10PM +0200, Andriy Gapon wrote: > On 15/11/2014 12:58, Konstantin Belousov wrote: > > On Fri, Nov 14, 2014 at 11:10:45PM +0200, Andriy Gapon wrote: > >> On 22/03/2012 16:14, Konstantin Belousov wrote: > >>> I already noted this to Jung-uk, I think that current suspend handling > >>> is (somewhat) wrong. We shall not stop other CPUs for suspension when > >>> they are executing some random kernel code. Rather, CPUs should be safely > >>> stopped at the kernel->user boundary, or at sleep point, or at designated > >>> suspend point like idle loop. > >>> > >>> We already are engaged into somewhat doubtful actions like restoring of %cr2, > >>> since we might, for instance, preemt page fault handler with suspend IPI. > >> > >> I recently revisited this issue in the context of some suspend+resume problems > >> that I am having with radeonkms driver. What surprised me is that the driver's > >> suspend code has no synchronization whatsoever with its other code paths. So, I > >> looked first at the Linux code and then at the illumos code to see how suspend > >> is implemented there. > >> As far as I can see, those kernels do exactly what you suggest that we do. > >> Before suspending devices they first suspend all threads except for one that > >> initiates the suspend. For userland threads a signal-like mechanism is used to > >> put them in a state similar to SIGSTOP-ed one. With the kernel threads > >> mechanisms are different between the kernels. Also, illumos freezes kernel > >> threads after suspending the devices, not before. > >> > >> I think that we could start with only the userland threads initially. Do you > >> think the SIGSTOP-like approach would be hard to implement for us? > > We have most, if not all, parts of the stopping code > > already implemented. I mean the single-threading code, see > > thread_single(SINGLE_BOUNDARY). The code ensures that other threads in > > the current process are stopped either at the kernel->user boundary, or > > at the safe kernel sleep point. > > > > This is not immediately applicable, since the caller is supposed to be > > a thread in the suspended process, but modifications to allow external > > process to do the same are really small comparing with the complexity > > of the code. I suspect that all what is needed is change of > > while/if (remaining != 1) > > to > > while/if ((p == curproc && remaining != 1) || > > (p != curproc && remaining != 0)) > > together with explicit passing of struct proc *p to thread_single. > > Thank you for the pointer! > I think that maybe even more changes are required for that code to be usable for > suspending. E.g. maybe a different p_flag bit should be used, because I think > that we would like to avoid interaction between the process level suspend and > the global suspend. I.e. the global suspend might encounter a multi-threaded > process in a single thread mode and would need to suspend its remaining thread. Thread which is a p_singlethread, is not at the safe point; in other words, a process which is under the singlethreading, should prevent the system from entering sleep state. The singlethreading is the temporal state anyway, it is established during exec() or exit(), so it is fine to wait for in-process singlethreading to end before outer singlethreading is done. Anyway, this requires real coding to experiment. I started looking at it since I did somewhat related changes now.