linux-kernel - Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

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]

Date:	Tue, 26 Apr 2016 12:05:01 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Thomas Graf <tgraf@...g.ch>,
	Peter Zijlstra <peterz@...radead.org>,
	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>, jamborm@....gnu.org,
	Ingo Molnar <mingo@...nel.org>,
	Himanshu Madhani <himanshu.madhani@...gic.com>,
	qla2xxx-upstream@...gic.com
Subject: Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

On Tuesday 26 April 2016 01:35:16 Christoph Hellwig wrote:
> On Tue, Apr 26, 2016 at 09:22:46AM +0200, Arnd Bergmann wrote:
> > > Agree, plus, as I've said before, we have 3-4 weeks before we go final,
> > > so we still have some time before a decision has to be made.  It looks
> > > like the gcc people already have a patch for the compiler, so the
> > > distributions could just push that out through channels.
> > 
> > I don't think we can realistically blacklist gcc-4.9.{0,1,2,3},
> > gcc-5.{0,1,2,3}.* and gcc-6.0 and require everyone to upgrade to compilers
> > that have not been released yet in order to build a linux-4.6 kernel.
> 
> Agreed.  What about just removing the wrappers?  They seem fairly
> pointless to start with.

I think at this point it's mainly a question of whether we want such a
big (however trivial) patch in v4.6. We can certainly do that for 4.7,
but as a fixup for the existing problem, either the __always_inline
hack or using a macro should be sufficient:

diff --git a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h
index bf66ea6bed2b..51a98b182a67 100644
--- a/include/scsi/scsi_transport_fc.h
+++ b/include/scsi/scsi_transport_fc.h
@@ -796,15 +796,8 @@ fc_remote_port_chkready(struct fc_rport *rport)
 	return result;
 }
 
-static inline u64 wwn_to_u64(u8 *wwn)
-{
-	return get_unaligned_be64(wwn);
-}
-
-static inline void u64_to_wwn(u64 inm, u8 *wwn)
-{
-	put_unaligned_be64(inm, wwn);
-}
+#define wwn_to_u64(wwn) get_unaligned_be64(wwn)
+#define u64_to_wwn(inm, wwn) put_unaligned_be64(inm, wwn)
 
 /**
  * fc_vport_set_state() - called to set a vport's state. Saves the old state,

	Arnd