From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Anshul Garg <aksgarg1989@gmail.com>
Cc: linux-input@vger.kernel.org,
"anshul.g@samsung.com" <anshul.g@samsung.com>
Subject: Re: [PATCH] Input:Flush client events on clk_type change
Date: Thu, 8 Jan 2015 13:41:09 -0800 [thread overview]
Message-ID: <20150108214109.GD23256@dtor-ws> (raw)
In-Reply-To: <CA+HOOshSijYZnshdKhV+uPW5NKhbQoOZfv3yptsR7Bv2CD7cUA@mail.gmail.com>
On Thu, Jan 08, 2015 at 07:27:59PM +0530, Anshul Garg wrote:
> Dear Mr. Dmitry ,
>
> Thanks a lot for your suggestions.
>
> > + spin_lock_irq(&dev->event_lock);
> > + spin_lock(&client->buffer_lock);
> > + spin_unlock(&dev->event_lock);
>
> Umm, why?
>
> Yes, there is no need of event_lock as we are modifying client
> specific data structure only.
>
> Hence only buffer_lock will guarantee atomicity for flushing of client
> pending events buffer.
>
> So i will modify locking mechanism to use buffer_lock only.
>
> > +
> > + /* Flush clients events after clk_type is changed
> > + * and queue SYN_DROPPED event.*/
> > + client->packet_head = client->head = client->tail;
> > + spin_unlock_irq(&client->buffer_lock);
> > +
> > + evdev_queue_syn_dropped(client);
>
> This is still racy. I'd rather we passed a flag to
> evdev_queue_syn_dropped() to indicate it should also clear queue.
>
> Can you please tell me in which scenario's this patch is prone to race
> condition's?
> As i think we are modifying the client's buffer indexes so buffer_lock
> would be sufficient.
New events may come up between resetting the queue and queuing EV_SYN
and client would not really know if they contain valid time or not.
>
>
> Yes by adding one more parameter in evdev_queue_syn_dropped function
> on the basis
> of which we can flush the buffer.
>
> Example ::
>
> static void evdev_queue_syn_dropped(struct evdev_client *client)
>
> It can be changed to
>
> static void evdev_queue_syn_dropped(struct evdev_client *client , bool flush)
> {
> spin_lock(buffer_lock);
>
> if(flush)
> client->packet_head = client->head = client->tail;
>
>
> .........
>
> spin_unlock(buffer_lock);
> }
>
> OR
> Similarly we can extend__evdev_flush_queue function to support
> flushing of client event queue.
> As currently this function flushes single type of events only.
>
> I think 2nd way is better.
>
> Please give your insignt on above suggested changes.
I do not see how make evdev_flush_queue() to flush all types of events
without adding another parameter that would "override" type, which is
ugly.
It looks like we can make evdev_queue_syn_dropped() zap the old events
unconditionally, so I'd rather do that.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2015-01-08 21:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-07 18:56 [PATCH] Input:Flush client events on clk_type change Anshul Garg
2015-01-07 19:32 ` Dmitry Torokhov
2015-01-08 13:57 ` Anshul Garg
2015-01-08 21:41 ` Dmitry Torokhov [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-01-07 18:26 Anshul Garg
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=20150108214109.GD23256@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=aksgarg1989@gmail.com \
--cc=anshul.g@samsung.com \
--cc=linux-input@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.