All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Antti Kervinen <antti.kervinen@intel.com>
Cc: tklauser@distanz.ch, Jonathan.Cameron@huawei.com,
	akpm@linux-foundation.org, andriy.shevchenko@linux.intel.com,
	linux-kernel@vger.kernel.org, peterz@infradead.org,
	song.bao.hua@hisilicon.com, tiantao6@hisilicon.com,
	yury.norov@gmail.com
Subject: Re: [PATCH] cpumask: Omit terminating null byte in cpumap_print_{list,bitmask}_to_buf
Date: Thu, 30 Sep 2021 12:43:41 +0200	[thread overview]
Message-ID: <YVWU3f5elbnRctae@kroah.com> (raw)
In-Reply-To: <20210930103010.2716097-1-antti.kervinen@intel.com>

On Thu, Sep 30, 2021 at 01:30:10PM +0300, Antti Kervinen wrote:
> 
> An original function, bitmap_print_to_pagebuf() in lib/bitmap.c,
> returns the number of printed characters, excluding terminating null.
> 
> Commit 1fae5629, a cause of this regression, introduced new functions
> to lib/bitmap.c:
> 
> - bitmap_print_to_buf()
>   (return value doc missing)
> 
> - bitmap_print_bitmask_to_buf()
>   (return value doc not explicit about terminating null, but
>   can be considered misleading)
> 
> - bitmap_print_list_to_buf()
>   (the same as above)
> 
> Unlike the original function, the return value of new functions
> include the terminating null.
> 
> As this behavior is clearly opposite to the original function, and
> functions that print to buffers in general, I would suggest fixing
> this problem by alignign these new functions with the original one:
> excluding the terminating null. And documenting this behavior
> unambiguously.
> 
> The suggested change to cpumask_print_{bitmask,list}_to_buf()
> functions decrements possible errors (like -ENOMEM) returned by
> bitmap_print_to_buf(). This must not happen.

I already pointed you at
	https://lore.kernel.org/r/20210916222705.13554-1-tklauser@distanz.ch
a few hours ago.

Why not test the patch there (and in linux-next) and let us know if it
resolves the issue you see or not.

thanks,

greg k-h

  reply	other threads:[~2021-09-30 10:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16 22:27 [PATCH] cpumask: Omit terminating null byte in cpumap_print_{list,bitmask}_to_buf Tobias Klauser
2021-09-16 22:53 ` Song Bao Hua (Barry Song)
2021-09-16 23:19   ` Yury Norov
2021-09-17  8:45     ` Tobias Klauser
2021-09-19  7:33       ` Barry Song
2021-09-19  7:52         ` Greg Kroah-Hartman
2021-09-30 10:30 ` Antti Kervinen
2021-09-30 10:43   ` Greg KH [this message]
2021-09-30 12:29     ` Antti Kervinen
2021-09-30 10:46   ` Barry Song

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=YVWU3f5elbnRctae@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=antti.kervinen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=song.bao.hua@hisilicon.com \
    --cc=tiantao6@hisilicon.com \
    --cc=tklauser@distanz.ch \
    --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.