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:	Tue, 4 Nov 2014 21:55:55 +0400
From:	Andrey Utkin <andrey.krieger.utkin@...il.com>
To:	Hans Verkuil <hverkuil@...all.nl>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux Media <linux-media@...r.kernel.org>,
	OSUOSL Drivers <devel@...verdev.osuosl.org>,
	ismael.luceno@...p.bluecherry.net,
	Mauro Carvalho Chehab <m.chehab@...sung.com>
Subject: Re: [PATCH 4/4] [media] solo6x10: don't turn off/on encoder interrupt
 in processing loop

2014-11-03 19:15 GMT+04:00 Hans Verkuil <hverkuil@...all.nl>:
> Hi Andrey,
>
> On 10/29/2014 05:03 PM, Andrey Utkin wrote:
>> The used approach actually cannot prevent new encoder interrupt to
>> appear, because interrupt handler can execute in different thread, and
>> in current implementation there is still race condition regarding this.
>
> I don't understand what you mean with 'interrupt handler can execute in
> different thread'. Can you elaborate?
>
> Note that I do think that this change makes sense, but I do like to have a
> better explanation.
>

Hi Hans, thanks for response.

I'm not proficient in linux kernel, so it's hard to make sure and
strict statements regarding this.

In the commit justification I mean that solo_ring_thread(), which is
edited, runs in a thread started with kthread_run().
Interrupt hander is executed on random kernel thread (whichever is
currently running, is it correct?). So temporarily disabling
interrupts from video encoders by writing to special register cannot
be used for "processing serialization", for "fixation of state" or
anything useful at all, thus it should be removed from code.

Is it clear now?

Please feel free to push the patch with edited description, even
without resubmission from me.

-- 
Andrey Utkin
--
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