From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034648AbcIWOAI (ORCPT ); Fri, 23 Sep 2016 10:00:08 -0400 Received: from smtp-out4.electric.net ([192.162.216.186]:53695 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934625AbcIWOAG (ORCPT ); Fri, 23 Sep 2016 10:00:06 -0400 X-Greylist: delayed 1282 seconds by postgrey-1.27 at vger.kernel.org; Fri, 23 Sep 2016 10:00:05 EDT From: David Laight To: "'Vlastimil Babka'" , Eric Dumazet CC: Alexander Viro , Andrew Morton , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Michal Hocko , "netdev@vger.kernel.org" , Linux API , "linux-man@vger.kernel.org" Subject: RE: [PATCH v2] fs/select: add vmalloc fallback for select(2) Thread-Topic: [PATCH v2] fs/select: add vmalloc fallback for select(2) Thread-Index: AQHSFPtnA7bZnB3Yc0m96JsM2uwSuaCG0LqA///2owCAAEmK4A== Date: Fri, 23 Sep 2016 13:35:52 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB0107FEB@AcuExch.aculab.com> References: <20160922164359.9035-1-vbabka@suse.cz> <1474562982.23058.140.camel@edumazet-glaptop3.roam.corp.google.com> <12efc491-a0e7-1012-5a8b-6d3533c720db@suse.cz> <1474564068.23058.144.camel@edumazet-glaptop3.roam.corp.google.com> <063D6719AE5E284EB5DD2968C1650D6DB0107DC8@AcuExch.aculab.com> <3bbcc269-ec8b-12dd-e0ae-190c18bc3f47@suse.cz> In-Reply-To: <3bbcc269-ec8b-12dd-e0ae-190c18bc3f47@suse.cz> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u8NE0DRo024659 From: Vlastimil Babka > Sent: 23 September 2016 10:59 ... > > I suspect that fdt->max_fds is an upper bound for the highest fd the > > process has open - not the RLIMIT_NOFILE value. > > I gathered that the highest fd effectively limits the number of files, > so it's the same. I might be wrong. An application can reduce RLIMIT_NOFILE below that of an open file. David