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: <CABb+yY0dvtOZoa=T+gyTeWy3XyAictXJnqSkbF39E=peHSXDuQ@mail.gmail.com>
Date:	Wed, 26 Sep 2012 22:19:02 +0530
From:	Jassi Brar <jassisinghbrar@...il.com>
To:	Inderpal Singh <inderpal.singh@...aro.org>
Cc:	linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
	boojin.kim@...sung.com, vinod.koul@...el.com, patches@...aro.org,
	kgene.kim@...sung.com
Subject: Re: [PATCH 3/3] DMA: PL330: Balance module remove function with probe

On Wed, Sep 26, 2012 at 4:25 PM, Inderpal Singh
<inderpal.singh@...aro.org> wrote:
> On 26 September 2012 15:02, Jassi Brar <jassisinghbrar@...il.com> wrote:
>> On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
>> <inderpal.singh@...aro.org> wrote:
>>
>>> How about conditionally DMA_TERMINATE_ALL and free resources like below ?
>>>
>>> @@ -3017,9 +3017,11 @@ static int __devexit pl330_remove(struct
>>> amba_device *adev)
>>>                 /* Remove the channel */
>>>                 list_del(&pch->chan.device_node);
>>>
>>> -               /* Flush the channel */
>>> -               pl330_control(&pch->chan, DMA_TERMINATE_ALL, 0);
>>> -               pl330_free_chan_resources(&pch->chan);
>>> +               if (pch->chan.client_count != 0) {
>>> +                       /* Flush the channel */
>>> +                       pl330_control(&pch->chan, DMA_TERMINATE_ALL, 0);
>>> +                       pl330_free_chan_resources(&pch->chan);
>>> +               }
>>>         }
>>>
>> It is perfectly safe to flush the channels that have client_count == 0
>> as well. Which is already the case.
>
> As per my understanding, if client_count ==0, It may mean following:
>
> 1. This channel was never allocated to any client. Hence
> alloc_chan_resources was not done for it.
> So, no need to flush and free resources if it was never allocated at
> the first place. If we free_chan_resources, it will not be balanced
> against alloc_chan_resources. Scenario: insmod and then rmmod.
>
> Or,
>
> 2. The channel was allocated to some client, alloc_chan_resource was
> done, the work for the client is completed and free_chan_resources was
> performed. Now  since resources have already been freed, no need to
> flush and free_chan_resources again in remove.
>
> The whole idea of this patch is to balance alloc_chan_resources and
> free_chan_resources.
>
Do you see any issue with channels that have zero client_count ?
AFAIU there are already enough checks in the path to weed out unused
channels, so let us please not uglify the code by adding new
unnecessary checks.

thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ