From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C5B72C82 for ; Thu, 11 Nov 2021 16:01:27 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id s136so5530076pgs.4 for ; Thu, 11 Nov 2021 08:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=7wfDHiPejbS6tDQijlCtZbth9NfDRjzLAZP+AtCVvZk=; b=WJnf3KMp3asJehyM7Bx3fguusBmvh/1/FoyX09dTZhMVRf11bVdfg603H7tjOHf6NG 3ll0hA8q7lUgamTugnuygz6LAfiSsYtNLGX0C8Ux2HKznUe9+GIg3JO8QucK7KRFew1g rQT0Y481E0ItBtfq29i4aXXk+7Y83b7tZ7FsRSyjKGoqcUDBiHBGMo3DAiVFwySpiniO o7fD/422sV00SY3f3IkCJVklAoRpc1y1ztmfSkka1+6KMsr4jMkO76mAaDBV31PNqwOW 63kVJwud9VMjv+2gKe7oQ0I9vy79RqlkhxZEON6VpYcu5IPrC0rsjdIo31qg7IwXJTrw oD4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=7wfDHiPejbS6tDQijlCtZbth9NfDRjzLAZP+AtCVvZk=; b=aMUZnSMTLTsJxDNnywI7srjW2m1BC9SEIR0jTUGA/gUzPUH6jcnjqZ+J9CuAKkpXPc hsBwhBS9VoKj3EtffNYDcSK45WkF55wmTHUsxnt2q1Dc/koD9gXyQODYK4tVRndGv0OH NGUHTnN5urcpLqVVUiwG1t40HFyo9iba5kJKMcHiwYg79bKMQMTmsCx0W8OxcHk/WDh3 VOVYYY3ml1hskOrszV7O29+MsTgf0jU2y93X0Qdx4qu+e5dCIVizF9C8ufPo9kN2jpV7 INtJ6E/QGwHGlYWEVke9VjEQ8/dA/yp6aFxpNpCYElltaKcQu5Rb0bkjoptMVPmAzdNX 5ElQ== X-Gm-Message-State: AOAM530jy9Y8AkseznFLWR6OOZaHyqlbsP6BEaSHz6dwdb3LRSNPpHT6 Ncz7l1hVTo/8N0P46xvCdV9dWg== X-Google-Smtp-Source: ABdhPJxBCA2agoApq1FTFonuazhl5sS5Hn1Z6aY/+CCKh/2B3iR7DCT0CJGRNC1UiIE2x80H7JSHow== X-Received: by 2002:a05:6a00:888:b0:44c:c00e:189c with SMTP id q8-20020a056a00088800b0044cc00e189cmr7439754pfj.79.1636646487541; Thu, 11 Nov 2021 08:01:27 -0800 (PST) Received: from [192.168.254.17] ([50.39.160.154]) by smtp.gmail.com with ESMTPSA id e14sm2636558pga.76.2021.11.11.08.01.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Nov 2021 08:01:27 -0800 (PST) Message-ID: <931f1038-d7ab-f236-8052-c5e5b9753b18@linaro.org> Date: Thu, 11 Nov 2021 08:01:26 -0800 Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH] skbuff: suppress clang object-size-mismatch error Content-Language: en-US To: Marco Elver Cc: "David S. Miller" , Nathan Chancellor , Nick Desaulniers , Jakub Kicinski , Jonathan Lemon , Alexander Lobakin , Willem de Bruijn , Paolo Abeni , Cong Wang , Kevin Hao , Ilias Apalodimas , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Kees Cook , Eric Dumazet References: <20211111003519.1050494-1-tadeusz.struk@linaro.org> From: Tadeusz Struk In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/11/21 07:52, Marco Elver wrote: >> The other way to fix it would be to make the struct sk_buff_head >> equal in size with struct sk_buff: >> >> struct sk_buff_head { >> - /* These two members must be first. */ >> - struct sk_buff *next; >> - struct sk_buff *prev; >> + union { >> + struct { >> + /* These two members must be first. */ >> + struct sk_buff *next; >> + struct sk_buff *prev; >> >> - __u32 qlen; >> - spinlock_t lock; >> + __u32 qlen; >> + spinlock_t lock; >> + }; >> + struct sk_buff __prv; >> + }; >> }; >> >> but that's much more invasive, and I don't even have means to >> quantify this in terms of final binary size and performance >> impact. I think that would be a flat out no go. >> >> From the other hand if you look at the __skb_queue functions >> they don't do much and at all so there is no much room for >> other issues really. I followed the suggestion in [1]: >> >> "if your function deliberately contains possible ..., you can >> use __attribute__((no_sanitize... " > That general advice might not be compatible with what the kernel > wants, especially since UBSAN_OBJECT_SIZE is normally disabled and I > think known to cause these issues in the kernel. > > I'll defer to maintainers to decide what would be the preferred way of > handling this. Sure, I would also like to know if there is a better way of fixing this. Thanks for your feedback. -- Thanks, Tadeusz