linux-kernel - Re: input.c: start on release

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:	Fri, 23 Feb 2007 10:06:14 -0500
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Pete Zaitcev" <zaitcev@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: input.c: start on release

On 2/23/07, Pete Zaitcev <zaitcev@...hat.com> wrote:
> Here's a curious code I found in drivers/input/input.c (2.6.21-rc1):
>
> void input_release_device(struct input_handle *handle)
> {
> ....
>        if (handle->handler->start)
>                handle->handler->start(handle);
> }
>
> Is the above supposed to be this way, or you meant ->stop here?

It should be ->start(). You are probably confused a little by the name
of the function. input_release_device() is called when userspace
issues ioctl(fd, EVIOCGRAB, 0) releasing (or ungrabbing) the device
(as opposed to xxx_release(file, inode) type functions that are called
when last user of a file drops off). In our case we want to give
handlers a chance to resume their control over device. Right now
standard keyboard driver uses start method do bring back in sync LED
state of a keyborad-like device after it was released (ungrabbed).

>
> The commit comment says:
>        Input: fix list iteration in input_release_device()
> It says me precisely nothing about the way it's supposed ot be, sorry...
>

It reason for ->start was explained in the patch it was introduced in,
the changeset you are referring to literally fixes issue with
iteration through list in this function.

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