On Mon, Oct 06, 2025 at 03:33:56PM +0300, Jarkko Sakkinen wrote: > On Sun, Oct 05, 2025 at 11:24:09AM -0700, Linus Torvalds wrote: > > On Sun, 5 Oct 2025 at 08:47, Jarkko Sakkinen <[email protected]> wrote: > > The exclusive access looks debatable to me too. I think you should > > also require that the open was done not only with O_EXCL, but as a > > write too. > > > > Exclusive reads do not make sense. > > True, I agree with this.
I'm not sure _reads_ make sense for the TPM device files at all. It's a command + response interface. What should we do if we get O_EXCL and O_RDONLY? Return an error? Ignore the O_EXCL flag? > After reading this email I realized also another issue with these patch > when I tested them sequentially building a VM for each commit ID. > > Without "tpm: Require O_EXCL for exclusive /dev/tpm access" applied, > there's a regression: usually a daemon of some sort opens /dev/tpm0: > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > tpm2-abrm 771444 tss 5u CHR 10,224 0t0 94 /dev/tpm0 > > Without top patch this leaves /dev/tpmrm0 unusuable, which is a huge > developer experience downgrade as it is nice and covenient device > to try and do things. I.e. tail patch needs to be squashed and > the whole patch set needs to be re-reviewed. That's a fair point; I structured the patches in that fashion because I felt the O_EXCL patch was potentially contentious and might not be accepted. > And based on this I'm happy to postpone O_EXCL changes to 6.19. > Patch set just needs to be restructured better so that in-the > middle of the series patches don't break things. And also it'd > be better if this patch would be relocated as the first in the > series: "tpm: Remove tpm_find_get_ops". I'll spin a set with the tpm_find_get_ops removal first, then the O_EXCL patch, then the other two, which I think fixes all the ordering concerns. J. -- ... Nice world. Let's make it weirder.
