From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751150AbeAOUHP (ORCPT + 1 other); Mon, 15 Jan 2018 15:07:15 -0500 Received: from mail-vk0-f54.google.com ([209.85.213.54]:41718 "EHLO mail-vk0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750764AbeAOUHO (ORCPT ); Mon, 15 Jan 2018 15:07:14 -0500 X-Google-Smtp-Source: ACJfBos7RYC8/Aikbj13V6ZiU2PEANiVZJjRov6Kt3FhqUL7B0mg3Y6ZV48BT7lQ5M1BTLkS3rvhhE3m7POSJJAMk9Y= MIME-Version: 1.0 In-Reply-To: References: <20180115155710.36e146ab@canb.auug.org.au> From: Kees Cook Date: Mon, 15 Jan 2018 12:07:12 -0800 Message-ID: Subject: Re: linux-next: manual merge of the akpm-current tree with the kspp tree To: Arnd Bergmann Cc: Stephen Rothwell , Andrew Morton , Linux-Next Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, Jan 15, 2018 at 4:41 AM, Arnd Bergmann wrote: > On Mon, Jan 15, 2018 at 5:57 AM, Stephen Rothwell wrote: >> Hi Andrew, >> >> Today's linux-next merge of the akpm-current tree got a conflict in: >> >> arch/cris/include/arch-v10/arch/bug.h >> >> between commit: >> >> c8133e59edb0 ("cris: Mark end of BUG() implementation as unreachable") >> >> from the kspp tree and commit: >> >> c5a1e183a75a ("bug.h: work around GCC PR82365 in BUG()") >> >> from the akpm-current tree. >> >> I fixed it up (I just used the akpm-current tree version) and can >> carry the fix as necessary. This is now fixed as far as linux-next is >> concerned, but any non trivial conflicts should be mentioned to your >> upstream maintainer when your tree is submitted for merging. You may >> also want to consider cooperating with the maintainer of the conflicting >> tree to minimise any particularly complex conflicts. > > Kees, > > it seems you ran into the same issue that I did, and got the same fix > for the first BUG() variant, but I think my version for the second one > is slightly better: > > /* This just causes an oops. */ > -#define BUG() (*(int *)0 = 0) > +#define BUG() \ > +do { \ > + barrier_before_unreachable(); \ > + __builtin_trap(); \ > +} while (0) > > compared to yours: > > /* This just causes an oops. */ > -#define BUG() (*(int *)0 = 0) > +#define BUG() \ > +do { \ > + (*(int *)0 = 0); \ > + do {} while (1); \ > + unreachable(); \ > +} while (0) > > which relies on a NULL pointer dereference to trap but otherwise > does the same thing. The easiest solution for the conflict seems to > be that you just drop your patch. Oh yeah, very nice. Yeah, yours is better. I'll drop mine. Thanks! -Kees -- Kees Cook Pixel Security