lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58df4c43-ab07-0001-f725-9098f18a8e6f@ideasonboard.com>
Date:   Wed, 2 Sep 2020 11:46:50 +0100
From:   Kieran Bingham <kieran.bingham@...asonboard.com>
To:     Kaaira Gupta <kgupta@...iitr.ac.in>,
        Helen Koike <helen.koike@...labora.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 9/9] media: vimc: Run multiple captures on same thread

Hi Kaaira,

On 19/08/2020 19:04, Kaaira Gupta wrote:
> If multiple captures try to enable stream, start their stream but do not
> initialise the pipeline again. Also, don't start the thread separately.
> Starting their streams will update the use count and their frames would
> be processed by the already running thread.
> 
> Signed-off-by: Kaaira Gupta <kgupta@...iitr.ac.in>
> ---
>  drivers/media/test-drivers/vimc/vimc-streamer.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/test-drivers/vimc/vimc-streamer.c b/drivers/media/test-drivers/vimc/vimc-streamer.c
> index fade37bee26d..880c31759cc0 100644
> --- a/drivers/media/test-drivers/vimc/vimc-streamer.c
> +++ b/drivers/media/test-drivers/vimc/vimc-streamer.c
> @@ -275,13 +275,14 @@ int vimc_streamer_s_stream(struct vimc_stream *stream,
>  		return ret;
>  
>  	if (enable) {
> -		if (stream->kthread)
> -			return 0;
>  
>  		ret = vimc_streamer_stream_start(ved);
>  		if (ret)
>  			goto out;
>  
> +		if (stream->kthread)
> +			goto out;
> +

This goto out makes it look like it's an error path. So that probably
warrants a comment along the lines of 'don't reinitialise the pipeline
if it has already started'. ?

I wonder if it's better to handle the pipeline_init during _stream_start
'only' in the code path where it's the first stream ?

Then similarly, the pipeline_terminate would happen on stream_stop
'only' when it's the last stream.

Or I guess that is handled by the refcount ... Hrm it would be nice to
be able to make/keep it symmetrical somehow.


>  		ret = vimc_streamer_pipeline_init(stream, ved);
>  		if (ret)
>  			goto out;
> 

-- 
Regards
--
Kieran

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ