From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 CF5901D546; Mon, 20 Nov 2023 15:38:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XggcxYpd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CFDA8C433C8; Mon, 20 Nov 2023 15:38:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700494691; bh=V/gEbXHf7msuIYmekR4+CzwjOqMIaKw26uDtvj0+qFM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XggcxYpdOUX2bbB8XTJAwJYcatmv0J9n0vYM4cR4w7viqBhtBRsz7CTZ9T+cqbUIL 44Aj/5aqonkcHTjvUrEjR9s7FRvivyFau/DZyMdBS/23foob8BJ18/ODKMotPsNt90 ka20WHes20fBe0hfg9bWBTKJgBGDgfLFduMUGGkUN0JjrhUp6BnEsqMYOdWsB7tTmQ zq8iL6dA/lgOiTSC/pL35W7gUFWVkWnIy23mqKPPHpuFnE8aati9dM7xDgw8TDXBqS DEGdC6qmJZW4mq8vl5J0WeOmqNuAzsCtqvbD6Fak09QFFxc95clvVGo4nC4Xa+cBRL +yow5ssMmjaNw== Date: Mon, 20 Nov 2023 16:38:05 +0100 From: Christian Brauner To: Miklos Szeredi Cc: Florian Weimer , libc-alpha@sourceware.org, linux-man , Alejandro Colomar , Linux API , linux-fsdevel@vger.kernel.org, Karel Zak , Ian Kent , David Howells , Christian Brauner , Amir Goldstein , Arnd Bergmann Subject: Re: proposed libc interface and man page for statmount(2) Message-ID: <20231120-wachhalten-darfst-ed3244509881@brauner> References: <87fs15qvu4.fsf@oldenburg.str.redhat.com> <87leawphcj.fsf@oldenburg.str.redhat.com> Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Mon, Nov 20, 2023 at 12:55:17PM +0100, Miklos Szeredi wrote: > On Fri, Nov 17, 2023 at 04:50:25PM +0100, Miklos Szeredi wrote: > > I wonder... Is there a reason this shouldn't be done statelessly by > > adding an "continue after this ID" argument to listmount(2)? The > > caller will just need to pass the last mount ID received in the array > > to the next listmount(2) call and iterate until a short count is > > returned. > > No comments so far... maybe more explanation is needed. > > New signature of listmount() would be: > > ssize_t listmount(uint64_t mnt_id, uint64_t last_mnt_id, > uint64_t *buf, size_t bufsize, unsigned int flags); > > And the usage would be: > > for (last = 0; nres == bufsize; last = buf[bufsize-1]) { > nres = listmount(parent, last, buf, bufsize, flags); > for (i = 0; i < nres; i++) { > /* process buf[i] */ > } > } > > > Here's a kernel patch against the version in Christian's tree. The syscall > signature doesn't need changing, since we have a spare u64 in the mnt_id_req for > listmount. > > The major difference is in the order that the mount ID's are listed, which is > now strictly increasing. Doing the recursive listing in DFS order is nicer, but > I don't think it's important enough. > > Comments? Sure. We can also add a size argument to struct mnt_id_req then you can version it by size and extend it easily later (see sched_{g,s}etattr() that do similar things): struct mnt_id_req { __u32 size; __u64 mnt_id; __u64 request_mask; union { __u64 request_mask; __u64 last_mnt_id; }; }; foo(struct mnt_id_req __user *ureq) { u32 size; struct mnt_id_req kreq; ret = get_user(size, &ureq->size); if (ret) return ret; if (size < MNT_ID_REQ_SIZE_VER0 || size > PAGE_SIZE) return -EINVAL; ret = copy_struct_from_user(&kreq, sizeof(kreq), ureq, size); if (ret) return ret; }