Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1106180pxu; Thu, 17 Dec 2020 02:16:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJxxao3+lTwmp8oPA/r+HsLNThUIBq0JmxNznuwUDRD4wC89R0p3AUemuNsDerfTDTe5zEks X-Received: by 2002:a50:f392:: with SMTP id g18mr37978059edm.306.1608200160103; Thu, 17 Dec 2020 02:16:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608200160; cv=none; d=google.com; s=arc-20160816; b=zBt2FoNqYSIJIFsTvNOQiNcoH+ZQGMIGJCaj/hkjHrtVdfUr1TRhGXwYmvghN0i9/3 8uFkUfkCWjhekf5YPUo+A9m8kFwjYR2SwwKnKtTPDvO9tbYrlrxHvP7hv2aa08wtHsdN b5nAKOy9j++L47tsOXQNqhVBoPDoY6BPSC+psmju5M3zyGnn7r1DAeEwzwbyB7cxLW4P DSUP5VFVyAOrUMBd3PxVgdbJnFF/tFmoDiYXn2+1OcL4uzqj6Crk1ILkDLeXzSYCwgl/ GyTNNjhNJmgfn5kLTCok7ymJPiED80QNkcLj7qVPRm7tTSIislUbID5lfhLi38xhxz9H 5htQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date; bh=D5ZGBDEBlxDEuGy+oSo1Hrct487W88cMoKt+BP98Cy8=; b=tovP4PJHFBGq/Y1gBnWRv/Xda9oANQjIDPeCADKdv3bDe1EziD9M9MFVdA8zBRLDZ7 BDMtR9CrZyxn+84jT0V6/qXgkGqBat0+IbzMbFsQPVsi6glIQ8A5mV8ZRI76gbtA2ZpG iufmBQRlV3NNpEqMdKCKs6dJkDIEPpFnLURCW7y2ixB8sJDF3B+rv0si3/rb34+FiS8Z WzQpB64Ug+EwG+Ij/p+0xbIf/2OPFNU8uXHCWyn1snNlM2Y1XzjOiVmfhNPUSOUBW3bM DrvlQK0JrLsM07TsRneaIqw65W3U1tbgGbpn6vMryI3XDo/qZKb76KxpD1UWBPrwLEzX L6og== 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 w5si2268329ejc.599.2020.12.17.02.15.37; Thu, 17 Dec 2020 02:16:00 -0800 (PST) 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 S1728052AbgLQKPZ (ORCPT + 99 others); Thu, 17 Dec 2020 05:15:25 -0500 Received: from mx2.suse.de ([195.135.220.15]:41218 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726533AbgLQKPZ (ORCPT ); Thu, 17 Dec 2020 05:15:25 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 60D6AAC7B; Thu, 17 Dec 2020 10:14:43 +0000 (UTC) Date: Thu, 17 Dec 2020 11:14:43 +0100 Message-ID: From: Takashi Iwai To: Lars-Peter Clausen Cc: Robin Gong , perex@perex.cz, tiwai@suse.com, akpm@linux-foundation.org, xiang@kernel.org, pierre-louis.bossart@linux.intel.com, gustavoars@kernel.org, shengjiu.wang@nxp.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 ] ALSA: core: memalloc: add page alignment for iram In-Reply-To: References: <1608221747-3474-1-git-send-email-yibin.gong@nxp.com> <05c824e5-0c33-4182-26fa-b116a42b10d6@metafoo.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 Dec 2020 10:55:42 +0100, Takashi Iwai wrote: > > On Thu, 17 Dec 2020 10:43:45 +0100, > Lars-Peter Clausen wrote: > > > > On 12/17/20 5:15 PM, Robin Gong wrote: > > > Since mmap for userspace is based on page alignment, add page alignment > > > for iram alloc from pool, otherwise, some good data located in the same > > > page of dmab->area maybe touched wrongly by userspace like pulseaudio. > > > > > I wonder, do we also have to align size to be a multiple of PAGE_SIZE > > to avoid leaking unrelated data? > > Hm, a good question. Basically the PCM buffer size itself shouldn't > be influenced by that (i.e. no hw-constraint or such is needed), but > the padding should be cleared indeed. I somehow left those to the > allocator side, but maybe it's safer to clear the whole buffer in > sound/core/memalloc.c commonly. That said, something like below (totally untested). We might pass the pass-aligned size to dmab->bytes field instead of keeping the original value, too. Takashi --- --- a/sound/core/memalloc.c +++ b/sound/core/memalloc.c @@ -126,6 +126,7 @@ static inline gfp_t snd_mem_get_gfp_flags(const struct device *dev, int snd_dma_alloc_pages(int type, struct device *device, size_t size, struct snd_dma_buffer *dmab) { + size_t orig_size = size; gfp_t gfp; if (WARN_ON(!size)) @@ -133,6 +134,7 @@ int snd_dma_alloc_pages(int type, struct device *device, size_t size, if (WARN_ON(!dmab)) return -ENXIO; + size = PAGE_ALIGN(size); dmab->dev.type = type; dmab->dev.dev = device; dmab->bytes = 0; @@ -177,7 +179,8 @@ int snd_dma_alloc_pages(int type, struct device *device, size_t size, } if (! dmab->area) return -ENOMEM; - dmab->bytes = size; + memset(dmab->area, 0, size); + dmab->bytes = orig_size; return 0; } EXPORT_SYMBOL(snd_dma_alloc_pages);