mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Pointer magic in mm_init_cpumask()
@ 2019-08-21 13:13 Siarhei Liakh
  2019-08-21 14:26 ` Rik van Riel
  0 siblings, 1 reply; 2+ messages in thread
From: Siarhei Liakh @ 2019-08-21 13:13 UTC (permalink / raw)
  To: LKML, riel

Hello everyone.
I was chasing some issue in my own code when I came across the
following in include/linux/mm_types.h:
======================
/* Pointer magic because the dynamic array size confuses some compilers. */
static inline void mm_init_cpumask(struct mm_struct *mm)
{
        unsigned long cpu_bitmap = (unsigned long)mm;

        cpu_bitmap += offsetof(struct mm_struct, cpu_bitmap);
        cpumask_clear((struct cpumask *)cpu_bitmap);
}

/* Future-safe accessor for struct mm_struct's cpu_vm_mask. */
static inline cpumask_t *mm_cpumask(struct mm_struct *mm)
{
        return (struct cpumask *)&mm->cpu_bitmap;
}
======================
Bodies of both functions came from commit
c1a2f7f0c06454387c2cd7b93ff1491c715a8c69 "mm: Allocate the mm_cpumask
(mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"

This raises the following issues:
If pointer magic is required in mm_init_cpumask(), then what makes
mm_cpumask() safe (and vice versa)?
If mm_cpumask() is not safe, then at the very least the following has
to be fixed:
$ grep -rIn 'cpumask_clear(mm_cpumask(' *
arch/powerpc/include/asm/tlb.h:69:    cpumask_clear(mm_cpumask(mm));
arch/sparc/mm/init_64.c:857:        cpumask_clear(mm_cpumask(mm));
arch/ia64/include/asm/mmu_context.h:92:        cpumask_clear(mm_cpumask(mm));
arch/csky/mm/asid.c:126:    cpumask_clear(mm_cpumask(mm));
arch/arm/mm/context.c:233:    cpumask_clear(mm_cpumask(mm));

Otherwise, mm_init_cpumask() can be simplified down to
cpumask_clear(mm_cpumask(mm)).
What do you think?

Please CC me on reply.
Thank you.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Pointer magic in mm_init_cpumask()
  2019-08-21 13:13 Pointer magic in mm_init_cpumask() Siarhei Liakh
@ 2019-08-21 14:26 ` Rik van Riel
  0 siblings, 0 replies; 2+ messages in thread
From: Rik van Riel @ 2019-08-21 14:26 UTC (permalink / raw)
  To: Siarhei Liakh, LKML

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Wed, 2019-08-21 at 09:13 -0400, Siarhei Liakh wrote:

> If mm_cpumask() is not safe, then at the very least the following has
> to be fixed:
> $ grep -rIn 'cpumask_clear(mm_cpumask(' *
> arch/powerpc/include/asm/tlb.h:69:    cpumask_clear(mm_cpumask(mm));
> arch/sparc/mm/init_64.c:857:        cpumask_clear(mm_cpumask(mm));
> arch/ia64/include/asm/mmu_context.h:92:        cpumask_clear(mm_cpuma
> sk(mm));
> arch/csky/mm/asid.c:126:    cpumask_clear(mm_cpumask(mm));
> arch/arm/mm/context.c:233:    cpumask_clear(mm_cpumask(mm));
> 
> Otherwise, mm_init_cpumask() can be simplified down to
> cpumask_clear(mm_cpumask(mm)).
> What do you think?

That looks like a nice cleanup.

I do not see why it would not work, but I suppose
that should be tested :)

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-08-21 14:26 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-21 13:13 Pointer magic in mm_init_cpumask() Siarhei Liakh
2019-08-21 14:26 ` Rik van Riel

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®