mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Indan Zupancic" <indan@nul.nu>
To: "Dmitry Torokhov" <dtor@insightbb.com>
Cc: linux-input@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org
Subject: Re: [RFC/RFT 1/5] Input: implement proper locking in input core
Date: Sat, 28 Jul 2007 01:28:15 +0200 (CEST)	[thread overview]
Message-ID: <58239.81.207.0.53.1185578895.squirrel@secure.samage.net> (raw)
In-Reply-To: <20070724044858.192608314.dtor@insightbb.com>

Hi,

Not real feedback, just some nitpicks.

On Tue, July 24, 2007 06:45, Dmitry Torokhov wrote:
> +static int input_defuzz_abs_event(int value, int old_val, int fuzz)
> +{
> +	if (fuzz) {
> +		if (value > old_val - fuzz / 2 && value < old_val + fuzz / 2)
> +			return value;
>
> -	add_input_randomness(type, code, value);
> +		if (value > old_val - fuzz && value < old_val + fuzz)
> +			return (old_val * 3 + value) / 4;
>
> -	switch (type) {
> +		if (value > old_val - fuzz * 2 && value < old_val + fuzz * 2)
> +			return (old_val + value) / 2;
> +	}

Shouldn't the return values of the second and third case be reversed?
In the 2nd check the new values is weighted for 1/4, while in the 3rd
case it counts for 1/2, which breaks the "account new value more when
it is closer to the old one" logic that I thought I saw here. So to sum up,
should the second return be "return (old_val + value * 3) / 4"?


> +/*
> + * Generate software autorepeat event. Note that we take
> + * dev->event_lock here to avoid racing with input_event
> + * which may cause keys get "stuck".
> + */

Hurray. :-)

> -			if (code > SW_MAX || !test_bit(code, dev->swbit) || !!test_bit(code, dev->sw) == value)
> -				return;
> +		if (dev->rep[REP_PERIOD])
> +			mod_timer(&dev->timer, jiffies +
> +					msecs_to_jiffies(dev->rep[REP_PERIOD]));
> +	}

Perhaps use a local var for the "msecs_to_jiffies(dev->rep[REP_PERIOD])" part.


> +static void input_start_autorepeat(struct input_dev *dev, int code)
> +{
> +	if (test_bit(EV_REP, dev->evbit) &&
> +	    dev->rep[REP_PERIOD] && dev->rep[REP_DELAY] &&
> +	    dev->timer.data) {
> +		dev->repeat_key = code;
> +		mod_timer(&dev->timer,
> +			  jiffies + msecs_to_jiffies(dev->rep[REP_DELAY]));
> +	}
> +}

Same here.


> +	case EV_KEY:
> +		if (is_event_supported(code, dev->keybit, KEY_MAX) &&
> +		    !!test_bit(code, dev->key) != value) {

A bit confusing, test_bit(0 only returns 0 or 1 anyway, doesn't it?
So "test_bit(code, dev->key) != value" should be all right.
I noticed that the old code did it too, but still.

> -		case EV_MSC:
> +	case EV_SW:
> +		if (is_event_supported(code, dev->swbit, SW_MAX) &&
> +		    !!test_bit(code, dev->sw) != value) {

Same.

> -			break;
> +	case EV_LED:
> +		if (is_event_supported(code, dev->ledbit, LED_MAX) &&
> +		    !!test_bit(code, dev->led) != value) {

And here.


> +void input_inject_event(struct input_handle *handle,
> +			unsigned int type, unsigned int code, int value)
>  {
> -	struct input_dev *dev = (void *) data;
> +	struct input_dev *dev = handle->dev;
> +	struct input_handle *grab;
>
> -	if (!test_bit(dev->repeat_key, dev->key))
> -		return;
> +	if (is_event_supported(type, dev->evbit, EV_MAX)) {
> +		spin_lock_irq(&dev->event_lock);
>
> -	input_event(dev, EV_KEY, dev->repeat_key, 2);
> -	input_sync(dev);
> +		grab = rcu_dereference(dev->grab);
> +		if (!grab || grab == handle)
> +			input_handle_event(dev, type, code, value);

'handle' can't be NULL, so can drop the "!grab" check, as checking
"grab == handle" should be sufficient.


> +/**
> + * input_open_device - open input device
> + * @handle: handle through which device is being accessed
> + *
> + * This function should be called by input handlers when they
> + * want to start receive events from given input device.
> + */
>  int input_open_device(struct input_handle *handle)
>  {
>  	struct input_dev *dev = handle->dev;
> -	int err;
> +	int retval;
>
> -	err = mutex_lock_interruptible(&dev->mutex);
> -	if (err)
> -		return err;
> +	retval = mutex_lock_interruptible(&dev->mutex);
> +	if (retval)
> +		return retval;
> +
> +	if (dev->going_away) {
> +		retval = -ENODEV;
> +		goto out;
> +	}
>
>  	handle->open++;
>
>  	if (!dev->users++ && dev->open)

Ugh, not your code, and perhaps it's me, but that looks weird.
The ++ hidden inthe if check is ugly, and would mean that "users"
can be negative, which is strange.

> -		err = dev->open(dev);
> +		retval = dev->open(dev);
>
> -	if (err)
> -		handle->open--;
> +	if (retval && !--handle->open) {

Eek! That -- is hidden well there. Would it hurt to call synchronize_sched()
unconditionally? Something like:

	if (retval) {
		handle->open--;

It's a rare case anyway.

> +		/*
> +		 * Make sure we are not delivering any more events
> +		 * through this handle
> +		 */
> +		synchronize_sched();
> +	}
>

> +/**
> + * input_close_device - close input device
> + * @handle: handle through which device is being accessed
> + *
> + * This function should be called by input handlers when they
> + * want to stop receive events from given input device.
> + */
>  void input_close_device(struct input_handle *handle)
>  {
>  	struct input_dev *dev = handle->dev;
>
> -	input_release_device(handle);
> -
>  	mutex_lock(&dev->mutex);
>
> +	__input_release_device(handle);
> +
>  	if (!--dev->users && dev->close)
>  		dev->close(dev);
> -	handle->open--;
> +
> +	if (!--handle->open) {
> +		/*
> +		 * synchronize_sched() makes sure that input_pass_event()
> +		 * completed and that no more input events are delivered
> +		 * through this handle
> +		 */
> +		synchronize_sched();
> +	}

Same here, though just leaving the original "handle->open--;" there and
merely adding the if check would be better too I think. Or just get rid of
the whole if thing.


>  static void input_seq_print_bitmap(struct seq_file *seq, const char *name,
> @@ -569,7 +765,9 @@ static const struct file_operations inpu
>
>  static void *input_handlers_seq_start(struct seq_file *seq, loff_t *pos)
>  {
> -	/* acquire lock here ... Yes, we do need locking, I knowi, I know... */

 ;-)

> +	if (mutex_lock_interruptible(&input_mutex))
> +		return NULL;
> +
>  	seq->private = (void *)(unsigned long)*pos;
>  	return seq_list_start(&input_handler_list, *pos);
>  }

Greetings,

Indan



  parent reply	other threads:[~2007-07-27 23:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-24  4:45 [RFC/RFT 0/5] Input locking patches Dmitry Torokhov
2007-07-24  4:45 ` [RFC/RFT 1/5] Input: implement proper locking in input core Dmitry Torokhov
2007-07-24  5:35   ` Jeff Garzik
2007-07-24  5:52     ` Dmitry Torokhov
2007-07-27 23:28   ` Indan Zupancic [this message]
2007-07-29  3:50     ` Dmitry Torokhov
2007-07-29 12:50       ` Indan Zupancic
2007-07-24  4:45 ` [RFC/RFT 2/5] evdev - implement proper locking Dmitry Torokhov
2007-07-24  4:45 ` [RFC/RFT 3/5] Input: tsdev " Dmitry Torokhov
2007-07-24  4:45 ` [RFC/RFT 4/5] Input: mousedev " Dmitry Torokhov
2007-07-24  4:45 ` [RFC/RFT 5/5] Input: joydev " Dmitry Torokhov
2007-07-27 22:25 ` [RFC/RFT 0/5] Input locking patches Indan Zupancic
2007-07-29  3:38   ` Dmitry Torokhov
2007-07-29 12:15     ` Indan Zupancic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58239.81.207.0.53.1185578895.squirrel@secure.samage.net \
    --to=indan@nul.nu \
    --cc=dtor@insightbb.com \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome