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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E643BC4332F for ; Tue, 31 Oct 2023 04:16:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TG3Hb4euZqLfHpLLZxk0MrmVP5dUNtJ/QPQ/hClvcvM=; b=rS1QoZ+5zVl7fA XcPZ1nD+WbHB1z4AadoUB5/RlJ4RCJZPW5FHEQ4jqEDK45DnaIAU8wR/wFUWQCvx9eZgLphg2rvJF zUNMjzSlHKoBLSO3Or4Iw9v5SFYW6Mj+N4xtP2484wRiwfaWOd0YG+kwhFEQ0F6CojGex80njuKYC pQi9f0zgP58B9Ie6XxL8YPMdvcTEP1xFfpF9ALLZ3dGusO6HFzZTQn8H0DTnwe9jAlkZ353HaUkpN kP6LJMFqRks2pdzS4DVvqLQhC+GngiQCAEfabcEx8pRmRIlfAxSBbtkEOFUNfoHWm8f76kV1yMDCo bMDbJCjlZJoW/mdRmosA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qxgAW-004VVY-32; Tue, 31 Oct 2023 04:15:56 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qxgAU-004VUx-0N for linux-arm-kernel@lists.infradead.org; Tue, 31 Oct 2023 04:15:55 +0000 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-40906fc54fdso40904545e9.0 for ; Mon, 30 Oct 2023 21:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1698725749; x=1699330549; darn=lists.infradead.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=4+XGJHIawgTSSX307LBjCODLlT0Tx2ra/fAXcNjtWag=; b=pL2U3Vdeyc9q+P+2zdjvxs2hu3jTbps3YBq2bqZWu8+0MAabwUPkqQSCBH+f3RpTb7 FWuzEPDuREl8ZipBhgKqcL7gh7oqyCj76y2mnX/gWlamR7zMPCNVS6sYjRm/BJ+xTJ6b LgDyyk5yDD1wOEgeWN6T7RElCX0NXvRiyYLzc83XqDEsGVlYNdbyUQDCM4yrp1A6D5Ji Ic+2ZpQoauVGotFsJ53F463QpTNaZrjLOtKWJYGfW/JSDw1EHhDxxhHOo+6f1IQwCb+h Zgw/KbNmRrRHEotDXI2JZppOn7pOXP+jqnZAU0LcxJuLMPGTxVGFsJ7N/bAXbJqKd/EH MjEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698725749; x=1699330549; 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=4+XGJHIawgTSSX307LBjCODLlT0Tx2ra/fAXcNjtWag=; b=Aku2F61d99JtyoZhaupdjAFFSZC2Oeg6urFlVphSkJXuVEl69oE6kG7gScKurWEkGE EpMfb/Lk8hwH33g0Lm4Fz6mVhJjSUS0w/mOazockoA+BJ1aczvUv/tXUiIh8swkyA9yJ mRi8JuFUEzfbS9+cvcJnnr/jDPr0NSGyyVD1iD8m4TMLVL/R7c7jZvY2CaClSRgzfn3x 5VWyPf45d/zPBWcIOcgabsCxny/myxx9FLsxJmeOWCCR5WFo4ysiSS9DwcIsLkcJgInI aeK35qKPRQgCJXOvXtov5Ei4h9Lt5znP+yde9rErinbL4MULvRmEC9ectSuhWayCV5pt idKg== X-Gm-Message-State: AOJu0Yz8ACAp75T5z4SKiI/Jdim1etTxw1S3k2KAQpMImuwC1INJ3+6r mFN8o4hFb9k/VAvI4xxgt2ZByg== X-Google-Smtp-Source: AGHT+IFjBHIFm1JTJ2xEz0x9KdrymxSPpvI2rSqxFdWsKkHsQHINPRE/hd5i8vrt3EqsK02hGA7lxw== X-Received: by 2002:a05:6000:2a8:b0:32f:7db1:22f1 with SMTP id l8-20020a05600002a800b0032f7db122f1mr6766214wry.60.1698725748696; Mon, 30 Oct 2023 21:15:48 -0700 (PDT) Received: from localhost ([102.36.222.112]) by smtp.gmail.com with ESMTPSA id q8-20020adfcd88000000b003197869bcd7sm498361wrj.13.2023.10.30.21.15.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 21:15:48 -0700 (PDT) Date: Tue, 31 Oct 2023 07:15:45 +0300 From: Dan Carpenter To: Sudeep Holla Cc: linux-arm-kernel@lists.infradead.org Subject: Re: [bug report] firmware: arm_ffa: Add schedule receiver callback mechanism Message-ID: <5ff13821-5b37-4dca-90ee-7fa54f7adffa@kadam.mountain> References: <0e8ddbca-d9da-4a3b-aae3-328993b62ba2@moroto.mountain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231030_211554_162682_DC3DD8BB X-CRM114-Status: GOOD ( 18.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Oct 30, 2023 at 04:01:07PM +0000, Sudeep Holla wrote: > On Mon, Oct 30, 2023 at 05:31:04PM +0300, Dan Carpenter wrote: > > Hello Sudeep Holla, > > > > The patch 0184450b8b1e: "firmware: arm_ffa: Add schedule receiver > > callback mechanism" from Oct 5, 2023 (linux-next), leads to the > > following Smatch static checker warning: > > > > drivers/firmware/arm_ffa/driver.c:1251 ffa_partitions_cleanup() > > warn: double check that we're allocating correct size: 8 vs 88 > > > > drivers/firmware/arm_ffa/driver.c > > 1243 static void ffa_partitions_cleanup(void) > > 1244 { > > 1245 struct ffa_dev_part_info **info; > > 1246 int idx, count = drv_info->partition_count; > > 1247 > > 1248 if (!count) > > 1249 return; > > 1250 > > --> 1251 info = kcalloc(count, sizeof(**info), GFP_KERNEL); > > > > I *think* this should be sizeof(*info). It ends up being a smaller > > allocation (8 bytes instead of 88). > > Not sure if I am following this warning properly. I am bit confused whether > it suggest 8 is correct or 88 is correct. Anyways, the expectation is to > just allocate 8 bytes for a pointer. We just fetch a list of stored pointer > in XArray and free them. > > One possible way to avoid any confusion is to use sizeof(struct ffa_dev_part_info *) > or even sizeof(void *). The static checker is saying that 8 is correct but we are allocating 88 bytes. There is an extra * in the sizeof(). I don't necessarily like to make buffers smaller in case I have misunderstood the code, but it seems like we should do that here. regards, dan carpenter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel