alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Keyon Jie <yang.jie@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	"Rajwa, Marcin" <marcin.rajwa@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue
Date: Fri, 17 Jan 2020 18:56:48 +0800	[thread overview]
Message-ID: <476be658-59a6-e1f1-d7fc-51331966f27b@linux.intel.com> (raw)
In-Reply-To: <s5h1rry5qad.wl-tiwai@suse.de>

On 2020/1/17 下午6:30, Takashi Iwai wrote:
> On Fri, 17 Jan 2020 11:13:31 +0100,
> Keyon Jie wrote:
>>
>>
>>
>> On 2020/1/17 下午3:57, Takashi Iwai wrote:
>>> On Fri, 17 Jan 2020 06:30:18 +0100,
>>> Keyon Jie wrote:
>>>>
>>>> On 2020/1/17 上午4:37, Takashi Iwai wrote:
>>>>
>>>> Hi Takashi, I get your concern here, but if we switch to use dma_max
>>>> limit, we won't change the preallocated buffer, it will be still 64KB
>>>> for each stream, user space can ask for re-allocate buffer for each
>>>> stream up to 32MB, but those pinned and can't be swapped out ones are
>>>> the 64KB preallocated ones only, am I wrong?
>>>
>>> No, in general, all sound hardware buffers are pinned.
>>
>> Sorry, I must have been wrong here, what I was focusing on is those
>> allocated SG DMA buffers, I am not sure if they are those you called
>> "hardware buffers" here.
>>
>> My understanding was like this:
>>
>> 1. in pcm_new() stage, the device PCM driver should call
>> snd_pcm_lib_preallocate_pages()->
>> 	snd_pcm_lib_preallocate_pages()->
>> 		preallocate_pcm_pages()
>> and then the substream->dma_buffer is initialized with the
>> preallocated buffer.
>>
>> 2. in pcm_open() stage, the device PCM driver should call
>> snd_pcm_lib_malloc_pages()->
>> 	snd_dma_alloc_pages() //if we need to reallocate bigger
>> buffer. *The substream->dma_buffer won't be freed, Takashi, this is
>> what I thought you named "pinned" buffer.* And those reallocated
>> bigger buffer via snd_dma_alloc_pages() will be freed at pcm_close()
>> per my understanding?
> 
> What I meant as "pinned" is that the pages are not swapped out by
> swapper process like the user-space or anonymous pages.
> So if you open all streams (say 16 streams) on a machine with 32MB
> buffers, it'll cost a half GB.  And, we have no restriction about
> which user may do it, so all normal users who have the access to the
> sound device can consume a half GB kernel space pages easily.  For a
> big server it's no problem, but for a small system, it's costing.

Understood, you are concerning about intentional attack from user space 
about memory consuming, you propose that normal user should be permitted 
to use the default 64KB only, if larger buffer required, please use proc 
fs expert mode, is my understanding correct?

Thanks,
~Keyon

> 
> 
> Takashi
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2020-01-17 10:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  4:53 [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue Keyon Jie
2020-01-16  7:15 ` Takashi Iwai
2020-01-16  9:50   ` Keyon Jie
2020-01-16 10:27     ` Takashi Iwai
2020-01-16 11:25       ` Keyon Jie
2020-01-16 11:50         ` Takashi Iwai
2020-01-16 14:14           ` Jie, Yang
2020-01-16 15:31             ` Jie, Yang
2020-01-16 16:07               ` Takashi Iwai
2020-01-16 16:39               ` Pierre-Louis Bossart
2020-01-16 17:25                 ` Rajwa, Marcin
2020-01-16 17:40                   ` Pierre-Louis Bossart
2020-01-16 20:37                     ` Takashi Iwai
2020-01-17  5:30                       ` Keyon Jie
2020-01-17  7:57                         ` Takashi Iwai
2020-01-17 10:13                           ` Keyon Jie
2020-01-17 10:30                             ` Takashi Iwai
2020-01-17 10:56                               ` Keyon Jie [this message]
2020-01-17 11:15                                 ` Takashi Iwai
2020-01-17  5:37                     ` Keyon Jie
2020-01-17  8:00                       ` Takashi Iwai
2020-01-17 10:43                         ` Keyon Jie
2020-01-17 11:12                           ` Takashi Iwai
2020-01-19  3:52                             ` Keyon Jie
2020-01-19  7:09                               ` Takashi Iwai
2020-01-19  8:11                                 ` Keyon Jie
2020-01-19  9:04                                   ` Takashi Iwai
2020-01-19 10:14                                     ` Keyon Jie
2020-01-19 10:43                                       ` Takashi Iwai
2020-01-20  2:23                                         ` Keyon Jie
2020-01-16 15:45             ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=476be658-59a6-e1f1-d7fc-51331966f27b@linux.intel.com \
    --to=yang.jie@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=marcin.rajwa@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).