From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0AB8E748E6 for ; Sat, 30 Sep 2023 21:56:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9B6F6B0161; Sat, 30 Sep 2023 17:56:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4BAA6B016E; Sat, 30 Sep 2023 17:56:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3A296B0171; Sat, 30 Sep 2023 17:56:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A5DE16B0161 for ; Sat, 30 Sep 2023 17:56:08 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 78C6C1601C4 for ; Sat, 30 Sep 2023 21:56:08 +0000 (UTC) X-FDA: 81294622416.07.B5E1BFA Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) by imf22.hostedemail.com (Postfix) with ESMTP id B01A7C0023 for ; Sat, 30 Sep 2023 21:56:06 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=W6rUA94l; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf22.hostedemail.com: domain of keescook@chromium.org designates 209.85.167.176 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696110966; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1icVX1vipL46lW3iEjwQH9ZT3scIXW/xZq3Wbk91zeo=; b=yh4j9nxfHdm4UGT5kqB1fH8t2nAxgBIl1ZLgtWRXShq0wjI5k5pLqbmGbg1e/NIf3ZEM4W gVCqOZAJGrUzYa57dJ2Cc4FMZVjNT6Dq7rpLcTPbYRCxGWN796iEbOoFDocK845kiirH+p 25sYkeFeWyVp1TM99DX07ZD3sjpOWpU= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=W6rUA94l; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf22.hostedemail.com: domain of keescook@chromium.org designates 209.85.167.176 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696110966; a=rsa-sha256; cv=none; b=hYwwEcG7/q3KGf3F6QhpzBHxk7thDtw8ewvNOW9OZgBUNWyRvwvE8MB3ozAhJuG4T90VFn So5TkGoKWw/mIA3A0D1Kk7/8igkLYUwfesGbP4nCP8YZGnsPM6qS1hdBgZhQccDdO2vAMF pqr6X6hoTt/WMV0M0yKdh853xchITTQ= Received: by mail-oi1-f176.google.com with SMTP id 5614622812f47-3aec067556dso3644400b6e.2 for ; Sat, 30 Sep 2023 14:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1696110966; x=1696715766; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=1icVX1vipL46lW3iEjwQH9ZT3scIXW/xZq3Wbk91zeo=; b=W6rUA94l3N8eM3kKn03ZWobVR1EJR/HDK2qthJ8EeWye91QvvoRGv7SyUFLFGihZnq fSsKo4bIMYwVa9hzNS7pyipF58wMx3wETkA75VJBQbnyEK8UsaPi80ZJJC18ujVDidL0 fjey2kA6pMKhkOSZtiGKEXiJxiKh05BGwY5EQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696110966; x=1696715766; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1icVX1vipL46lW3iEjwQH9ZT3scIXW/xZq3Wbk91zeo=; b=Kdx88WhwXXfuGxsDCs1QSlafGkE8FstCBjLNVMewV8jsnLAzd/lA3E8guqpgs+j+v+ SxN85GSc9D1VB95ZWmgVcETvuy8gAaWfetY1vUSMnAde19j9tKc5nrGP4rPSXjob4WMk j8vCHxSNqvhqGUkW3ktTQ8ebjaMonBfsy+VOxlxe///dTrYaSryThASi8LeKhyhSaopt 1zze/EkbZ5dn6dOnHp/CdNUPYaHH41E2MP1vsOz+0bUw5Irf/77ZCoPfB+5djJJ+5ptF 0NSkIYeD+a1Jc6V+Sjen/EbGpWt+ERHecA/zY1rJfH+Xf3B49jl6DntiJhsd0BzjjxIi AKag== X-Gm-Message-State: AOJu0YylMTHPHlox++hRyQ00TIjdpwU0oouNps3joSJCto2RxVpRz2NO gb3HtgfxgxPJhC96hr171Annew== X-Google-Smtp-Source: AGHT+IFkI3tRr+/6289gTcMVtjTAWDXeyklSe2Qt3xiCvsM7nQGjkWpzKBhDTJj9OyNhzL6HMfwCSQ== X-Received: by 2002:a05:6808:645:b0:3ab:929e:c5e1 with SMTP id z5-20020a056808064500b003ab929ec5e1mr8085723oih.39.1696110965716; Sat, 30 Sep 2023 14:56:05 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id n5-20020a170902e54500b001b8c6890623sm19257993plf.7.2023.09.30.14.56.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Sep 2023 14:56:04 -0700 (PDT) Date: Sat, 30 Sep 2023 14:56:01 -0700 From: Kees Cook To: Kent Overstreet Cc: Andrew Morton , Brian Foster , kernel test robot , Linux Memory Management List , linux-fsdevel@vger.kernel.org, linux-bcachefs@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [linux-next:master] BUILD REGRESSION df964ce9ef9fea10cf131bf6bad8658fde7956f6 Message-ID: <202309301403.82201B0A@keescook> References: <202309301308.d22sJdaF-lkp@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202309301308.d22sJdaF-lkp@intel.com> X-Rspamd-Queue-Id: B01A7C0023 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: eic61dedptwm5ey4goxneo86az8ruey4 X-HE-Tag: 1696110966-29044 X-HE-Meta: U2FsdGVkX1+1zWDLVCSm9r2r9I63p3169gdsFCESJzo/vrEoJ44T2Kvc8nMRh1C5h6wDbZi6Bj8LbIGJlsooFuChEsTLTckSVDTejt69hr1iH9mjK/Q9rxeBmmDsQHUfUQL8LBn5N2PWsMPefG8rJofGRRxzQv7i1/bXGn7tn5wO/BudNWDXIB8XJTeQ+10d5syh5OjoYk1Lx8LvR4rCwxDeHHAJJYb07vdj6cPVe7jsL3MOYsdVhyXIObZ7yJlXesO75rhiDHNr7HC+5qxM1GIShIBoa3V+G7ZGsgDZBBsINTu0FChguBOLT7JiSJeLeyKw+/Eu9U0aLQaeoYukqSTDqdt+i8qdggqUdjXei5SuOaSSj+GopDVcFYADYIjN8pqcieMjjf52qjO2oCc77QByz3IE27LY3XNp2prCfVUenFo6ksKJ6CAB89UsR/pF094B+Kn9BoEX4JLkNcaHaUuoSm5UGloiHeXnt119H+Uo50Do0eFxwwjpvVqaFa4I3zduR+6PJSd9A4U4rBtMN6FEaBAhRDcrHikVwfhqJ+PHLfkc9f/dfIfaUz85fgUQzbfAXiHGxYkwQQR/lPrLGJhlJzpUEVbXW2atbYNTfxz3iK5goPEqkWzi62L5nIN9MqmNuPye6zhUQdFnXKs0GVDHNthWCmkPHfYY/4jyLdEZhKISt6aJimXWzRNj/dCnDhWmQ7QFsJn31MlxJY69CE1dHZISEizMlbmdvFK4aSVdd+xZWn4lTKT4iB9IGdpHhhAkN24fSh1n56HzvQlmonpuPgiuDkyr6IXUEAaXs2EwFM/W1LH627VtfSWeDcSoT+AdHMhSNt144X/RUROYGfQbXnmbEU5DNe6boWptS3FBq+o3HeiO9UWhziiGeB1lOFVb+rlsnU7zDszzPWaznzKH/4IU6OTTuV5wva8SY17QgKAkoffgCQNVXz/vb4V8qgiHDZ+sFP0Tbrl97A1 wDd/US3E zfv1l2BXNZbsw3lrozwvXvNF7V4O81rFgreN7Fo4NI+AE30W+Y8TSSGf+fClUz329IUA2Z79h82LkTa2M+5Fo5Fr9UVVpaiL7t9gx3XCZMoES/sMOV8EpH0hNbtVmhE7XGKKqK7lbFoWVouHWMucdsISo+cXHOOGAMNecOEvLVBkhcSEdBYlq0BLqiHxm174Swefbdjazs+w2jhzglUXSFDZXMd+UZ55s0eWJesvngJ7WKQmQPeB2ZX3g8rTFwt3qanL/xx2vEhF/e9jAHC36lZf0eom4IsZZTqEjKGnpHfvpTxHRAYZeoEuFF2JFbvox6EptoBC7FDcQVDgidDWV8Opzi1nNJx3Pa9OiUaUaIE4ZDb8zmbJC8+R7MLEl74VbX6HTQHP0rXeAblO3cIHCP6KaxUppMKZd9AwpinU4dOPecaF7zivj1Kc7kA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000249, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Kent, Andrew pointed this out to me, and it's a FORTIFY issue under a W=1 build: On Sat, Sep 30, 2023 at 01:25:34PM +0800, kernel test robot wrote: > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > branch HEAD: df964ce9ef9fea10cf131bf6bad8658fde7956f6 Add linux-next specific files for 20230929 > > Error/Warning reports: > > [...] > https://lore.kernel.org/oe-kbuild-all/202309192314.VBsjiIm5-lkp@intel.com fs/bcachefs/extents.c: In function 'bch2_bkey_append_ptr': include/linux/fortify-string.h:57:33: warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=] 57 | #define __underlying_memcpy __builtin_memcpy | ^ include/linux/fortify-string.h:648:9: note: in expansion of macro '__underlying_memcpy' 648 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ include/linux/fortify-string.h:693:26: note: in expansion of macro '__fortify_memcpy_chk' 693 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ fs/bcachefs/extents.c:235:17: note: in expansion of macro 'memcpy' 235 | memcpy((void *) &k->v + bkey_val_bytes(&k->k), | ^~~~~~ fs/bcachefs/bcachefs_format.h:287:33: note: destination object 'v' of size 0 287 | struct bch_val v; | ^ The problem here is the struct bch_val is explicitly declared as a zero-sized array, so the compiler becomes unhappy. :) Converting bch_val to a flexible array will just kick the can down the road, since this is going to run into -Wflex-array-member-not-at-end soon too since bch_val overlaps with other structures: struct bch_inode_v3 { struct bch_val v; __le64 bi_journal_seq; ... }; As a container_of() target, this is fine -- leave it a zero-sized array. The problem is using it as a destination for memcpy, etc, since the compiler will believe it to be 0 sized. Instead, we need to impart a type of some kind so that the compiler can actually unambiguously reason about sizes. The memcpy() in the warning is targeting bch_val, so I think the best fix is to correctly handle the different types. So just to have everything in front of me, here's a summary of what I'm seeing in the code: struct bkey { /* Size of combined key and value, in u64s */ __u8 u64s; ... }; /* Empty placeholder struct, for container_of() */ struct bch_val { __u64 __nothing[0]; }; struct bkey_i { __u64 _data[0]; struct bkey k; struct bch_val v; }; static inline void bch2_bkey_append_ptr(struct bkey_i *k, struct bch_extent_ptr ptr) { EBUG_ON(bch2_bkey_has_device(bkey_i_to_s(k), ptr.dev)); switch (k->k.type) { case KEY_TYPE_btree_ptr: case KEY_TYPE_btree_ptr_v2: case KEY_TYPE_extent: EBUG_ON(bkey_val_u64s(&k->k) >= BKEY_EXTENT_VAL_U64s_MAX); ptr.type = 1 << BCH_EXTENT_ENTRY_ptr; memcpy((void *) &k->v + bkey_val_bytes(&k->k), &ptr, sizeof(ptr)); k->k.u64s++; break; default: BUG(); } } So this is appending u64s into the region that start with bkey_i. Could this gain a u64 flexible array? struct bkey_i { __u64 _data[0]; struct bkey k; struct bch_val v; __u64 ptrs[]; }; Then the memcpy() could be just a direct assignment: k->ptrs[bkey_val_u64s(&k->k)] = (u64)ptr; k->k.u64s++; Alternatively, perhaps struct bkey could be the one to grow this flexible array, and then it could eventually be tracked with __counted_by (but not today since it expects to count the array element count, not a whole struct size): struct bkey { /* Size of combined key and value, in u64s */ __u8 u64s; ... __u64 data[] __counted_by(.u64s - BKEY_U64s); }; And bch_val could be dropped... Then the memcpy becomes: k->k.u64s++; k->k.data[bkey_val_u64s(&k->k)] = (u64)ptr; It just seems like there is a lot of work happening that could really just type casting or unions... What do you think? -- Kees Cook