On Tue, 2013-09-24 at 08:59 +0300, Michael S. Tsirkin wrote: > On Mon, Sep 23, 2013 at 07:10:23PM +0000, Nicholas A. Bellinger wrote: > > From: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx> > > > > Fix GFP_KERNEL -> GFP_ATOMIC usage of percpu_ida_alloc() within > > vhost_scsi_get_tag(), as this code is expected to be called directly > > from interrupt context. > > > > Cc: Michael S. Tsirkin <mst@xxxxxxxxxx> > > Cc: Asias He <asias@xxxxxxxxxx> > > Signed-off-by: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx> > > --- > > drivers/vhost/scsi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c > > index 4b79a1f..532820c 100644 > > --- a/drivers/vhost/scsi.c > > +++ b/drivers/vhost/scsi.c > > @@ -728,7 +728,7 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq, > > } > > se_sess = tv_nexus->tvn_se_sess; > > > > - tag = percpu_ida_alloc(&se_sess->sess_tag_pool, GFP_KERNEL); > > + tag = percpu_ida_alloc(&se_sess->sess_tag_pool, GFP_ATOMIC); > > cmd = &((struct tcm_vhost_cmd *)se_sess->sess_cmd_map)[tag]; > > sg = cmd->tvc_sgl; > > pages = cmd->tvc_upages; > > > Just a question: what exactly happens when this fails? > As GFP_ATOMIC allocations are likely to fail, some strategy > for retrying them needs to be present. > What retries them here? > Correct. This should actually fail for tag < 0 when GFP_ATOMIC is used and percpu_ida_alloc is unable schedule + steal tags from another cpu. However with vhost, 2x (256) the number tags vs. vring elements (128) are setup during percpu_ida_init(), so this should not be happening in practice. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
