From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtualization <virtualization@lists.linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Marc Zyngier <maz@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Stefano Garzarella <sgarzare@redhat.com>,
Keir Fraser <keirf@google.com>,
"Paul E. McKenney" <paulmck@kernel.org>
Subject: Re:
Date: Tue, 29 Mar 2022 15:12:14 +0800 [thread overview]
Message-ID: <CACGkMEtDybY_ZnQkkfuSkx8eMZKoMAe+pnEwyetuS2cmzRVFgw@mail.gmail.com> (raw)
In-Reply-To: <20220328062452-mutt-send-email-mst@kernel.org>
On Mon, Mar 28, 2022 at 6:41 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, Mar 28, 2022 at 02:18:22PM +0800, Jason Wang wrote:
> > On Mon, Mar 28, 2022 at 1:59 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Mon, Mar 28, 2022 at 12:56:41PM +0800, Jason Wang wrote:
> > > > On Fri, Mar 25, 2022 at 6:10 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > >
> > > > > On Fri, Mar 25, 2022 at 05:20:19PM +0800, Jason Wang wrote:
> > > > > > On Fri, Mar 25, 2022 at 5:10 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > >
> > > > > > > On Fri, Mar 25, 2022 at 03:52:00PM +0800, Jason Wang wrote:
> > > > > > > > On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > Bcc:
> > > > > > > > > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ
> > > > > > > > > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org>
> > > > > > > > > Reply-To:
> > > > > > > > > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com>
> > > > > > > > >
> > > > > > > > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote:
> > > > > > > > > >
> > > > > > > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道:
> > > > > > > > > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote:
> > > > > > > > > > > > This is a rework on the previous IRQ hardening that is done for
> > > > > > > > > > > > virtio-pci where several drawbacks were found and were reverted:
> > > > > > > > > > > >
> > > > > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ
> > > > > > > > > > > > that is used by some device such as virtio-blk
> > > > > > > > > > > > 2) done only for PCI transport
> > > > > > > > > > > >
> > > > > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening
> > > > > > > > > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts")
> > > > > > > > > > > > by introducing a global irq_soft_enabled variable for each
> > > > > > > > > > > > virtio_device. Then we can to toggle it during
> > > > > > > > > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is
> > > > > > > > > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In
> > > > > > > > > > > > the future, we may provide config_ops for the transport that doesn't
> > > > > > > > > > > > use IRQ. With this, vring_interrupt() can return check and early if
> > > > > > > > > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used
> > > > > > > > > > > > but the cost should be acceptable.
> > > > > > > > > > > Maybe it should be but is it? Can't we use synchronize_irq instead?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Even if we allow the transport driver to synchornize through
> > > > > > > > > > synchronize_irq() we still need a check in the vring_interrupt().
> > > > > > > > > >
> > > > > > > > > > We do something like the following previously:
> > > > > > > > > >
> > > > > > > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled))
> > > > > > > > > > return IRQ_NONE;
> > > > > > > > > >
> > > > > > > > > > But it looks like a bug since speculative read can be done before the check
> > > > > > > > > > where the interrupt handler can't see the uncommitted setup which is done by
> > > > > > > > > > the driver.
> > > > > > > > >
> > > > > > > > > I don't think so - if you sync after setting the value then
> > > > > > > > > you are guaranteed that any handler running afterwards
> > > > > > > > > will see the new value.
> > > > > > > >
> > > > > > > > The problem is not disabled but the enable.
> > > > > > >
> > > > > > > So a misbehaving device can lose interrupts? That's not a problem at all
> > > > > > > imo.
> > > > > >
> > > > > > It's the interrupt raised before setting irq_soft_enabled to true:
> > > > > >
> > > > > > CPU 0 probe) driver specific setup (not commited)
> > > > > > CPU 1 IRQ handler) read the uninitialized variable
> > > > > > CPU 0 probe) set irq_soft_enabled to true
> > > > > > CPU 1 IRQ handler) read irq_soft_enable as true
> > > > > > CPU 1 IRQ handler) use the uninitialized variable
> > > > > >
> > > > > > Thanks
> > > > >
> > > > > Yea, it hurts if you do it. So do not do it then ;).
> > > > >
> > > > > irq_soft_enabled (I think driver_ok or status is a better name)
> > > >
> > > > I can change it to driver_ok.
> > > >
> > > > > should be initialized to false *before* irq is requested.
> > > > >
> > > > > And requesting irq commits all memory otherwise all drivers would be
> > > > > broken,
> > > >
> > > > So I think we might talk different issues:
> > > >
> > > > 1) Whether request_irq() commits the previous setups, I think the
> > > > answer is yes, since the spin_unlock of desc->lock (release) can
> > > > guarantee this though there seems no documentation around
> > > > request_irq() to say this.
> > > >
> > > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is
> > > > using smp_wmb() before the request_irq().
> > > >
> > > > And even if write is ordered we still need read to be ordered to be
> > > > paired with that.
>
> IMO it synchronizes with the CPU to which irq is
> delivered. Otherwise basically all drivers would be broken,
> wouldn't they be?
I guess it's because most of the drivers don't care much about the
buggy/malicious device. And most of the devices may require an extra
step to enable device IRQ after request_irq(). Or it's the charge of
the driver to do the synchronization.
> I don't know whether it's correct on all platforms, but if not
> we need to fix request_irq.
>
> > > >
> > > > > if it doesn't it just needs to be fixed, not worked around in
> > > > > virtio.
> > > >
> > > > 2) virtio drivers might do a lot of setups between request_irq() and
> > > > virtio_device_ready():
> > > >
> > > > request_irq()
> > > > driver specific setups
> > > > virtio_device_ready()
> > > >
> > > > CPU 0 probe) request_irq()
> > > > CPU 1 IRQ handler) read the uninitialized variable
> > > > CPU 0 probe) driver specific setups
> > > > CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups
> > > > CPU 1 IRQ handler) read irq_soft_enable as true
> > > > CPU 1 IRQ handler) use the uninitialized variable
> > > >
> > > > Thanks
> > >
> > >
> > > As I said, virtio_device_ready needs to do synchronize_irq.
> > > That will guarantee all setup is visible to the specific IRQ,
> >
> > Only the interrupt after synchronize_irq() returns.
>
> Anything else is a buggy device though.
Yes, but the goal of this patch is to prevent the possible attack from
buggy(malicious) devices.
>
> > >this
> > > is what it's point is.
> >
> > What happens if an interrupt is raised in the middle like:
> >
> > smp_store_release(dev->irq_soft_enabled, true)
> > IRQ handler
> > synchornize_irq()
> >
> > If we don't enforce a reading order, the IRQ handler may still see the
> > uninitialized variable.
> >
> > Thanks
>
> IMHO variables should be initialized before request_irq
> to a value meaning "not a valid interrupt".
> Specifically driver_ok = false.
> Handler in the scenario you describe will then see !driver_ok
> and exit immediately.
So just to make sure we're on the same page.
1) virtio_reset_device() will set the driver_ok to false;
2) virtio_device_ready() will set the driver_ok to true
So for virtio drivers, it often did:
1) virtio_reset_device()
2) find_vqs() which will call request_irq()
3) other driver specific setups
4) virtio_device_ready()
In virtio_device_ready(), the patch perform the following currently:
smp_store_release(driver_ok, true);
set_status(DRIVER_OK);
Per your suggestion, to add synchronize_irq() after
smp_store_release() so we had
smp_store_release(driver_ok, true);
synchornize_irq()
set_status(DRIVER_OK)
Suppose there's a interrupt raised before the synchronize_irq(), if we do:
if (READ_ONCE(driver_ok)) {
vq->callback()
}
It will see the driver_ok as true but how can we make sure
vq->callback sees the driver specific setups (3) above?
And an example is virtio_scsi():
virtio_reset_device()
virtscsi_probe()
virtscsi_init()
virtio_find_vqs()
...
virtscsi_init_vq(&vscsi->event_vq, vqs[1])
....
virtio_device_ready()
In virtscsi_event_done():
virtscsi_event_done():
virtscsi_vq_done(vscsi, &vscsi->event_vq, ...);
We need to make sure the even_done reads driver_ok before read vscsi->event_vq.
Thanks
>
>
> > >
> > >
> > > > >
> > > > >
> > > > > > >
> > > > > > > > We use smp_store_relase()
> > > > > > > > to make sure the driver commits the setup before enabling the irq. It
> > > > > > > > means the read needs to be ordered as well in vring_interrupt().
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt
> > > > > > > > > which surprises me.
> > > > > > > > >
> > > > > > > > > CC Paul to help make sure I'm right.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a
> > > > > > > > > > > > module parameter is introduced to enable the hardening so function
> > > > > > > > > > > > hardening is disabled by default.
> > > > > > > > > > > Which devices are these? How come they send an interrupt before there
> > > > > > > > > > > are any buffers in any queues?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I copied this from the commit log for 22b7050a024d7
> > > > > > > > > >
> > > > > > > > > > "
> > > > > > > > > >
> > > > > > > > > > This change will also benefit old hypervisors (before 2009)
> > > > > > > > > > that send interrupts without checking DRIVER_OK: previously,
> > > > > > > > > > the callback could race with driver-specific initialization.
> > > > > > > > > > "
> > > > > > > > > >
> > > > > > > > > > If this is only for config interrupt, I can remove the above log.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > This is only for config interrupt.
> > > > > > > >
> > > > > > > > Ok.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the
> > > > > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7
> > > > > > > > > > > > ("virtio: defer config changed notifications"). But the method that is
> > > > > > > > > > > > used by config interrupt can't be reused by the vring interrupt
> > > > > > > > > > > > handler because it uses spinlock to do the synchronization which is
> > > > > > > > > > > > expensive.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > > > > > > > > > >
> > > > > > > > > > > > ---
> > > > > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++
> > > > > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++-
> > > > > > > > > > > > include/linux/virtio.h | 4 ++++
> > > > > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++
> > > > > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> > > > > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644
> > > > > > > > > > > > --- a/drivers/virtio/virtio.c
> > > > > > > > > > > > +++ b/drivers/virtio/virtio.c
> > > > > > > > > > > > @@ -7,6 +7,12 @@
> > > > > > > > > > > > #include <linux/of.h>
> > > > > > > > > > > > #include <uapi/linux/virtio_ids.h>
> > > > > > > > > > > > +static bool irq_hardening = false;
> > > > > > > > > > > > +
> > > > > > > > > > > > +module_param(irq_hardening, bool, 0444);
> > > > > > > > > > > > +MODULE_PARM_DESC(irq_hardening,
> > > > > > > > > > > > + "Disalbe IRQ software processing when it is not expected");
> > > > > > > > > > > > +
> > > > > > > > > > > > /* Unique numbering for virtio devices. */
> > > > > > > > > > > > static DEFINE_IDA(virtio_index_ida);
> > > > > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev)
> > > > > > > > > > > > * */
> > > > > > > > > > > > void virtio_reset_device(struct virtio_device *dev)
> > > > > > > > > > > > {
> > > > > > > > > > > > + /*
> > > > > > > > > > > > + * The below synchronize_rcu() guarantees that any
> > > > > > > > > > > > + * interrupt for this line arriving after
> > > > > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see
> > > > > > > > > > > > + * irq_soft_enabled == false.
> > > > > > > > > > > News to me I did not know synchronize_rcu has anything to do
> > > > > > > > > > > with interrupts. Did not you intend to use synchronize_irq?
> > > > > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier
> > > > > > > > > > > though it's most likely is ...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu():
> > > > > > > > > >
> > > > > > > > > > """
> > > > > > > > > >
> > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock()
> > > > > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in
> > > > > > > > > > * v5.0 and later, regions of code across which interrupts, preemption,
> > > > > > > > > > * or softirqs have been disabled also serve as RCU read-side critical
> > > > > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers,
> > > > > > > > > > * and NMI handlers.
> > > > > > > > > > """
> > > > > > > > > >
> > > > > > > > > > So interrupt handlers are treated as read-side critical sections.
> > > > > > > > > >
> > > > > > > > > > And it has the comment for explain the barrier:
> > > > > > > > > >
> > > > > > > > > > """
> > > > > > > > > >
> > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees.
> > > > > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns,
> > > > > > > > > > * each CPU is guaranteed to have executed a full memory barrier since
> > > > > > > > > > * the end of its last RCU read-side critical section whose beginning
> > > > > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having
> > > > > > > > > > """
> > > > > > > > > >
> > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the
> > > > > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the
> > > > > > > > > > irq_soft_enabled as false.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > You are right. So then
> > > > > > > > > 1. I do not think we need load_acquire - why is it needed? Just
> > > > > > > > > READ_ONCE should do.
> > > > > > > >
> > > > > > > > See above.
> > > > > > > >
> > > > > > > > > 2. isn't synchronize_irq also doing the same thing?
> > > > > > > >
> > > > > > > >
> > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific.
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > + */
> > > > > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false);
> > > > > > > > > > > > + synchronize_rcu();
> > > > > > > > > > > > +
> > > > > > > > > > > > dev->config->reset(dev);
> > > > > > > > > > > > }
> > > > > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device);
> > > > > > > > > > > Please add comment explaining where it will be enabled.
> > > > > > > > > > > Also, we *really* don't need to synch if it was already disabled,
> > > > > > > > > > > let's not add useless overhead to the boot sequence.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Ok.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev)
> > > > > > > > > > > > spin_lock_init(&dev->config_lock);
> > > > > > > > > > > > dev->config_enabled = false;
> > > > > > > > > > > > dev->config_change_pending = false;
> > > > > > > > > > > > + dev->irq_soft_check = irq_hardening;
> > > > > > > > > > > > +
> > > > > > > > > > > > + if (dev->irq_soft_check)
> > > > > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n");
> > > > > > > > > > > > /* We always start by resetting the device, in case a previous
> > > > > > > > > > > > * driver messed it up. This also tests that code path a little. */
> > > > > > > > > > > one of the points of hardening is it's also helpful for buggy
> > > > > > > > > > > devices. this flag defeats the purpose.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Do you mean:
> > > > > > > > > >
> > > > > > > > > > 1) we need something like config_enable? This seems not easy to be
> > > > > > > > > > implemented without obvious overhead, mainly the synchronize with the
> > > > > > > > > > interrupt handlers
> > > > > > > > >
> > > > > > > > > But synchronize is only on tear-down path. That is not critical for any
> > > > > > > > > users at the moment, even less than probe.
> > > > > > > >
> > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt()
> > > > > > > > in the virtio_device_ready() and synchronize the IRQ handlers with
> > > > > > > > spinlock or others.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk
> > > > > > > > > > for old hypervisors
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK.
> > > > > > > >
> > > > > > > > Probably not, we have devices that accept random inputs from outside,
> > > > > > > > net, console, input etc. I've done a round of audits of the Qemu
> > > > > > > > codes. They look all fine since day0.
> > > > > > > >
> > > > > > > > > So with this approach, how about we rename the flag "driver_ok"?
> > > > > > > > > And then add_buf can actually test it and BUG_ON if not there (at least
> > > > > > > > > in the debug build).
> > > > > > > >
> > > > > > > > This looks like a hardening of the driver in the core instead of the
> > > > > > > > device. I think it can be done but in a separate series.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > And going down from there, how about we cache status in the
> > > > > > > > > device? Then we don't need to keep re-reading it every time,
> > > > > > > > > speeding boot up a tiny bit.
> > > > > > > >
> > > > > > > > I don't fully understand here, actually spec requires status to be
> > > > > > > > read back for validation in many cases.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > > > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644
> > > > > > > > > > > > --- a/drivers/virtio/virtio_ring.c
> > > > > > > > > > > > +++ b/drivers/virtio/virtio_ring.c
> > > > > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq)
> > > > > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq);
> > > > > > > > > > > > }
> > > > > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq)
> > > > > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v)
> > > > > > > > > > > > {
> > > > > > > > > > > > + struct virtqueue *_vq = v;
> > > > > > > > > > > > + struct virtio_device *vdev = _vq->vdev;
> > > > > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq);
> > > > > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) {
> > > > > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK");
> > > > > > > > > > > > + return IRQ_NONE;
> > > > > > > > > > > > + }
> > > > > > > > > > > > +
> > > > > > > > > > > > if (!more_used(vq)) {
> > > > > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq);
> > > > > > > > > > > > return IRQ_NONE;
> > > > > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> > > > > > > > > > > > index 5464f398912a..957d6ad604ac 100644
> > > > > > > > > > > > --- a/include/linux/virtio.h
> > > > > > > > > > > > +++ b/include/linux/virtio.h
> > > > > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq);
> > > > > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore)
> > > > > > > > > > > > * @config_enabled: configuration change reporting enabled
> > > > > > > > > > > > * @config_change_pending: configuration change reported while disabled
> > > > > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled
> > > > > > > > > > > > + * @irq_soft_enabled: callbacks enabled
> > > > > > > > > > > > * @config_lock: protects configuration change reporting
> > > > > > > > > > > > * @dev: underlying device.
> > > > > > > > > > > > * @id: the device type identification (used to match it with a driver).
> > > > > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device {
> > > > > > > > > > > > bool failed;
> > > > > > > > > > > > bool config_enabled;
> > > > > > > > > > > > bool config_change_pending;
> > > > > > > > > > > > + bool irq_soft_check;
> > > > > > > > > > > > + bool irq_soft_enabled;
> > > > > > > > > > > > spinlock_t config_lock;
> > > > > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */
> > > > > > > > > > > > struct device dev;
> > > > > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
> > > > > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644
> > > > > > > > > > > > --- a/include/linux/virtio_config.h
> > > > > > > > > > > > +++ b/include/linux/virtio_config.h
> > > > > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev,
> > > > > > > > > > > > return __virtio_test_bit(vdev, fbit);
> > > > > > > > > > > > }
> > > > > > > > > > > > +/*
> > > > > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks
> > > > > > > > > > > > + * @vdev: the device
> > > > > > > > > > > > + */
> > > > > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev)
> > > > > > > > > > > > +{
> > > > > > > > > > > > + if (!vdev->irq_soft_check)
> > > > > > > > > > > > + return true;
> > > > > > > > > > > > +
> > > > > > > > > > > > + /*
> > > > > > > > > > > > + * Read irq_soft_enabled before reading other device specific
> > > > > > > > > > > > + * data. Paried with smp_store_relase() in
> > > > > > > > > > > paired
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Will fix.
> > > > > > > > > >
> > > > > > > > > > Thanks
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in
> > > > > > > > > > > > + * virtio_reset_device().
> > > > > > > > > > > > + */
> > > > > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled);
> > > > > > > > > > > > +}
> > > > > > > > > > > > +
> > > > > > > > > > > > /**
> > > > > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk
> > > > > > > > > > > > * @vdev: the device
> > > > > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev)
> > > > > > > > > > > > if (dev->config->enable_cbs)
> > > > > > > > > > > > dev->config->enable_cbs(dev);
> > > > > > > > > > > > + /*
> > > > > > > > > > > > + * Commit the driver setup before enabling the virtqueue
> > > > > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in
> > > > > > > > > > > > + * virtio_irq_soft_enabled()
> > > > > > > > > > > > + */
> > > > > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true);
> > > > > > > > > > > > +
> > > > > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK);
> > > > > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK);
> > > > > > > > > > > > }
> > > > > > > > > > > > --
> > > > > > > > > > > > 2.25.1
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>
next prev parent reply other threads:[~2022-03-29 7:12 UTC|newest]
Thread overview: 415+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 6:30 Michael S. Tsirkin
2022-03-25 7:52 ` Jason Wang
2022-03-25 9:10 ` Re: Michael S. Tsirkin
2022-03-25 9:20 ` Re: Jason Wang
2022-03-25 10:09 ` Re: Michael S. Tsirkin
2022-03-28 4:56 ` Re: Jason Wang
2022-03-28 5:59 ` Re: Michael S. Tsirkin
2022-03-28 6:18 ` Re: Jason Wang
2022-03-28 10:40 ` Re: Michael S. Tsirkin
2022-03-29 7:12 ` Jason Wang [this message]
2022-03-29 14:08 ` Re: Michael S. Tsirkin
2022-03-30 2:40 ` Re: Jason Wang
2022-03-30 5:14 ` Re: Michael S. Tsirkin
2022-03-30 5:53 ` Re: Jason Wang
2022-03-29 8:35 ` Re: Thomas Gleixner
2022-03-29 14:37 ` Re: Michael S. Tsirkin
2022-03-29 18:13 ` Re: Thomas Gleixner
2022-03-29 22:04 ` Re: Michael S. Tsirkin
2022-03-30 2:38 ` Re: Jason Wang
2022-03-30 5:09 ` Re: Michael S. Tsirkin
2022-03-30 5:53 ` Re: Jason Wang
2022-04-12 6:55 ` Re: Michael S. Tsirkin
-- strict thread matches above, loose matches on Subject: below --
2024-03-07 6:07 KR Kim
2024-03-07 8:01 ` Miquel Raynal
2024-03-08 1:27 ` Re: Kyeongrho.Kim
[not found] ` <SE2P216MB210205B301549661575720CC833A2@SE2P216MB2102.KORP216.PROD.OUTLOOK.COM>
2024-03-29 4:41 ` Re: Kyeongrho.Kim
2023-11-27 13:37 [PATCH 2/3] net: microchip_t1s: add support for LAN867x Rev.C1 Andrew Lunn
2023-12-05 10:20 ` Félix Piédallu
2023-12-06 20:58 ` Ramón Nordin Rodriguez
2023-11-11 4:21 Andrew Worsley
2023-11-11 8:22 ` Javier Martinez Canillas
[not found] <DB3PR10MB6835AF75D60D9A96465F35C2E8AAA@DB3PR10MB6835.EURPRD10.PROD.OUTLOOK.COM>
2023-11-06 12:55 ` Re: syzbot
2023-10-18 18:50 PIC probing code from e179f6914152 failing Mario Limonciello
2023-10-18 22:50 ` Thomas Gleixner
2023-10-19 21:20 ` Mario Limonciello
2023-10-23 15:59 ` Thomas Gleixner
2023-10-25 9:23 ` Thomas Gleixner
2023-10-25 14:41 ` Mario Limonciello
2023-10-25 15:25 ` David Lazar
2023-10-25 17:31 ` Thomas Gleixner
2023-10-25 21:04 ` [PATCH] x86/i8259: Skip probing when ACPI/MADT advertises PCAT compatibility, Thomas Gleixner
2023-10-25 22:11 ` Mario Limonciello
2023-10-26 9:27 ` Re: Thomas Gleixner
[not found] <64b09dbb.630a0220.e80b9.e2ed@mx.google.com>
2023-07-14 8:05 ` Re: Andy Shevchenko
2023-05-11 12:58 Ryan Roberts
2023-05-11 13:13 ` Ryan Roberts
2023-03-12 6:52 [PATCH v2] uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2 Greg Kroah-Hartman
2023-03-27 13:54 ` Yaroslav Furman
2023-03-27 14:19 ` Greg Kroah-Hartman
2023-01-18 20:59 [PATCH v5 0/5] CXL Poison List Retrieval & Tracing alison.schofield
2023-01-27 1:59 ` Dan Williams
2023-01-27 16:10 ` Alison Schofield
2023-01-27 19:16 ` Re: Dan Williams
2023-01-27 21:36 ` Re: Alison Schofield
2023-01-27 22:04 ` Re: Dan Williams
2022-11-21 11:11 Denis Arefev
2022-11-21 14:28 ` Jason Yan
2022-09-14 13:12 Amjad Ouled-Ameur
2022-09-14 13:18 ` Amjad Ouled-Ameur
2022-05-15 20:36 [PATCH bpf-next 1/2] cpuidle/rcu: Making arch_cpu_idle and rcu_idle_exit noinstr Jiri Olsa
2023-05-20 9:47 ` Ze Gao
2023-05-21 3:58 ` Yonghong Song
2023-05-21 15:10 ` Re: Ze Gao
2023-05-21 20:26 ` Re: Jiri Olsa
2023-05-22 1:36 ` Re: Masami Hiramatsu
2023-05-22 2:07 ` Re: Ze Gao
2023-05-23 4:38 ` Re: Yonghong Song
2023-05-23 5:30 ` Re: Masami Hiramatsu
2023-05-23 6:59 ` Re: Paul E. McKenney
2023-05-25 0:13 ` Re: Masami Hiramatsu
2023-05-21 8:08 ` Re: Jiri Olsa
2023-05-21 10:09 ` Re: Masami Hiramatsu
2023-05-21 14:19 ` Re: Ze Gao
[not found] <CANiq72k+5Rdj7i3Df2dcE6_OPYPXK3z5EWLKnY56sSMz4G3OvA@mail.gmail.com>
[not found] ` <CAABZP2z64aYWfVSdXHaQopWc+BAbJJUGqtrju2iWER3DDTDFWg@mail.gmail.com>
[not found] ` <20220406170012.GO4285@paulmck-ThinkPad-P17-Gen-1>
[not found] ` <87pmls6nt7.fsf@mpe.ellerman.id.au>
[not found] ` <87k0bz7i1s.fsf@mpe.ellerman.id.au>
2022-04-13 5:11 ` Nicholas Piggin
2022-04-22 15:53 ` Thomas Gleixner
2022-04-23 2:29 ` Re: Nicholas Piggin
2022-04-21 16:41 Yury Norov
2022-04-21 23:04 ` John Hubbard
2022-04-21 23:09 ` Re: John Hubbard
2022-04-21 23:17 ` Re: Yury Norov
2022-04-21 23:21 ` Re: John Hubbard
2022-01-20 15:28 Myrtle Shah
2022-01-20 15:37 ` Vitaly Wool
2022-01-20 23:29 ` Re: Damien Le Moal
2022-02-04 21:45 ` Re: Palmer Dabbelt
[not found] <20211126221034.21331-1-lukasz.bartosik@semihalf.com--annotate>
2021-11-29 21:59 ` Re: sean.wang
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
2021-11-02 9:49 ` [PATCH v5 05/11] clk: Introduce clk-tps68470 driver Hans de Goede
[not found] ` <163588780885.2993099.2088131017920983969@swboyd.mtv.corp.google.com>
2021-11-25 15:01 ` Hans de Goede
[not found] <CAP7CzPcLhtXDyLudfmR2pWR5fzSQ_jhJSoRheH=cytoDnb_ujg@mail.gmail.com>
2021-09-14 15:37 ` Re: Nick Desaulniers
2021-08-12 9:21 Valdis Klētnieks
2021-08-12 9:42 ` SeongJae Park
2021-08-12 20:19 ` Re: Andrew Morton
2021-08-13 8:14 ` Re: SeongJae Park
2021-07-27 2:59 [PATCH v9] iomap: Support file tail packing Gao Xiang
2021-07-27 15:10 ` Darrick J. Wong
2021-07-27 15:23 ` Andreas Grünbacher
2021-07-27 15:30 ` Re: Gao Xiang
2021-06-06 19:19 Davidlohr Bueso
2021-06-07 16:02 ` André Almeida
2021-04-05 0:01 Mitali Borkar
2021-04-06 7:03 ` Arnd Bergmann
[not found] <CAPncsNOFoUt7uEDEdihDTZY4pJsuPxt146W-L+Ju53SgZ6ezYw@mail.gmail.com>
[not found] ` <CAPncsNMWCim1kozMyJaT7_suEnWyGadf1Kg1fzjyWfdGDVMZ3A@mail.gmail.com>
[not found] ` <CAPncsNOpMhn=N+9+uC8hx0shRE-5uhvHCmZKJ8X3=aAeja1sag@mail.gmail.com>
2021-03-18 6:51 ` Re: Jarvis Jiang
2021-01-19 0:10 David Howells
2021-01-20 14:46 ` Jarkko Sakkinen
[not found] <CAGMNF6W8baS_zLYL8DwVsbfPWTP2ohzRB7xutW0X=MUzv93pbA@mail.gmail.com>
2020-12-02 17:09 ` Re: Kun Yi
2020-12-02 1:10 [PATCH] lib/find_bit: Add find_prev_*_bit functions Yun Levi
2020-12-02 9:47 ` Andy Shevchenko
2020-12-02 10:04 ` Rasmus Villemoes
2020-12-02 11:50 ` Yun Levi
[not found] ` <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com>
2020-12-02 18:22 ` Yun Levi
2020-12-02 21:26 ` Yury Norov
2020-12-02 22:51 ` Yun Levi
2020-12-03 1:23 ` Yun Levi
2020-12-03 8:33 ` Rasmus Villemoes
2020-12-03 9:47 ` Re: Yun Levi
2020-12-03 18:46 ` Re: Yury Norov
2020-12-03 18:52 ` Re: Willy Tarreau
2020-12-04 1:36 ` Re: Yun Levi
2020-12-04 18:14 ` Re: Yury Norov
2020-12-05 0:45 ` Re: Yun Levi
2020-12-05 11:10 ` Re: Rasmus Villemoes
2020-12-05 18:20 ` Re: Yury Norov
2020-08-05 11:02 [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) Amit Pundir
2020-08-06 22:31 ` Konrad Dybcio
2020-08-12 13:37 ` Amit Pundir
2020-06-30 17:56 Vasiliy Kupriakov
2020-07-10 20:36 ` Andy Shevchenko
2020-05-06 5:52 Jiaxun Yang
2020-05-06 17:17 ` Nick Desaulniers
[not found] <5e7dc543.vYG3wru8B/me1sOV%chenanqing@oppo.com>
2020-03-27 15:53 ` Re: Lee Duncan
[not found] <5e7dbb10.ulraq/ljeOm297+z%chenanqing@oppo.com>
2020-03-27 8:59 ` Re: Ilya Dryomov
2020-03-03 15:27 Gene Chen
2020-03-04 14:56 ` Matthias Brugger
2020-03-04 15:15 ` Re: Lee Jones
2020-03-04 18:00 ` Re: Matthias Brugger
2020-02-11 22:34 Rajat Jain
2020-02-12 9:30 ` Jarkko Nikula
2020-02-12 10:24 ` Re: Andy Shevchenko
[not found] <f618ed4d-05ce-75cd-8cd9-24d8fe5a2551@samsung.com>
[not found] ` <CGME20191105044921epcas1p2869157cceaf45351adf9dd2e59161db7@epcas1p2.samsung.com>
2019-11-05 4:54 ` Re: Chanwoo Choi
2019-10-27 21:36 Re: Margaret Kwan Wing Han
2019-09-24 19:49 Venkat Subbiah
[not found] <CAK8P3a16=ktJm5B3c5-XS7SqVuHBY5+E2FwVUqbdOdWK-AUgSA@mail.gmail.com>
[not found] ` <20190830202959.3539-1-msuchanek@suse.de>
2019-08-30 20:32 ` Arnd Bergmann
[not found] <E1hUrZM-0007qA-Q8@sslproxy01.your-server.de>
2019-05-29 19:54 ` Re: Alex Williamson
2019-05-21 0:06 [PATCH v6 0/3] add new ima hook ima_kexec_cmdline to measure kexec boot cmdline args Prakhar Srivastava
2019-05-21 0:06 ` [PATCH v6 2/3] add a new ima template field buf Prakhar Srivastava
2019-05-24 15:12 ` Mimi Zohar
2019-05-24 15:42 ` Roberto Sassu
2019-05-24 15:47 ` Re: Roberto Sassu
2019-05-24 18:09 ` Re: Mimi Zohar
2019-05-24 19:00 ` Re: prakhar srivastava
2019-05-24 19:15 ` Re: Mimi Zohar
2019-04-12 23:06 RE, Sharifah Ahmad Mustahfa
[not found] <20190319144116.400-1-mlevitsk@redhat.com>
2019-03-20 11:03 ` Felipe Franciosi
2019-03-20 19:08 ` Re: Maxim Levitsky
2019-03-21 16:12 ` Re: Stefan Hajnoczi
2019-03-21 16:21 ` Re: Keith Busch
2019-03-21 16:41 ` Re: Felipe Franciosi
2019-03-21 17:04 ` Re: Maxim Levitsky
2019-03-22 7:54 ` Re: Felipe Franciosi
2019-03-22 10:32 ` Re: Maxim Levitsky
2019-03-22 15:30 ` Re: Keith Busch
2019-03-25 15:44 ` Re: Felipe Franciosi
2019-03-13 23:49 RE, LUIS EDUARDO CEPEDA CABRERA
2019-01-07 17:28 [PATCH] arch/arm/mm: Remove duplicate header Souptick Joarder
2019-01-17 11:23 ` Souptick Joarder
2019-01-17 11:28 ` Mike Rapoport
2019-01-31 5:54 ` Souptick Joarder
2019-01-31 12:58 ` Vladimir Murzin
2019-02-01 12:32 ` Re: Souptick Joarder
2019-02-01 12:36 ` Re: Vladimir Murzin
2019-02-01 12:41 ` Re: Souptick Joarder
2019-02-01 13:02 ` Re: Vladimir Murzin
2019-02-01 15:15 ` Re: Russell King - ARM Linux admin
2019-02-01 15:22 ` Re: Russell King - ARM Linux admin
[not found] <CAMkWEXP4Mm5x9rdrKn9xRNVm7vxqoL62ftxb+UcJFAiJ+U9X3A@mail.gmail.com>
2018-10-22 0:26 ` Re: Dave Airlie
2018-10-21 20:23 ` Re: Michael Tirado
2018-10-22 1:50 ` Re: Dave Airlie
2018-10-21 22:20 ` Re: Michael Tirado
2018-10-23 1:47 ` Re: Michael Tirado
2018-10-23 6:23 ` Re: Dave Airlie
[not found] <1530911788-7033-1-git-send-email-santosh.shilimkar@oracle.com>
[not found] ` <1530911788-7033-3-git-send-email-santosh.shilimkar@oracle.com>
2018-07-06 21:18 ` Re: Santosh Shilimkar
2018-01-11 17:16 Fabian Huegel
2018-01-11 17:25 ` Ben Evans
2017-11-13 14:55 Re: Amos Kalonzo
2017-09-07 8:50 Re: Quick Loan
2017-08-18 19:47 Re: Jessy
2017-07-31 23:46 TD CREDIT
2017-07-15 3:29 Saif Al-Islam
2017-07-07 17:04 Mrs Alice Walton
2017-05-28 13:39 RE: Lasek László
2017-05-03 6:23 H.A
2017-04-28 8:20 Anatolij Gustschin
2017-04-28 8:43 ` Linus Walleij
2017-04-28 9:26 ` Re: Anatolij Gustschin
2017-02-23 15:09 Qin's Yanjun
2017-01-07 14:47 Information
2016-11-15 4:40 Apply
2016-11-08 13:46 vaserman
2016-11-02 2:36 U
2016-07-21 21:50 Amit Jain
2016-07-04 15:47 Re: Mr. Bun Sam
2016-07-02 11:30 Re: Mr. Bun Sam
2016-06-27 8:24 Re: Fidelity Loans
2016-02-10 14:36 Petr Mladek
2016-02-10 14:44 ` Steven Rostedt
2016-02-08 3:11 Qatar Foundation
2016-01-26 20:52 Ms Nadia Mohammed
2016-01-15 2:39 Re: Trust Guarantee
2015-12-18 11:50 Re:
2015-12-11 9:30 Re: Матвеева Руслана
[not found] <D0613EBE33E8FD439137DAA95CCF59555B7A5A4D@MGCCCMAIL2010-5.mgccc.cc.ms.us>
2015-11-24 13:21 ` Amis, Ryann
[not found] <CA+47Ykimr0d9cR35aWoCtm8JoXUYjKFXL0HJ-c=EE_suTAPR8w@mail.gmail.com>
2015-11-07 17:33 ` bbmbbm1
2015-11-07 16:48 Re: Mohammed
2015-10-29 2:40
2015-10-23 14:46 RE: MajorAlan
2015-10-21 2:26 Mohammed
2015-10-08 8:30 Re BRGF
2015-09-01 16:06 Zariya
2015-09-01 14:14 Mika Penttilä
2015-09-01 15:22 ` Fabio Estevam
2015-09-01 12:01 Re: Zariya
2015-08-19 13:01 Re: christain147
2015-07-24 10:34 Re: Mrs Nadia Mohammed
[not found] <CACy=+DtdZOUT4soNZ=zz+_qhCfM=C8Oa0D5gjRC7QM3nYi4oEw@mail.gmail.com>
2015-07-11 18:37 ` Re: Mustapha Abiola
[not found] <CAHxZcryF7pNoENh8vpo-uvcEo5HYA5XgkZFWrLEHM5Hhf5ay+Q@mail.gmail.com>
2015-07-05 16:38 ` Re: t0021
[not found] <E1Yz4NQ-0000Cw-B5@feisty.vs19.net>
2015-05-31 15:37 ` Re: Roman Volkov
2015-05-31 15:53 ` Re: Hans de Goede
2015-05-22 0:17 Re: kontakt
[not found] <90BA5B564A2E4B4782C6F4398C32EE104E54369A@NHS-PCLI-MBC003.AD1.NHS.NET>
2015-05-21 10:49 ` Ratnakumar Sagana (KING'S COLLEGE HOSPITAL NHS FOUNDATION TRUST)
[not found] <9E5F73AAFC185F49B0D37FE62E65D6C20724A9D8@XSERVER23A.campus.tue.nl>
2015-05-10 13:03 ` RE: Singer, W.P.
2015-04-21 7:43 Galaxy Darlehen Firma
[not found] <CAONCqDfSP9DSWwPSDqz4NS6YHmzwMo=6VnRURRAJZLeGE_QKYA@mail.gmail.com>
2015-04-07 18:47 ` Re: Wilson Aggard
2015-04-01 21:56 Re: Globale Trust Company
2015-03-04 10:29 Quentin Lambert
2015-03-04 10:32 ` Quentin Lambert
2014-12-18 18:08 Re: Peter Page
2014-12-01 13:02 Re: Quan Han
2014-11-14 20:49 Re: salim
2014-11-14 18:56 milke
[not found] <E1XgbTy-00072R-N3@feisty.vs19.net>
2014-10-21 15:48 ` Patrik Lundquist
[not found] <E1Xf0HT-0005ZQ-OP@feisty.vs19.net>
2014-10-17 5:49 ` Re: Hillf Danton
2014-10-13 6:18 Re: geohughes
[not found] <5633293EA8BBC640804038866F5D329F0B3A17@mail00.baptist.local>
2014-09-30 17:20 ` Sonya Wright
2014-09-20 19:45 Richard Wong
2014-09-16 14:54 Re: promocion_derechos.isna
[not found] <AB37FB01B00BF44E85C75F6CFEC35E7D47324643@LPPTCPMXMBX01.LPCH.NET>
2014-09-15 23:42 ` Mandic, Andrew
2014-09-16 0:44 ` RE: Mandic, Andrew
[not found] <6A286AB51AD8EC4180C4B2E9EF1D0A027AAD7EFF1E@exmb01.wrschool.net>
2014-09-08 16:58 ` RE: Deborah Mayher
2014-08-18 15:38 Mrs. Hajar Vaserman.
[not found] <E1XFOD5-00007y-8L@feisty.vs19.net>
2014-08-07 14:23 ` Re: Pranith Kumar
2014-07-29 7:17 Re: eye2eye
[not found] <blk-mq updates>
2014-04-14 8:30 ` Christoph Hellwig
2014-04-15 20:16 ` Jens Axboe
2014-03-10 3:04 Re: inforbonus
2014-03-10 3:01 Re: inforbonus
2014-01-11 2:11 Re: Mr. Jerry Natai
2013-12-30 10:43 st2
2013-12-30 9:06 RE: funds2
2013-12-20 11:49 RE: Unify Loan Company
2013-11-30 3:46 Bin Sumari
2013-11-07 12:09 Re: mypersonalmailbox1
2013-09-03 23:50 Matthew Garrett
2013-09-04 15:53 ` Kees Cook
2013-09-04 16:05 ` Re: Josh Boyer
2013-08-23 18:04 Andreas Werner
2013-08-23 21:10 ` Andy Lutomirski
[not found] <B719EF0A9FB7A247B5147CD67A83E60E011FEB76D1@EXCH10-MB3.paterson.k12.nj.us>
2013-08-23 10:47 ` Ruiz, Irma
2013-08-07 20:43 Western Union
2013-07-08 4:52 Re: Wesstern Union money Transfer
2013-06-28 10:14 Re: emirates
2013-06-28 10:12 Re: emirates
2013-06-20 12:28 tingwei liu
2013-06-20 12:51 ` Jiri Slaby
2013-06-24 1:43 ` Re: tingwei liu
2013-06-24 8:24 ` Re: Jiri Slaby
[not found] ` <CA+qZnSSPxO3h0v7An3R7e-HHs+bi4Ua-LE9coJtQL8CFWOHNBA@mail.gmail.com>
2013-06-27 5:12 ` Re: tingwei liu
2013-05-14 13:07 Re: info
2013-04-27 13:20 PRIVATE BUSINESS
2013-04-02 13:29 Mrs Akilah Saeedi
2013-03-26 2:26 Re: Mrs Akilah Saeedi
2013-02-04 0:47 Re: JUMBO PROMO
2013-01-27 21:59 Re: Congjun Yang
2013-01-13 19:58 Re: Michael A. Purwoadi
2012-11-21 14:04 roman
2012-11-21 14:50 ` Alan Cox
2012-10-30 9:19 Re: wumin_tsinghua
2012-10-06 23:15 David Howells
2012-10-07 6:36 ` Geert Uytterhoeven
2012-10-11 9:57 ` Re: Will Deacon
2012-09-04 14:40 [GIT PULL] sound fixes for 3.6-rc5 Takashi Iwai
2012-09-06 6:02 ` Markus Trippelsdorf
2012-09-06 6:33 ` Re: Daniel Mack
2012-09-06 6:45 ` Re: Markus Trippelsdorf
2012-09-06 6:48 ` Re: Takashi Iwai
2012-09-06 6:53 ` Re: Markus Trippelsdorf
2012-08-10 5:32 devendra.aaru
2012-08-10 8:45 ` Linus Walleij
2012-08-10 10:47 ` Re: Bernd Petrovitsch
2012-08-09 13:54 Fengguang Wu
2012-08-09 17:29 ` Mauro Carvalho Chehab
2012-08-06 16:59 anish kumar
2012-08-06 17:05 ` Maarten Lankhorst
2012-07-12 11:43 Re: macckone
2012-06-18 9:44 sakthiperumal karuthasamy
2012-06-18 11:52 `
2012-05-20 22:20 Re: Mr. Peter Wong
2011-12-13 3:49 Re: Ryan Black
2011-11-22 12:06 Re: Balbir Singh
2011-11-09 11:58 Re: pradeep Annavarapu
2011-11-08 1:58 linux-next: manual merge of the bluetooth tree with Linus tree Stephen Rothwell
2011-11-08 2:26 ` Wu Fengguang
2011-11-08 4:40 ` Stephen Rothwell
2011-10-28 16:03 Re: Young Chang
2011-10-28 15:55 Re: Young Chang
2011-10-26 20:51 Re: bfeely
2011-08-21 19:22 Re: jeffrice
2011-08-18 22:07 San Mehat
2011-08-18 22:08 ` San Mehat
2011-08-13 10:59 Mr. Kenneth Williams
2011-08-06 13:23 RE: John Coker
2011-07-22 0:32 Jason Baron
2011-07-22 0:57 ` Paul Turner
2011-05-23 9:11 Re: Young Chang
2011-05-18 15:57 Re: alex zaim
2011-05-06 18:52 Nat Gurumoorthy
2011-05-06 19:13 ` Guenter Roeck
2011-05-06 20:00 ` Re: Natarajan Gurumoorthy
2011-05-01 13:35 Re: lotto
2011-04-10 1:20 Re: Young Chang
2011-04-07 21:00 Re: Tim Peters
2011-02-23 9:18 Irish Online News Center
2011-02-01 16:39 young chang
2010-12-04 21:06 FreeLotto Online Promo
[not found] <3E0D78C2-CEAF-42C3-9840-20B01AA4EFC7@vsecurity.com>
2010-11-21 18:33 ` Dan J. Rosenberg
2010-11-22 17:02 ` Re: Vasiliy Kulikov
2010-10-14 11:47 Re : World Bank
2010-10-09 17:52 Mr.Young Chang
2010-07-20 0:22 Re: wins
2010-07-17 3:37 Re: SINOPEC OIL AND GAS COMPANY
2010-07-11 21:42 Western Union
2010-07-11 22:23 ` Noah McNallie
[not found] <7a07eea248913e9f.4c3919f6@access.k12.wv.us>
2010-07-11 0:49 ` Re: tkprice
2010-07-02 20:13 Re: ($10,500,000.00) Donation for Charitable Goals
2010-07-02 19:29 Re: ($10,500,000.00) Donation for Charitable Goals
2010-07-01 16:09 Re ! BRITISH COLUMBIA
2010-07-01 10:49 FUJITA Tomonori
2010-07-01 12:29 ` Jens Axboe
2010-06-14 20:26 [PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages Justin P. Mattock
2010-06-14 20:26 ` [PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used Justin P. Mattock
2010-06-14 21:44 ` [PATCH] ieee1394: sbp2: remove unused code Stefan Richter
2010-06-14 22:35 ` Justin P. Mattock
2010-06-14 23:22 ` Stefan Richter
2010-06-14 23:58 ` Justin P. Mattock
2010-06-13 6:16 Mike Gilks
2010-06-13 8:58 ` Tejun Heo
2010-06-08 4:27 FRL
2010-06-08 4:05 RE: FRL
2010-05-11 22:28 RE: Euro-Millions
[not found] <20100510223054.luv5qlqdlp28g08o@webmail.wcsd.k12.oh.us>
[not found] ` <20100510223506.77ylw39bns84c80c@webmail.wcsd.k12.oh.us>
[not found] ` <20100510223656.m8nzy8mwqf44g8g8@webmail.wcsd.k12.oh.us>
2010-05-11 4:19 ` Mr. Vincent Hong
2010-05-08 2:56 Promo
2010-05-08 0:01 IRISH NEWS CENTRE
2010-05-07 11:39 Re: William Wilcox
2010-05-07 11:37 Re: William Wilcox
2010-04-14 12:54 Alan Cox
2010-04-14 13:35 ` Jean Delvare
2010-04-02 23:17 RE; Mrs Claire page
2010-03-23 7:50 RE, FROM CENTRAL BANK
2010-03-11 16:40 Monica D.
2010-02-25 13:39 Re; William Wilcox
2010-01-16 1:54 Capt Chris P. Mark
2010-01-13 0:48 Jeff Mahoney
2010-01-13 8:24 ` David Woodhouse
2010-01-09 17:03 Ustin Gavrie
2009-12-19 17:38 OFFICE OF THE SENATE
2009-12-12 16:04 T Dent
2009-12-13 5:55 ` andrew hendry
2009-12-08 6:23 Irish News Center
2009-11-26 1:03 [PATCH 1/2] hw_random: core updates to allow more efficient drivers Matt Mackall
2009-11-26 10:49 ` Ian Molton
2009-11-26 11:38 ` Matt Mackall
2009-11-26 11:48 ` Re: Ian Molton
2009-11-27 22:54 ` Re: Matt Mackall
2009-11-20 13:29 Jerome Glisse
2009-12-01 23:53 ` Dave Airlie
2009-12-02 7:17 ` Re: Thomas Hellstrom
[not found] <cover.1257602781.git.andre.goddard@gmail.com>
[not found] ` <7206ef594e67a240a842339f520284de6569b1fc.1257602781.git.andre.goddard@gmail.com>
[not found] ` <31525.1257770343@redhat.com>
2009-11-09 15:31 ` Re: André Goddard Rosa
2009-11-05 3:24 Re: Irish News Centre
2009-11-01 17:00 Re: Irish News Centre
2009-10-10 19:13 Irish News Center
2009-09-26 15:22 RE: Irish News Center
2009-09-25 23:13 RE: Irish News Center
2009-06-20 19:45 Kay Sievers
2009-06-21 9:04 ` Takashi Iwai
2009-06-22 12:56 ` Re: David Woodhouse
2009-01-11 3:41 Jose Luis Marchetti
2009-01-11 5:44 ` Cooper Yuan
2008-11-30 11:23 Re: Frank
2008-10-11 7:30 Yudha Harimantoro T
2008-10-11 15:12 ` Bill Davidsen
2008-10-13 6:18 ` Re: Yudha Harimantoro T
2008-10-13 8:29 ` Re: Yudha Harimantoro T
2008-10-13 12:03 ` Re: Alan Jenkins
[not found] <0K6B0005EN54GNO0@l-daemon>
2008-08-29 0:14 ` Re: Robert Hancock
[not found] <alpine.LFD.1.10.0807271037190.3486@nehalem.linux-foundation.org>
2008-07-27 22:37 ` Trond Myklebust
2008-07-09 15:47 Mathieu Desnoyers
2008-07-09 16:07 ` Eduard - Gabriel Munteanu
2008-07-09 16:35 ` Re: Mathieu Desnoyers
2008-05-20 12:34 Lukas Hejtmanek
2008-05-20 12:40 ` Oliver Neukum
2008-04-09 8:45 Andreas Grimm
2008-04-10 1:14 ` Lee Revell
2008-02-03 11:13 am kara
2008-02-03 18:23 ` Benny Halevy
2007-11-10 1:18 Luck, Tony
2007-11-10 1:42 ` Eric Dumazet
2007-11-11 5:18 ` Re: David Miller
2007-08-14 23:04 [PATCH 0/24] make atomic_read() behave consistently across all architectures Chris Snook
2007-08-15 6:49 ` Herbert Xu
2007-08-15 8:18 ` Heiko Carstens
2007-08-15 13:53 ` Stefan Richter
2007-08-15 14:35 ` Satyam Sharma
2007-08-15 14:52 ` Herbert Xu
2007-08-15 16:09 ` Stefan Richter
2007-08-15 16:27 ` Paul E. McKenney
2007-08-15 18:31 ` Segher Boessenkool
2007-08-15 18:57 ` Paul E. McKenney
2007-08-15 19:54 ` Satyam Sharma
2007-08-15 20:47 ` Segher Boessenkool
2007-08-16 0:36 ` Satyam Sharma
2007-08-16 1:38 ` Segher Boessenkool
2007-08-07 16:34 Brian J. Murrell
2007-08-09 20:33 ` Mark Lord
2007-08-09 21:04 ` Re: Brian J. Murrell
[not found] <FC1D1B23302A22499C60C967336B2AE00186B15C@pdsmsx411.ccr.corp.intel.com>
2007-07-24 13:40 ` Re: Shaohua Li
2007-02-09 6:29 Priyanka Sharma
2007-02-10 2:41 ` hackmiester (Hunter Fuller)
2006-08-16 9:30 Re: shane
2006-05-16 10:34 Chris Boot
2006-05-16 12:34 ` Arnaldo Carvalho de Melo
2006-03-11 1:00 Re: Alec
2006-03-03 14:54 Re: Kennedy
2006-02-23 12:16 Re: Norberto
2006-02-18 16:04 Re: Donne
2006-02-04 14:33 Re: Ira Jackson
2006-01-27 10:05 sarat
2006-01-27 10:09 ` Arjan van de Ven
2005-12-31 0:27 system keeps freezing once every 24 hours / random apps crashing Alistair John Strachan
2005-12-31 0:42 ` Mark v Wolher
2005-12-31 0:51 ` Alistair John Strachan
2005-12-31 0:54 ` Mark v Wolher
2005-12-31 10:31 ` Mark v Wolher
2005-12-31 11:08 ` Jesper Juhl
2005-12-31 11:40 ` Mark v Wolher
2005-12-31 11:49 ` Jesper Juhl
2005-12-31 12:46 ` Mark v Wolher
2005-12-31 15:18 ` Mark v Wolher
2005-12-31 16:34 ` Sami Farin
2005-12-31 16:48 ` Mark v Wolher
2006-01-01 2:26 ` Mark v Wolher
2006-01-01 13:06 ` Mark v Wolher
2006-01-01 14:47 ` Mark v Wolher
2006-01-01 18:38 ` Jiri Slaby
2006-01-01 18:49 ` Mark v Wolher
2006-01-01 19:12 ` Jiri Slaby
2006-01-01 19:37 ` Mark v Wolher
2005-12-02 16:03 Yu, Luming
2005-12-02 16:46 ` Dmitry Torokhov
2005-12-02 20:11 ` Re: Miloslav Trmac
2005-11-09 16:13 Nestor Velazquez
2005-11-09 16:17 ` Alejandro Bonilla
2005-09-21 13:20 Robert.Boermans
2005-09-21 13:27 ` Denis Vlasenko
2005-06-28 9:18 d binderman
2005-06-28 11:03 ` Andrew Morton
2005-06-28 9:15 d binderman
2005-06-28 11:00 ` Andrew Morton
[not found] <360D47F92A8ACCH7@vger.kernel.org>
2005-05-30 2:49 ` Re: radej
2005-05-06 20:23 Edison Giovanny Mendoza
2005-05-06 20:32 ` Alejandro Bonilla
2005-03-25 7:03 Søren Lott
2005-03-25 7:18 ` Jeff Garzik
2005-03-20 5:24 Re: info
2005-03-08 16:32 Peter W. Morreale
2005-03-08 19:32 ` Ross Biro
2005-03-05 10:11 Raffaele Ianniello
2005-03-05 18:14 ` Randy.Dunlap
2005-02-26 14:57 Yong Haynes
2005-02-17 17:14 Deepti Patel
2005-02-17 17:46 ` Matthias-Christian Ott
2005-01-19 14:25 Gmail
2005-01-19 15:22 ` Paolo Ornati
2004-11-08 7:39 Marcelo Tosatti
2004-11-08 11:08 ` Paolo Ciarrocchi
2004-11-08 8:34 ` Re: Marcelo Tosatti
2004-11-08 22:08 ` Re: Guennadi Liakhovetski
2004-09-19 12:29 plt
[not found] ` <200409191508.33537.Norbert@edusupport.nl>
[not found] ` <1095607945.414da6891fc94@webmail.taylorassociate.com>
2004-09-19 16:31 ` Norbert van Nobelen
2004-06-27 14:18 Vinu Moses
2004-06-27 20:14 ` Vinu Moses
2004-03-17 22:03 Kendrick Logan
2004-03-07 20:08 Michael Frank
2004-03-07 20:26 ` John Bradford
2004-02-22 17:51 redzic fadil
2004-02-22 18:48 ` Larry Reaves
2004-02-14 23:17 Re: Alexandr Chernyy
[not found] <7A25937D23A1E64C8E93CB4A50509C2A0310F099@stca204a.bus.sc.rolm.com>
2004-02-05 17:02 ` Re: Tommy Reynolds
2003-12-11 23:37 Hettinger Tamas
2003-12-12 1:29 ` Jonathan Corbet
2003-12-05 17:36 gmack
2003-12-05 23:16 ` Oliver Hunt
2003-12-03 15:08 Bloch, Jack
2003-12-04 4:56 ` Raj
2003-09-10 2:20 John Yau
2003-09-10 2:31 ` Nick Piggin
2003-08-25 13:53 Marcelo Tosatti
2003-08-25 14:12 ` Nick Piggin
2003-08-12 13:55 Catalin BOIE
2003-08-12 17:05 ` Ian Hastie
2003-07-16 18:36 Sir Ace
2003-07-16 23:10 ` jiho
2003-06-30 3:16 usenet
2003-06-30 8:09 ` Bruce Harada
2003-06-30 8:23 ` Re: Matti Aarnio
2003-06-03 23:51 Justin T. Gibbs
2003-06-03 23:58 ` Marc-Christian Petersen
2003-04-30 21:39 Mauricio Oliveira Carneiro
2003-05-01 0:03 ` Eyal Lebedinsky
[not found] <001e01c2d9ef$01cdc970$0200a8c0@wsl3>
2003-02-21 21:34 ` Re: b_adlakha
2003-02-08 10:40 Re: Manfred Spraul
2003-01-12 13:28 Philip K.F. Hölzenspies
2003-01-12 17:57 ` Shawn Starr
2002-10-17 7:41 Rusty Russell
2002-10-17 14:49 ` Roman Zippel
2002-10-11 0:11 sridhar vaidyanathan
2002-10-11 0:21 ` Steven Dake
2002-09-29 10:11 Richard Cooper
2002-09-29 17:49 ` David Lloyd
2002-06-08 21:35 tushar korde
2002-08-21 16:30 ` Daniel Phillips
2002-05-31 8:04 Oliver Pitzeier
2002-05-31 14:37 ` Alan Cox
2002-04-18 11:23 Satish Mohan
2002-04-18 11:35 ` François Cami
2002-04-09 13:25 Kuppuswamy, Priyadarshini
2002-03-31 19:17 mpaa3d
2002-04-01 9:43 ` Vance Lankhaar
2002-02-20 17:55 Torrey Hoffman
2001-12-25 16:17 Manfred Spraul
2001-12-25 19:14 ` Re: Legacy Fishtank
2001-12-25 21:23 ` Re: Kurt Roeckx
2001-12-25 22:03 ` Re: Alan Cox
2002-01-03 0:06 ` Re: David S. Miller
2002-01-03 0:23 ` Re: Alan Cox
2001-12-05 16:05 Romain Giry
2001-12-05 21:25 ` Dipak
2001-12-06 10:43 ` Re: Romain Giry
2001-12-06 11:28 ` Re: Alan Cox
2001-10-15 6:25 Dinesh Gandhewar
2001-10-15 6:56 ` David Ford
2001-10-15 16:02 ` Re: Timur Tabi
2001-10-02 15:30 Dinesh Gandhewar
2001-10-09 10:25 ` VDA
2001-10-02 15:29 Dinesh Gandhewar
2001-10-02 15:23 ` Tommy Reynolds
2001-10-02 15:32 ` Re: Alex Bligh - linux-kernel
2001-08-16 12:18 Re: Saravana
2001-08-14 3:08 Re: Parag Warudkar
2001-08-14 3:17 ` Re: Keith Owens
2001-07-25 18:44 Sumit Bhardwaj
2001-07-25 19:18 ` Matthew M
2001-06-11 4:58 kiran.thirumalai
2001-06-11 6:54 ` Anil Kumar
2001-05-22 4:25 Rajiv Majumdar
2001-05-08 19:48 Richard B. Johnson
2001-05-08 21:33 ` george anzinger
2001-05-09 13:04 ` Re: Richard B. Johnson
2001-05-09 14:10 ` Re: Alan Cox
2001-05-09 16:59 ` Re: george anzinger
2001-05-09 17:15 ` Re: Alan Cox
2001-05-09 0:36 ` Re: Andrew Morton
2001-04-18 0:15 Vibol Hou
2001-04-18 0:26 ` Jaquemet Loic
2001-04-18 0:32 ` Re: Jeff Garzik
2001-04-20 2:47 ` Re: Francois Cami
2001-04-21 1:26 ` Re: Andrew Morton
2001-03-22 18:02 Re: Gunnar Ahlberg
2001-01-19 13:37 Robert Kaiser
2001-01-19 14:33 ` Michael Rothwell
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=CACGkMEtDybY_ZnQkkfuSkx8eMZKoMAe+pnEwyetuS2cmzRVFgw@mail.gmail.com \
--to=jasowang@redhat.com \
--cc=keirf@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mst@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=sgarzare@redhat.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.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;
as well as URLs for NNTP newsgroup(s).