linux-kernel - Re: [PATCH] kthread: saa7134-tvaudio.c

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: <1156959402.3852.82.camel@praia>
Date:	Wed, 30 Aug 2006 14:36:41 -0300
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Andrew Morton <akpm@...l.org>
Cc:	Cedric Le Goater <clg@...ibm.com>,
	Sukadev Bhattiprolu <sukadev@...ibm.com>,
	video4linux-list@...hat.com, kraxel@...esex.org,
	haveblue@...ibm.com, serue@...ibm.com, Containers@...ts.osdl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kthread: saa7134-tvaudio.c

Em Qua, 2006-08-30 às 09:49 -0700, Andrew Morton escreveu:
> On Wed, 30 Aug 2006 18:30:27 +0200
> Cedric Le Goater <clg@...ibm.com> wrote:
> 

> > The thread of this driver allows SIGTERM for some obscure reason. Not sure
> > why, I didn't find anything relying on it.
> > 
> > could we just remove the allow_signal() ?
> > 
> 
> I hope so.  However I have a bad feeling that the driver wants to accept
> signals from userspace.  Hopefully Mauro & co will be able to clue us in.

The history we have on our development tree goes only until Feb, 2004.
This line were added before it.

I've looked briefly the driver. The same allow_signal is also present on
tvaudio (part of bttv driver). BTTV were written to kernel 2.1, so, this
piece seems to be an inheritance from 2.1 time.

No other V4L drivers have this one, although cx88-tvaudio (written on
2.6 series) have a similar kthread to check if audio status changed. 

On cx88-tvaudio, it does:
                if (kthread_should_stop())
                        break;
instead of:

                if (dev->thread.shutdown || signal_pending(current))
                        goto done;

It is likely to work if we remove allow_signal and replacing the
signal_pending() by kthread_should_stop() as above.

The better is to check the real patch on a saa7134 hardware before
submiting to mainstream. You may submit the final patch for us to test
at the proper hardware.

Cheers, 
Mauro.

-
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/