From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 6B18D3A8748 for ; Tue, 28 Apr 2026 09:36:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777368983; cv=none; b=PSQMxC0kvl37a8l2QxY56iHwChgTwN9lKgHwvrnU3VTcIQJtKFUjmOqyZqqRr/SjtzTLfQbw3Bh8b16XxDPXkR7sxLy6GuNKGF60iqSsRdC8G+8TTHjnSOJqBmS4XHvstQ01hBYZB6EF3hXygn+x6rKlBl2aZpqF5tQ7z7tcAOo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777368983; c=relaxed/simple; bh=8DPrOqm/MQALU2UOUDeOQ9su/H/BzZxxlv0DQu2wyKs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rZitMloIJ1YIvQlKfH8tDk4xP80x7fU3LNL5hypyc0tUX/rjF+2dLUXhc3fQKvIylo9qmOQ7JaiJUBLgdMRodJUKuL70UlJiB4JOWC/Y3WOYmBW9FDuaoIVzCHzR0gQ7T9CMYQRzdhVpRiOouPs5XvxYxPt2cDzWcL39GQvXjxY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Pi7mKrpz; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Pi7mKrpz" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4890d945eb4so56417895e9.0 for ; Tue, 28 Apr 2026 02:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777368980; x=1777973780; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=/jLRNwHr7auelyVO83HtYYK5qAXRWo3niE2hSctyKqM=; b=Pi7mKrpzepJQVTqzKTt+8mWlRfVcUwaPHIM6nyzbVuCWSmVQk3K9fwKXpjvd93I5vi o5TjFBViamvSFURPnnj69DN8bt+5V+UjqunrgEeWHWeTQSeOF6RQLHDif40MMtnaeQ2j bjrtOZqxctYMQaiXttBWfP+aaiktxNQHiVUE6+rLEgnXRH3KwcfQAv/ed8R/do2neO/6 ixjumM+dHeuiiZcBpwjo3+VABRfv+2vw/t0Zd5t981O3YvuIyYp9lZCOVhCdkOKSFmVu 4Wx8U9cJI+N/lueEeumtQliM3xVB2o3Dy0AIabhJiTeEePrlsz1GqsK/0LzzPBvlTWFd D3DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777368980; x=1777973780; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=/jLRNwHr7auelyVO83HtYYK5qAXRWo3niE2hSctyKqM=; b=jkjIreIwZ/cnQVhegg/Ov9do8z7ORB4GfUIcxZLlOig5zI+bXotzxk1OqcAI04C4+x j8zu3R4kLFkMR9iWm98xNUPPWe9a7D/zqLbAk3EY+IDjJ4O8pxd6QMFag/wvtDjjDs/W O0Noj9cc+Nv3ky6qu+6ZKWG13HI49jSVun441HUuuZBPqt1H1s0fjT60s6f9mZOWm1kw WWlJ/9L+8sKXQqbk6xANlqpjsJtZFWc3VcQdcKhsztEb5TbmSl8+Kzdu5kNXMCRHfnrx FLHy4rRUS7GHe9CYA98bmnSSP91LjhATUR7spjHmUt+cFqM1PpN+DWZVFRqpsM+SRG6J qrag== X-Forwarded-Encrypted: i=1; AFNElJ+u7tQ5Z1bBKWN/3ts/uCVAUfa6T+Nmi1Dax3Quj+uY5eOpxCsZiP0iyTdPpKP8UuE0rjmQ7axZZkKk5Yc=@vger.kernel.org X-Gm-Message-State: AOJu0YwmoQ+qfggi5hWzdInN9OG46u/Ifbv3BRxxVSzvT5iqcqNv7gsR nhqcCNfhMKi8NNwxl+iUP57O9T7GNbQFSrU00b/LRODb0Wda/1do8Bxm X-Gm-Gg: AeBDiesUAfNX5oKycuUDLZc4iHW+zkNSsapFCtz515RKXZ/R4QFY7DCaFeYF//Cf65H Xi11KdBiqm8BJM/WlbeAfzb1f21NC4eGmscuxEf/LNxHbPFKe1VNyR/z89LaVSknhhN04cvyfYb xtQvQBU0dK/lRN72Gkmy4tLOwOZXwFEJAJWBVxOoPBnkdSIrIQfG/e/z89/Fh3H3D5YvvlZZNZF vVCwzsUybPsEEec5hfHwVRtsbjf/1oEp/KxZRtBt9XOU8FE/hRaUMmfZ2RDn1NevuCzOrDCuNsb WgON9r2FaN9mu31/S7JyLqmamgFrfBAe9eamYgp19IYjnmXPfvlG/zmNFPHdgNput4jXc1qUjg3 kWVsLSiq/Sgb4ABESHN2Pb6s411Z2j+jCb0to/eIFx5f3VbPU2rNiwxEMOVPkWjCaKPWTXSf6wU lka6ZWXRH5/JFmavaZ8YyPDfH8inrCr3LZMin34uWxOlJky3GB3PlRvrW1vNyi3u2JSBZyppMG+ CQ= X-Received: by 2002:a05:600c:3ba6:b0:489:1baf:8c03 with SMTP id 5b1f17b1804b1-48a78a43734mr27693135e9.11.1777368979518; Tue, 28 Apr 2026 02:36:19 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a775ea85bsm21487095e9.6.2026.04.28.02.36.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2026 02:36:19 -0700 (PDT) Date: Tue, 28 Apr 2026 10:36:17 +0100 From: David Laight To: David Lechner Cc: Giorgi Tchankvetadze , antoniu.miclaus@analog.com, lars@metafoo.de, Michael.Hennerich@analog.com, jic23@kernel.org, nuno.sa@analog.com, andy@kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Jonathan Cameron , Andy Shevchenko Subject: Re: [PATCH v2] iio: adc: ti-ads7138: replace kmalloc() with stack allocation in i2c_write_block Message-ID: <20260428103617.148027c1@pumpkin> In-Reply-To: <3512cce0-6660-42a9-91bb-07e78a002205@baylibre.com> References: <20260427112705.71138-3-giorgitchankvetadze1997@gmail.com> <20260427143137.27bc4552@pumpkin> <3512cce0-6660-42a9-91bb-07e78a002205@baylibre.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 27 Apr 2026 10:21:37 -0500 David Lechner wrote: > On 4/27/26 8:31 AM, David Laight wrote: > > On Mon, 27 Apr 2026 15:27:07 +0400 > > Giorgi Tchankvetadze wrote: > > > >> The ads7138_i2c_write_block() function currently utilizes kmalloc() > >> to allocate a buffer for I2C transfers. However, the length > >> parameter passed to this function is strictly 2 bytes across all > >> driver invocations, making the total payload buffer size exactly 4 bytes. > >> Invoking the heap allocator for a 4-byte buffer introduces > >> unnecessary SLUB overhead. > > > > Have you confirmed that the buffer is never used for DMA? > > > > Provided the lock that blocks concurrent access from two threads > > is actually outside this code, a buffer for short transfers could > > be allocated within 'struct i2c_client'. > > > > David > > > Giorgi, > > This is why it is important to include a changelog and a link to the > previous discussion [1] in the cover letter or after --- in a single patch > when you submit a new revision. I think that would have answered David's > question. > > [1]: https://lore.kernel.org/linux-iio/20260424081809.61841-2-giorgitchankvetadze1997@gmail.com/ > > The thing is I remember issues with on-stack buffers being used for dma - which worked before kernel stacks were allocated using vmalloc(). One of the solutions to that is to use kmalloc() for buffers that could be on stack. I think I found exactly 1 call to this function. Indeed, just inlining the logic would make everything clearer. David