linux-kernel - Re: linux-next: build failure after merge of the rtc tree

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: <20151218164341.GB3541@piout.net>
Date:	Fri, 18 Dec 2015 17:43:41 +0100
From:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the rtc tree

On 18/12/2015 at 10:30:22 -0500, Sasha Levin wrote :
> On 12/17/2015 06:21 AM, Alexandre Belloni wrote:
> > On 17/12/2015 at 16:03:44 +1100, Stephen Rothwell wrote :
> >> > Hi Alexandre,
> >> > 
> >> > After merging the rtc tree, today's linux-next build (arm
> >> > multi_v7_defconfig) failed like this:
> >> > 
> >> > drivers/built-in.o: In function `rtc_time64_to_tm':
> >> > sunxi_sid.c:(.text+0x366e54): undefined reference to `__aeabi_ldivmod'
> >> > sunxi_sid.c:(.text+0x366e6c): undefined reference to `__aeabi_ldivmod'
> >> > 
> >> > Caused by commit
> >> > 
> >> >   bfad4c280be0 ("rtc: fix overflow and incorrect calculation in rtc_time64_to_tm")
> >> > 
> >> > I have used the rtc tree from next-20151216 for today.
> >> > 
> > Well, the kbuild test robot didn't complain at the time so I assumed
> > that it was ok to take the patch but indeed, there are more division
> > further in the function.
> 
> Yeah, I'm not sure what happened here. Compiler optimizations?
> 
> > Sasha, I think I prefer having 32 bit platforms fail on the 21st of
> > January 11761191 rather than adding more uses of do_div in the function.
> > I'll have a look at the performance impact on 32 bit platforms.
> 
> I'm really fine with just adding a WARN_ON() and aborting if it's the year
> 11761191 :)
> 

One simple way to solve it for 64bit platforms is to define days as
unsigned long. Maybe throw a comment that it will fail for 32bit
platforms in January 11761191 ;).

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/