From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752246AbdJLRo6 (ORCPT ); Thu, 12 Oct 2017 13:44:58 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:43359 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750992AbdJLRo4 (ORCPT ); Thu, 12 Oct 2017 13:44:56 -0400 X-Google-Smtp-Source: AOwi7QAtvn26U+tPTL9iSZfDACut6/4gHEZV/Yd5pl4JEuiMPIDdUYf6t6jaE9AWMCcZ8Wn617gUFA== Subject: Re: [PATCH] bcache: safeguard a dangerous addressing in closure_queue To: Liang Chen , linux-bcache@vger.kernel.org Cc: i@coly.li, kent.overstreet@gmail.com, linux-kernel@vger.kernel.org References: <20171012143737.24577-1-liangchen.linux@gmail.com> From: Michael Lyle Message-ID: <0b4be514-0ce8-efd9-4e17-8772729ac336@lyle.org> Date: Thu, 12 Oct 2017 10:44:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171012143737.24577-1-liangchen.linux@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/12/2017 07:37 AM, Liang Chen wrote: > The use of the union reduces the size of closure struct by taking advantage > of the current size of its members. The offset of func in work_struct equals > the size of the first three members, so that work.work_func will just > reference the forth member - fn. > > This is smart but dangerous. It can be broken if work_struct or the other > structs get changed, and can be a bit difficult to debug. > > Signed-off-by: Liang Chen So the objective here is to make sure that struct work_struct and the anonymous struct remain identical? I agree that's a potential problem for future maintenance. Could we use BUILD_BUG_ON with offsets and sizes to do the same, to get compile-time checking and avoid doing anything at runtime (I know the compiler can usually omit the BUG but better to be safe)? Otherwise a kernel that triggered this problem would compile, and it'd only be if someone actually used bcache that it would trigger. Mike