linux-kernel - Re: [RFC PATCH v11 6/9] media: tegra: Add Tegra210 Video input driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <06a4a067-8d54-4322-b2a6-14e82eaeda29@nvidia.com>
Date:   Thu, 30 Apr 2020 10:06:30 -0700
From:   Sowjanya Komatineni <skomatineni@...dia.com>
To:     Dmitry Osipenko <digetx@...il.com>, <thierry.reding@...il.com>,
        <jonathanh@...dia.com>, <frankc@...dia.com>, <hverkuil@...all.nl>,
        <sakari.ailus@....fi>, <helen.koike@...labora.com>
CC:     <sboyd@...nel.org>, <linux-media@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-clk@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v11 6/9] media: tegra: Add Tegra210 Video input driver


On 4/30/20 9:29 AM, Sowjanya Komatineni wrote:
>
> On 4/30/20 9:04 AM, Sowjanya Komatineni wrote:
>>
>> On 4/30/20 7:13 AM, Dmitry Osipenko wrote:
>>> 30.04.2020 17:02, Dmitry Osipenko пишет:
>>>> 30.04.2020 16:56, Dmitry Osipenko пишет:
>>>>> 30.04.2020 01:00, Sowjanya Komatineni пишет:
>>>>>> +static int chan_capture_kthread_finish(void *data)
>>>>>> +{
>>>>>> +    struct tegra_vi_channel *chan = data;
>>>>>> +    struct tegra_channel_buffer *buf;
>>>>>> +
>>>>>> +    set_freezable();
>>>>>> +
>>>>>> +    while (1) {
>>>>>> +        try_to_freeze();
>>>>> I guess it won't be great to freeze in the middle of a capture 
>>>>> process, so:
>>>>>         if (list_empty(&chan->done))
>>>>>             try_to_freeze();
>>>> And here should be some locking protection in order not race with the
>>>> chan_capture_kthread_start because kthread_finish could freeze before
>>>> kthread_start.
>>> Or maybe both start / finish threads should simply be allowed to freeze
>>> only when both capture and done lists are empty.
>>>
>>> if (list_empty(&chan->capture) &&
>>>      list_empty(&chan->done))
>>>     try_to_freeze();
>>
>> good to freeze when not in middle of the frame capture but why should 
>> we not allow freeze in between captures?
>>
>> Other drivers do allow freeze in between frame captures.
>>
>> I guess we can freeze before dequeue for capture and in finish thread 
>> we can freeze after capture done. This also don't need to check for 
>> list_empty with freeze to allow between frame captures.
>>
> Also if we add check for both lists empty, freeze is not allowed as 
> long as streaming is going on and in case of continuous streaming 
> freeze will never happen.

Hi Dmitry,

Will update in v12 to not allow freeze in middle of a frame capture.

Can you please confirm on above if you agree to allow freeze to happen 
in b/w frame captures?

Also as most feedback has been received from you by now, appreciate if 
you can provide all in this v11 if you have anything else so we will not 
have any new changes after v12.

Thanks

Sowjanya