mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zijun Hu <zijun_hu@icloud.com>
To: Matteo Martelli <matteomartelli3@gmail.com>
Cc: Marc Gonzalez <marc.w.gonzalez@free.fr>,
	Peter Rosin <peda@axentia.se>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Cameron <jic23@kernel.org>,
	Joe Perches <joe@perches.com>, Jens Axboe <axboe@kernel.dk>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-block@vger.kernel.org
Subject: Re: iio, syfs, devres: devm_kmalloc not aligned to pow2 size argument
Date: Thu, 14 Nov 2024 20:25:59 +0800	[thread overview]
Message-ID: <ff24d6c8-581d-4dd1-8565-916d3f429ae4@icloud.com> (raw)
In-Reply-To: <cf50fd85a836c32bbb828a832e22d2df@gmail.com>

On 2024/11/14 19:29, Matteo Martelli wrote:
>>>> The address of a chunk allocated with `kmalloc` is aligned to at least
>>>> ARCH_KMALLOC_MINALIGN bytes. For sizes of power of two bytes, the
>>>> alignment is also guaranteed to be at least to the respective size.
>>>>
>>>> To do so I was thinking to try to move the devres metadata after the
>>>> data buffer, so that the latter would directly correspond to pointer
>>>> returned by kmalloc. I then found out that it had been already suggested
>>>> previously to address a memory optimization [2]. Thus I am reporting the
>>>> issue before submitting any patch as some discussions might be helpful
>>>> first.
>>>>
>> no, IMO, that is not good idea absolutely.
> It’s now quite clear to me that the issue is a rare corner case, and the
> potential impact of making such a change does not justify it. However,
> for completeness and future reference, are there any additional reasons
> why this change is a bad idea?

1)
as i ever commented, below existing APIs is very suitable for your
requirements. right ?
addr = devm_get_free_pages(dev, GFP_KERNEL|__GFP_ZERO, 0);
devm_free_pages(dev,addr);

2)
touching existing API which have been used frequently means high risk?

3) if you put the important metadata at the end of the memory block.
   3.1) it is easy to be destroyed by out of memory access.
   3.2) the API will be used to allocate memory with various sizes
        how to seek the tail metadata ?  is it easy to seek it?
   3.3) if you allocate one page, the size to allocate is page size
        + meta size, it will waste memory align.

4) below simple alternative is better than your idea. it keep all
attributes of original kmalloc(). right ?

static int devres_raw_kmalloc_match(struct device *dev, void *res, void *p)
{
	void **ptr = res;
	return *ptr == p;
}

static void devres_raw_kmalloc_release(struct device *dev, void *res)
{
	void **ptr = res;
	kfree(*ptr);
}

void *devm_raw_kmalloc(struct device *dev, size_t size, gfp_t gfp)
{
	void **ptr;
	
	ptr = devres_alloc(devres_raw_kmalloc_release, sizeof(*ptr), GFP_KERNEL);
	f (!ptr)
		return NULL;
	
	*ptr = kmalloc(size, gfp);
	if (!*ptr) {
		devres_free(ptr);
		return NULL;
	}
	devres_add(dev, ptr);
	return *ptr;
}
EXPORT(...)

void *devm_raw_kfree(struct device *dev, void *p)
{
	devres_release(dev, devres_raw_kmalloc_release,
devres_raw_kmalloc_match, p);
}
EXPORT(...)

  reply	other threads:[~2024-11-14 12:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-28 12:04 matteomartelli3
2024-11-08  9:04 ` Matteo Martelli
2024-11-09  9:29   ` Greg Kroah-Hartman
2024-11-09 15:51     ` Jonathan Cameron
2024-11-09 16:57       ` Greg Kroah-Hartman
2024-11-09 21:10   ` Zijun Hu
2024-11-14 11:29     ` Matteo Martelli
2024-11-14 12:25       ` Zijun Hu [this message]
2024-11-14 16:09         ` Matteo Martelli

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=ff24d6c8-581d-4dd1-8565-916d3f429ae4@icloud.com \
    --to=zijun_hu@icloud.com \
    --cc=axboe@kernel.dk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jic23@kernel.org \
    --cc=joe@perches.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.w.gonzalez@free.fr \
    --cc=matteomartelli3@gmail.com \
    --cc=peda@axentia.se \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®