public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: wharms@bfs.de
Cc: Benny Halevy <bhalevy@tonian.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	"James E.J. Bottomley" <JBottomley@parallels.com>,
	osd-dev@open-osd.org, linux-scsi@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [patch] [SCSI] libosd: check for kzalloc() failure
Date: Wed, 30 Jan 2013 15:51:38 +0000	[thread overview]
Message-ID: <5109418A.6080900@panasas.com> (raw)
In-Reply-To: <51092F7F.2090105@bfs.de>

On 01/30/2013 04:34 PM, walter harms wrote:
> 
<>
> I start to see the complexity of the situation. Would you mind to add
> the comment "it can be anything.  UTF-8 is more likely but not guaranteed either" ?
> For now using a pascal-string seems the best solution but it should be warned
> that get_attrs[a].val_ptr is NOT a c-string and therefore can not be used with
> the printf-family (i guess the situation will become more clear in future)
> 

OK, So... The long story

The STD says that osdname can be *anything* binary or otherwise, and of *any*
length. And is used to uniquely identify the OSD-device/partition in a cluster.

We decided that if so we would stick an 40 char UUID in it, generated by a uuidgen
and all the external utilities and surrounding code forces it, and treat it as
a c-string. But this code here in the core cannot make that assumption and still
support the STD.

On the other hand we did want the osdname to be printable in traces and messages
because it is such an important identifier. So I have decided to sacrifice an
extra char in-memory to carry a \NUL and safely stick it into printk(s). Those
(none existent) OSD devices that will put unprintable characters in here will
still function fine, but will look real scary in printk(s).

Please note that the one that sets policy is the osd-target vendor. (And they
all currently use my code base)

So save the kzalloc check this code (tested) is safe and will show strings when
present, but will gracefully show ugly things but still work when not.

> I have no clue why you need that, using c-strings makes life more easy in the
> last minute a sprintf(buf,"%u") will save the day ;)
> 

Actually it is very funny, because just recently (last week) I have discovered
something that eliminates all those funny business.

	printf("%*s", odi->osdname, odi->osdname_len);

The "*" will instruct c to expect an extra variable following %s which is the
max_length of %s. This is exactly for pascal strings and the such like above.

So I added a TODO to clean that a bit by always printing with "%*s"

>>
> It look clever to add the NULL test here.
> Noone reviewing the code will understand that.
> (Rule of least surprise)
> 

Thanks for looking, I agree it needs a fat comment, I'll do that when I'll
convert to above system. Thanks for looking, That code is really old and never
had any extra eyes on it.

> just my 2 cents,
> re,
>  wh
> 

Cheers
Boaz


  reply	other threads:[~2013-01-30 15:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-30  7:06 [patch] [SCSI] libosd: check for kzalloc() failure Dan Carpenter
2013-01-30  8:15 ` walter harms
2013-01-30  8:27   ` Dan Carpenter
2013-01-30  8:57     ` walter harms
2013-01-30  9:51       ` Benny Halevy
2013-01-30 13:00         ` walter harms
2013-01-30 13:40           ` Benny Halevy
2013-01-30 14:34             ` walter harms
2013-01-30 15:51               ` Boaz Harrosh [this message]
2013-01-30 10:05 ` Benny Halevy
2013-01-30 15:56 ` Boaz Harrosh

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=5109418A.6080900@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=JBottomley@parallels.com \
    --cc=bhalevy@tonian.com \
    --cc=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=osd-dev@open-osd.org \
    --cc=wharms@bfs.de \
    /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