Message ID | 20230922175050.work.819-kees@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp5870600vqi; Fri, 22 Sep 2023 14:16:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFXa88UC2uTUV+4l9MgO0CIEpkc6CzqzBBhqZ7N3T1yuKw9BOQjjtypbwiiTGVZ5t4QUYHb X-Received: by 2002:a05:6808:1493:b0:3a7:6d4a:fd78 with SMTP id e19-20020a056808149300b003a76d4afd78mr1077966oiw.24.1695417413464; Fri, 22 Sep 2023 14:16:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695417413; cv=none; d=google.com; s=arc-20160816; b=gQoH8e2q43iE40WAJVCs5Bl6YatgPVdj1ynNcQFeuAIE1RXcSfIpsAN++fOHSsnKEg GS7LHBb5tVdbOd/Tknq0BHeHWDk+RAoA5TfrSmzBaX9nIZ/d9bM1IhK77ZyNVoEft9vo giF81tO0puNGNn+43q84hbC0f1LRmXq/orom4Xk6OY+J+b1m1EMh76tloXrdQMn5GUVy 6SSgsKH7UvBhI+2HEEpOgW4WQsy33v1BYA0FtgGh9UpUdRv33pjXXVzGmMUxuTzRWhe3 l6QtfKlW1gjLhMagJxMPQZj7BRh7JbsUOQfM1A/sww8ErNPSDL9pbehlIpHHWRofO9l/ z0zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=3oEkxAEP7bGPEZ+qBOxMzwux9ypcm6j3kmlQze2cxoU=; fh=YVD1tR8vEWWUU5j6EmYPhzBtImpaQ/8eU9cchR2rMmE=; b=b7/x1SGEhI+1LVsoSTGKPemYFA5mRw8KiS9T5fnlUHmGY0iYGZyIR9PsUnQwYSCjd+ Svt9fx2/A1eh1d1gZJyG2z92OpvguY5Ibh94+BFr+sDoEArmxgPgUqZqoOXbjZzcrT86 TalXp6GOi7XSkN5JUnz0TjBkOseH0y3kcp1LhfGt2wsO/SH052v7wd43RW/LwGNGxqFx TO/ZK3mBu0o5V+U8bulsOljhX95ecCiBk2oy1PA4dBkLmGdbCLV36NhrpDeKyyEk5Aac CQvcPjXcI9td2S5Sa2gz07YUSGta+i6JxZwxZQCktg4aRSPco5fuIxFiSxmjDfTDnKz9 hVOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=iXWPa6zf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id g4-20020a056a001a0400b00690fb3c5cecsi4897613pfv.16.2023.09.22.14.16.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 14:16:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=iXWPa6zf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 75A5F81167BF; Fri, 22 Sep 2023 10:52:51 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233404AbjIVRvf (ORCPT <rfc822;pwkd43@gmail.com> + 28 others); Fri, 22 Sep 2023 13:51:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233449AbjIVRvP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 22 Sep 2023 13:51:15 -0400 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8AF1D199 for <linux-kernel@vger.kernel.org>; Fri, 22 Sep 2023 10:50:52 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-692b2bdfce9so685267b3a.3 for <linux-kernel@vger.kernel.org>; Fri, 22 Sep 2023 10:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1695405052; x=1696009852; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=3oEkxAEP7bGPEZ+qBOxMzwux9ypcm6j3kmlQze2cxoU=; b=iXWPa6zf+GsCL5VuchZLiIXa5IsI9fxJp8AEvCjVS8cyShhjJ85kKl6KLUwIWAv8X4 Km8CIYeAdsZtR218HFwmqkVf7V+AvgC7l9jryz1q1sEAmBamuLJ+lHoF205gfklOVh1/ GZfvmTbl2PQy4WW3F5LvzM5kCobc78IBN3zzY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695405052; x=1696009852; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3oEkxAEP7bGPEZ+qBOxMzwux9ypcm6j3kmlQze2cxoU=; b=l1PqX9vIrKdSr55eY/uMl28RTyX7Ml17gI5Xxw3zl04l0Ye7gp9ZC671O9Ugj02XeI RSU8+MCtNrM4v1mL3cj3xvmkzkHXTSgr8k2VH09S7ohHCzSIziuN4CzKZTd1GY+4HPkP gRYCuoWrqwfYLdb1b9z0vEdD19GlV8kUbdk8Q+0BXzD8696MFplaPCHmIRr2EqxfDJrO 6svz9xnDQ3UIs/Nv6qVJshy8N57Wf3Knmbbzvem3R5ldxlSRTm6ywwl70JFXUzinxjQF O00rHwdHwKPcDPcxtS2n+niiDds3iQ78p8ehJQXiKJ8CThgLzPelt/DpRJcgH+gcA0lS e0JQ== X-Gm-Message-State: AOJu0YzRzrXT6F/ffJkWW9YZqA9zIivPeezu3XXaZ4pBuAWAsJi1rjwx fABoOJH37yUNoP1i3JAMeLSPEQ== X-Received: by 2002:a05:6a00:2d0b:b0:68e:2d9d:b0cc with SMTP id fa11-20020a056a002d0b00b0068e2d9db0ccmr170192pfb.6.1695405052057; Fri, 22 Sep 2023 10:50:52 -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 x18-20020a62fb12000000b0068fe6ad4e18sm3484364pfm.157.2023.09.22.10.50.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 10:50:51 -0700 (PDT) From: Kees Cook <keescook@chromium.org> To: =?utf-8?q?Martin_Povi=C5=A1er?= <povik+lin@cutebit.org> Cc: Kees Cook <keescook@chromium.org>, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, asahi@lists.linux.dev, alsa-devel@alsa-project.org, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, linux-hardening@vger.kernel.org Subject: [PATCH] ASoC: apple: mca: Annotate struct mca_data with __counted_by Date: Fri, 22 Sep 2023 10:50:50 -0700 Message-Id: <20230922175050.work.819-kees@kernel.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Developer-Signature: v=1; a=openpgp-sha256; l=1312; i=keescook@chromium.org; h=from:subject:message-id; bh=j4yqmKRzUCzvjLbfaqNFg/RfKie7KU/QXR2i1mhhyZg=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBlDdP657tnli5eAN/8roOFU78C7eb8FJ8g94j9+ W70ZL/MvxiJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCZQ3T+gAKCRCJcvTf3G3A JhkwEACoXPDQbe9ClOALZy20QDUufFBZZdIyVDd7vsffjD0NADca1ZAdJibsqdbv0WoKOHbe7dg F8Qn9PbceKIap9s4b67hMoSvLv/sRH+NJCuoMirhWdpYRQguwiegMtsMUFcYpoZbJxhsugsZe9t DK+ZzfTvFpFasQA9noJDlpzCnqoAk40oyu7hfxITKafl8jzz2KF54cvC9Ou9KHC06x/dfuyUh3Z +cmap5XZ3PqL5al8/8bcWjwRep86fpLPje6ZowtIA8Xz6rF7RHkhB8rzFhH6PM2GYovTHn0sJpI +pM58i4vueNt/36/5tWQf7yEhHUKyebeEHhEMsMRopJ0EYttF2K4LrdNc0UD/GHQZfvXr3pJ3TB vspNBhikEwP/27a3H+GMjqo6WIjzMyesedSKO1UvQRx/Sb9Z06KQfe3crNNJQS6alyp2TzjbfQy 5gN8LH2Zy5ftPZWfWKFD/E4LWcSC+j6ATdxgH6xHRu/HZYAYHNAriuf8cp5wbT2hhPy36aGjuBq Qpw2w7PeKkGdpUHShbLmHqpy7JVnuKcdJ2I7b7BjXcQxlx0jahM77cytS0CSOqHHMpQRiVYQ+W8 0zmAS/02v7hvny2scuMrpPhpW1fuR7xhIcXejJX0R3d1NNsYsRZ8qVoiJEvRSdm53xxORkZWxEE +bzZBeY tCA1uhOQ== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Fri, 22 Sep 2023 10:52:51 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777774009810016431 X-GMAIL-MSGID: 1777774009810016431 |
Series |
ASoC: apple: mca: Annotate struct mca_data with __counted_by
|
|
Commit Message
Kees Cook
Sept. 22, 2023, 5:50 p.m. UTC
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct mca_data.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: "Martin Povišer" <povik+lin@cutebit.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: asahi@lists.linux.dev
Cc: alsa-devel@alsa-project.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
sound/soc/apple/mca.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 9/22/23 11:50, Kees Cook wrote: > Prepare for the coming implementation by GCC and Clang of the __counted_by > attribute. Flexible array members annotated with __counted_by can have > their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS > (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > functions). > > As found with Coccinelle[1], add __counted_by for struct mca_data. > > [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci > > Cc: "Martin Povišer" <povik+lin@cutebit.org> > Cc: Liam Girdwood <lgirdwood@gmail.com> > Cc: Mark Brown <broonie@kernel.org> > Cc: Jaroslav Kysela <perex@perex.cz> > Cc: Takashi Iwai <tiwai@suse.com> > Cc: asahi@lists.linux.dev > Cc: alsa-devel@alsa-project.org > Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Thanks
On Fri, Sep 22, 2023 at 10:50:50AM -0700, Kees Cook wrote: > Prepare for the coming implementation by GCC and Clang of the __counted_by > attribute. Flexible array members annotated with __counted_by can have > their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS > (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > functions). > > As found with Coccinelle[1], add __counted_by for struct mca_data. Friendly ping. Mark, can you pick this up please? Thanks! -Kees > > [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci > > Cc: "Martin Povišer" <povik+lin@cutebit.org> > Cc: Liam Girdwood <lgirdwood@gmail.com> > Cc: Mark Brown <broonie@kernel.org> > Cc: Jaroslav Kysela <perex@perex.cz> > Cc: Takashi Iwai <tiwai@suse.com> > Cc: asahi@lists.linux.dev > Cc: alsa-devel@alsa-project.org > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > sound/soc/apple/mca.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/soc/apple/mca.c b/sound/soc/apple/mca.c > index ce77934f3eef..99e547ef95e6 100644 > --- a/sound/soc/apple/mca.c > +++ b/sound/soc/apple/mca.c > @@ -161,7 +161,7 @@ struct mca_data { > struct mutex port_mutex; > > int nclusters; > - struct mca_cluster clusters[]; > + struct mca_cluster clusters[] __counted_by(nclusters); > }; > > static void mca_modify(struct mca_cluster *cl, int regoffset, u32 mask, u32 val) > -- > 2.34.1 >
On Fri, Oct 06, 2023 at 01:22:55PM -0700, Kees Cook wrote: > On Fri, Sep 22, 2023 at 10:50:50AM -0700, Kees Cook wrote: > > Prepare for the coming implementation by GCC and Clang of the __counted_by > > attribute. Flexible array members annotated with __counted_by can have > > their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS > > (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > > functions). > > > > As found with Coccinelle[1], add __counted_by for struct mca_data. > > Friendly ping. Mark, can you pick this up please? Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend conferences and so on so unless there is some reason for urgency (like critical bug fixes) please allow at least a couple of weeks for review. If there have been review comments then people may be waiting for those to be addressed. Sending content free pings adds to the mail volume (if they are seen at all) which is often the problem and since they can't be reviewed directly if something has gone wrong you'll have to resend the patches anyway, so sending again is generally a better approach though there are some other maintainers who like them - if in doubt look at how patches for the subsystem are normally handled.
On Fri, Oct 06, 2023 at 09:53:49PM +0100, Mark Brown wrote: > On Fri, Oct 06, 2023 at 01:22:55PM -0700, Kees Cook wrote: > > On Fri, Sep 22, 2023 at 10:50:50AM -0700, Kees Cook wrote: > > > > Prepare for the coming implementation by GCC and Clang of the __counted_by > > > attribute. Flexible array members annotated with __counted_by can have > > > their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS > > > (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > > > functions). > > > > > > As found with Coccinelle[1], add __counted_by for struct mca_data. > > > > Friendly ping. Mark, can you pick this up please? > > Please don't send content free pings and please allow a reasonable time > for review. People get busy, go on holiday, attend conferences and so > on so unless there is some reason for urgency (like critical bug fixes) > please allow at least a couple of weeks for review. If there have been > review comments then people may be waiting for those to be addressed. > > Sending content free pings adds to the mail volume (if they are seen at > all) which is often the problem and since they can't be reviewed > directly if something has gone wrong you'll have to resend the patches > anyway, so sending again is generally a better approach though there are > some other maintainers who like them - if in doubt look at how patches > for the subsystem are normally handled. I'm happy to do whatever you'd like for this kind of thing, but I'm annoyed by this likely automated response seems to ask for the things that have already happened or generally don't make sense. :P - It _has_ been 2 weeks. - Review comments have _not_ required changes. - Sending a no-change patch is just as much email as sending a ping. - It's not content-free: I'm asking if you're going to take it; patches have gotten lost in the past, so it's a valid question. - I'm not interested in other subsystems, I'm interested in yours. :P You've made it clear you don't want me to pick up these kinds of trivial patches that would normally go through your tree, so I'm left waiting with no indication if you've seen the patch. My normal routine with treewide changes is to pick up trivial stuff that has gotten review but the traditional maintainer hasn't responded to in 2 weeks. Do you want these kinds of patches to be re-sent every 2 weeks if they haven't been replied to by you? -Kees
On Mon, Oct 09, 2023 at 10:17:33AM -0700, Kees Cook wrote: > On Fri, Oct 06, 2023 at 09:53:49PM +0100, Mark Brown wrote: > > Please don't send content free pings and please allow a reasonable time > > for review. People get busy, go on holiday, attend conferences and so > > on so unless there is some reason for urgency (like critical bug fixes) > > please allow at least a couple of weeks for review. If there have been > > review comments then people may be waiting for those to be addressed. > I'm happy to do whatever you'd like for this kind of thing, but I'm > annoyed by this likely automated response seems to ask for the things > that have already happened or generally don't make sense. :P It's a form letter so not quite automated but sure. Since it's the same form letter I send for all these pings it covers a bunch of things that might not apply in each individual case. > - It _has_ been 2 weeks. That's *at least* two weeks. For a non-urgent change like this I'd generally go with longer than that, for example I'd originally had these changes queued for -rc5 to give the driver maintainers a couple of weeks to look at them (my scripting understands -rcs more than dates so you'll see more patches going in on Mondays). > - Review comments have _not_ required changes. > - Sending a no-change patch is just as much email as sending a ping. A no-change patch is directly and readily actionable, a ping typically requires going and digging out the original mail or sending a reply asking for a resend. > - It's not content-free: I'm asking if you're going to take it; > patches have gotten lost in the past, so it's a valid question. That is not something I can meaningfully distinguish from being content free, it provides no new information. Something with content would be for example information about dependencies progressing. > - I'm not interested in other subsystems, I'm interested in yours. :P > You've made it clear you don't want me to pick up these kinds of trivial > patches that would normally go through your tree, so I'm left waiting > with no indication if you've seen the patch. Sure, but that seems fairly normal for the kernel - when sending this sort of stuff myself I'd be leaving it more like a month before I got particularly worried. One way or another it seems fairly common for things to be left for at least a couple of weeks with things like waiting for review, restrictions on when patches actually get applied and just people being busy or whatever. Personally for incoming patches when I'm leaving time for driver maintainers I tend to go for leaving things for a -rc or two - things like who's involved, how early it is in the week when the original patch gets sent and how late in the release cycle we are will factor in there. More urgent things like fixes will tend to go faster, minor stuff that just needs to be handled sometime before the next release will tend to be slower. I don't send out mails saying that I've reviewed and queued things before actually applying them since doing that tends to discourage other people from doing review and I'd rather they did, this means I don't generally send out entirely positive review comments prior to applying anything unless I'm actively chasing for feedback from someone. It can also be a bit confusing for people if I tell them something is OK then later run into test issues. > My normal routine with treewide changes is to pick up trivial stuff that > has gotten review but the traditional maintainer hasn't responded to > in 2 weeks. > Do you want these kinds of patches to be re-sent every 2 weeks if they > haven't been replied to by you? No, please leave it longer - that's the main thing here, you're not leaving adequate time for non-urgent patches like this. If you leave it two weeks for maintainer review and I also leave it two weeks for maintainer review then we will both expire the timers at the same time and we're going to trample over each other. For me it will typically be a bit more or less than two weeks rather than two weeks to the day but IIRC the time you applied something it was while the patch was actually running through my CI. Off the top of my head I'd say wait at least three weeks for this sort of patch before doing anything and then prefer to do a resend, that's should avoid most issues. If you're going to just apply things yourself I'd suggest waiting for -rc6 or so before doing so (assuming the patches were initially sent reasonably early), that does seem like a reasonable backstop so things don't completely miss releases.
On Mon, Oct 09, 2023 at 08:43:44PM +0100, Mark Brown wrote: > Off the top of my head I'd say wait at least three weeks for this sort > of patch before doing anything and then prefer to do a resend, that's > should avoid most issues. If you're going to just apply things yourself > I'd suggest waiting for -rc6 or so before doing so (assuming the patches > were initially sent reasonably early), that does seem like a reasonable > backstop so things don't completely miss releases. Okay, sounds good. Thanks for the clarification!
On Fri, 22 Sep 2023 10:50:50 -0700, Kees Cook wrote: > Prepare for the coming implementation by GCC and Clang of the __counted_by > attribute. Flexible array members annotated with __counted_by can have > their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS > (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > functions). > > As found with Coccinelle[1], add __counted_by for struct mca_data. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: apple: mca: Annotate struct mca_data with __counted_by commit: 59825951707eccf92782e109c04772d34fc07eb6 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
diff --git a/sound/soc/apple/mca.c b/sound/soc/apple/mca.c index ce77934f3eef..99e547ef95e6 100644 --- a/sound/soc/apple/mca.c +++ b/sound/soc/apple/mca.c @@ -161,7 +161,7 @@ struct mca_data { struct mutex port_mutex; int nclusters; - struct mca_cluster clusters[]; + struct mca_cluster clusters[] __counted_by(nclusters); }; static void mca_modify(struct mca_cluster *cl, int regoffset, u32 mask, u32 val)