linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Greg KH <greg@kroah.com>,
	linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH v5 1/2] tpm: add sysfs exports for all banks of PCR registers
Date: Fri, 15 Jan 2021 09:10:25 -0800	[thread overview]
Message-ID: <d80ad831d970e1c0828c8eb44ff5359bf07474b5.camel@HansenPartnership.com> (raw)
In-Reply-To: <YAE8fjt/lfYmEZxc@kernel.org>

On Fri, 2021-01-15 at 08:55 +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 14, 2021 at 04:21:08PM -0800, James Bottomley wrote:
> > On Thu, 2021-01-14 at 08:59 +0100, Greg KH wrote:
[...]
> > > Please use sysfs_emit() and sysfs_emit_at() for new sysfs files.
> > 
> > Hey these interfaces were added after this patch began life.  But
> > looking at sysfs_emit_at() I've got to say "aah ... don't you guys
> > ever read rusty's guide to interfaces?" an interface which takes in
> > an absolute page position but returns a relative offset to the
> > position it took in is asking for people to get it wrong.  You
> > should always be consistent about uses for inputs and
> > outputs.  Basically the only way you can ever use sysfs_emit_at in
> > a show routine is as
> > 
> > offset += sysfs_emit_at(buf, offset, ...);
> > 
> > because you always need to track the absolute offset.
> > 
> > It looks like we already have a couple of bugs in the kernel
> > introduced by this confusion ...  return sysfs_emit() vs return
> > sysfs_emit_at() being the most tricky ...
> 
> How is using sysfs_emit() different from using snprintf() for the
> caller, ignoring the added safety measures? I'm new to this API.

Using the sprintX variants you maintain a cursor pointer, so they all
look like

char *cursor = buf;

...

cursor += sprintX(cursor, "...", ...

...

return cursor - buf;

So the input is a relative cursor and the output is the additional
offset.  I'm not claiming it's the best interface but it is hard to get
wrong, just that if we're going to force a new interface we should make
it much better.

with sysfs_emit_at you use an offset "cursor" but it's hard to know
without reading the function how to do it because the return is
relative rather than absolute.  To have an interface it would be hard
to misuse, I think the best way would be to take a pointer to the
offset and adjust it after use, so

sysfs_emit_at(buf, &offset, ...);

That way it returns void so you can't use it in place of 

return sysfs_emit()

And you don't have to worry about whether the return is absolute or
relative because it adjusts the pointer for you.

The whole point about Rusty and interfaces is that if you are going to
invent new interfaces you should make them easy to get right and hard
to misuse.  A function you can't figure out how to use until you read
the source is about 2/10 on the rusty scale:

https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html

James



  reply	other threads:[~2021-01-15 17:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 23:26 [PATCH v5 0/2] add sysfs exports for TPM 2 PCR registers James Bottomley
2021-01-13 23:26 ` [PATCH v5 1/2] tpm: add sysfs exports for all banks of " James Bottomley
2021-01-14  7:59   ` Greg KH
2021-01-15  0:21     ` James Bottomley
2021-01-15  6:55       ` Jarkko Sakkinen
2021-01-15 17:10         ` James Bottomley [this message]
2021-01-15 13:54       ` Greg KH
2021-01-15 17:26         ` James Bottomley
2021-01-15 18:07           ` James Bottomley
2021-01-15 20:48             ` Joe Perches
2021-01-15 21:06               ` James Bottomley
2021-01-15 21:14                 ` Joe Perches
2021-01-15 20:32         ` Joe Perches
2021-01-15  6:48   ` Jarkko Sakkinen
2021-01-13 23:26 ` [PATCH v5 2/2] ABI: add sysfs description for tpm exports " James Bottomley
2021-01-15  6:40   ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d80ad831d970e1c0828c8eb44ff5359bf07474b5.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=greg@kroah.com \
    --cc=jarkko@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).