From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="JrPCTJa+" Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B255D1AD for ; Fri, 17 Nov 2023 07:13:58 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-53db360294fso3199475a12.3 for ; Fri, 17 Nov 2023 07:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1700234037; x=1700838837; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7Oo189R36r9S1P5c11qiLhRbRaLL1RPe2gX3RGHrDug=; b=JrPCTJa+oNx/yxLHdc3BtbQcpBIUyO8JIu7mx0UHx5aE5JWC+19EWeeF19Y7fdRYi9 AhrY69cGPvg+Mi4vQ4aNRVd2QRVykNAtY5UGKg4lv9v6YULNBQVHuvaDyGlPeHoZ1YFd 6zvucP6pd1P3jlWeBnTgXS5sy2q823MHMHBrE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700234037; x=1700838837; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7Oo189R36r9S1P5c11qiLhRbRaLL1RPe2gX3RGHrDug=; b=ugzZ2lFXLsMlyors/oSSDbrSPWNNAAwPBd8d3PBcAYESKA/xtFd48eqY2QFEvPubBI HgA09ReDV/iuyO7gU0+X4qAzFNca86o7xB3/Eb5Zxp782KMjyTJQnqg1HPMxuBMMazmL +k/X3F5jEAW13BFqBUiJhtgeBkRmV+9M0ptDR9oOuKOV9o1miFIUERZzadfRIRlsNObE FJnUI7S8+xwbfgiBjhxy2jTKMelb5PhjzhbPLGVMV4TGjfviFHae1BxuavBL/xLRNyxi b+NUp5C/Jh9BLIeR6BDfNZjBpm+0JUZeY6e4H1jqvxID6iW7IhF0KhAu+MUtCF5aSE43 3isA== X-Gm-Message-State: AOJu0YzAkCDeKuR1+XGM0CcOZFXbFjrNXTKsVjUGRK6PqfGT9DZcnsEv oqYn7vai9u2vQhhW0B5mONMYsEJ0GyL1ABECkImHEQ== X-Google-Smtp-Source: AGHT+IHMUXnjmlNoD8wvqNvaWmdh3jNGp37NhE+vXpAEq21urujA7z030N8vV5bqDLo2H5+mjckvnRSnPDlR0gomq3o= X-Received: by 2002:a17:906:738d:b0:9f8:a622:d670 with SMTP id f13-20020a170906738d00b009f8a622d670mr1439944ejl.19.1700234037204; Fri, 17 Nov 2023 07:13:57 -0800 (PST) Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <87fs15qvu4.fsf@oldenburg.str.redhat.com> <87leawphcj.fsf@oldenburg.str.redhat.com> In-Reply-To: <87leawphcj.fsf@oldenburg.str.redhat.com> From: Miklos Szeredi Date: Fri, 17 Nov 2023 16:13:45 +0100 Message-ID: Subject: Re: proposed libc interface and man page for statmount(2) To: Florian Weimer Cc: 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 Content-Type: text/plain; charset="UTF-8" On Fri, 17 Nov 2023 at 15:47, Florian Weimer wrote: > The strings could get fairly large if they ever contain key material, > especially for post-quantum cryptography. A bit far fetched, but okay. > We have plenty of experience with these double-buffer-and-retry > interfaces and glibc, and the failure mode once there is much more data > than initially expected can be quite bad. For new interfaces, I want a > way to avoid that. At least as long applications use statmount_allloc, > we have a way to switch to a different interface if that becomes > necessary just with a glibc-internal change. Fair enough. And that brings us to listmount(2) where I'm less sure that the alloc+retry strategy is the right one. I still think that a namespace with millions of mounts is unlikely, but it's not completely out of the question. Also a listmount_alloc(3) API is less obvious since the mount ID array as well as its size needs to be returned. So I'm thinking whether it's a good idea to turn this into a open/list/.../close style of interface in libc? We could do that in the kernel as well, but I'm not sure it's worth it at this point. Thanks, Miklos