From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH] devres: zero the memory in devm_krealloc() if needed
Date: Fri, 30 Oct 2020 12:57:06 +0200 [thread overview]
Message-ID: <20201030105706.GK4077@smile.fi.intel.com> (raw)
In-Reply-To: <CAMRc=MfuejMqpcfOedPMMTR3EY6s2K+4whoWyk7RmJYPaB176w@mail.gmail.com>
On Fri, Oct 30, 2020 at 10:03:50AM +0100, Bartosz Golaszewski wrote:
> On Thu, Oct 29, 2020 at 9:05 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Oct 26, 2020 at 01:27:28PM +0100, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > >
> > > If we're returning the same pointer (when new size is smaller or equal
> > > to the old size) we need to check if the user wants the memory zeroed
> > > and memset() it manually if so.
> >
> > Any use case? Because to me it sounds contradictory to the whole idea of [k]realloc().
>
> This is kind of a gray area in original krealloc() too and I want to
> submit a patch for mm too. Right now krealloc ignores the __GFP_ZERO
> flag if new_size <= old_size but zeroes the memory if new_size >
> old_size.
> This should be consistent - either ignore __GFP_ZERO or
> don't ignore it in both cases. I think that not ignoring it is better
> - if user passes it then it's for a reason.
Sorry, but I consider in these two choices the best is the former one, i.e.
ignoring, because non-ignoring for sizes less than current is counter the
REalloc() by definition.
Reading realloc(3):
"If the new size is larger than the old size, the added memory will not be
initialized."
So, supports my choice over yours.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-10-30 10:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 12:27 [PATCH] devres: zero the memory in devm_krealloc() if needed Bartosz Golaszewski
2020-10-26 13:14 ` Andy Shevchenko
2020-10-30 9:03 ` Bartosz Golaszewski
2020-10-30 10:57 ` Andy Shevchenko [this message]
2020-10-30 10:58 ` Andy Shevchenko
2020-10-30 11:03 ` Bartosz Golaszewski
2020-10-30 12:21 ` Bartosz Golaszewski
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=20201030105706.GK4077@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=bgolaszewski@baylibre.com \
--cc=brgl@bgdev.pl \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
/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.