[PATCH V3 2/2] vhost: handle polling errors

2013-01-05 Thread Jason Wang
Polling errors were ignored by vhost/vhost_net, this may lead to crash when
trying to remove vhost from waitqueue when after the polling is failed. Solve
this problem by:

- checking the poll->wqh before trying to remove from waitqueue
- report an error when poll() returns a POLLERR in vhost_start_poll()
- report an error when vhost_start_poll() fails in
  vhost_vring_ioctl()/vhost_net_set_backend() which is used to notify the
  failure to userspace.
- report an error in the data path in vhost_net when meet polling errors.

After those changes, we can safely drop the tx polling state in vhost_net since
it was replaced by the checking of poll->wqh.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c   |   74 
 drivers/vhost/vhost.c |   31 +++-
 drivers/vhost/vhost.h |2 +-
 3 files changed, 49 insertions(+), 58 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index d10ad6f..125c1e5 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -64,20 +64,10 @@ enum {
VHOST_NET_VQ_MAX = 2,
 };
 
-enum vhost_net_poll_state {
-   VHOST_NET_POLL_DISABLED = 0,
-   VHOST_NET_POLL_STARTED = 1,
-   VHOST_NET_POLL_STOPPED = 2,
-};
-
 struct vhost_net {
struct vhost_dev dev;
struct vhost_virtqueue vqs[VHOST_NET_VQ_MAX];
struct vhost_poll poll[VHOST_NET_VQ_MAX];
-   /* Tells us whether we are polling a socket for TX.
-* We only do this when socket buffer fills up.
-* Protected by tx vq lock. */
-   enum vhost_net_poll_state tx_poll_state;
/* Number of TX recently submitted.
 * Protected by tx vq lock. */
unsigned tx_packets;
@@ -155,24 +145,6 @@ static void copy_iovec_hdr(const struct iovec *from, 
struct iovec *to,
}
 }
 
-/* Caller must have TX VQ lock */
-static void tx_poll_stop(struct vhost_net *net)
-{
-   if (likely(net->tx_poll_state != VHOST_NET_POLL_STARTED))
-   return;
-   vhost_poll_stop(net->poll + VHOST_NET_VQ_TX);
-   net->tx_poll_state = VHOST_NET_POLL_STOPPED;
-}
-
-/* Caller must have TX VQ lock */
-static void tx_poll_start(struct vhost_net *net, struct socket *sock)
-{
-   if (unlikely(net->tx_poll_state != VHOST_NET_POLL_STOPPED))
-   return;
-   vhost_poll_start(net->poll + VHOST_NET_VQ_TX, sock->file);
-   net->tx_poll_state = VHOST_NET_POLL_STARTED;
-}
-
 /* In case of DMA done not in order in lower device driver for some reason.
  * upend_idx is used to track end of used idx, done_idx is used to track head
  * of used idx. Once lower device DMA done contiguously, we will signal KVM
@@ -227,6 +199,7 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf, 
bool success)
 static void handle_tx(struct vhost_net *net)
 {
struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
+   struct vhost_poll *poll = net->poll + VHOST_NET_VQ_TX;
unsigned out, in, s;
int head;
struct msghdr msg = {
@@ -252,7 +225,8 @@ static void handle_tx(struct vhost_net *net)
wmem = atomic_read(&sock->sk->sk_wmem_alloc);
if (wmem >= sock->sk->sk_sndbuf) {
mutex_lock(&vq->mutex);
-   tx_poll_start(net, sock);
+   if (vhost_poll_start(poll, sock->file))
+   vq_err(vq, "Fail to start TX polling\n");
mutex_unlock(&vq->mutex);
return;
}
@@ -261,7 +235,7 @@ static void handle_tx(struct vhost_net *net)
vhost_disable_notify(&net->dev, vq);
 
if (wmem < sock->sk->sk_sndbuf / 2)
-   tx_poll_stop(net);
+   vhost_poll_stop(poll);
hdr_size = vq->vhost_hlen;
zcopy = vq->ubufs;
 
@@ -283,8 +257,10 @@ static void handle_tx(struct vhost_net *net)
 
wmem = atomic_read(&sock->sk->sk_wmem_alloc);
if (wmem >= sock->sk->sk_sndbuf * 3 / 4) {
-   tx_poll_start(net, sock);
-   set_bit(SOCK_ASYNC_NOSPACE, &sock->flags);
+   if (vhost_poll_start(poll, sock->file))
+   vq_err(vq, "Fail to start TX 
polling\n");
+   else
+   set_bit(SOCK_ASYNC_NOSPACE, 
&sock->flags);
break;
}
/* If more outstanding DMAs, queue the work.
@@ -294,8 +270,10 @@ static void handle_tx(struct vhost_net *net)
(vq->upend_idx - vq->done_idx) :
(vq->upend_idx + UIO_MAXIOV - vq->done_idx);
if (unlikely(num_pends > VHOST_MAX_PEND)) {
-   tx_poll_start(net, sock);
-   set_bit(SOCK_ASYNC_NOSPACE, &sock->flags);
+   if (vhost_poll_start(poll, sock->file))

[PATCH V3 1/2] vhost_net: correct error handling in vhost_net_set_backend()

2013-01-05 Thread Jason Wang
Currently, when vhost_init_used() fails the sock refcnt and ubufs were
leaked. Correct this by calling vhost_init_used() before assign ubufs and
restore the oldsock when it fails.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c |   16 +++-
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index ebd08b2..d10ad6f 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -827,15 +827,16 @@ static long vhost_net_set_backend(struct vhost_net *n, 
unsigned index, int fd)
r = PTR_ERR(ubufs);
goto err_ubufs;
}
-   oldubufs = vq->ubufs;
-   vq->ubufs = ubufs;
+
vhost_net_disable_vq(n, vq);
rcu_assign_pointer(vq->private_data, sock);
-   vhost_net_enable_vq(n, vq);
-
r = vhost_init_used(vq);
if (r)
-   goto err_vq;
+   goto err_used;
+   vhost_net_enable_vq(n, vq);
+
+   oldubufs = vq->ubufs;
+   vq->ubufs = ubufs;
 
n->tx_packets = 0;
n->tx_zcopy_err = 0;
@@ -859,6 +860,11 @@ static long vhost_net_set_backend(struct vhost_net *n, 
unsigned index, int fd)
mutex_unlock(&n->dev.mutex);
return 0;
 
+err_used:
+   rcu_assign_pointer(vq->private_data, oldsock);
+   vhost_net_enable_vq(n, vq);
+   if (ubufs)
+   vhost_ubuf_put_and_wait(ubufs);
 err_ubufs:
fput(sock->file);
 err_vq:
-- 
1.7.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH V3 0/2] handle polling errors

2013-01-05 Thread Jason Wang
This is an update version of last version to fix the handling of polling errors
in vhost/vhost_net.

Currently, vhost and vhost_net ignore polling errors which can lead kernel
crashing when it tries to remove itself from waitqueue after the polling
failure. Fix this by checking the poll->wqh before the removing and report an
error when meet polling errors.

Changes from v2:
- check poll->wqh instead of the wrong assumption about POLLERR and waitqueue
- drop the whole tx polling state check since it was replaced by the wqh
  checking
- drop the buggy tuntap patch

Changes from v1:
- restore the state before the ioctl when vhost_init_used() fails
- log the error when meet polling errors in the data path
- don't put into waitqueue when tun_chr_poll() return POLLERR

Jason Wang (2):
  vhost_net: correct error handling in vhost_net_set_backend()
  vhost: handle polling errors

 drivers/vhost/net.c   |   88 +++-
 drivers/vhost/vhost.c |   31 +
 drivers/vhost/vhost.h |2 +-
 3 files changed, 59 insertions(+), 62 deletions(-)

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH] tcm_vhost: Use llist for cmd completion list

2013-01-05 Thread Asias He
This drops the cmd completion list spin lock and makes the cmd
completion queue lock-less.

Signed-off-by: Asias He 
---
 drivers/vhost/tcm_vhost.c | 46 +-
 drivers/vhost/tcm_vhost.h |  2 +-
 2 files changed, 14 insertions(+), 34 deletions(-)

diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index b20df5c..3720604 100644
--- a/drivers/vhost/tcm_vhost.c
+++ b/drivers/vhost/tcm_vhost.c
@@ -47,6 +47,7 @@
 #include 
 #include  /* TODO vhost.h currently depends on this */
 #include 
+#include 
 
 #include "vhost.c"
 #include "vhost.h"
@@ -64,8 +65,7 @@ struct vhost_scsi {
struct vhost_virtqueue vqs[3];
 
struct vhost_work vs_completion_work; /* cmd completion work item */
-   struct list_head vs_completion_list;  /* cmd completion queue */
-   spinlock_t vs_completion_lock;/* protects s_completion_list */
+   struct llist_head vs_completion_list; /* cmd completion queue */
 };
 
 /* Local pointer to allocated TCM configfs fabric module */
@@ -301,9 +301,7 @@ static void vhost_scsi_complete_cmd(struct tcm_vhost_cmd 
*tv_cmd)
 {
struct vhost_scsi *vs = tv_cmd->tvc_vhost;
 
-   spin_lock_bh(&vs->vs_completion_lock);
-   list_add_tail(&tv_cmd->tvc_completion_list, &vs->vs_completion_list);
-   spin_unlock_bh(&vs->vs_completion_lock);
+   llist_add(&tv_cmd->tvc_completion_list, &vs->vs_completion_list);
 
vhost_work_queue(&vs->dev, &vs->vs_completion_work);
 }
@@ -347,27 +345,6 @@ static void vhost_scsi_free_cmd(struct tcm_vhost_cmd 
*tv_cmd)
kfree(tv_cmd);
 }
 
-/* Dequeue a command from the completion list */
-static struct tcm_vhost_cmd *vhost_scsi_get_cmd_from_completion(
-   struct vhost_scsi *vs)
-{
-   struct tcm_vhost_cmd *tv_cmd = NULL;
-
-   spin_lock_bh(&vs->vs_completion_lock);
-   if (list_empty(&vs->vs_completion_list)) {
-   spin_unlock_bh(&vs->vs_completion_lock);
-   return NULL;
-   }
-
-   list_for_each_entry(tv_cmd, &vs->vs_completion_list,
-   tvc_completion_list) {
-   list_del(&tv_cmd->tvc_completion_list);
-   break;
-   }
-   spin_unlock_bh(&vs->vs_completion_lock);
-   return tv_cmd;
-}
-
 /* Fill in status and signal that we are done processing this command
  *
  * This is scheduled in the vhost work queue so we are called with the owner
@@ -377,12 +354,18 @@ static void vhost_scsi_complete_cmd_work(struct 
vhost_work *work)
 {
struct vhost_scsi *vs = container_of(work, struct vhost_scsi,
vs_completion_work);
+   struct virtio_scsi_cmd_resp v_rsp;
struct tcm_vhost_cmd *tv_cmd;
+   struct llist_node *llnode;
+   struct se_cmd *se_cmd;
+   int ret;
 
-   while ((tv_cmd = vhost_scsi_get_cmd_from_completion(vs))) {
-   struct virtio_scsi_cmd_resp v_rsp;
-   struct se_cmd *se_cmd = &tv_cmd->tvc_se_cmd;
-   int ret;
+   llnode = llist_del_all(&vs->vs_completion_list);
+   while (llnode) {
+   tv_cmd = llist_entry(llnode, struct tcm_vhost_cmd,
+tvc_completion_list);
+   llnode = llist_next(llnode);
+   se_cmd = &tv_cmd->tvc_se_cmd;
 
pr_debug("%s tv_cmd %p resid %u status %#02x\n", __func__,
tv_cmd, se_cmd->residual_count, se_cmd->scsi_status);
@@ -426,7 +409,6 @@ static struct tcm_vhost_cmd *vhost_scsi_allocate_cmd(
pr_err("Unable to allocate struct tcm_vhost_cmd\n");
return ERR_PTR(-ENOMEM);
}
-   INIT_LIST_HEAD(&tv_cmd->tvc_completion_list);
tv_cmd->tvc_tag = v_req->tag;
tv_cmd->tvc_task_attr = v_req->task_attr;
tv_cmd->tvc_exp_data_len = exp_data_len;
@@ -859,8 +841,6 @@ static int vhost_scsi_open(struct inode *inode, struct file 
*f)
return -ENOMEM;
 
vhost_work_init(&s->vs_completion_work, vhost_scsi_complete_cmd_work);
-   INIT_LIST_HEAD(&s->vs_completion_list);
-   spin_lock_init(&s->vs_completion_lock);
 
s->vqs[VHOST_SCSI_VQ_CTL].handle_kick = vhost_scsi_ctl_handle_kick;
s->vqs[VHOST_SCSI_VQ_EVT].handle_kick = vhost_scsi_evt_handle_kick;
diff --git a/drivers/vhost/tcm_vhost.h b/drivers/vhost/tcm_vhost.h
index 7e87c63..47ee80b 100644
--- a/drivers/vhost/tcm_vhost.h
+++ b/drivers/vhost/tcm_vhost.h
@@ -34,7 +34,7 @@ struct tcm_vhost_cmd {
/* Sense buffer that will be mapped into outgoing status */
unsigned char tvc_sense_buf[TRANSPORT_SENSE_BUFFER];
/* Completed commands list, serviced from vhost worker thread */
-   struct list_head tvc_completion_list;
+   struct llist_node tvc_completion_list;
 };
 
 struct tcm_vhost_nexus {
-- 
1.7.11.7

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linu

Accepted Workshops in the CISTI'2013 - 8th Iberian Conference on IST

2013-01-05 Thread Maria Lemos
***
CISTI'2013 Accepted Workshops
8th Iberian Conference on Information Systems and Technologies
Lisbon, Portugal, June 19 - 23, 2013
http://www.aisti.eu/cisti2013/index.php?option=com_content&view=article&id=64&Itemid=68&lang=en
***

List of accepted workshops in the CISTI'2013 - 8th Iberian Conference on 
Information Systems and Technologies:

> IAwDQ'2013 - Fourth Ibero-American Workshop on Data Quality 

> SGaMePlay'2013 - Third Iberian Workshop on Serious Games and Meaningful Play

> WISA'2013 - Fifth Workshop on Intelligent Systems and Applications 

> WISIS'2013 - Third Workshop on Information Systems for Interactive Spaces

> WSEQP'2013 - First Workshop in Software Engineering and Quality Process

Best regards,

Maria Lemos
AISTI / CISTI'2013
http://www.aisti.eu/cisti2013

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


CFP: Scientific Cloud Computing (ScienceCloud) -- co-located with ACM HPDC 2013

2013-01-05 Thread Ioan Raicu

---
*** Call for Papers ***
4th Workshop on Scientific Cloud Computing (ScienceCloud) 2013
Co-located with ACM HPDC 2013, New York City, NY, USA -- June 17th, 2013
http://datasys.cs.iit.edu/events/ScienceCloud2013/
---

Computational and Data-Driven Sciences have become the third and fourth 
pillar
of scientific discovery in addition to experimental and theoretical 
sciences.
Scientific Computing has already begun to change how science is done, 
enabling
scientific breakthroughs through new kinds of experiments that would 
have been
impossible only a decade ago. Today’s “Big Data” science is generating 
datasets
that are increasing exponentially in both complexity and volume, making 
their
analysis, archival, and sharing one of the grand challenges of the 21st 
century.
The support for data intensive computing is critical to advance modern 
science
as storage systems have exposed a widening gap between their capacity 
and their
bandwidth by more than 10-fold over the last decade. There is a growing 
need
for advanced techniques to manipulate, visualize and interpret large 
datasets.
Scientific Computing is the key to solving “grand challenges” in many 
domains
and providing breakthroughs in new knowledge, and it comes in many 
shapes and

forms: high-performance computing (HPC) which is heavily focused on compute-
intensive applications; high-throughput computing (HTC) which focuses on 
using

many computing resources over long periods of time to accomplish its
computational tasks; many-task computing (MTC) which aims to bridge the gap
between HPC and HTC by focusing on using many resources over short 
periods of

time; and data-intensive computing which is heavily focused on data
distribution, data-parallel execution, and harnessing data locality by
scheduling of computations close to the data.

The 4th workshop on Scientific Cloud Computing (ScienceCloud) will 
provide the
scientific community a dedicated forum for discussing new research, 
development,
and deployment efforts in running these kinds of scientific computing 
workloads
on Cloud Computing infrastructures. The ScienceCloud workshop will focus 
on the

use of cloud-based technologies to meet new compute-intensive and data-
intensive scientific challenges that are not well served by the current
supercomputers, grids and HPC clusters. The workshop will aim to address
questions such as: What architectural changes to the current cloud 
frameworks
(hardware, operating systems, networking and/or programming models) are 
needed

to support science? Dynamic information derived from remote instruments and
coupled simulation, and sensor ensembles that stream data for real-time
analysis are important emerging techniques in scientific and cyber-physical
engineering systems. How can cloud technologies enable and adapt to 
these new
scientific approaches dealing with dynamism? How are scientists using 
clouds?
Are there scientific HPC/HTC/MTC workloads that are suitable candidates 
to take
advantage of emerging cloud computing resources with high efficiency? 
Commercial
public clouds provide easy access to cloud infrastructure for 
scientists. What

are the gaps in commercial cloud offerings and how can they be adapted for
running existing and novel eScience applications? What benefits exist by
adopting the cloud model, over clusters, grids, or supercomputers? What 
factors

are limiting clouds use or would make them more usable/efficient?

This workshop encourages interaction and cross-pollination between those
developing applications, algorithms, software, hardware and networking,
emphasizing scientific computing for such cloud platforms. We believe the
workshop will be an excellent place to help the community define the 
current
state, determine future goals, and define architectures and services for 
future

science clouds.

TOPICS
---
We invite the submission of original work that is related to the topics 
below.

The papers can be either short (4 pages) position papers, or long (8 pages)
research papers. Topics of interest include (in the context of Cloud 
Computing):

- Scientific application cases studies on Cloud infrastructure
- Performance evaluation of Cloud environments and technologies
- Fault tolerance and reliability in cloud systems
- Data-intensive workloads and tools on Clouds
- Use of programming models such as Map-Reduce and its implementations
- Storage cloud architectures
- I/O and Data management in the Cloud
- Workflow and resource management in the Cloud
- Use of cloud technologies (e.g., NoSQL databases) for scientific 
applications

- Data streaming and dynamic applications on Clouds
- Dynamic resource provisioning
- Many-Task Computing in the Cloud
- Application of cloud concepts in HPC environments or v