linux-kernel - Re: [PATCH v2 3/4] DMA: PL330: Balance module remove function with probe

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]

Date:	Sat, 27 Oct 2012 15:50:55 +0530
From:	Inderpal Singh <inderpal.singh@...aro.org>
To:	Vinod Koul <vkoul@...radead.org>
Cc:	vinod.koul@...el.com, linux-samsung-soc@...r.kernel.org,
	linux-kernel@...r.kernel.org, jassisinghbrar@...il.com,
	boojin.kim@...sung.com, patches@...aro.org, kgene.kim@...sung.com
Subject: Re: [PATCH v2 3/4] DMA: PL330: Balance module remove function with probe

Hi Vinod,

On 26 October 2012 10:15, Vinod Koul <vkoul@...radead.org> wrote:
> On Thu, 2012-10-25 at 16:53 +0530, Inderpal Singh wrote:
>>
>> This code will get executed only in case of force removal of the
>> module which was discussed in the first version of the patch at [1].
>> Now, if we do not have to think about force removal then this patch
>> will go back to the first version.
> But why are you doing force removal of driver even when client is
> holding a reference to you.
>
> What happens when client finally tries to free the channel?
Since we return EBUSY so forced removal won't succeed. Client can free
the channel eventually.

>
> What is the problem you are trying to solve?
>>

There was a long discussion about it in the first version of the
patch. Allow me to explain it to you.

The existing driver does DMA_TERMINATE_ALL and frees resources for all
the channels in the _remove function. The first version of patch
removed this flushing and freeing of channel resources because they
are not getting allocated in the probe. Jassi pointed out that manual
flushing is needed if a force removal happens and some client is
queued. Then it was agreed that flushing is not needed, instead we
should return EBUSY if client is queued on some channel (this will
happen only in force removal case). Hence this additional check in v2
version so that force removal does not succeeds if any client is
queued.

If you think force removal is not a practical scenario and we should
not be bothering about it, this check can be removed and the patch
will go back to first version which just removes flushing and freeing
of channels beacues they are not getting allocated in probe.

Let me know your view.

Regards,
Inder

>> Let me know your view.
>>
>> [1] https://patchwork.kernel.org/patch/1503171/
>>
>
>
> --
> Vinod Koul
> Intel Corp.
>
--
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/