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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2123401.bK87U6BMYJ@wuerfel>
Date:	Mon, 01 Feb 2016 17:13:44 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	gregkh@...uxfoundation.org, Greg Hackmann <ghackmann@...gle.com>,
	Jin Qian <jinqian@...roid.com>,
	Alan Cox <alan@...ux.intel.com>, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] staging: goldfish: use div64_s64 instead of do_div

On Monday 01 February 2016 14:54:57 One Thousand Gnomes wrote:
> On Mon, 01 Feb 2016 11:33 +0100
> Arnd Bergmann <arnd@...db.de> wrote:
> 
> > The goldfish nand driver divides a signed 64-bit number (loff_t)
> > in multiple places using the do_div() function. This has always
> > been unreliable but now produces a compiler warning (since 4.5-rc1):
> > 
> > goldfish/goldfish_nand.c: In function 'goldfish_nand_erase':
> > goldfish/goldfish_nand.c:107:91: error: comparison of distinct pointer types lacks a cast [-Werror]
> > goldfish/goldfish_nand.c: In function 'goldfish_nand_read_oob':
> > goldfish/goldfish_nand.c:145:91: error: comparison of distinct pointer types lacks a cast [-Werror]
> > 
> > This changes the code to the equivalent div_s64{,_rem} that
> > works correctly for negative numbers (which we should never
> > get here).
> 
> We can't get negatives as you say so surely the right fix is a cast or to
> fix mtd->writesize ?

A cast won't work because the first argument to the do_div() macro is
both input and output.

It's not the mtd->writesize argument that is the problem here, but the
'ofs' argument that comes from the loff_t argument in mtdchar_read()
and others (ultimately from the lseek/pread/pwrite/...)

We could change all the function prototypes in struct mtd_info to use
u64 instead of loff_t, but that involve change all MTD drivers and the
subsystem.

	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ