From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753501AbcEYKa0 (ORCPT ); Wed, 25 May 2016 06:30:26 -0400 Received: from mail-db5eur01on0101.outbound.protection.outlook.com ([104.47.2.101]:24256 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752681AbcEYKaY (ORCPT ); Wed, 25 May 2016 06:30:24 -0400 X-Greylist: delayed 91715 seconds by postgrey-1.27 at vger.kernel.org; Wed, 25 May 2016 06:30:24 EDT Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=virtuozzo.com; Date: Wed, 25 May 2016 13:30:11 +0300 From: Vladimir Davydov To: Eric Dumazet CC: Andrew Morton , Alexander Viro , Johannes Weiner , Michal Hocko , , , , , Subject: Re: [PATCH RESEND 7/8] pipe: account to kmemcg Message-ID: <20160525103011.GF11150@esperanza> References: <2c2545563b6201f118946f96dd8cfc90e564aff6.1464079538.git.vdavydov@virtuozzo.com> <1464094742.5939.46.camel@edumazet-glaptop3.roam.corp.google.com> <20160524161336.GA11150@esperanza> <1464120273.5939.53.camel@edumazet-glaptop3.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1464120273.5939.53.camel@edumazet-glaptop3.roam.corp.google.com> X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: AM5PR0901CA0021.eurprd09.prod.outlook.com (10.164.186.159) To VI1PR08MB0590.eurprd08.prod.outlook.com (10.163.169.20) X-MS-Office365-Filtering-Correlation-Id: 828a9faa-c08b-4418-aa5a-08d384879220 X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB0590;2:41VCm/1+lPtRbe1b5lecAdgqt2cy+9jsm1s2nmzoT4jBxwwWZeMdT7btiPTB4Uo3Sct3puUqsH3bCQ9rUywS36peofiRvDBZ4M4+YxiwqrjUGcwB6w8vu4+nAGC/2cE7cC/QQIw3xZQ1m8zyq0HtdOWgDCrQD43O5gnqZCUmi+uvdr5WHuokG5MK2RWWXlva;3:udxZBoAdCYgwR1NWuJhJN0PkukevYDTtTeD3pDjWIekA0BOjJYypJH4PZ9NnEKJq4hPf53DcQ4EOAIH1P4J//Pzv24phcpKH5Eq2EzYmiYedWdapq3IG4EBuoLqbhXCo X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR08MB0590; X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB0590;25:Is2fse8lZZ8aCb16Sbmx76tenX+Ni4RV1YUfXryb34OOxpXdSp4GiTC481cSMHh2bwIyQ9aXmFR8QJ/JX9DNw2U/cR7vlGf4HwmOkvHKK+ny3qzA3YSE40KJHu0b+COyepUhq4/WWH1ymTrSdnNFSfi+DltbHF9K9WuGXYEYmcATRESGA5DeeGSVZhO4oYLwWoK4EdTAwFnd69as3DoliTTE47e/UffFFKA92H1m2YjLbRH+WkXTS51axRh3CScwc6r7+WvVukNm7zXq0HkRyfQl6fq66fYBG3QVKEfYaEzZRG9+eM8swydCQLhTA646yCQmoYYVlmiMcU3G3r0phlOsA8rbE5l+eql8W/Hs5InwMu0mE1XdRRcd7z+c0Mt/WpBXDvhDP3A9gHiwf78M6o3B4tOWRGYKvJVxD9sck6xAhMgrhNULB1u7nLnotk9VkakjdhctQ6xeCCsOcJ6Yq9t51U6Rat7PLsivJwrFI82pIZA8He7C1gyuWp1Mc+EpfvsOmZYG6thwGK2SuJ/HpveDqe101Jenu6S68J0++RregnlzBe85sKJfXaVCr2N+U3MN65y79h+PxtuKTkxKZRky7zfcrqIG0T0mB2MONedGcND7lnILTuO7Xxb/tBG7R8pL++/DTAWSbnpKUqwW/qK5+E0Lzv6DdjIujxsaw/efRd1pk2drc+b8qzoivRYL10xsM3cKospmrUl6BJDS5mh5qEpUqNzuAamhytiRXOs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:VI1PR08MB0590;BCL:0;PCL:0;RULEID:;SRVR:VI1PR08MB0590; X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB0590;4:gWOtyASsnqth9ur4U44xek6ayNvdBRkDBooQ751rhydvazBmavk9FqNjAy70IdDihrMOai1mwP0hm1RDKCZHVFtrqVypaEQ7NJMhbEFPS//L8ym/DAuwtrIBFif6nuwUfhyiH5Zno7SiZln1p/etRFXmicNA4i1x0Vc4gTXURMs0Kyc+j1JF/NZKGPx0EgPBZJGshM3dAVNAh4rW+CINEGqurBA+ByPwNOMdIK0ovj8x6kImpAK1D/ugHH2WUzf1G39JA6rjvbKzYs1XgmysBYNwYQKlp2d3Fd3eMm52S1DVkyDZ5h5sh96lmCX7Bo/k/ZddVowxLZppwl6ARtTmaPqXyt6LvZi5B2xKtKrjPLaVL1NWzzNM4YmBiSmCWdAKFm6jFKnpv5sc5qtBruhTVyZn5XVC3oNvOMmj6hJMGb0= X-Forefront-PRVS: 09538D3531 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(24454002)(377424004)(33656002)(86362001)(189998001)(81166006)(54356999)(50986999)(76176999)(586003)(42186005)(8676002)(5008740100001)(4326007)(110136002)(2906002)(1076002)(33716001)(3846002)(6116002)(23726003)(97756001)(46406003)(77096005)(9686002)(50466002)(66066001)(5004730100002)(80792005)(93886004)(92566002)(2950100001)(217873001);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR08MB0590;H:esperanza;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB0590;23:FYW11Uo20h/Y05Tl20Bgj81poXIcEavoWGr/rkYYjJs9JcHqLirzXzy9GYNS8CxeihPOMlmx1fL51WVUQIGLzQbbNXyw3aE4lMiJEJjce7GBmypbHuqISDh4pGQRelDGz5PTzcESgyx2efysct4LOyku/9uNt/v7UNr0dF+fD4jDiDfK4m1K83iGw6vBh43Y9QplDBlo3M6l+0cTEQZ3wccCvKOIVHEvc285NlNW+t+F/hg8iqTxAJthiUOj5MdkPwftY0UY9cec0BE/RzMZFdpWmh08b50d+wR4mxpKBfsFDvIfaGM480RI6FTUgpFNaV9EWfzDQfg0ZYdY8B7qGMUMVZzCHCIZ9n/qFxYknBLbFmh1RqHb+aDFVeM4njROD2lycgV6XLgE7wc1UheKnMd7ie/5NFCHI5/O9dCln5KYAxta4HDNCF1zRJ8omN6QGLrU1SsZBAsuWtrfB3UGOSjY2tnpGFc6pxVG7IeVn7dPTiXS0lALX6v1K2y1bcUAk6dJWMArxj/cVxA1/j+PRhQlmVGfF0q/9Fc4fDYnyA+a3wpyi0pWRENaQu0/khEHgmdUogLnpezUqOn1gud7bfUMx0wT5f4ofYtX/IYkPK0MV9g6KnQcYbQDQP5uYy7dSZmjHIjNYi41svItVn7KDLXbs58NTLxIbR6tWWLPmiywRue5w/6dhFCvQmWiwjSJpdZLC6EM9WhorrVYyDgqCChgYTrTu6qat4Vi3LOd0pHcMd1IsDnVPFAq0V0uA143VAZYtYVyYCIjyRB5vRXWCLUixsSgR1iy7k3rGpcjxg7l9YAhPC9NVabKoi/xA4eBnPBhzeDYzQ3ptxAd4pBZ99zXAYbcnLkpvCezDscHWwW3DKsUtLCkUM0+zGBZEDJS1MQIdHVEFJaNsIUx+U4is/hdswhx+Q4cfKiaJyKJLfI= X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB0590;5:PFHUSs0VQdZup4Uubs9y9ZbYxDEJMtI5H9XpF+MgljZSXIiFwzf4IVaAeFib+fNg9vujM8ZUzDKsfS0/Xvc1T54mP4CHg7apUrNWaEtbcLcvlINo42+9cT3ZB3GWLkTaYnWyCa4FsBzUTLlD33EqrQ==;24:gkb4SbRh9+T/6S3iXOjdOe5hCFZx5u4VqWroOP9UJjzoJuHwHNzsZdoeLeJ8qtKkl32UGgRMQ7yN5UdD1p+cvxoPWzxWVvQQPGfPezZM3i4=;7:Y+luxGFAklEGx0BS3SLZ7kIJdOT9P1UUOrIQPg5aWvs6W3K6axmCe0neaH16ddTm0UgMU+r6O7PRqlHHvqqnBbcXe1X2bexoqJspMc6wrKwF5yY8qNHvWOof0y+PSTyvIXjifmAjtO04Y+vsdHnharo+PA9vQILqbuuhIDEyMFSpXJM8H9fKvRDcM6/i0EGh;20:2vcf+XJNU2yo6SK4RD1MrfQ4E5K0/iG2WozKraN36HDJNqCqPMUlKwtW3JmTUSdNwuMC5+rskod3esQulDgGeo5KxgrkMYGFjG/PeZ9s3PAjzlcAY4AdgA3cbySxn9L0JFry6S9rqfJLuk1g48fJC6fmg6zgUMrQG1c6YHUtZ2U= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 May 2016 10:30:18.3468 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB0590 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 24, 2016 at 01:04:33PM -0700, Eric Dumazet wrote: > On Tue, 2016-05-24 at 19:13 +0300, Vladimir Davydov wrote: > > On Tue, May 24, 2016 at 05:59:02AM -0700, Eric Dumazet wrote: > > ... > > > > +static int anon_pipe_buf_steal(struct pipe_inode_info *pipe, > > > > + struct pipe_buffer *buf) > > > > +{ > > > > + struct page *page = buf->page; > > > > + > > > > + if (page_count(page) == 1) { > > > > > > This looks racy : some cpu could have temporarily elevated page count. > > > > All pipe operations (pipe_buf_operations->get, ->release, ->steal) are > > supposed to be called under pipe_lock. So, if we see a pipe_buffer->page > > with refcount of 1 in ->steal, that means that we are the only its user > > and it can't be spliced to another pipe. > > > > In fact, I just copied the code from generic_pipe_buf_steal, adding > > kmemcg related checks along the way, so it should be fine. > > So you guarantee that no other cpu might have done > get_page_unless_zero() right before this test ? Each pipe_buffer holds a reference to its page. If we find page's refcount to be 1 here, then it can be referenced only by our pipe_buffer. And the refcount cannot be increased by a parallel thread, because we hold pipe_lock, which rules out splice, and otherwise it's impossible to reach the page as it is not on lru. That said, I think I guarantee that this should be safe. Thanks, Vladimir From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 25 May 2016 13:30:11 +0300 From: Vladimir Davydov To: Eric Dumazet CC: Andrew Morton , Alexander Viro , Johannes Weiner , Michal Hocko , , , , , Subject: Re: [PATCH RESEND 7/8] pipe: account to kmemcg Message-ID: <20160525103011.GF11150@esperanza> References: <2c2545563b6201f118946f96dd8cfc90e564aff6.1464079538.git.vdavydov@virtuozzo.com> <1464094742.5939.46.camel@edumazet-glaptop3.roam.corp.google.com> <20160524161336.GA11150@esperanza> <1464120273.5939.53.camel@edumazet-glaptop3.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1464120273.5939.53.camel@edumazet-glaptop3.roam.corp.google.com> Sender: owner-linux-mm@kvack.org List-ID: On Tue, May 24, 2016 at 01:04:33PM -0700, Eric Dumazet wrote: > On Tue, 2016-05-24 at 19:13 +0300, Vladimir Davydov wrote: > > On Tue, May 24, 2016 at 05:59:02AM -0700, Eric Dumazet wrote: > > ... > > > > +static int anon_pipe_buf_steal(struct pipe_inode_info *pipe, > > > > + struct pipe_buffer *buf) > > > > +{ > > > > + struct page *page = buf->page; > > > > + > > > > + if (page_count(page) == 1) { > > > > > > This looks racy : some cpu could have temporarily elevated page count. > > > > All pipe operations (pipe_buf_operations->get, ->release, ->steal) are > > supposed to be called under pipe_lock. So, if we see a pipe_buffer->page > > with refcount of 1 in ->steal, that means that we are the only its user > > and it can't be spliced to another pipe. > > > > In fact, I just copied the code from generic_pipe_buf_steal, adding > > kmemcg related checks along the way, so it should be fine. > > So you guarantee that no other cpu might have done > get_page_unless_zero() right before this test ? Each pipe_buffer holds a reference to its page. If we find page's refcount to be 1 here, then it can be referenced only by our pipe_buffer. And the refcount cannot be increased by a parallel thread, because we hold pipe_lock, which rules out splice, and otherwise it's impossible to reach the page as it is not on lru. That said, I think I guarantee that this should be safe. Thanks, Vladimir -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by kanga.kvack.org (Postfix) with ESMTP id AB42B6B0005 for ; Wed, 25 May 2016 06:30:24 -0400 (EDT) Received: by mail-oi0-f70.google.com with SMTP id r64so68012176oie.1 for ; Wed, 25 May 2016 03:30:24 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0115.outbound.protection.outlook.com. [104.47.2.115]) by mx.google.com with ESMTPS id b6si4708362otc.116.2016.05.25.03.30.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 May 2016 03:30:23 -0700 (PDT) Date: Wed, 25 May 2016 13:30:11 +0300 From: Vladimir Davydov Subject: Re: [PATCH RESEND 7/8] pipe: account to kmemcg Message-ID: <20160525103011.GF11150@esperanza> References: <2c2545563b6201f118946f96dd8cfc90e564aff6.1464079538.git.vdavydov@virtuozzo.com> <1464094742.5939.46.camel@edumazet-glaptop3.roam.corp.google.com> <20160524161336.GA11150@esperanza> <1464120273.5939.53.camel@edumazet-glaptop3.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1464120273.5939.53.camel@edumazet-glaptop3.roam.corp.google.com> Sender: owner-linux-mm@kvack.org List-ID: To: Eric Dumazet Cc: Andrew Morton , Alexander Viro , Johannes Weiner , Michal Hocko , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org On Tue, May 24, 2016 at 01:04:33PM -0700, Eric Dumazet wrote: > On Tue, 2016-05-24 at 19:13 +0300, Vladimir Davydov wrote: > > On Tue, May 24, 2016 at 05:59:02AM -0700, Eric Dumazet wrote: > > ... > > > > +static int anon_pipe_buf_steal(struct pipe_inode_info *pipe, > > > > + struct pipe_buffer *buf) > > > > +{ > > > > + struct page *page = buf->page; > > > > + > > > > + if (page_count(page) == 1) { > > > > > > This looks racy : some cpu could have temporarily elevated page count. > > > > All pipe operations (pipe_buf_operations->get, ->release, ->steal) are > > supposed to be called under pipe_lock. So, if we see a pipe_buffer->page > > with refcount of 1 in ->steal, that means that we are the only its user > > and it can't be spliced to another pipe. > > > > In fact, I just copied the code from generic_pipe_buf_steal, adding > > kmemcg related checks along the way, so it should be fine. > > So you guarantee that no other cpu might have done > get_page_unless_zero() right before this test ? Each pipe_buffer holds a reference to its page. If we find page's refcount to be 1 here, then it can be referenced only by our pipe_buffer. And the refcount cannot be increased by a parallel thread, because we hold pipe_lock, which rules out splice, and otherwise it's impossible to reach the page as it is not on lru. That said, I think I guarantee that this should be safe. Thanks, Vladimir -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org