Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5007827pxj; Tue, 22 Jun 2021 13:00:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz8aLCgYj+Spg5dEHqHAae70tw1yjvrBVvrXc2Xom4DOj+5N1f/byE1d10/+d/afO8GpO0Y X-Received: by 2002:a17:906:8c1:: with SMTP id o1mr5887320eje.530.1624392001904; Tue, 22 Jun 2021 13:00:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624392001; cv=none; d=google.com; s=arc-20160816; b=mD40zxas4NPNC6Xy/Kktj3aKwNoCmk7+ABNUR3doeXz2V3vMWCnfLCdD9pKwY99dyZ 2rJHEK0/njjhppO41+ECeEoJI6dXb877I9ABC+UR2MpCarq5XAW/SEQkRA422V8HRCC0 57DellRvfC2rAVriHzGoQPw6mE9+Dc81Sft9FgZqhdzE79HoO5OtbMUIk/RqfTTe5Qmj +XAThF3F8BjLmRyMnQrmG4B2Jgq1rp8FU1V3/AMe/Tuc7R4E5TLdSDgrvl4IeOIb/smO /HOCIaymufadwrVYOXF0OmxuIi3Ybi5Aqjz0ZHrgssIO8WISnmFnmr+afZqS9Fs7dj7A IdlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=aLouebosyMw1WbN7+7eEUh8eh696mHptEglbeO0PZYc=; b=ZL0NLYm0XzXcHRJxeCxuBhFKePKyDzNosPEoWq81dQSChQESjLtHwiZrzJQPywtZe5 489qZumX3zkIT9qDq9eQXdR24+TAzlNRHf2L3haP5PXYclACGOoCIM3NSYRJxXp3NcL8 4i7ypBKYfsHJQt/GltmqXR5spZrTIz7iUxF6YnXtzspYeSIQo/svfcVS97jlSIPZoBUH x33lbixZGGefg8PWgF4UMqT4E3S3NzOUseKIV5ATi2X1+uHbcvtfr8pU/lhmY8p/vYfJ GE681ozuN2QbYFNMEd88xGi+Y8E9kiD2fKIMgv7JAUuF58IsNoZ7Supna3WaZOkuzI0I bhEg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s13si18370469edy.85.2021.06.22.12.59.39; Tue, 22 Jun 2021 13:00:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232812AbhFVUAz (ORCPT + 99 others); Tue, 22 Jun 2021 16:00:55 -0400 Received: from netrider.rowland.org ([192.131.102.5]:47679 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S232418AbhFVUAx (ORCPT ); Tue, 22 Jun 2021 16:00:53 -0400 Received: (qmail 468382 invoked by uid 1000); 22 Jun 2021 15:58:36 -0400 Date: Tue, 22 Jun 2021 15:58:36 -0400 From: 'Alan Stern' To: David Laight Cc: 'Mauro Carvalho Chehab' , "linux-usb@vger.kernel.org" , "linuxarm@huawei.com" , "mauro.chehab@huawei.com" , Laurent Pinchart , Mauro Carvalho Chehab , "linux-kernel@vger.kernel.org" , "linux-media@vger.kernel.org" , "stable@vger.kernel.org" Subject: Re: [PATCH v3] media: uvc: don't do DMA on stack Message-ID: <20210622195836.GA468074@rowland.harvard.edu> References: <6832dffafd54a6a95b287c4a1ef30250d6b9237a.1624282817.git.mchehab+huawei@kernel.org> <20210622132922.GB452785@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 22, 2021 at 02:21:27PM +0000, David Laight wrote: > From: Alan Stern > > Sent: 22 June 2021 14:29 > ... > > > Thought... > > > > > > Is kmalloc(1, GFP_KERNEL) guaranteed to return a pointer into > > > a cache line that will not be accessed by any other code? > > > (This is slightly weaker than requiring a cache-line aligned > > > pointer - but very similar.) > > > > As I understand it, on architectures that do not have cache-coherent > > I/O, kmalloc is guaranteed to return a buffer that is > > cacheline-aligned and whose length is a multiple of the cacheline > > size. > > > > Now, whether that buffer ends up being accessed by any other code > > depends on what your driver does with the pointer it gets from > > kmalloc. :-) > > Thanks for the clarification. > > Most of the small allocates in the usb stack are for transmits > where it is only necessary to ensure a cache write-back. > > I know there has been some confusion because one of the > allocators can add a small header to every allocation. > This can lead to unexpectedly inadequately aligned pointers. > If it is updated when the preceding block is freed (as some > user-space mallocs do) then it would need to be in a > completely separate cache line. If you really want to find out what the true story is, you should ask on the linux-mm mailing list. The rest of us are not experts on this stuff. Alan Stern