From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752351AbcDZP7b (ORCPT ); Tue, 26 Apr 2016 11:59:31 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:57940 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751840AbcDZP73 (ORCPT ); Tue, 26 Apr 2016 11:59:29 -0400 From: Arnd Bergmann To: "Martin K. Petersen" Cc: James Bottomley , Josh Poimboeuf , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, Denys Vlasenko , Thomas Graf , Peter Zijlstra , David Rientjes , Andrew Morton , jamborm@gcc.gnu.org, Ingo Molnar , Himanshu Madhani , qla2xxx-upstream@qlogic.com Subject: Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Date: Tue, 26 Apr 2016 17:58:20 +0200 Message-ID: <5298237.1Guzp0G04x@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <20160419085221.GA29087@gmail.com> <5249561.9VpAPLD61M@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:SLAVl+xGkUXqVXSFttC9eHo9zzwovBxGXdYosOnxMjdGV6EoRcv VuZS7V3yHbihUuXufybrk9rOWqmZe6mEg+giNBP8vtCXZ9JM38hSP3+72E9BdqSeV7O4S42 U52NxL2DfNbLPxK39Mer5emtuyoFbxUUmFidV+70f0st3FvZFPVdvrH/bqOLBU2S1t+xCnQ wNJCanEt3xaDmSx9pjZxQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:CbwfMOokubg=:inrzTJIPboNrA/LiCHHayK ageS/QXgRpalpgIYe8hadG3G085L/Dzpc9Gf9aw0usK/eDwU6bcrUOE28Te57UR2uhBIJZYUD eaK0UhOGuZuUa53KbUq0UoBiN9Nb0+EAbBbGQJMnWZsT3xoRmf1f9ZJkFQsK0auGdLhDTkZuH sQeLTkg3tVjMjHC57NGCKhcZZ76gOGjfZopPWSW24+BX4yqShAWXNrPhhBqjHo8LYc1mnwiPT o93ysbzAGGXXaWM1Q4GX/hiAFMW/By8Eup4/y2jQlfaLMWCalC7E9LFPu0frRiAAkgprLgwGs ihGs8IqxiIWnLady2Mz4UwIWrUT4aar+sC2rTur3jJ9CqJs0h6hXwzoJhwybixQko5LyeqFTI oHzTPulyOcf2WKvULU3jlf+1vBsFBsQZfwxqQNFtZHG/+0DnLPCEu6Dq2rjGnEugEacPx6Zou /gOMJOdavYmnQqri8upj0Uy8tu0WA61bdwqLxPXNZdMOBGoZ/k0QtiVTaZHf1wKE3IQgGC/JP dy8IPKK8dWPWN3aXKPrIwL5Mh2RESeK1izRg66ehhcg2CJJjLt2A4c1hkuge1p6VpvjqtVj4H 1eZuYuyBmcfyHzhAd6FTOcyjv4YFl4y0okaKXtiowlsdkdM03JUbqqSfhjrU097v1hRaG25mT QTLztK55oSVLQ6VgMCUNKmH1o4R/xkmEPSwKbI6vgNg01MpBKxJRk50s9tjKKLbJ9stHBRQg4 YrAC9nEbwrn5RUSm Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 26 April 2016 09:06:54 Martin K. Petersen wrote: > >>>>> "Arnd" == Arnd Bergmann writes: > > Arnd> I don't think we can realistically blacklist gcc-4.9.{0,1,2,3}, > Arnd> gcc-5.{0,1,2,3}.* and gcc-6.0 and require everyone to upgrade to > Arnd> compilers that have not been released yet in order to build a > Arnd> linux-4.6 kernel. > > I agree that compiler blacklisting is problematic and I'd like to avoid > it. The question is how far we go in the kernel to accommodate various > levels of brokenness. > > In any case. Sticking compiler workarounds in device driver code is akin > to putting demolition orders on display on Alpha Centauri. At the very > minimum the patch should put a fat comment in the code stating that > these wrapper functions or #defines should not be changed in the future > because that'll break builds using gcc XYZ. But that does not solve the > problem for anybody else that might be doing something similar. > Converting between u64 and $RANDOM_TYPE in an inline wrapper does not > seem like a rare and unusual programming pattern. It's not the driver really, it's the core scsi/fc layer, which makes it a little dangerous that a random driver. I agree that putting a comment in would also help. What I understand from the bug report is that to trigger this bug you need these elements: 1. an inline function marked __always_inline 2. another inline function that is automatically inlined (not __always_inline) 3. CONFIG_OPTIMIZE_INLINING=y to guarantee 2 4. __builtin_compatible_p inside that inline function The last point is what Denys introduced in the kernel with bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining of some byteswap operations"). So maybe it's better after all to revert that patch, to have a higher confidence in the same bug not appearing elsewhere. It's also really a workaround for another quirk of the compiler, but that one only results in duplicated functions in object code rather than functions that end in the middle. Arnd