From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21A68CD54A7 for ; Tue, 19 Sep 2023 08:02:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230272AbjISICk (ORCPT ); Tue, 19 Sep 2023 04:02:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbjISICi (ORCPT ); Tue, 19 Sep 2023 04:02:38 -0400 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 957DB120 for ; Tue, 19 Sep 2023 01:02:30 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2bffc55af02so34814451fa.2 for ; Tue, 19 Sep 2023 01:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1695110549; x=1695715349; 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=nWwOBXcgP9QHb+ZwLC4z/fad6HDujTXM9X3AXgFefao=; b=F3pgzF80ybykApF9N2exJ0huxmKEj/JwYyG9wZoIC+wUdSJA/bRF6YpfJc/mg/szkA OsImu0uqYiBUmx53o4mPonCr5nLtlyInVMv7EjTlXZBV/OW+jgLtaIHKQWItQCF9ulRs M+qXKlMomeIukmh0UgualD1oUS+FSCc1iTE1A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695110549; x=1695715349; 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=nWwOBXcgP9QHb+ZwLC4z/fad6HDujTXM9X3AXgFefao=; b=OoX5NYK7Il/6lRqaQXeGyKFP7cET6QuaKyMSivHiQOjps7nMed+z/zrfxmeQASnZfj vIdKFqwqACvZ+yeZqUB1+IYQs6hJq2kRqnUxExEc0ORONhDFn2ZKjjb9MKehq4Xdc17f 3XlT1TmVK6PqpK7D9VPgGMZFowNfFZNFK8EuVIj9a5CW6nU9S+yijXXgyoyEhbxTsYZM JOFTTrIT2I2GQmfDpUh0VEyzD987QEtAP3TNkAjVL+l9ulZ5mb3P9nQ+tFGTqiveQTyY kZpJh+Z0X0r8Ou90H86FAEUOq5SwHcTsxC0tC3X6/SmnyL0Rtte+xiDM0EqGPDzHh01E huFw== X-Gm-Message-State: AOJu0Yw4uoxuuLa4m84k4zz2satxfDdEQbd9m0ki9F4kmtvP84exffaW xSQKGk6/K6+fypoLfV12Sw9+DANLhd+tAe/LYE16PQ== X-Google-Smtp-Source: AGHT+IF39NIDgeU/oOTNvV5zRchTf9jdNdxeIj1xURpUADWsrOYnhsqNCpFqVeqIom7TB0F8lXRC41YrHzXHEQ7vZTE= X-Received: by 2002:a2e:9f0a:0:b0:2bc:be3c:9080 with SMTP id u10-20020a2e9f0a000000b002bcbe3c9080mr9595518ljk.27.1695110548691; Tue, 19 Sep 2023 01:02:28 -0700 (PDT) MIME-Version: 1.0 References: <20230914-salzig-manifest-f6c3adb1b7b4@brauner> <20230914-lockmittel-verknallen-d1a18d76ba44@brauner> <20230918-grafik-zutreffen-995b321017ae@brauner> <20230918-hierbei-erhielten-ba5ef74a5b52@brauner> <20230918-stuhl-spannend-9904d4addc93@brauner> <20230918-bestialisch-brutkasten-1fb34abdc33c@brauner> <20230919003800.93141-1-mattlloydhouse@gmail.com> In-Reply-To: <20230919003800.93141-1-mattlloydhouse@gmail.com> From: Miklos Szeredi Date: Tue, 19 Sep 2023 10:02:17 +0200 Message-ID: Subject: Re: [RFC PATCH 2/3] add statmnt(2) syscall To: Matthew House Cc: Christian Brauner , Miklos Szeredi , Linus Torvalds , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-man@vger.kernel.org, linux-security-module@vger.kernel.org, Karel Zak , Ian Kent , David Howells , Al Viro , Christian Brauner , Amir Goldstein Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Tue, 19 Sept 2023 at 02:38, Matthew House wrote: > One natural solution is to set either of the two lengths to the expected > size if the provided buffer are too small. That way, the caller learns both > which of the buffers is too small, and how large they need to be. Replacing > a provided size with an expected size in this way already has precedent in > existing syscalls: This is where the thread started. Knowing the size of the buffer is no good, since the needed buffer could change between calls. We are trying to create a simple interface, no? My proposal would need a helper like this: struct statmnt *statmount(uint64_t mnt_id, uint64_t mask, unsigned int flags) { size_t bufsize = 1 << 15; void *buf; int ret; for (;;) { buf = malloc(bufsize <<= 1); if (!buf) return NULL; ret = syscall(__NR_statmnt, mnt_id, mask, buf, bufsize, flags); if (!ret) return buf; free(buf); if (errno != EOVERFLOW) return NULL; } } Christian's would be (ignoring .fs_type for now): int statmount(uint64_t mnt_id, uint64_t mask, struct statmnt *st, unsigned int flags) { int ret; st->mnt_root_size = 1 << 15; st->mountpoint_size = 1 << 15; for (;;) { st->mnt_root = malloc(st->mnt_root_size <<= 1); st->mountpoint = malloc(st->mountpoint <<= 1); if (!st->mnt_root || !st->mountpoint) { free(st->mnt_root); free(st->mountpoint); return -1; } ret = syscall(__NR_statmnt, mnt_id, mask, st, sizeof(*st), flags); if (!ret || errno != EOVERFLOW) return ret; free(st->mnt_root); free(st->mountpoint); } } It's not hugely more complex, but more complex nonetheless. Also having the helper allocate buffers inside the struct could easily result in leaks since it's not obvious what the caller needs to free, while in the first example it is. Note that I'm not against having the prototype on the kernel interface take a typed pointer. If strings are not needed, both interfaces would work in exactly the same way. Thanks, Miklos