From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752929AbdJSR2c (ORCPT ); Thu, 19 Oct 2017 13:28:32 -0400 Received: from mailout2.samsung.com ([203.254.224.25]:36141 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752727AbdJSR23 (ORCPT ); Thu, 19 Oct 2017 13:28:29 -0400 X-AuditID: b6c32a37-c75ff70000001076-4e-59e8e0ba6e6d Subject: Re: [PATCH 4/4][PoC][RFC] Allow to trace fd usage with rlimit-events To: Al Viro Cc: gregkh@linuxfoundation.org, arnd@arndb.de, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, k.lewandowsk@samsung.com, l.stelmach@samsung.com, p.szewczyk@samsung.com, b.zolnierkie@samsung.com, andrzej.p@samsung.com, kopasiak90@gmail.com From: Krzysztof Opasiak Message-id: Date: Thu, 19 Oct 2017 19:28:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-version: 1.0 In-reply-to: <20171018230521.GP21978@ZenIV.linux.org.uk> Content-type: text/plain; charset="utf-8"; format="flowed" Content-language: en-US Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsWy7bCmnu6uBy8iDVbfNbKY9bKdxeLvpGPs FhtnrGe1aF68ns2i8dNcZotnp/Msbh5awWjRsesri8WevSdZLC7vmsNm8Ws+UMP5v8dZHXg8 fv+axOixc9Zddo/9c9ewe/RtWcXo8XmTnMemJ2+ZAtiiuGxSUnMyy1KL9O0SuDJa+o+zFzzl r7h9/g1zA+Nlni5GDg4JAROJWxdduhi5OIQEdjBKnDyynQ3C+c4ose/ocaYuRk6wom8XFrJD JDYwSnSsmMMI4dxnlJj0sZERpEpYwF/i57s7LCC2iICqxJ1TZ5hAipgF5jJJPLtyhhFkH5uA vsS8XaIgNbwCdhLr3jxgA7FZgOqXTWhlB7FFBSIkLmz6yQRRIyjxY/I9sJmcAhYSH35uBbOZ Bawknv1rZYWwxSWaW29CxeUlNq95ywyyV0LgO5vEwrm72SD+dJHYsdIf4hthiVfHt7BDhKUl Lh21hShfxyhxYSvEPRICuxklWp5GQ9jWEn9WTWSDmM8n8e5rDytEL69ER5sQRImHxKK5M1gg bEeJs3fmMUPC5y2jxIKJB1kmMMrNQvLOLCQvzELywiwkLyxgZFnFKJZaUJybnlpsWGCsV5yY W1yal66XnJ+7iRGcjLTMdzBuOOdziFGAg1GJh3fDhReRQqyJZcWVuYcYJTiYlUR4l90ECvGm JFZWpRblxxeV5qQWH2KU5mBREucVW38tQkggPbEkNTs1tSC1CCbLxMEp1cC4KGnKAvmv0w7V N3Fs1t92ZXKnX1RT7qFm+YLQPotMb23zuBPV59Y8vrZq20c+hUcrF6y5VPxqzvpLDE5Lb3DV 6Oxqz38qob/8Yq9s5+FJ3IUeZbpvlipryDB+5RZd5fRvWjln06UFS7urT29ne35lb7j1Ip3E vyWnXmS8fskhWWl0+VFmRflMJZbijERDLeai4kQAJdY2E0IDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42I5/e+xoO6uBy8iDTZOl7OY9bKdxeLvpGPs FhtnrGe1aF68ns2i8dNcZotnp/Msbh5awWjRsesri8WevSdZLC7vmsNm8Ws+UMP5v8dZHXg8 fv+axOixc9Zddo/9c9ewe/RtWcXo8XmTnMemJ2+ZAtiiuGxSUnMyy1KL9O0SuDJa+o+zFzzl r7h9/g1zA+Nlni5GTg4JAROJbxcWsncxcnEICaxjlHh39QgbSEJI4CGjxLRDqSC2sICvxLm/ 98HiIgKqEndOnWECaWAWmMsk8Xt1AytE91tGiUcvvwBlODjYBPQl5u0SBWngFbCTWPfmAVgz C1Dzsgmt7CAlogIREhs28kOUCEr8mHyPBcTmFLCQ+PBzK5jNLGAm8eXlYVYIW1yiufUmVFxe YvOat8wTGAVmIWmfhaRlFpKWWUhaFjCyrGKUTC0ozk3PLTYqMMxLLdcrTswtLs1L10vOz93E CIyfbYe1+nYw3l8Sf4hRgINRiYc34tyLSCHWxLLiytxDjBIczEoivMtuAoV4UxIrq1KL8uOL SnNSiw8xSnOwKInz3s47FikkkJ5YkpqdmlqQWgSTZeLglGpglCkPfrtg2o46Pr6mHUKubY7p iqGlb7nP8E856X4h9Qv3xw1RS9IeNt2q33f2wKuK5qS80CsB19gCKzyZF9/21jX6/bvhJ29O b6GPLPdqp7LapbP6lzIbZc+o2/Su/4nxDVeTXT/VTnWuuljT1Cmq4K4ycXJYSNuOfwo1vNwc nhXh65LLG5mUWIozEg21mIuKEwHeOOfnmwIAAA== X-CMS-MailID: 20171019172826epcas1p38e8ed9c16a13fce6bf3e9617f95e4315 X-Msg-Generator: CA X-Sender-IP: 182.195.42.142 X-Local-Sender: =?UTF-8?B?S3J6eXN6dG9mIE9wYXNpYWsbU1JQT0wtU3lzdGVtIChUUCkb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NvZnR3YXJlIEVuZ2luZWVyIC8gRXhwZXJ0IFByb2dy?= =?UTF-8?B?YW1tZXI=?= X-Global-Sender: =?UTF-8?B?S3J6eXN6dG9mIE9wYXNpYWsbU1JQT0wtU3lzdGVtIChUUCkb?= =?UTF-8?B?U2Ftc3VuZ8KgRWxlY3Ryb25pY3MbU29mdHdhcmUgRW5naW5lZXIgLyBFeHBl?= =?UTF-8?B?cnQgUHJvZ3JhbW1lcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTY=?= CMS-TYPE: 101P X-CMS-RootMailID: 20171018203342epcas1p23933a20a33807f92c716433374374397 X-RootMTR: 20171018203342epcas1p23933a20a33807f92c716433374374397 References: <20171018203230.29871-1-k.opasiak@samsung.com> <20171018203230.29871-5-k.opasiak@samsung.com> <20171018230521.GP21978@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 10/19/2017 01:05 AM, Al Viro wrote: > On Wed, Oct 18, 2017 at 10:32:30PM +0200, Krzysztof Opasiak wrote: > >> @@ -417,7 +417,7 @@ static int task_get_unused_fd_flags(struct binder_proc *proc, int flags) >> rlim_cur = task_rlimit(proc->tsk, RLIMIT_NOFILE); >> unlock_task_sighand(proc->tsk, &irqs); >> >> - return __alloc_fd(files, 0, rlim_cur, flags); >> + return __alloc_fd(proc->tsk, 0, rlim_cur, flags); > > Who said that proc->files will remain equal to proc->tsk->files? > >> -static void __put_unused_fd(struct files_struct *files, unsigned int fd) >> +static void __put_unused_fd(struct task_struct *owner, unsigned int fd) >> { >> + struct files_struct *files = owner->files; >> struct fdtable *fdt = files_fdtable(files); >> __clear_open_fd(fd, fdt); >> if (fd < files->next_fd) >> files->next_fd = fd; >> + >> + if (rlimit_noti_watch_active(owner, RLIMIT_NOFILE)) { >> + unsigned int count; >> + >> + count = count_open_fds(fdt); >> + rlimit_noti_res_changed(owner, RLIMIT_NOFILE, count + 1, count); >> + } >> } > > [... and similar for other __...fd() primitives] > This is blatantly wrong - you *CAN'T* modify files_struct unless it's > a) yours (i.e. current->files) or > b) you've had its refcount incremented for you by some process that > did, at the time, have current->files pointing to it. > > There is a reason why binder keeps ->files explicitly, rather than going through > ->tsk->files. Your are perfectly right! Thank you very much for catching this. To be honest, initially I just added the struct task_struct ptr to the argument list keeping that in mind. Then when I was cleaning up patches before sending I found this to look a litlle bit odd and forgot that I did this on purpose because tsk->files can be reassigned and that's why I removed the files param. I'll fix this for v2. Thanks once again. Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics