Re: [PATCH v3 06/25] rust: alloc: implement `Vmalloc` allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 04, 2024 at 04:57:30PM -0700, Boqun Feng wrote:
> On Sun, Aug 04, 2024 at 07:39:52PM +0200, Danilo Krummrich wrote:
> [...]
> > > > > > +unsafe impl Allocator for Vmalloc {
> > > > > > +    unsafe fn realloc(
> > > > > > +        ptr: Option<NonNull<u8>>,
> > > > > > +        layout: Layout,
> > > > > > +        flags: Flags,
> > > > > > +    ) -> Result<NonNull<[u8]>, AllocError> {
> > > > > > +        let realloc = ReallocFunc::vrealloc();
> > > > > > +
> > > > > 
> > > > > IIUC, vrealloc() calls __vmalloc_noprof() in allocation case, that is
> > > > > calling __vmalloc_node_noprof() with align=1. In such a case, how would
> > > > > vmalloc() guarantee the allocated memory is aligned to layout.align()?
> > > > 
> > > > True, good catch. I thought of this a while ago and then forgot to fix it.
> > > 
> > > Just for clarification, we're always PAGE_SIZE aligned (guaranteed by
> > > __alloc_vmap_area()), which probably would always be sufficient. That's why I
> > > didn't gave it too much attention in the first place and then forgot about it.
> > > 
> > > However, we indeed do not honor layout.align() if it's larger than PAGE_SIZE.
> > 
> > Another note on that:
> > 
> > My plan for this series was to just fail allocation for alignment requests
> > larger than PAGE_SIZE. And, if required, address larger alignments in a later
> 
> Yeah, this sounds reasonable.
> 
> > series, since this one is probably big enough already.
> > 
> > However, for `Vmalloc` we could support it right away, since it's trivial. For
> > `KVmalloc` though it requires a bit more effort.
> > 
> 
> Could you elaborate why it requires a bit more effort? Because
> kvrealloc() and kvmalloc() in C don't have a way to specify alignment
> requirement?

Yes, exactly that.

> If so, I think a solution to that would be just providing
> the K-or-V switch in Rust code, i.e. just `Vmalloc` and `Kmalloc` to
> implement `KVmalloc`, which I don't think is a bad idea.

I really think we should do it in C. Look at all the special cases is
__kvmalloc_node_noprof(): fixup page flags, sanity check the size on kmalloc
failure, fail on certain page flags, etc.

I think we really want to keep all this logic in a single place and not
replicate it on the Rust side.

> 
> Regards,
> Boqun
> 
> > For consistancy it would probably be better to support alignments larger than
> > PAGE_SIZE either for `Vmalloc` and `KVmalloc` or neither of those though.
> > 
> > My personal tendency goes a bit more into the direction of picking consistancy.
> > 
> > Any other opinions?
> > 
> [...]
> 




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux