From patchwork Tue Dec 24 01:20:15 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nixiaoming X-Patchwork-Id: 13919577 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9FA2418D; Tue, 24 Dec 2024 01:20:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.190 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735003222; cv=none; b=Aia5n7LIJwQ49a3vShlRv5DnNckhhYffXqm+r/Vu0ae11fpy+Frd4o/jXdzjJQWatKBKM5VRRvSqvsJE4HVJIh3poVgVZcKfQrVAQh7ub6kuUHT3YLIHINXjgb/Qpn0ZnBeOe9vcXX/eEIssM31diYuzvQxr1mSPHGffT9WHl0o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735003222; c=relaxed/simple; bh=ZMH7vtWdAf6kYlZiBNdl2l15bBxAq14Y71aH/mjaxjc=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=TasgoI7UJgxLyeoA+zdeGYjkAyhqA/TBNUJZXqX0Cf6pFdhRcQH/p1BRNyQx+wBsHwdgNwosC9iMRgErUAb9AWzWabVpFzi/BPZSFwuni13EllkegMNFHoOMoB8aHoc7Icoke9KtNgBkzSsgGzlUhzhyc7a9dSSsLvrTMw9wT/E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.190 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4YHH896TfVz21p6L; Tue, 24 Dec 2024 09:18:17 +0800 (CST) Received: from kwepemf100011.china.huawei.com (unknown [7.202.181.225]) by mail.maildlp.com (Postfix) with ESMTPS id 5BDC51A0188; Tue, 24 Dec 2024 09:20:16 +0800 (CST) Received: from kwepemd100026.china.huawei.com (7.221.188.98) by kwepemf100011.china.huawei.com (7.202.181.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 24 Dec 2024 09:20:16 +0800 Received: from kwepemd100026.china.huawei.com ([7.221.188.98]) by kwepemd100026.china.huawei.com ([7.221.188.98]) with mapi id 15.02.1544.011; Tue, 24 Dec 2024 09:20:15 +0800 From: Nixiaoming To: "arnd@arndb.de" , "viro@zeniv.linux.org.uk" , "brauner@kernel.org" , "jack@suse.cz" CC: "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "weiyongjun (A)" , "Liuyang (Young,C)" Subject: [RFC] RLIMIT_NOFILE: the maximum number of open files or the maximum fd index? Thread-Topic: [RFC] RLIMIT_NOFILE: the maximum number of open files or the maximum fd index? Thread-Index: AdtVoev4zwP9BO3zRfO8OhNn2n+8UA== Date: Tue, 24 Dec 2024 01:20:15 +0000 Message-ID: <4731d54723b841599882a24f7aa73aaa@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 I always thought that RLIMIT_NOFILE limits the number of open files, but when I read the code for alloc_fd(), I found that RLIMIT_NOFILE is the largest fd index? Is this a mistake in my understanding, or is it a code implementation error? ----- alloc_fd code: ----- Test Procedure 1. ulimit -n 1024. 2. Create 1000 FDs. 3. ulimit -n 100. 4. Close all FDs less than 100 and continue to hold FDs greater than 100. 5. Open() and check whether the FD is successfully created, If RLIMIT_NOFILE is the upper limit of the number of opened files, step 5 should fail, but step 5 returns success. ----- test code: #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { int fd, i; struct rlimit rl; rl.rlim_cur = 1024; rl.rlim_max = 1024; if (setrlimit(RLIMIT_NOFILE, &rl) == -1) { perror("setrlimit"); exit(EXIT_FAILURE); } for (i = 0; i < 1000; i++) { fd = open("/dev/null", O_RDWR | O_CLOEXEC); if (fd == -1) { perror("open"); exit(EXIT_FAILURE); } } rl.rlim_cur = 100; rl.rlim_max = 100; if (setrlimit(RLIMIT_NOFILE, &rl) == -1) { perror("setrlimit"); exit(EXIT_FAILURE); } for (i = 3; i < 100; i++) { close(i); } fd = open("/dev/null", O_RDWR | O_CLOEXEC); if (fd == -1) { if (errno == EMFILE) { printf("ok\n"); return 0; } else { perror("open"); exit(EXIT_FAILURE); } } else { printf("fail: {OPEN_MAX} file descriptors are currently open in the calling process, but open() still returns a success\n"); return -1; } return 0; } ---- Best regards, Xiaoming Ni diff --git a/fs/file.c b/fs/file.c index fb1011c..e47ddac 100644 --- a/fs/file.c +++ b/fs/file.c @@ -561,6 +561,7 @@ static int alloc_fd(unsigned start, unsigned end, unsigned flags) */ error = -EMFILE; if (unlikely(fd >= end)) + // There may be unclosed fd between [end, max]. the number of open files can be greater than RLIMIT_NOFILE. goto out; if (unlikely(fd >= fdt->max_fds)) {