linux-kernel - Re: [tip:timers/core] ptp_clock: Allow for it to be optional

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

Date:   Fri, 18 Nov 2016 10:15:54 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:     linux-kernel@...r.kernel.org, tglx@...utronix.de,
        josh@...htriplett.org, mingo@...nel.org, hpa@...or.com,
        richardcochran@...il.com, pebolle@...cali.nl, ecree@...arflare.com,
        john.stultz@...aro.org, mmarek@...e.com,
        linux-tip-commits@...r.kernel.org
Subject: Re: [tip:timers/core] ptp_clock: Allow for it to be optional

On Thursday, November 17, 2016 7:48:00 PM CET Nicolas Pitre wrote:
> > 
> > It was introduced in linux-next today, but it only happens if you
> > don't do a 'make clean' or 'make mrproper'. Apparently patch 1
> > of the series changes kconfig but that change does not trigger
> > a rebuild of the kconfig binary for me. After removing kconfig
> > from the object directory, it works again.
> 
> That's odd.  If I do a git checkout from linux-next of a commit before 
> this series, then "make oldconfig", and then checkout of master and 
> "make oldconfig again, in both cases I always get:
> 
> $ make oldconfig
>   HOSTCC  scripts/kconfig/conf.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf  --oldconfig Kconfig
> [...]
> 
> And obviously no errors.

I usually build with "make -skj30", so it's possible that it only
happens in a parallel build environment on the first run.
 
> > I also ran into a problem with CONFIG_TIMERFD enabled but
> > CONFIG_POSIX_TIMERS turned off. This could be related to some
> > of my own patches though, haven't tried if that happens
> > with just your patches applied.
> 
> Tried that combination in my checkout of linux-next, and once again no 
> build errors here.

Ok, thanks for testing this. It must be something in the y2038
patches I have on top of next. They clashed quite a bit with your
work already, this added dependency is just one more detail for
me to remember with my series, nothing you need to worry about.

	Arnd