From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Tadeusz Struk <tadeusz.struk@intel.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Mauro Carvalho Chehab <m.chehab@samsung.com>,
Helge Deller <deller@gmx.de>,
Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Joe Perches <joe@perches.com>, Marek Vasut <marex@denx.de>
Subject: Re: [PATCH v3 1/5] seq_file: provide an analogue of print_hex_dump()
Date: Mon, 01 Sep 2014 14:33:42 +0300 [thread overview]
Message-ID: <1409571222.30155.55.camel@linux.intel.com> (raw)
In-Reply-To: <CAMuHMdWcWD2nMoRNooC=aMTMk07R9vmOfc1mzeNQJO8JATS8fA@mail.gmail.com>
On Mon, 2014-09-01 at 12:59 +0200, Geert Uytterhoeven wrote:
> Hi Andy,
>
> On Mon, Sep 1, 2014 at 12:15 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> >>>> I think it needs a call to seq_set_overflow() in case the buffer is too small,
> >>>> so the caller will retry with a bigger buffer.
> >>>
> >>> Yes, in two places it would be useful to do.
> >>
> >> Two places? I see only one, just before calling hex_dump_to_buffer.
> >
> > seq_putc doesn't set it as I can see.
> >
> >>> But what the condition for "buffer is too small", the same groupsize * 2
> >>> + 1 or you mean something else?
> >>
> >> "groupsize * 2 + 1" is not the amount of bytes hex_dump_to_buffer() wants
> >> to write. It's only the size for one word.
> >>
> >> You could check if there are at least "32 * 3 + 2 + 32 + 1" bytes (your
> >> old linebuf size) available.
> >
> > This is a good question why this number? What if we have to print only
> > one byte (as different groupsize)?
>
> I don't think complaining about a too-small buffer prematurely hurts.
>
> > I think the requirement for one groupsize is quite okay.
>
> Then you will loose data if the buffer is too small.
>
> >> However, to protect against overflows if hex_dump_to_buffer() ever changes,
> >> I think it would be better to let hex_dump_to_buffer() indicate if the
> >> passed buffer was to small (it already checks the passed linebuflen).
> >> Then you can just check for that.
> >
> > I thought about that. We may introduce either new call and make
> > current one the user of it or change all occurrences.
> > Nevertheless, currently it will print only one groupsize if there is
> > enough room for it but for two or more.
> > Thus, I prefer to keep the behaviour "print until we can".
>
> The idea of seq_*() is that it will retry with a bigger bufsize if there's
> not enough space.
Fair enough.
So, summarize above, the check before hex_dump_to_buffer() should care
about maximum possible buffer needed for one line. But we have already
rowsize calculated (we actually can't rely on groupsize in this case).
Do you agree with formula rowsize * 3 + 2 + rowsize + 1?
--
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2014-09-01 11:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-25 9:03 [PATCH v3 0/5] fs/seq_file: introduce seq_hex_dump() helper Andy Shevchenko
2014-08-25 9:03 ` [PATCH v3 1/5] seq_file: provide an analogue of print_hex_dump() Andy Shevchenko
2014-08-30 22:54 ` Al Viro
2014-09-01 8:36 ` Andy Shevchenko
2014-09-01 8:58 ` Geert Uytterhoeven
2014-09-01 9:09 ` Andy Shevchenko
2014-09-01 9:25 ` Geert Uytterhoeven
2014-09-01 10:15 ` Andy Shevchenko
2014-09-01 10:59 ` Geert Uytterhoeven
2014-09-01 11:33 ` Andy Shevchenko [this message]
2014-09-01 11:49 ` Geert Uytterhoeven
2014-09-01 11:53 ` Andy Shevchenko
2014-08-25 9:03 ` [PATCH v3 2/5] saa7164: convert to seq_hex_dump() Andy Shevchenko
2014-08-25 9:03 ` [PATCH v3 3/5] crypto: qat - use seq_hex_dump() to dump buffers Andy Shevchenko
2014-08-25 9:03 ` [PATCH v3 4/5] parisc: " Andy Shevchenko
2014-08-26 19:36 ` Helge Deller
2014-08-25 9:03 ` [PATCH v3 5/5] [S390] zcrypt: " Andy Shevchenko
2014-08-27 13:26 ` Ingo Tuchscherer
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=1409571222.30155.55.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=deller@gmx.de \
--cc=geert@linux-m68k.org \
--cc=herbert@gondor.apana.org.au \
--cc=ingo.tuchscherer@de.ibm.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=marex@denx.de \
--cc=tadeusz.struk@intel.com \
--cc=viro@zeniv.linux.org.uk \
/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