Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753232AbdHNMoo (ORCPT ); Mon, 14 Aug 2017 08:44:44 -0400 Received: from smtp-out4.electric.net ([192.162.216.189]:58148 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752253AbdHNMon (ORCPT ); Mon, 14 Aug 2017 08:44:43 -0400 From: David Laight To: "'Daniel Borkmann'" , James Hogan , David Miller CC: "ast@kernel.org" , "linux-kernel@vger.kernel.org" , "rostedt@goodmis.org" , "mingo@redhat.com" , "netdev@vger.kernel.org" Subject: RE: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk Thread-Topic: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk Thread-Index: AQHTEU7nLjVjwpjKgkShLVBIqn6v5aJ/T4oAgAR/OOA= Date: Mon, 14 Aug 2017 12:44:35 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD0054C88@AcuExch.aculab.com> References: <59897A7C.10009@iogearbox.net> <20170808.094857.245786887664041622.davem@davemloft.net> <650EB3B0-1101-4624-905A-E68D2EC5920F@imgtec.com> <20170808.145433.1287676484744976417.davem@davemloft.net> <20170809073926.GO6973@jhogan-linux.le.imgtec.org> <598B71C9.7090303@iogearbox.net> <598DDF88.6020809@iogearbox.net> In-Reply-To: <598DDF88.6020809@iogearbox.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v7ECioxX000987 Content-Length: 1077 Lines: 29 From: Daniel Borkmann > Sent: 11 August 2017 17:47 > On 08/09/2017 10:34 PM, Daniel Borkmann wrote: > > On 08/09/2017 09:39 AM, James Hogan wrote: > > [...] > >> time (but please consider looking at the other patch which is certainly > >> a more real issue). > > > > Sorry for the delay, started looking into that and whether we > > have some other options, I'll get back to you on this. > > Could we solve this more generically (as in: originally intended) in > the sense that we don't need to trust the gcc va_list handling; I feel > this is relying on an implementation detail? Perhaps something like > below poc patch? That patch still has 'cond ? arg : cond1 ? (long)arg : (u32)arg' so probably has the same warning as the original version. The va_list handling is defined by the relevant ABI, not gcc. It is ok on x86-64 because all 32bit values are extended to 64bits before being passed as arguments (either in registers, or on the stack). Nothing in the C language requires that, so other 64bit architectures could pass 32bit values in 4 bytes of stack. David