linux-kernel - Re: [PATCH v8 18/25] powerpc: Implement nvram sync ioctl

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 3 Jan 2019 09:25:08 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Arnd Bergmann <arnd@...db.de>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v8 18/25] powerpc: Implement nvram sync ioctl

On Tue, 1 Jan 2019, I wrote:

> 
> There are no [nvram] ioctls common to all architectures. So your example 
> becomes,
> 
> static long nvram_misc_ioctl(struct file *file, unsigned int cmd,
>                              unsigned long arg)
> {
>      if (ops->ioctl)
>           return ops->ioctl(file, cmd, arg);
>      return -ENOTTY;
> }
> 
> And then my objection is the same: m68k and x86 now have to duplicate 
> their common ops->ioctl() implementation.
> 

Perhaps code duplication is inevitable. Either you punt the ioctl 
implementation from the char misc driver (and duplicate that ioctl 
implementation under arch/) or else you duplicate the char misc driver.

Maybe this dilemma explains the situation we have now* which is duplicated 
drivers (drivers/char/nvram.c and drivers/char/generic_nvram.c). But this 
explanation doesn't seem to offer any solution. Re-using either of the 
existing drivers seems to be impossible.

Different interpretations of the NVRAM Kconfig symbol accross the tree are 
not helping. And having separate Kconfig symbols (NVRAM and GENERIC_NVRAM) 
for the two drivers doesn't help either. But maybe the NVRAM symbol can be 
dropped from arch/powerpc and all of the powerpc drivers...

* Actually, we presently have duplicated misc device drivers AND 
duplicated ioctl implementations too, for good measure. See 
arch/powerpc/kernel/nvram_64.c and drivers/char/generic_nvram.c.

--