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 74249CD13DD for ; Mon, 18 Sep 2023 17:02:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231366AbjIRRCl (ORCPT ); Mon, 18 Sep 2023 13:02:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231289AbjIRRCj (ORCPT ); Mon, 18 Sep 2023 13:02:39 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C067EAF; Mon, 18 Sep 2023 10:02:33 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9DD72C32788; Mon, 18 Sep 2023 14:35:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695047715; bh=ZLM4uoXja+zAiLIjYwhVmMEy6VOFuum0PgmoPN9LGCI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NPBwd5dgOfqaXViVkdRXK1DtwA3TsAKmBHOLsoJZyq7Rx6xum+24NFGop6AbEB/fx aZ9PhThcmToXryHNCGbAazkNY04lInBATmbAWvq+bBef+uSOJ/FIanVNR4Pj8TGnhw xG921yK0Zl7KC8Hjszekg5FL/JfZcBHhTaOliV08OcfrOXA13RRe7IgnEME3HZ3a9L 7fNCJh4afGhuMkdL4joRtsvjJ5xVtsZquIS+S4Ske6vDlx19VqSBIixn45Mf67bKrA 960XkmwQvSnTpkauN1AI0itVwLwAVlsOuP45TKgZLBj+34Etm9URXbgIkh6bA+euo5 WXEB7mZcHvULg== Date: Mon, 18 Sep 2023 16:35:09 +0200 From: Christian Brauner To: Jeff Layton Cc: Miklos Szeredi , 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 Subject: Re: [RFC PATCH 2/3] add statmnt(2) syscall Message-ID: <20230918-geber-kruste-f9491ce3de41@brauner> References: <20230913152238.905247-1-mszeredi@redhat.com> <20230913152238.905247-3-mszeredi@redhat.com> <20230914-salzig-manifest-f6c3adb1b7b4@brauner> <20230914-lockmittel-verknallen-d1a18d76ba44@brauner> <3183d8b21e78dce2c1d5cbc8a1304f2937110621.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3183d8b21e78dce2c1d5cbc8a1304f2937110621.camel@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org > Fixed size structs are much nicer to deal with, and most of the fields > we're talking about don't change ofetn enough to make trying to strive > for perfect atomicity worthwhile. I think we can live with mnt_root and mnt_mountpoint in struct statmnt if we add a length field for both them and make them __u64 pointers. That's what we did in clone3() for the pid array and bpf is doing that as well for log buffers and pathnames. So if Miklos is fine with that then I'm happy to compromise. And I think that's all the variable length data we want in struct statmount anyway. > ...and then if the mnt_change_cookie hasn't changed, you know that the > string option was stable during that window. Meh, I would really like to sidestep this and keep it as simple as we can. I like the proposal overall I just don't want it to get diluted too much by exploding into another overly broad solution.