Received-SPF: pass (google.com: domain of linux-kernel+bounces-33969-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240117143548.595884070@goodmis.org> <20240117143810.531966508@goodmis.org>
 <CAMuHMdXKiorg-jiuKoZpfZyDJ3Ynrfb8=X+c7x0Eewxn-YRdCA@mail.gmail.com>
 <20240122100630.6a400dd3@gandalf.local.home> <CAMuHMdXD0weO4oku8g2du6fj-EzxGaF+0i=zrPScSXwphFAZgg@mail.gmail.com>
 <20240122114743.7e46b7cb@gandalf.local.home> <CAHk-=wiq5mr+wSb6pmtt7QqBhQo_xr7ip=yMwQ5ryWVwCyMhfg@mail.gmail.com>
 <CAHk-=wjGxVVKvxVf=NDnMhB3=eQ_NMiEY3onG1wRAjJepig=aw@mail.gmail.com>
In-Reply-To: <CAHk-=wjGxVVKvxVf=NDnMhB3=eQ_NMiEY3onG1wRAjJepig=aw@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 22 Jan 2024 10:19:12 -0800
Message-ID: <CAHk-=wiLqJYT2GGSBhKuJS-Uq1DVq3S32oP0SwqQiATuBivxcg@mail.gmail.com>
Subject: Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and
 directories all be the same
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Kees Cook <keescook@chromium.org>, 
	linux-kernel@vger.kernel.org, Masami Hiramatsu <mhiramat@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, 
	Andrew Morton <akpm@linux-foundation.org>, Christian Brauner <brauner@kernel.org>, 
	Al Viro <viro@zeniv.linux.org.uk>, Ajay Kaher <ajay.kaher@broadcom.com>
Content-Type: multipart/mixed; boundary="000000000000cfa3ae060f8cdedd"

--000000000000cfa3ae060f8cdedd
Content-Type: text/plain; charset="UTF-8"

On Mon, 22 Jan 2024 at 09:39, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Actually, why not juist add an inode number to your data structures,
> at least for directories? And just do a static increment on it as they
> get registered?
>
> That avoids the whole issue with possibly leaking kernel address data.

The 'nlink = 1' thing doesn't seem to make 'find' any happier for this
case, sadly.

But the inode number in the 'struct eventfs_inode' looks trivial. And
doesn't even grow that structure on 64-bit architectures at least,
because the struct is already 64-bit aligned, and had only one 32-bit
entry at the end.

On 32-bit architectures the structure size grows, but I'm not sure the
allocation size grows. Our kmalloc() is quantized at odd numbers.

IOW, this trivial patch seems to be much safer than worrying about
some pointer exposure.

              Linus

--000000000000cfa3ae060f8cdedd
Content-Type: text/x-patch; charset="US-ASCII"; name="patch.diff"
Content-Disposition: attachment; filename="patch.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_lrp92tln0>
X-Attachment-Id: f_lrp92tln0

IGZzL3RyYWNlZnMvZXZlbnRfaW5vZGUuYyB8IDYgKysrKy0tCiBmcy90cmFjZWZzL2ludGVybmFs
LmggICAgfCAxICsKIDIgZmlsZXMgY2hhbmdlZCwgNSBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9u
cygtKQoKZGlmZiAtLWdpdCBhL2ZzL3RyYWNlZnMvZXZlbnRfaW5vZGUuYyBiL2ZzL3RyYWNlZnMv
ZXZlbnRfaW5vZGUuYwppbmRleCA2Nzk1ZmRhMmFmMTkuLjBiNTJlYzExMWNmMyAxMDA2NDQKLS0t
IGEvZnMvdHJhY2Vmcy9ldmVudF9pbm9kZS5jCisrKyBiL2ZzL3RyYWNlZnMvZXZlbnRfaW5vZGUu
YwpAQCAtMzk1LDggKzM5NSw3IEBAIHN0YXRpYyBzdHJ1Y3QgZGVudHJ5ICpjcmVhdGVfZGlyKHN0
cnVjdCBldmVudGZzX2lub2RlICplaSwgc3RydWN0IGRlbnRyeSAqcGFyZW50CiAJaW5vZGUtPmlf
b3AgPSAmZXZlbnRmc19yb290X2Rpcl9pbm9kZV9vcGVyYXRpb25zOwogCWlub2RlLT5pX2ZvcCA9
ICZldmVudGZzX2ZpbGVfb3BlcmF0aW9uczsKIAotCS8qIEFsbCBkaXJlY3RvcmllcyB3aWxsIGhh
dmUgdGhlIHNhbWUgaW5vZGUgbnVtYmVyICovCi0JaW5vZGUtPmlfaW5vID0gRVZFTlRGU19ESVJf
SU5PREVfSU5POworCWlub2RlLT5pX2lubyA9IGVpLT5pbm87CiAKIAl0aSA9IGdldF90cmFjZWZz
KGlub2RlKTsKIAl0aS0+ZmxhZ3MgfD0gVFJBQ0VGU19FVkVOVF9JTk9ERTsKQEAgLTg1OSw2ICs4
NTgsNyBAQCBzdHJ1Y3QgZXZlbnRmc19pbm9kZSAqZXZlbnRmc19jcmVhdGVfZGlyKGNvbnN0IGNo
YXIgKm5hbWUsIHN0cnVjdCBldmVudGZzX2lub2RlCiAJCQkJCSBpbnQgc2l6ZSwgdm9pZCAqZGF0
YSkKIHsKIAlzdHJ1Y3QgZXZlbnRmc19pbm9kZSAqZWk7CisJc3RhdGljIGludCBpbm9fY291bnRl
ciA9IEVWRU5URlNfRElSX0lOT0RFX0lOTzsKIAogCWlmICghcGFyZW50KQogCQlyZXR1cm4gRVJS
X1BUUigtRUlOVkFMKTsKQEAgLTg4OSw2ICs4ODksOCBAQCBzdHJ1Y3QgZXZlbnRmc19pbm9kZSAq
ZXZlbnRmc19jcmVhdGVfZGlyKGNvbnN0IGNoYXIgKm5hbWUsIHN0cnVjdCBldmVudGZzX2lub2Rl
CiAJSU5JVF9MSVNUX0hFQUQoJmVpLT5saXN0KTsKIAogCW11dGV4X2xvY2soJmV2ZW50ZnNfbXV0
ZXgpOworCWVpLT5pbm8gPSArK2lub19jb3VudGVyOworCiAJaWYgKCFwYXJlbnQtPmlzX2ZyZWVk
KSB7CiAJCWxpc3RfYWRkX3RhaWwoJmVpLT5saXN0LCAmcGFyZW50LT5jaGlsZHJlbik7CiAJCWVp
LT5kX3BhcmVudCA9IHBhcmVudC0+ZGVudHJ5OwpkaWZmIC0tZ2l0IGEvZnMvdHJhY2Vmcy9pbnRl
cm5hbC5oIGIvZnMvdHJhY2Vmcy9pbnRlcm5hbC5oCmluZGV4IDEyYjdkMDE1MGFlOS4uMWE1NzRk
MzA2ZWE5IDEwMDY0NAotLS0gYS9mcy90cmFjZWZzL2ludGVybmFsLmgKKysrIGIvZnMvdHJhY2Vm
cy9pbnRlcm5hbC5oCkBAIC02NCw2ICs2NCw3IEBAIHN0cnVjdCBldmVudGZzX2lub2RlIHsKIAkJ
c3RydWN0IGxsaXN0X25vZGUJbGxpc3Q7CiAJCXN0cnVjdCByY3VfaGVhZAkJcmN1OwogCX07CisJ
dW5zaWduZWQgaW50CQkJaW5vOwogCXVuc2lnbmVkIGludAkJCWlzX2ZyZWVkOjE7CiAJdW5zaWdu
ZWQgaW50CQkJaXNfZXZlbnRzOjE7CiAJdW5zaWduZWQgaW50CQkJbnJfZW50cmllczozMDsK
--000000000000cfa3ae060f8cdedd--