All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Yury Norov <yury.norov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Amritha Nambiar <amritha.nambiar@intel.com>,
	Willem de Bruijn <willemb@google.com>,
	Kees Cook <keescook@chromium.org>,
	Matthew Wilcox <willy@infradead.org>,
	"Tobin C . Harding" <tobin@kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Vineet Gupta <vineet.gupta1@synopsys.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Yury Norov <ynorov@marvell.com>,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	Steffen Klassert <steffen.klassert@secunet.com>
Subject: Re: [PATCH 4/6] lib: rework bitmap_parse()
Date: Sun, 28 Apr 2019 19:57:45 +0300	[thread overview]
Message-ID: <20190428165745.GX9224@smile.fi.intel.com> (raw)
In-Reply-To: <20190428032936.1317-5-ynorov@marvell.com>

On Sat, Apr 27, 2019 at 08:29:34PM -0700, Yury Norov wrote:
> bitmap_parse() is ineffective and full of opaque variables and opencoded
> parts. It leads to hard understanding of it. This rework includes:
>  - remove bitmap_shift_left() call from the cycle. Now it makes the
>    complexity of the algorithm as O(nbits^2). In the suggested approach
>    the input string is parsed in reverse direction, so no shifts needed;
>  - relax requirement on a single comma and no white spaces between chunks.
>    It is considered useful in scripting, and it aligns with
>    bitmap_parselist();
>  - split bitmap_parse() to small readable helpers;
>  - make an explicit calculation of the end of input line at the
>    beginning, so users of the bitmap_parse() won't bother doing this.

> +static inline bool in_str(const char *start, const char *ptr)
> +{
> +	return start <= ptr;
> +}
> +

I don't see how it's better than explicit use. Moreover, explicit use shows the
exact condition in-line. Even by used characters it's longer.

> +static const char *bitmap_get_hex32_rev(const char *start,
> +					const char *end, u32 *num)

In kernel few functions to work with hex u32 named foo_x32(). I would rather
use that. Besides, we spell "reverse" in full.

> +{
> +	u32 ret = 0;
> +	int c, i;
> +
> +	if (hex_to_bin(*end) < 0)
> +		return ERR_PTR(-EINVAL);
> +
> +	for (i = 0; i < 32; i += 4) {
> +		c = hex_to_bin(*end--);
> +		if (c < 0)

Perhaps we may need similar patch for hex_to_bin() as in the commit
9888a588ea96 ("lib/hexdump.c: return -EINVAL in case of error in hex2bin()")

> +			return ERR_PTR(-EINVAL);

> +
> +		ret |= c << i;
> +
> +		if (!in_str(start, end) || __end_of_region(*end))
> +			goto out;
> +	}
> +
> +	if (hex_to_bin(*end) >= 0)
> +		return ERR_PTR(-EOVERFLOW);
> +out:
> +	*num = ret;
> +	return end;
> +}

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2019-04-28 16:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-28  3:29 [PATCH 0/4] lib: rework bitmap_parse Yury Norov
2019-04-28  3:29 ` [PATCH 1/6] lib/string: add strnchrnul() Yury Norov
2019-04-28 16:04   ` Andy Shevchenko
2019-04-28 18:26     ` Yury Norov
2019-04-28 19:22       ` Andy Shevchenko
2019-04-28 18:58   ` Rasmus Villemoes
2019-04-28  3:29 ` [PATCH 2/6] bitops: more BITS_TO_* macros Yury Norov
2019-04-28 16:06   ` Andy Shevchenko
2019-04-28  3:29 ` [PATCH 3/6] lib/bitmap: make bitmap_parse_user a wrapper on bitmap_parse Yury Norov
2019-04-28  3:29 ` [PATCH 4/6] lib: rework bitmap_parse() Yury Norov
2019-04-28 16:57   ` Andy Shevchenko [this message]
2019-05-01  0:37     ` Yury Norov
2019-04-28  3:29 ` [PATCH 5/6] lib: add test for bitmap_parse() Yury Norov
2019-04-28  3:29 ` [PATCH 6/6] cpumask: don't calculate length of the input string Yury Norov
2019-04-28 15:40 ` [PATCH 0/4] lib: rework bitmap_parse Andy Shevchenko

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=20190428165745.GX9224@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=amritha.nambiar@intel.com \
    --cc=axboe@kernel.dk \
    --cc=chris@chris-wilson.co.uk \
    --cc=davem@davemloft.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mszeredi@redhat.com \
    --cc=sfr@canb.auug.org.au \
    --cc=steffen.klassert@secunet.com \
    --cc=tobin@kernel.org \
    --cc=vineet.gupta1@synopsys.com \
    --cc=will.deacon@arm.com \
    --cc=willemb@google.com \
    --cc=willy@infradead.org \
    --cc=ynorov@marvell.com \
    --cc=yury.norov@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.