From nobody Mon Apr 27 07:12:00 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g3vss3DGPz6brsv for ; Mon, 27 Apr 2026 07:13:05 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g3vsq4gcdz49Kh for ; Mon, 27 Apr 2026 07:13:03 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=JCOuoxki; dmarc=pass (policy=none) header.from=gmail.com; arc=pass ("google.com:s=arc-20240605:i=1"); spf=pass (mx1.freebsd.org: domain of cedric.blancher@gmail.com designates 2001:4860:4864:20::35 as permitted sender) smtp.mailfrom=cedric.blancher@gmail.com Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-43034c0fd27so386332fac.1 for ; Mon, 27 Apr 2026 00:13:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777273977; cv=none; d=google.com; s=arc-20240605; b=cJtI6+cWAg4vpqgzCh6op0W2NIvYIAX/QPqRJERAjvznA9scWWxHzeE7AwjV8pt+CD AGkESWLT6rtrnaEB1iKpaqm6AGkJOawq8UtIHrlUIXqeoUNhv7BH5YOkCDIayMPrOtDy BEpBk2twn7Uaf/ZJ6W1EgLBJa8zEZoa/WPNqfSU16oitT0EPbXOjxWv2Tp7xB872tr3h OvRFrWtBJjqV5pwEqQ33FFzANKAcBsGGsjSvyzr5i4LrAWub54dvu1nVI7r0RGNCxN5g NrTRQ4wxvAwWBHSOcJQzhR+iTokEC9S/qIJuFDlSSF6615j/Y4gfAXr6S2THQVQU3PBF uo8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=TxyPkit5nnIe8jOr2X0KB6MHGkqtNvxjf3t6iOl48/k=; fh=BGnlq/Bnk5yuHoIOHmeKjbe0R0Wn0sUc6aL/mCAMBkg=; b=YPrr9s3KhGixqqRRnncdF3G5iEmZXIxnVNdtAzLP4C9T9TYrON+UM6UQnSWzmv0Oii onMYx29a9oCxK+MFDCRhBN6+YOIzXnpGFHDoh+QoZRzOUSY6On8dzl34t4s34cn5uwq9 t0UFEjw7yeD9CMXnWN5RGoIYpTxkiurcc7hNoT80s4NgJdeoPpQj5cUdDUOa7Yws/5Yz 0SKjLxjcvBMGbuthZXARRo/qEMqF3fsBEwsm8a3vqOfp9G3VvzwJibuTwgoPangzt/EA qTfilGIG0NFf3zsljJlD2IlasksAhINO4G6zE5EQ4NVvJxOExF7EJBXezW+0MPb+LjZi q9TA==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777273977; x=1777878777; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=TxyPkit5nnIe8jOr2X0KB6MHGkqtNvxjf3t6iOl48/k=; b=JCOuoxkih9bxOk2MXN02tegz55slQjtE9sl883YPISYEVqabMH1FvF2Vq0U4VDerbw YhwdPy+1sEQCDHrBEYw/OYmSb8CPWle1lVpNdX9lLgySOmzq17mEUo0Q+9Tn20RoR5+f dzFqm5jy4V5geJToqXVJxbYzRXtIMDD+T0l8Q357SVL7sfOZ8MQmOu+Aq7uGC9toAHck Q0bJF6KvKG0M3CADX1Bc433BlwjjHnvpnRVIMfLeVkU7lcavUHro4/8ceS3OG1a2jjt4 bDREHmmWim5lu++J8RWGENQNebNIhPgFPTMw2Aw0937qmRWkfFd33HM6UTGjnYv7WDbp VcJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777273977; x=1777878777; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TxyPkit5nnIe8jOr2X0KB6MHGkqtNvxjf3t6iOl48/k=; b=RIDH2gLt6h6mYO3J+he5JDoBgHhuAeV6uhKGiKlUUFEln7Aq4mOF0Kv0MXHuG0Pf/f iB53jW/zCVLUQcKW4bv+S/ipmjh5guwo1fDUmiMBTtSKcFLDbfnOir7+iFe1zfbDbBkn yBRz5Vvf07f+sGHInhfXDjUvGPyLI3zpnwYDCmumIPkrczH0CkBu4C/mwdmn683uq3YQ RQ86X/yBSYe1cznzle9jtcHYXnl9kQ5HTJzszaNcGI8qhyAlUnOfRUBroS6AVwjcrkMS 0/1iyNSjBkNI51NuT6LEaWDfhAHzq5Un3xV8dxT5XAy5lyY8YN5bwn7aJKtJN2oo3hFR aMcw== X-Gm-Message-State: AOJu0YyXDWhJz264iwDxRO6VpYCHhEydetg31bNLueSU8jJfgwlMxd5f lL1YFilwBVFexiA3hos0+EMa3rR3LpTxtxPFl4GXVPzkLDhNzeXGvPWQh/z1MkYQHWOzLEMOqf0 Z3ikH7QNxg/UzoGW8MKFfYhbaKqLTB9rVig== X-Gm-Gg: AeBDies3BrVQXtNuSxGa5C8mgxj8eNOZzYwa6yMeHvsbj4Tw7t/rH7i8iN5mPyHDL+t WDrlmEtpm/5rbFvXszphQOUyrWqFw7zysHz1o+H3CiAhO6EL2rS1vaUScxWp7Yjqv8l6t7DxPqF YYCSMP3tzQFAkHX0wBczLsS/rmMDXo3MoGAz2Nc0NdHudkU3X5y/MeXW3ZLD2BP+A35WtUZzEra spDnPAXHI7dC1k49SQU3tqhdnAYtdl5REygSBHuz+JYYi/L2C0XpRh4+DqOiJVVsiSRilwk+/Xw 9WSi+r4IYFvUD2j3bDG1PSTPfPQ= X-Received: by 2002:a05:6870:ec86:b0:42f:cd67:2b84 with SMTP id 586e51a60fabf-42fcd675157mr11884385fac.9.1777273977020; Mon, 27 Apr 2026 00:12:57 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <20260424-case-sensitivity-v11-0-de5619beddaf@oracle.com> <20260424-case-sensitivity-v11-3-de5619beddaf@oracle.com> In-Reply-To: <20260424-case-sensitivity-v11-3-de5619beddaf@oracle.com> From: Cedric Blancher Date: Mon, 27 Apr 2026 09:12:00 +0200 X-Gm-Features: AVHnY4K9azsYNbOnLXEMna-MPIbcPexuenz-4E6JPJ4-aDAlDZBAYZxHW3PeaJY Message-ID: Subject: FreeBSD NFSv4.1 server exporting FreeBSD FAT filesystem - case-insensitive=true? Fwd: [PATCH v11 03/15] fat: Implement fileattr_get for case sensitivity To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-5.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; ARC_ALLOW(-1.00)[google.com:s=arc-20240605:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4864::/56]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::35:from]; RCVD_COUNT_ONE(0.00)[1]; SUBJECT_HAS_QUESTION(0.00)[] X-Rspamd-Queue-Id: 4g3vsq4gcdz49Kh X-Spamd-Bar: ---- Good morning! How does the FreeBSD NFSv4.1 server behave when it exports a FreeBSD FAT filesystem? Does it set the case-insensitive and case-nonpreserving FATTR4 attributes to case-insensitive=true? Ced ---------- Forwarded message --------- From: Chuck Lever Date: Sat, 25 Apr 2026 at 03:53 Subject: [PATCH v11 03/15] fat: Implement fileattr_get for case sensitivity To: Al Viro , Christian Brauner , Jan Kara Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , Chuck Lever , Roland Mainz From: Chuck Lever Report FAT's case sensitivity behavior via the FS_XFLAG_CASEFOLD and FS_XFLAG_CASENONPRESERVING flags. FAT filesystems are case-insensitive by default. MSDOS supports a 'nocase' mount option that enables case-sensitive behavior; check this option when reporting case sensitivity. VFAT long filename entries preserve case; without VFAT, only uppercased 8.3 short names are stored. MSDOS with 'nocase' also preserves case since the name-formatting code skips upcasing when 'nocase' is set. Check both options when reporting case preservation. Reviewed-by: Jan Kara Reviewed-by: Roland Mainz Signed-off-by: Chuck Lever --- fs/fat/fat.h | 3 +++ fs/fat/file.c | 32 ++++++++++++++++++++++++++++++++ fs/fat/namei_msdos.c | 1 + fs/fat/namei_vfat.c | 1 + 4 files changed, 37 insertions(+) diff --git a/fs/fat/fat.h b/fs/fat/fat.h index 5a58f0bf8ce8..99ed9228a677 100644 --- a/fs/fat/fat.h +++ b/fs/fat/fat.h @@ -10,6 +10,8 @@ #include #include +struct file_kattr; + /* * vfat shortname flags */ @@ -408,6 +410,7 @@ extern void fat_truncate_blocks(struct inode *inode, loff_t offset); extern int fat_getattr(struct mnt_idmap *idmap, const struct path *path, struct kstat *stat, u32 request_mask, unsigned int flags); +int fat_fileattr_get(struct dentry *dentry, struct file_kattr *fa); extern int fat_file_fsync(struct file *file, loff_t start, loff_t end, int datasync); diff --git a/fs/fat/file.c b/fs/fat/file.c index becccdd2e501..5f0178fc2ede 100644 --- a/fs/fat/file.c +++ b/fs/fat/file.c @@ -17,6 +17,7 @@ #include #include #include +#include #include "fat.h" static long fat_fallocate(struct file *file, int mode, @@ -398,6 +399,36 @@ void fat_truncate_blocks(struct inode *inode, loff_t offset) fat_flush_inodes(inode->i_sb, inode, NULL); } +int fat_fileattr_get(struct dentry *dentry, struct file_kattr *fa) +{ + struct msdos_sb_info *sbi = MSDOS_SB(dentry->d_sb); + bool case_sensitive; + + /* + * FAT filesystems are case-insensitive by default. VFAT + * becomes case-sensitive when mounted with 'check=strict', + * which installs vfat_dentry_ops. MSDOS has no such option; + * its 'nocase' mount option selects case-sensitive matching. + * + * VFAT long filename entries preserve case. Without VFAT, only + * uppercased 8.3 short names are stored. MSDOS with 'nocase' + * also preserves case. + */ + if (sbi->options.isvfat) + case_sensitive = sbi->options.name_check == 's'; + else + case_sensitive = sbi->options.nocase; + + if (!case_sensitive) { + fa->fsx_xflags |= FS_XFLAG_CASEFOLD; + fa->flags |= FS_CASEFOLD_FL; + if (!sbi->options.isvfat) + fa->fsx_xflags |= FS_XFLAG_CASENONPRESERVING; + } + return 0; +} +EXPORT_SYMBOL_GPL(fat_fileattr_get); + int fat_getattr(struct mnt_idmap *idmap, const struct path *path, struct kstat *stat, u32 request_mask, unsigned int flags) { @@ -575,5 +606,6 @@ EXPORT_SYMBOL_GPL(fat_setattr); const struct inode_operations fat_file_inode_operations = { .setattr = fat_setattr, .getattr = fat_getattr, + .fileattr_get = fat_fileattr_get, .update_time = fat_update_time, }; diff --git a/fs/fat/namei_msdos.c b/fs/fat/namei_msdos.c index 4cc65f330fb7..0fd2971ad4b1 100644 --- a/fs/fat/namei_msdos.c +++ b/fs/fat/namei_msdos.c @@ -644,6 +644,7 @@ static const struct inode_operations msdos_dir_inode_operations = { .rename = msdos_rename, .setattr = fat_setattr, .getattr = fat_getattr, + .fileattr_get = fat_fileattr_get, .update_time = fat_update_time, }; diff --git a/fs/fat/namei_vfat.c b/fs/fat/namei_vfat.c index 918b3756674c..e909447873e3 100644 --- a/fs/fat/namei_vfat.c +++ b/fs/fat/namei_vfat.c @@ -1185,6 +1185,7 @@ static const struct inode_operations vfat_dir_inode_operations = { .rename = vfat_rename2, .setattr = fat_setattr, .getattr = fat_getattr, + .fileattr_get = fat_fileattr_get, .update_time = fat_update_time, }; -- 2.53.0 -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur From nobody Mon Apr 27 14:21:34 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g45NL1GYGz6b8mv for ; Mon, 27 Apr 2026 14:21:38 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Received: from mail.stormshield.eu (mail.stormshield.eu [91.212.116.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stormshield.eu", Issuer "Sectigo Public Server Authentication CA OV R36" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g45NJ6yzLz3ThP; Mon, 27 Apr 2026 14:21:36 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stormshield.eu header.s=signer2 header.b=vmEHk3LG; dmarc=pass (policy=quarantine) header.from=stormshield.eu; spf=pass (mx1.freebsd.org: domain of Stephane.ROCHOY@stormshield.eu designates 91.212.116.25 as permitted sender) smtp.mailfrom=Stephane.ROCHOY@stormshield.eu DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stormshield.eu; s=signer2; t=1777299695; h=From:Subject:Date:Message-ID:To:Cc :MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To :References; bh=A/PQ2SF7Gsj9pxpwhDgig3JSAOverQ+eE6fa1IRlNJg=; b=vmEHk3LGL wuCczLX/cl5Z3/+/M1nuVKKCHYzuCmQ7hE907nXbCVi4LO3GpoT0iYVcqFR+KtOfma0KnQ0O1 8L/5iH4TK2/vL+WPixn1jJV8eDplOPlbTGvEqTXV3JzHtyX0Ov9o9Ieub9Q1wGVN4XHUC+fuK VLTv62xfgTpKnPIri/5jXSYBENyn8oSGDzQJyG7EcBoVnMDy5ZuSNHjyDGZffQEb8POvCaCKg PeOeK/6DQ2zdU50xM8+ZYM2vgBW7CrVesLK+2UPrpTsRH2sd3h9ixo08FCUdii19KJ9ZGjPah o/Eq1BYwH2I8evWxrVsHWIsM5O7mNATRnuhZhA/8A==; From: =?utf-8?Q?St=C3=A9phane_Rochoy?= To: Dmitry Salychev CC: Subject: Re: Looking for committers to add sysutils/fand to src In-Reply-To: <86eckzt5gf.fsf@peasant.salychev.org> (Dmitry Salychev's message of "Wed, 01 Apr 2026 11:06:40 +0200") References: <87eckz3zgl.fsf@stormshield.eu> <86eckzt5gf.fsf@peasant.salychev.org> Date: Mon, 27 Apr 2026 16:21:34 +0200 Message-ID: <87bjf4cwlt.fsf@stormshield.eu> User-Agent: Gnus/5.13 (Gnus v5.13) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: ICTDCCEXCH003.one.local (10.180.4.3) To ICTDCCEXCH002.one.local (10.180.4.2) X-DKIM-Signer: DkimX (v3.70.370) X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[stormshield.eu,quarantine]; R_SPF_ALLOW(-0.20)[+a:mail.stormshield.eu]; R_DKIM_ALLOW(-0.20)[stormshield.eu:s=signer2]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[stormshield.eu:+] X-Rspamd-Queue-Id: 4g45NJ6yzLz3ThP X-Spamd-Bar: --- Dmitry Salychev writes: > I've a question after reading the github discussion. Who's going to > maintain fand if it'll be merged to the base system? Corey mentioned > that he'd archive his github repository in this case. Hi, Oops, didn't notice I missed to CC freebsd-hackers@ :/ As my work is sponsored by my company (Stormshield), I'll be happy to maintain fand as long as I'm allowed to, of course. BTW I'm still looking for a commiter qualified to mark this as fit-for-base ;) Regards, St=C3=A9phane From nobody Mon Apr 27 21:30:10 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g4GvD6hKdz6bf9R for ; Mon, 27 Apr 2026 21:30:32 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g4GvC5dpZz3ZyD for ; Mon, 27 Apr 2026 21:30:31 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=EZv8Q9mf; dmarc=pass (policy=none) header.from=gmail.com; arc=pass ("google.com:s=arc-20240605:i=1"); spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52e as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-676e62faf2bso10726160a12.1 for ; Mon, 27 Apr 2026 14:30:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777325425; cv=none; d=google.com; s=arc-20240605; b=eqw1bArLuI27w6YPHjMTZLxavrVNBxXLJVbMlEo+wNglP0WrH8mWnLCLAXMcA2l7pi lW2vTeUPZS2R5y1/81bRiNRiJ9gQFryKRNCfIhmoDsSKzf5VNOx6v6dIS1k39NRtZ7jr IDs4S/CVUcg9VUTlzycVbYHbzX4XETuYQ4PcZERBQaC5kodPCMHsiwAsUWImxJpq8y4w HhSpLtXD+5E6HmwF2EA6X009yoTl9A/Jgxesi8SRA2OoNzYtdHHTV9gqMJGcg5PHEEQh NfV5nQjK8YA7gZnsijVB277XN0EtKmqNGOw8WOnzXxgt7Lc7KEk/cKr+GA1ksNVmi2W9 KsXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=KrTJLxbDvYtgGIT2IpPYkPiN9EFpCOmIgXwR5NaCVHA=; fh=GiEwXB7QRoc4X6ae2zqHZpsT+xIPexs6eDog6+Cgyus=; b=aPRKwGh0JiZyFuq9lpFQYA3L5szKax4Nn/w8Vt08NkU9QSYDKpUbTAfebAuo5JF25A Pgx1ZkfQmiOOAc4Zfggh51qO0H5ZDmtHp9BaBdnOtczo0rNOgd1uhIkuxZB0/XDdxx6R zlqFjvNJpUYNFTYXLeZpBnYZ2h4C5J6UYL8nkqSgCvk5SzOg6N04nh96kZwPaVfjJSbB YsJTg8Mk2BIJPlzGUYarlkHoPb43JQIRxLThh/wi9c7lFaGiZG7SbAcZMU9hH5jPmckF N1sQQw2uGqeO3/IG7+9jQV2zvKoUZlRuP9MZVm5UZFAcfb01fjH3VJf8ak0JVMgzcPSO 9LPQ==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777325425; x=1777930225; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KrTJLxbDvYtgGIT2IpPYkPiN9EFpCOmIgXwR5NaCVHA=; b=EZv8Q9mfhrfIGRgUxzRSCEQKWt0JoCgsvbnBDhAPbPcrkHjh8w1qEddT8P2yVoWi/W 38vzSWsEiI8wrFeb22snWeBgNtG/c7/VUwGZia6E3kvjtqnMTWF2oVdPCoeERAcxCXcg pu3duB9bH4MVe8eXgfGzRJLCtojXiTtX1r+Sd6zt8OOHS3SR0HKcX9hne1kMwfYT/iu1 Qs8vyb3CPMieMlb9VLllp1JmICq43lb6GxwX7/nH2lwx3x/A3LwMgt/n2wrwlAdHbw3/ Hy6x7Z7VpPWQf3K85RahS9l9CXMmi1IR0eUpgswGZeGkpZH2CXk8y9elFRuBYMlHDLdN aGPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777325425; x=1777930225; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=KrTJLxbDvYtgGIT2IpPYkPiN9EFpCOmIgXwR5NaCVHA=; b=osrsPiIdwmaOEIsSHJQNyVNw+G9jmu12LHsMCc5xt4I/9RTDJKPmQUKC9Rw4lBzxGl vlZjRP5+o9ieoKUrHQMVdh5TVSsDmYo3pdLMHX+Z4/a/apI4RA9BzO4jJHTMKj7gttMY i3r9XCr4MFE9UGZRXqLfoYIJoKh1puWeEgCB/g4HP+MzFEnACCSIrnPGaAgY+h3vLPtg MRurcmy5qcOwUlKDBREd8W56OO5bNaLG4BstACLhOub5kYsbEMBsHdT67LsBJHUk2m3e EgyKYj6OAHFwYT2OemGwav5DobuHi4i/6BFcv5tTmveEVcyJ6vxomlFaL3fvkgkqRCVR rlcw== X-Gm-Message-State: AOJu0YyFV9tF3s9MocU94+txbsh87bAjPnm573tZqKT7wAeFmy2GloN6 jX3zPz8Mlt+AacE21QAe4dU9me1qrUb/KgHGhj2AFjKbfsnQoa593A+WQLxYc3WdYfRuROwOA3y WANoZ2oJWNx4z0d1R1woWkrj6jtJ6kBoL X-Gm-Gg: AeBDies6TtkYiCBwGC4pnZcL6In/vbkJTtaOJrRotf9f7E1jcueLmxvbcelontZllTF XANFUMmPodGx27/DhDLsigXVQwdoO6WXABQvwzywwfmXpZ3c1+Yea5pYXJuHIhgbjGNO48epSeH eiW+gXBqOY5xzt2cwVmO2Fh4nTfbnY74fgYIFsaMoYZMvXSer9Mk5PsNu6FT2/NQUfiBRPUbU/y NY/RO2t+jXS2E0v+SvbcMvGBSeqH8s2i06L1QD249f0B/n4E3nnc8kqPdXWIdFKD23+yYIiRb5Y +Q6N4NJwXEtHQHq00oLib9jSexd4ygHSsEu+xUFysRD8t8/8Ug== X-Received: by 2002:a05:6402:505b:b0:671:dad8:80d6 with SMTP id 4fb4d7f45d1cf-679bb04a831mr129401a12.6.1777325424442; Mon, 27 Apr 2026 14:30:24 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <20260424-case-sensitivity-v11-0-de5619beddaf@oracle.com> <20260424-case-sensitivity-v11-3-de5619beddaf@oracle.com> In-Reply-To: From: Rick Macklem Date: Mon, 27 Apr 2026 14:30:10 -0700 X-Gm-Features: AVHnY4KgSQFR3scv6xUxgsHU_8QBh7PyOptUjRlPBEGqFL2M7EpvCJN8x1ORXY4 Message-ID: Subject: Re: FreeBSD NFSv4.1 server exporting FreeBSD FAT filesystem - case-insensitive=true? Fwd: [PATCH v11 03/15] fat: Implement fileattr_get for case sensitivity To: Cedric Blancher Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.37 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20240605:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.37)[-0.369]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4864::/56]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52e:from]; RCVD_COUNT_ONE(0.00)[1]; SUBJECT_HAS_QUESTION(0.00)[] X-Rspamd-Queue-Id: 4g4GvC5dpZz3ZyD X-Spamd-Bar: ---- On Mon, Apr 27, 2026 at 12:13=E2=80=AFAM Cedric Blancher wrote: > > Good morning! > > How does the FreeBSD NFSv4.1 server behave when it exports a FreeBSD > FAT filesystem? Does it set the case-insensitive and > case-nonpreserving FATTR4 attributes to case-insensitive=3Dtrue? It replies case-insensitive and case-preserving as both true. (When I create a file called Readme, ls returns Readme, so I believe that means case-preserving should be true.) The file can be open'd with any combination of case: README, readme or Readme, for example. rick > > Ced > > ---------- Forwarded message --------- > From: Chuck Lever > Date: Sat, 25 Apr 2026 at 03:53 > Subject: [PATCH v11 03/15] fat: Implement fileattr_get for case sensitivi= ty > To: Al Viro , Christian Brauner > , Jan Kara > Cc: , , > , , > , , > , > , , > , , > , , > , , , > , , , > , , > , , , > , , , > , Chuck Lever , > Roland Mainz > > > From: Chuck Lever > > Report FAT's case sensitivity behavior via the FS_XFLAG_CASEFOLD > and FS_XFLAG_CASENONPRESERVING flags. FAT filesystems are > case-insensitive by default. > > MSDOS supports a 'nocase' mount option that enables case-sensitive > behavior; check this option when reporting case sensitivity. > > VFAT long filename entries preserve case; without VFAT, only > uppercased 8.3 short names are stored. MSDOS with 'nocase' also > preserves case since the name-formatting code skips upcasing when > 'nocase' is set. Check both options when reporting case preservation. > > Reviewed-by: Jan Kara > Reviewed-by: Roland Mainz > Signed-off-by: Chuck Lever > --- > fs/fat/fat.h | 3 +++ > fs/fat/file.c | 32 ++++++++++++++++++++++++++++++++ > fs/fat/namei_msdos.c | 1 + > fs/fat/namei_vfat.c | 1 + > 4 files changed, 37 insertions(+) > > diff --git a/fs/fat/fat.h b/fs/fat/fat.h > index 5a58f0bf8ce8..99ed9228a677 100644 > --- a/fs/fat/fat.h > +++ b/fs/fat/fat.h > @@ -10,6 +10,8 @@ > #include > #include > > +struct file_kattr; > + > /* > * vfat shortname flags > */ > @@ -408,6 +410,7 @@ extern void fat_truncate_blocks(struct inode > *inode, loff_t offset); > extern int fat_getattr(struct mnt_idmap *idmap, > const struct path *path, struct kstat *stat, > u32 request_mask, unsigned int flags); > +int fat_fileattr_get(struct dentry *dentry, struct file_kattr *fa); > extern int fat_file_fsync(struct file *file, loff_t start, loff_t end, > int datasync); > > diff --git a/fs/fat/file.c b/fs/fat/file.c > index becccdd2e501..5f0178fc2ede 100644 > --- a/fs/fat/file.c > +++ b/fs/fat/file.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include "fat.h" > > static long fat_fallocate(struct file *file, int mode, > @@ -398,6 +399,36 @@ void fat_truncate_blocks(struct inode *inode, > loff_t offset) > fat_flush_inodes(inode->i_sb, inode, NULL); > } > > +int fat_fileattr_get(struct dentry *dentry, struct file_kattr *fa) > +{ > + struct msdos_sb_info *sbi =3D MSDOS_SB(dentry->d_sb); > + bool case_sensitive; > + > + /* > + * FAT filesystems are case-insensitive by default. VFAT > + * becomes case-sensitive when mounted with 'check=3Dstrict', > + * which installs vfat_dentry_ops. MSDOS has no such option; > + * its 'nocase' mount option selects case-sensitive matching. > + * > + * VFAT long filename entries preserve case. Without VFAT, only > + * uppercased 8.3 short names are stored. MSDOS with 'nocase' > + * also preserves case. > + */ > + if (sbi->options.isvfat) > + case_sensitive =3D sbi->options.name_check =3D=3D 's'; > + else > + case_sensitive =3D sbi->options.nocase; > + > + if (!case_sensitive) { > + fa->fsx_xflags |=3D FS_XFLAG_CASEFOLD; > + fa->flags |=3D FS_CASEFOLD_FL; > + if (!sbi->options.isvfat) > + fa->fsx_xflags |=3D FS_XFLAG_CASENONPRESERVING; > + } > + return 0; > +} > +EXPORT_SYMBOL_GPL(fat_fileattr_get); > + > int fat_getattr(struct mnt_idmap *idmap, const struct path *path, > struct kstat *stat, u32 request_mask, unsigned int flags) > { > @@ -575,5 +606,6 @@ EXPORT_SYMBOL_GPL(fat_setattr); > const struct inode_operations fat_file_inode_operations =3D { > .setattr =3D fat_setattr, > .getattr =3D fat_getattr, > + .fileattr_get =3D fat_fileattr_get, > .update_time =3D fat_update_time, > }; > diff --git a/fs/fat/namei_msdos.c b/fs/fat/namei_msdos.c > index 4cc65f330fb7..0fd2971ad4b1 100644 > --- a/fs/fat/namei_msdos.c > +++ b/fs/fat/namei_msdos.c > @@ -644,6 +644,7 @@ static const struct inode_operations > msdos_dir_inode_operations =3D { > .rename =3D msdos_rename, > .setattr =3D fat_setattr, > .getattr =3D fat_getattr, > + .fileattr_get =3D fat_fileattr_get, > .update_time =3D fat_update_time, > }; > > diff --git a/fs/fat/namei_vfat.c b/fs/fat/namei_vfat.c > index 918b3756674c..e909447873e3 100644 > --- a/fs/fat/namei_vfat.c > +++ b/fs/fat/namei_vfat.c > @@ -1185,6 +1185,7 @@ static const struct inode_operations > vfat_dir_inode_operations =3D { > .rename =3D vfat_rename2, > .setattr =3D fat_setattr, > .getattr =3D fat_getattr, > + .fileattr_get =3D fat_fileattr_get, > .update_time =3D fat_update_time, > }; > > > -- > 2.53.0 > > > > > -- > Cedric Blancher > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur > From nobody Mon Apr 27 22:12:15 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g4HqX2YTjz6ZlHJ for ; Mon, 27 Apr 2026 22:12:24 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4g4HqT2j63z3kSK for ; Mon, 27 Apr 2026 22:12:20 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dec.sakura.ne.jp header.s=s2405 header.b=WJTpw8zk; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp Received: from delta.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 63RMCFro015072; Tue, 28 Apr 2026 07:12:16 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1777327936; bh=g7QZaU3Jw3SgCraCErV8GqrI9Cx6G8nwHWP50881gPE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=WJTpw8zkFqWfOH8jbYT4vusFHA79tTF+cKK1EN5YFm7MB6HA2bIJ/Waki2N3uKAf6 u08vYDt0KtNCPUkxZR87eqVCO5FQBDr/Miw710dTQ44BQOIy9av0clMW1IVKg8wvg5 tjuUC9+rLRCwqhk2d5T6pTrkZeWX6yW1IaJm/tII= Date: Tue, 28 Apr 2026 07:12:15 +0900 From: Tomoaki AOKI To: Rick Macklem Cc: Cedric Blancher , freebsd-hackers@freebsd.org Subject: Re: FreeBSD NFSv4.1 server exporting FreeBSD FAT filesystem - case-insensitive=true? Fwd: [PATCH v11 03/15] fat: Implement fileattr_get for case sensitivity Message-Id: <20260428071215.a6b7364c1afcdffb09dbdee5@dec.sakura.ne.jp> In-Reply-To: References: <20260424-case-sensitivity-v11-0-de5619beddaf@oracle.com> <20260424-case-sensitivity-v11-3-de5619beddaf@oracle.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[dec.sakura.ne.jp,none]; R_SPF_ALLOW(-0.20)[+ip4:153.125.133.16/28]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[dec.sakura.ne.jp:s=s2405]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-Rspamd-Queue-Id: 4g4HqT2j63z3kSK X-Spamd-Bar: --- On Mon, 27 Apr 2026 14:30:10 -0700 Rick Macklem wrote: > On Mon, Apr 27, 2026 at 12:13 AM Cedric Blancher > wrote: > > > > Good morning! > > > > How does the FreeBSD NFSv4.1 server behave when it exports a FreeBSD > > FAT filesystem? Does it set the case-insensitive and > > case-nonpreserving FATTR4 attributes to case-insensitive=true? > It replies case-insensitive and case-preserving as both true. > (When I create a file called Readme, ls returns Readme, so I believe > that means case-preserving should be true.) > > The file can be open'd with any combination of case: README, readme > or Readme, for example. So the behavior matches with original {PC|MS}-DOS FAT filesystem driver. As a filesystem "format", FAT doesn't matter whether or not the filename is upper case or not. Just store what's written in the directory entry. As a filesystem "driver" on {PC|MS}-DOS, FAT always convert filenames into upper cases (capital) on writes and matces, but not listings. This was why file operations via filesystem driver causes filenames to be written all upper cases. And also, this was why so-called "filers" like original FD by A.Idei could create/rename/delete or even open wanted one when there are something like "ReadMe, readMe, README and readme coexists in the same directory" cases. This was possible because FD (and maybe other filers, too) doesn't use genuine FAT filesystem "driver", but read/write FAT filesystem in disks directly with cluster (sector) reads/writes. And openes files by specifying directory entry number, not by specifying filenames. And for anything accessing via filesyste "driver" like editors, the first one appears alone (in my above example, "ReadMe") could be opened, as the filesystem driver seems to open "first match" in directory entries. And if the user attempt to save file as "readME" with "Save as..." functionalities of an editor, it caused "file exists" warnings. This also means that once reordering the above example like "readme, readMe, README and ReadMe coexists in the same directory" and write to the disk (directory) using FD or alike, "readme" was preferred. > > rick > > > > > Ced > > > > ---------- Forwarded message --------- > > From: Chuck Lever > > Date: Sat, 25 Apr 2026 at 03:53 > > Subject: [PATCH v11 03/15] fat: Implement fileattr_get for case sensitivity > > To: Al Viro , Christian Brauner > > , Jan Kara > > Cc: , , > > , , > > , , > > , > > , , > > , , > > , , > > , , , > > , , , > > , , > > , , , > > , , , > > , Chuck Lever , > > Roland Mainz > > > > > > From: Chuck Lever > > > > Report FAT's case sensitivity behavior via the FS_XFLAG_CASEFOLD > > and FS_XFLAG_CASENONPRESERVING flags. FAT filesystems are > > case-insensitive by default. > > > > MSDOS supports a 'nocase' mount option that enables case-sensitive > > behavior; check this option when reporting case sensitivity. > > > > VFAT long filename entries preserve case; without VFAT, only > > uppercased 8.3 short names are stored. MSDOS with 'nocase' also > > preserves case since the name-formatting code skips upcasing when > > 'nocase' is set. Check both options when reporting case preservation. > > > > Reviewed-by: Jan Kara > > Reviewed-by: Roland Mainz > > Signed-off-by: Chuck Lever > > --- > > fs/fat/fat.h | 3 +++ > > fs/fat/file.c | 32 ++++++++++++++++++++++++++++++++ > > fs/fat/namei_msdos.c | 1 + > > fs/fat/namei_vfat.c | 1 + > > 4 files changed, 37 insertions(+) > > > > diff --git a/fs/fat/fat.h b/fs/fat/fat.h > > index 5a58f0bf8ce8..99ed9228a677 100644 > > --- a/fs/fat/fat.h > > +++ b/fs/fat/fat.h > > @@ -10,6 +10,8 @@ > > #include > > #include > > > > +struct file_kattr; > > + > > /* > > * vfat shortname flags > > */ > > @@ -408,6 +410,7 @@ extern void fat_truncate_blocks(struct inode > > *inode, loff_t offset); > > extern int fat_getattr(struct mnt_idmap *idmap, > > const struct path *path, struct kstat *stat, > > u32 request_mask, unsigned int flags); > > +int fat_fileattr_get(struct dentry *dentry, struct file_kattr *fa); > > extern int fat_file_fsync(struct file *file, loff_t start, loff_t end, > > int datasync); > > > > diff --git a/fs/fat/file.c b/fs/fat/file.c > > index becccdd2e501..5f0178fc2ede 100644 > > --- a/fs/fat/file.c > > +++ b/fs/fat/file.c > > @@ -17,6 +17,7 @@ > > #include > > #include > > #include > > +#include > > #include "fat.h" > > > > static long fat_fallocate(struct file *file, int mode, > > @@ -398,6 +399,36 @@ void fat_truncate_blocks(struct inode *inode, > > loff_t offset) > > fat_flush_inodes(inode->i_sb, inode, NULL); > > } > > > > +int fat_fileattr_get(struct dentry *dentry, struct file_kattr *fa) > > +{ > > + struct msdos_sb_info *sbi = MSDOS_SB(dentry->d_sb); > > + bool case_sensitive; > > + > > + /* > > + * FAT filesystems are case-insensitive by default. VFAT > > + * becomes case-sensitive when mounted with 'check=strict', > > + * which installs vfat_dentry_ops. MSDOS has no such option; > > + * its 'nocase' mount option selects case-sensitive matching. > > + * > > + * VFAT long filename entries preserve case. Without VFAT, only > > + * uppercased 8.3 short names are stored. MSDOS with 'nocase' > > + * also preserves case. > > + */ > > + if (sbi->options.isvfat) > > + case_sensitive = sbi->options.name_check == 's'; > > + else > > + case_sensitive = sbi->options.nocase; > > + > > + if (!case_sensitive) { > > + fa->fsx_xflags |= FS_XFLAG_CASEFOLD; > > + fa->flags |= FS_CASEFOLD_FL; > > + if (!sbi->options.isvfat) > > + fa->fsx_xflags |= FS_XFLAG_CASENONPRESERVING; > > + } > > + return 0; > > +} > > +EXPORT_SYMBOL_GPL(fat_fileattr_get); > > + > > int fat_getattr(struct mnt_idmap *idmap, const struct path *path, > > struct kstat *stat, u32 request_mask, unsigned int flags) > > { > > @@ -575,5 +606,6 @@ EXPORT_SYMBOL_GPL(fat_setattr); > > const struct inode_operations fat_file_inode_operations = { > > .setattr = fat_setattr, > > .getattr = fat_getattr, > > + .fileattr_get = fat_fileattr_get, > > .update_time = fat_update_time, > > }; > > diff --git a/fs/fat/namei_msdos.c b/fs/fat/namei_msdos.c > > index 4cc65f330fb7..0fd2971ad4b1 100644 > > --- a/fs/fat/namei_msdos.c > > +++ b/fs/fat/namei_msdos.c > > @@ -644,6 +644,7 @@ static const struct inode_operations > > msdos_dir_inode_operations = { > > .rename = msdos_rename, > > .setattr = fat_setattr, > > .getattr = fat_getattr, > > + .fileattr_get = fat_fileattr_get, > > .update_time = fat_update_time, > > }; > > > > diff --git a/fs/fat/namei_vfat.c b/fs/fat/namei_vfat.c > > index 918b3756674c..e909447873e3 100644 > > --- a/fs/fat/namei_vfat.c > > +++ b/fs/fat/namei_vfat.c > > @@ -1185,6 +1185,7 @@ static const struct inode_operations > > vfat_dir_inode_operations = { > > .rename = vfat_rename2, > > .setattr = fat_setattr, > > .getattr = fat_getattr, > > + .fileattr_get = fat_fileattr_get, > > .update_time = fat_update_time, > > }; > > > > > > -- > > 2.53.0 > > > > > > > > > > -- > > Cedric Blancher > > [https://plus.google.com/u/0/+CedricBlancher/] > > Institute Pasteur -- Tomoaki AOKI From nobody Wed Apr 29 07:05:47 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g57cl2Kjjz6b39N for ; Wed, 29 Apr 2026 07:05:59 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4g57cj2WQKz3Ps1 for ; Wed, 29 Apr 2026 07:05:57 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk Received: from dino.sk ([84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by cm0.netlabit.sk with ESMTPSA id 00000000004BF0CD.0000000069F1ADCC.00006D0F; Wed, 29 Apr 2026 09:05:48 +0200 Date: Wed, 29 Apr 2026 09:05:47 +0200 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: SYSVIPC and jails Message-ID: <20260429090547.16709362.28181704.71119016@dino.sk> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.70)[0.699]; NEURAL_HAM_SHORT(-0.70)[-0.698]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4g57cj2WQKz3Ps1 Hi, I am trying to move some old data collecting system to recent OS. Jails (with vnet in old system, both non-vnet and vnet ones in newer in order to do some division of tasks for better maintainability) and shared memory is in use, allowing the jails to share some status data, possibly fast changing. Original system is over 10 years old, based on FreeBSD 9.3, basically no longer maintainable, and it started to show some problems. Jail here was created with simple command jail -c name=xxx vnet persist allow.sysvipc and everything just works. In base system a shared memory segment is created, filled with some data, subsequently it is used in both base system and jail. I can't get this behavior with FreeBSD 14.3 (I tested a bit with 15.0 as well, not fully). I know allow.sysvipc should be replaced with sysvshm and, additionally if usefull, sysvmsg and sysvsem, but that's not an issue. With 'jls -vs' I see following properties sysvmsg=inherit sysvsem=inherit sysvshm=inherit allow.sysvipc set, so, according to 'man jail' it should work. It does not, however - when using non-null integer for shmkey in shmget call, I see that number in 'ipcs -a' output in jail where this segment is created, but zero in another jail. This leads to No such file or directory error when calling shmget to attach existing shared memory segment. If I use zero value for shmkey in shmget call, fail moves to shmat call, and error is Permission denied even in the jail where this segment was created. Looking into sysctl for possible hint, I found two objects with sysvipc in their names, with jail in their tree, additionaly: security.jail.param.allow.sysvipc security.jail.sysvipc_allowed I am able to set the latter to 1, but not the former, executing sysctl security.jail.param.allow.sysvipc=1 does not change the value, while executing sysctl security.jail.sysvipc_allowed=1 changes the object's value from 0 to 1. Even after this change, shared memory segment is not shared among jails. What changed I am missing? How should I achieve desired behavior? I am out of ideas. By the way, I am using kernel modules, but all required are loaded - this approach works if no inter jail shared memory segment visibility is required. Regards, Milan From nobody Wed Apr 29 19:56:53 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g5SkG47G6z6bptf for ; Wed, 29 Apr 2026 19:56:54 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g5SkG3bTxz3S1Z; Wed, 29 Apr 2026 19:56:54 +0000 (UTC) (envelope-from jamie@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1777492614; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nWS4VdrXhAgkDlaT4I3gigb4EuMVX/7DCsiRtLD+dMo=; b=VfthfBDi72s23IK2C8MmCiGgFMyVO9sYVqXUIO9SA4GbYbckf4iwUNDlCAXfrFXxA98RnY Z9QyN0pH3osyW59SmUH2Xek8ADBDCCeQSCa8Wioy1oiq1ckyD4R4Rj0jsaH27Nycs9fC47 EhVBL7tznkqFN/YWU5WyMLGjvXCUVSQYdsgd6+I1lOQpIu5JdK+RLtfmb7B/BR5k+23wjH iADjwCnIrzSPi9QdYGZ5tanYEmxuCF8iViefhfI2efVm0NaOUByxDg/m7n3qsMd/cXqO3f 17xaKXueYiTBabzjvA+6SMRpKTcB4kbno5cV27ivsn6TcERd8YFpfPGRj50VpA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1777492614; a=rsa-sha256; cv=none; b=I4a6YgE0QsPrKL8XsbpbQKPrRyPcyf9KT+kBThpexnOftKTv4AVKPPVkPkUMdoFo0zAd4+ yw4OLB5N6kJXopDUZonH9OqQDu7dSpBRNt3+jZO9aqVFSUlkszChm4gV4w0/TQKpCFe4q1 sBUXaauoPQjYd/kWpCWKYgrWFeqKHRd37dBzZRrZRLxQCAEeYxZj3k7XlIY15cYkt7vSKv cOY4ZvyZcgYGIrCNA+Rayuzkar72BQzbHoEcUXDjEVQXk/yvX1Nab4/YFHF3FabUBZMWK1 3e443cwxlFV6+4xDX1kGHkR8JJU9ZOSHu5pFHpwNy64o9vTdRZSB+iZT3oUTtg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1777492614; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nWS4VdrXhAgkDlaT4I3gigb4EuMVX/7DCsiRtLD+dMo=; b=mTxSkwf0ucbG9CzyzGfEvp+FqEitwDulAmYpLvMuuY67bZWhwCVk9VEBEbEoV8kDemmtGM qXmdblAApm7ykBefj6kdYqyD0vWkgMhaybliuX2U1MZVPP7QadCcQLGCjrfdEtQq1YXhco nkY4wbWYdcZ0OxcGGcfjDmAp/B3mVsJSGNJ3kzNmaFx6+Jkh3+Aq59ERLH4g4QEkzjSq7o +1crOXHX4NFDBR1WL5DXbVHGmk3YEIwbR9TUSm7J6KbfMgDZvHCHo/AmmdowHvFV2oMBAr lllr2+ITagQqgXMQVbkh86Y21S5HOILpfomfgynca5CPl30SkdlbKFYhS9tKuQ== Received: from m2.gritton.org (gritton.org [67.43.236.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jamie) by smtp.freebsd.org (Postfix) with ESMTPSA id 4g5SkG2fdVz3Xx; Wed, 29 Apr 2026 19:56:54 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (localgritton [127.0.0.212]) by m2.gritton.org (Postfix) with ESMTPSA id 36F5A7105B; Wed, 29 Apr 2026 12:56:53 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Date: Wed, 29 Apr 2026 12:56:53 -0700 From: James Gritton To: Freebsd Hackers Cc: Milan Obuch Subject: Re: SYSVIPC and jails In-Reply-To: <20260429090547.16709362.28181704.71119016@dino.sk> References: <20260429090547.16709362.28181704.71119016@dino.sk> Message-ID: <872527688056fd21b6ece46fc89944ca@freebsd.org> X-Sender: jamie@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2026-04-29 00:05, Milan Obuch wrote: > Original system is over 10 years old, based on FreeBSD 9.3, basically > no longer maintainable, and it started to show some problems. Jail here > was created with simple command > > jail -c name=xxx vnet persist allow.sysvipc > > and everything just works. In base system a shared memory segment is > created, filled with some data, subsequently it is used in both base > system and jail. > > I can't get this behavior with FreeBSD 14.3 (I tested a bit with 15.0 > as > well, not fully). I know allow.sysvipc should be replaced with sysvshm > and, additionally if usefull, sysvmsg and sysvsem, but that's not an > issue. With 'jls -vs' I see following properties > > sysvmsg=inherit > sysvsem=inherit > sysvshm=inherit > allow.sysvipc > > set, so, according to 'man jail' it should work. It does not, however - > when using non-null integer for shmkey in shmget call, I see that > number in 'ipcs -a' output in jail where this segment is created, but > zero in another jail. Yes, according to the docs it should work, and no it actually doesn't. There's a historical quirk at work here, between the way allow.sysvipc was set up, and the design when the sysvmsg/etc parameters were added: allow.sysvipc was only on or off, an on meant that jails could see each others' SYSV IPC objects, but kept their own key spaces (so you see zero as the key when you example other jails' objects). You could interact beytween jails, but only if you had some way of communicating the id apart from the normal method of using the key. sysvxxx=new gives the jail its own namespace, with both keys and ids unique to the jail. sysvxxx=inherit uses the parent's namespace for both keys and ids, as if you were in the same jail. At least that's how it's supposed to work, and how it's documented to work. But in reality, sysvxxx=inherit is exactly the same as allow.sysvipc. ID space is shared, but each jail has its own key space. File a bug report for this, and I'll work on getting it fixed. Hopefully, no one is relying on the weird hybrid behavior, but just in case, I can leave it for the otherwise-obsolete allow.sysvipc parameter. - Jamie PS > Looking into sysctl for possible hint, I found two objects with sysvipc > in their names, with jail in their tree, additionaly: > > security.jail.param.allow.sysvipc > security.jail.sysvipc_allowed > > I am able to set the latter to 1, but not the former, executing > > sysctl security.jail.param.allow.sysvipc=1 > > does not change the value, while executing > > sysctl security.jail.sysvipc_allowed=1 > > changes the object's value from 0 to 1. Even after this change, shared > memory segment is not shared among jails. security.jail.param.* never change anything. They're just how the jail system makes userspace aware of what parameters exist and how they're coded. security.jail.sysvipc.allowed (and a host of other such sysctls) are a relic of the old jail system, where almost all options were global, and are now default value of per-jail parameters. From nobody Wed Apr 29 21:49:17 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g5WD359y6z6c1YH for ; Wed, 29 Apr 2026 21:49:23 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4g5WD1689Cz3s5l for ; Wed, 29 Apr 2026 21:49:21 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk Received: from dino.sk ([84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by cm0.netlabit.sk with ESMTPSA id 00000000004E64BB.0000000069F27CDE.000033DF; Wed, 29 Apr 2026 23:49:18 +0200 Date: Wed, 29 Apr 2026 23:49:17 +0200 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Re: SYSVIPC and jails Message-ID: <20260429234917.32851164.28181704.92249248@dino.sk> In-Reply-To: <872527688056fd21b6ece46fc89944ca@freebsd.org> References: <20260429090547.16709362.28181704.71119016@dino.sk> <872527688056fd21b6ece46fc89944ca@freebsd.org> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.23 / 15.00]; NEURAL_SPAM_LONG(0.99)[0.993]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; NEURAL_HAM_SHORT(-0.94)[-0.935]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4g5WD1689Cz3s5l On Wed, 29 Apr 2026 12:56:53 -0700 James Gritton wrote: > On 2026-04-29 00:05, Milan Obuch wrote: > > Original system is over 10 years old, based on FreeBSD 9.3, > > basically no longer maintainable, and it started to show some > > problems. Jail here was created with simple command > > > > jail -c name=xxx vnet persist allow.sysvipc > > > > and everything just works. In base system a shared memory segment is > > created, filled with some data, subsequently it is used in both base > > system and jail. > > > > I can't get this behavior with FreeBSD 14.3 (I tested a bit with > > 15.0 as > > well, not fully). I know allow.sysvipc should be replaced with > > sysvshm and, additionally if usefull, sysvmsg and sysvsem, but > > that's not an issue. With 'jls -vs' I see following properties > > > > sysvmsg=inherit > > sysvsem=inherit > > sysvshm=inherit > > allow.sysvipc > > > > set, so, according to 'man jail' it should work. It does not, > > however - when using non-null integer for shmkey in shmget call, I > > see that number in 'ipcs -a' output in jail where this segment is > > created, but zero in another jail. > > Yes, according to the docs it should work, and no it actually doesn't. > There's a historical quirk at work here, between the way allow.sysvipc > was set up, and the design when the sysvmsg/etc parameters were added: > > allow.sysvipc was only on or off, an on meant that jails could see > each others' SYSV IPC objects, but kept their own key spaces (so you > see zero as the key when you example other jails' objects). It did not work that way in old 'just on and off' time... when allow.sysvipc is on, both id and key are the same in base and jail, no difference. Actually, I see no rationale why should key space be separated in case of mutual visibility. Do you? I'd like to know more. > You could interact beytween jails, but only if you had some way of > communicating the id apart from the normal method of using the key. > > sysvxxx=new gives the jail its own namespace, with both keys and ids > unique to the jail. > > sysvxxx=inherit uses the parent's namespace for both keys and ids, > as if you were in the same jail. ... which is what I'd like to use. > At least that's how it's supposed to work, and how it's documented > to work. But in reality, sysvxxx=inherit is exactly the same as > allow.sysvipc. ID space is shared, but each jail has its own key > space. So it is possible to get documented behavior for real? That would be great. > File a bug report for this, and I'll work on getting it fixed. > Hopefully, no one is relying on the weird hybrid behavior, but just > in case, I can leave it for the otherwise-obsolete allow.sysvipc > parameter. I'll try to do it and let you know, just a bit later I am afraid :) Regards, Milan From nobody Wed Apr 29 23:07:07 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g5gcZ2ZJ4z6cZqd for ; Thu, 30 Apr 2026 04:07:42 +0000 (UTC) (envelope-from anthony.katernoza@gmail.com) Received: from mail-yx1-xb136.google.com (mail-yx1-xb136.google.com [IPv6:2607:f8b0:4864:20::b136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g5gcY35NVz3QSB for ; Thu, 30 Apr 2026 04:07:41 +0000 (UTC) (envelope-from anthony.katernoza@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b="I/1HWGo3"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of anthony.katernoza@gmail.com designates 2607:f8b0:4864:20::b136 as permitted sender) smtp.mailfrom=anthony.katernoza@gmail.com; arc=pass ("google.com:s=arc-20240605:i=1") Received: by mail-yx1-xb136.google.com with SMTP id 956f58d0204a3-64937edbc9eso370389d50.2 for ; Wed, 29 Apr 2026 21:07:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777522059; cv=none; d=google.com; s=arc-20240605; b=kC1rFXpm7zJXpELq1tQnH2cAI/SZg8DV/+FnecZdhpzByn/XmSnXJT0chgzLByahiP mIhXCg1isD5Yo61h/I3t8qTqGt85RabOAvYjP5Gu4znC0vW1Qi/WCES+lORLVfA+X5vh jtdrE5T+o6kPNi0tWrSViDWK2fQkTQRwElIlCbFDNCbK5YdqodaS9NpB9YbAETAiDqUw B9MA5gVpH9VaGiPP2gKqb45eNDwUDQWmGb98SaDIqN4kdczvHfzYi37jmGpuhkmfw86Q /zlkMAAe3evW12qkAPnfix3dxQmNBKXd7fusJMfTd0IwJ2+ll1rB6s5zciZPnN5NQaVH u7Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=JRTP1+9rdSlYlb7V7Oy1upOZapKi73qc7jLs+px8xng=; fh=BGnlq/Bnk5yuHoIOHmeKjbe0R0Wn0sUc6aL/mCAMBkg=; b=WSZwc/0Q8q2QS/ckKSErB6WNX4HP1qZNr2SwdTLfLFQTzQ24C7BW9x4/76irZ+MR4p QXEP5/vhOC21QeZOupnC5uh/gJToFt3Ongdh/RZ9CFxPdfLT1ak00vG4q2qEx/8XQ5cG nxXLhDK7FfxYI28t5+1gPOq59NCWlwHHQevSfe2xGtqS5n5hMT/31fwqOJykORqj2Uvh iNOft051nNDz5XocT6CdJWW2OmB8IopmFxNRud5yr8B/I9HriFnrsWMk+6JOQL097lC4 Ytsa91V779QoLeATmRycerqWba1MTqAZtfJUabe0IksxrgG4vFWIj/cdl2ZwoDeANmCt uMFQ==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777522059; x=1778126859; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=JRTP1+9rdSlYlb7V7Oy1upOZapKi73qc7jLs+px8xng=; b=I/1HWGo3Cb2tGb72/DJJMAEYcKh/FQKRdMD13FbKtroGFH+aLSJroK5/T+cgTsIxRJ 9Wpr0odWBs9JnXODfxM+HJPbRUv/+i7elWVOUL2RCuyvWpRlupd4i/esYf+YDUzRq8Nv pHdjATrX3UlPwO0tgkohJQHgWeYuY1KPMdseRBvjJaZjhr9qX1e/CWw1iGVSe7hZD3cB klwhPadnzTGevVH2izLjswETNK+GJaj7YEqTStw62z7aDQLAJvOuCQxDvXdDR0HWAS/W Gba1N0aIm1qy8pafoccdm+tAls0a4PerIp1ViUHVC4jth1AVx9aylqM7wrNFXOJMIkbk 5dwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777522059; x=1778126859; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JRTP1+9rdSlYlb7V7Oy1upOZapKi73qc7jLs+px8xng=; b=VlbMcPPo9TRCdYMoKEf3qb+kIh4Ezcg2oOKE8153hf0RUSqY4PpgOYEjQ0IeQlv4Cm V+F4tpL0XfTFR6vQPiyFM9onhr9Ssi6pepkQDwZeN+koGOZKC2Aj58U3s0xJK6/lFMaR AjJEfUKzZ4YleEAwO8rRb26/dQZYCgh4uGL+s5XEqDeKduhvMcTTMwSMmMhlz92X+zqQ QjMyvdJsVZZzHhL2tzS2XQGMza8z+Q0ostnhgTPxyiex+/JXj/aZ2pEzgPzpvE9bm1OX G7LEIcqO6ntvrUPyun8ifXIyHR40Z0Co3wRGQz9J6VYupix7ezhF75lunruXuYiBXyBd CIbA== X-Gm-Message-State: AOJu0YytR2J4By2LCGqOZkfjAndxRqaaI6BbbIz/116T/uLmUveV8S2a SyjI3X4e7enty+UUY5b0l05h+r8NzN12NQnI4FnsXHFpTA5zTTvRt8HYJX+g0YmkwVlg/8hijnZ Dt22rWBoykhnZVzQtrO3kmn6ef4GiPt8Mm33g X-Gm-Gg: AeBDietVE2rzqJNXYr6879Sz3M3GdBRuzOSgm0PQFrD9f3gPZ3nBwSylzL+mtPrKIWy nlGRlMEm5FdYCFKjp5LWO+GP6VTJWhITce3kLlH9hlecXQC/kjR+Mk8klE+kD2ZZyVTgLgeBkx+ 3DfxqJaY+PIdbn41b8UJdUsrXbUUCPZ8UzEG2sSkOP0SiZOv3k7mXc7Bsh4KHXpy68PEoj7y5uk Go+yLTvITuVBWn0DTzY8ZUcB8QAPBJPXwPnAqF+ivN/1CjkTKY0FVHncypK9VNYiSGQRso1EYpP hyAvuxeyCWx6t6xq50h8Q4ItrBOyXd0= X-Received: by 2002:a05:690e:169a:b0:650:37e7:e590 with SMTP id 956f58d0204a3-65c18c4f314mr765267d50.15.1777522058945; Wed, 29 Apr 2026 21:07:38 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 From: Anthony Katernoza Date: Wed, 29 Apr 2026 23:07:07 +0000 X-Gm-Features: AVHnY4KRvQP7MyNKsXv0QN6olHt2w5TttZ2KTRKI4l_lRL3nLoGmDt7qDNmqdWc Message-ID: Subject: Guidance needed: FreeBSD 15.0-CURRENT Driver attachment for AMD Phoenix SoC To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e7672e0650a59a2a" X-Spamd-Result: default: False [-4.97 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20240605:i=1]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.97)[-0.972]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4864::/56]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b136:from] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4g5gcY35NVz3QSB --000000000000e7672e0650a59a2a Content-Type: text/plain; charset="UTF-8" Hello, I am seeking support on hardware gaps for the AMD Phoenix SoC. This issue is on a FreeBSD 15.0-CURRENT system. I have AMD drivers on my system that are unmanaged (none@pci). Critically, my FCH LPC Bridge (PCI ID: 1022:790e) is unmanaged. Sensor Fusion (PCI ID: 1022:164a) is also unmanaged. This looks to be an issue in the SoC's newbus hierarchy, as it prevents the kernel from attaching to child devices under FCH, such as the Embedded Controller (EC0). Confirmation of EC0 issues are in the ACPI dump, where the ACPI subsystem comes back as "AE_NOT_FOUND". Furthermore, 9 other related AMD drivers are labeled none@pci. I have already filed a formal bug report, which includes evidence from a compilation of ACPI, dmesg, pciconf & vmstat logs about this issue. FCH, Sensor Fusion, multimedia & other driver results are included: (Aforementioned logs are compiled into an attached .txt file). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294406 This being said, I am looking for technical assistance on: 1. Whether the problem devices require new chipset drivers or if adding the ID to existing isab(4) or chipset(4) logic is viable. 2. If there are specific testers and/or developers currently working on this type of SoC fabric, who may need raw data from this device. Best regards, Anthony Katernoza --000000000000e7672e0650a59a2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I am seeking support on hardware gaps for = the AMD Phoenix SoC.
This issue is on a FreeBSD 15.0-CURRENT system.

I have AMD drivers on my system t= hat are unmanaged (none@pci).
Critically, my FCH LPC Bridge (PCI ID: 1022:790e) is unmanage= d.
Sensor Fusion (PCI ID: 1022:164a) is also unma= naged.
This looks to be an issue in the SoC's newbus hierarchy,
as it prevents the kernel from attaching to = child devices under FCH,
such as the Embedded= Controller (EC0).
Confirmation of EC0 issues ar= e in the ACPI dump,
where the ACPI subsystem com= es back as "AE_NOT_FOUND".
Furthermore, 9 = other related AMD drivers are labeled none@pci.

I have already filed= a formal bug report, which includes evidence from
a= compilation of ACPI, dmesg, pciconf & vmstat logs about this issue.
FCH, Sensor Fusion, multimedia & other driver = results are included:
(Aforementioned logs are= compiled into an attached .txt file).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D294406

This being said, I am looking for technical assistance on:

<= /div>
1. Whether the problem devices require new chipset drivers
<= div>or if adding the ID to existing isab(4) or chipset(4) logic is viable.<= br>
2. If there are specific testers and/or developers currently = working on
this type of SoC fabric, who may need raw data fr= om this device.

Best regards,
Anthony Katernoza
=

--000000000000e7672e0650a59a2a-- From nobody Thu Apr 30 06:36:50 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g5kwm0Tdxz6ZdpV for ; Thu, 30 Apr 2026 06:36:56 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4g5kwk1w9Rz3kYJ for ; Thu, 30 Apr 2026 06:36:53 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk Received: from dino.sk ([84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by cm0.netlabit.sk with ESMTPSA id 00000000004E646D.0000000069F2F883.0000EDDF; Thu, 30 Apr 2026 08:36:51 +0200 Date: Thu, 30 Apr 2026 08:36:50 +0200 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Re: Guidance needed: FreeBSD 15.0-CURRENT Driver attachment for AMD Phoenix SoC Message-ID: <20260430083650.1ddf024b@dino.sk> In-Reply-To: References: X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-0.87 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.89)[-0.894]; NEURAL_HAM_MEDIUM(-0.68)[-0.675]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4g5kwk1w9Rz3kYJ On Wed, 29 Apr 2026 23:07:07 +0000 Anthony Katernoza wrote: > Hello, > > I am seeking support on hardware gaps for the AMD Phoenix SoC. > This issue is on a FreeBSD 15.0-CURRENT system. > > I have AMD drivers on my system that are unmanaged (none@pci). > Critically, my FCH LPC Bridge (PCI ID: 1022:790e) is unmanaged. Hi, I am just comparing your data with that of mine, on another AMD based box, with Renoir/Cezanne CPU/SoC. In my case, FCH LPC Bridge is isab0, in 'pciconf -lvb' output I see the same PCI ID (vendor and device), but subvendor and subdevice differs. My device has sub-id 0x1022:0x790e, while yours is 0x1028:0x0ca9. > Sensor Fusion (PCI ID: 1022:164a) is also unmanaged. > This looks to be an issue in the SoC's newbus hierarchy, > as it prevents the kernel from attaching to child devices under FCH, > such as the Embedded Controller (EC0). > Confirmation of EC0 issues are in the ACPI dump, > where the ACPI subsystem comes back as "AE_NOT_FOUND". > Furthermore, 9 other related AMD drivers are labeled none@pci. So, none0 is Phoenix IOMMU, I have Renoir/Cezanne IOMMU here as well. none1, none2 and none3 are weird - all fields are zeros, we need to consult TRM for SoC for details I think... did you try to find one? Basically all details should be looked for in TRM for given SoC. But I think those three devices are not important. none4 we already analysed above (LPC bridge) none5 is Phoenix CCP/PSP 3.0 Device, in my case I have none1 with description Raven/Raven2/FireFlight/Renoir/Cezanne Platform Security Processor, so I consider this not that much important for a moment (no idea whether we have support for similar devices). none6 - Audio Coprocessor, no idea on this one. none7 - Sensor Fusion Hub, again, no idea here. none8 - Phoenix Dummy Function, I have none2 Zeppelin/Raven/Raven2 PCIe Dummy Function. I think we can skip this one for now. none9 - AMD IPU Device, no idea on this one none10 - another Phoenix Dummy Function, Skip for now... > I have already filed a formal bug report, which includes evidence from > a compilation of ACPI, dmesg, pciconf & vmstat logs about this issue. > FCH, Sensor Fusion, multimedia & other driver results are included: > (Aforementioned logs are compiled into an attached .txt file). > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294406 My feeling is one attachment per command output would be better, but this is still workable. ACPI dumps are being somewhat bigger, which makes combining them with other output somewhat harder to manage, but I think you compiled relevant bits there. Could you eventually add another attachment with just dmesg output from verbose boot? We can get more info from there. And, while I am on this, you could get more detailed output from 'pciconf -lBbcevV' and attach it (separate attachment would be better in my oppinion) to your PR as well. I think this way you can collect all possible details on your device in well manageable fassion. > This being said, I am looking for technical assistance on: > > 1. Whether the problem devices require new chipset drivers > or if adding the ID to existing isab(4) or chipset(4) logic is viable. Looking quickly over sources, it appears to me isab is handled in sys/dev/pci/isa_pci.c file. In isab_pci_probe function, I see some general logic and exception added... maybe you could add there one more special case and test. But I am not confident I am looking at the right place, I have no special knowledge in this area. But as it is basically just one line added, it is simple to test... > 2. If there are specific testers and/or developers currently working > on this type of SoC fabric, who may need raw data from this device. No idea on this... just wait for someone else to appear. Hope this helps abit. Regards, Milan