lkml.org 
[lkml]   [2018]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 4/9] drm/xen-front: Implement Xen event channel handling
    From
    Date
    On 02/23/2018 04:44 PM, Boris Ostrovsky wrote:
    > On 02/23/2018 02:00 AM, Oleksandr Andrushchenko wrote:
    >> On 02/23/2018 01:50 AM, Boris Ostrovsky wrote:
    >>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
    >>>> +
    >>>> +static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id)
    >>>> +{
    >>>> + struct xen_drm_front_evtchnl *evtchnl = dev_id;
    >>>> + struct xen_drm_front_info *front_info = evtchnl->front_info;
    >>>> + struct xendispl_resp *resp;
    >>>> + RING_IDX i, rp;
    >>>> + unsigned long flags;
    >>>> +
    >>>> + spin_lock_irqsave(&front_info->io_lock, flags);
    >>>> +
    >>>> + if (unlikely(evtchnl->state != EVTCHNL_STATE_CONNECTED))
    >>>> + goto out;
    >>> Do you need to check the state under lock? (in other routines too).
    >> not really, will move out of the lock in interrupt handlers
    >> other places (I assume you refer to be_stream_do_io)
    >
    > I was mostly referring to evtchnl_interrupt_evt().
    ah, then we are on the same page: I will move the check
    in interrupt handlers
    > -boris
    >
    >
    >> it is set under lock as a part of atomic operation, e.g.
    >> we get a new request pointer from the ring and reset completion
    >> So, those places still seem to be ok

    \
     
     \ /
      Last update: 2018-02-23 15:50    [W:4.640 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site