lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALBuU529+=+Xmsccc3AU2R0tSOCJtMQx=yMGDHopc3=tO3uM3Q@mail.gmail.com>
Date:   Wed, 21 Aug 2019 09:13:08 -0400
From:   Siarhei Liakh <sliakh.lkml@...il.com>
To:     LKML <linux-kernel@...r.kernel.org>, riel@...riel.com
Subject: Pointer magic in mm_init_cpumask()

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ