Call for Papers - WorldCIST'19 - La Toja Island, Spain

[ML]

*** Best papers published in JCR/SCI/SSCI journals



--   -
WorldCIST'19 - 7th World Conference on Information Systems and Technologies

16 - 19 April 2019 | La Toja Island, Spain

http://www.worldcist.org/ 

--   --   
--   --


Scope

The WorldCist'19 - 7th World Conference on Information Systems and 
Technologies, to be held at La Toja Island, Galicia, Spain, 16 - 19 April 2019, 
is a global forum for researchers and practitioners to present and discuss the 
most recent innovations, trends, results, experiences and concerns in the 
several perspectives of Information Systems and Technologies.

We are pleased to invite you to submit your papers to WorldCist'18. All 
submissions will be reviewed on the basis of relevance, originality, importance 
and clarity.



Themes

Submitted papers should be related with one or more of the main themes proposed 
for the Conference:

A) Information and Knowledge Management (IKM);

B) Organizational Models and Information Systems (OMIS);

C) Software and Systems Modeling (SSM);

D) Software Systems, Architectures, Applications and Tools (SSAAT);

E) Multimedia Systems and Applications (MSA);

F) Computer Networks, Mobility and Pervasive Systems (CNMPS);

G) Intelligent and Decision Support Systems (IDSS);

H) Big Data Analytics and Applications (BDAA);

I) Human-Computer Interaction (HCI);

J) Ethics, Computers and Security (ECS)

K) Health Informatics (HIS);

L) Information Technologies in Education (ITE);

M) Information Technologies in Radiocommunications (ITR);

N) Technologies for Biomedical Applications (TBA)



Types of Submissions and Decisions

Four types of papers can be submitted:

Full paper: Finished or consolidated R works, to be included in one of the 
Conference themes. These papers are assigned a 10-page limit.

Short paper: Ongoing works with relevant preliminary results, open to 
discussion. These papers are assigned a 7-page limit.

Poster paper: Initial work with relevant ideas, open to discussion. These 
papers are assigned to a 4-page limit.

Company paper: Companies' papers that show practical experience, R & D, tools, 
etc., focused on some topics of the conference. These papers are assigned to a 
4-page limit.

Submitted papers must comply with the format of Advances in Intelligent Systems 
and Computing Series (see Instructions for Authors at Springer Website 

 or download a Word Template 
or 
Latex Package 
) 
be written in English, must not have been published before, not be under review 
for any other conference or publication and not include any information leading 
to the authors’ identification. Therefore, the authors’ names, affiliations and 
bibliographic references should not be included in the version for evaluation 
by the Program Committee. This information should only be included in the 
camera-ready version, saved in Word or Latex format and also in PDF format. 
These files must be accompanied by the Consent to Publish form 
 filled out, in a ZIP file, and uploaded at 
the conference management system.


All papers will be subjected to a “double-blind review” by at least two members 
of the Program Committee.

Based on Program Committee evaluation, a paper can be rejected or accepted by 
the Conference Chairs. In the later case, it can be accepted as the type 
originally submitted or as another type. Thus, full papers can be accepted as 
short papers or poster papers only. Similarly, short papers can be accepted as 
poster papers only. In these cases, the authors will be allowed to maintain the 
original number of pages in the camera-ready version.

The authors of accepted poster papers must also build and print a poster to be 
exhibited during the Conference. This poster must follow an A1 or A2 vertical 
format. The Conference can includes Work Sessions where these posters are 
presented and orally discussed, with a 5 minute limit per poster.

The authors of accepted full papers will have 15 minutes to present their work 
in a Conference Work Session; approximately 5 minutes of discussion will follow 
each presentation. The authors of accepted short papers and company papers will 
have 11 minutes to present their work in a Conference Work Session; 
approximately 4 minutes of discussion will follow each presentation.



Publication and Indexing

To ensure that a full paper, short paper, poster paper or company paper is 
published, at least one of the authors must be fully registered by the 13th of 
January 2019, and the paper must comply with the suggested 

Re: [PATCH 1/1] Add vhost_blk driver

[kbuild test robot]

Hi Vitaly,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on vhost/linux-next]
[also build test ERROR on v4.19 next-20181102]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Vitaly-Mayatskikh/vhost-add-vhost_blk-driver/20181103-084141
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=mips 

All error/warnings (new ones prefixed by >>):

   drivers/vhost/blk.c: In function 'vhost_blk_iocb_complete':
>> drivers/vhost/blk.c:129:2: error: implicit declaration of function 
>> 'vhost_vq_work_queue'; did you mean 'vhost_work_queue'? 
>> [-Werror=implicit-function-declaration]
 vhost_vq_work_queue(>q->vq, >q->w);
 ^~~
 vhost_work_queue
   In file included from include/linux/kernel.h:14:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/vhost/blk.c:11:
   drivers/vhost/blk.c: In function 'vhost_blk_req_handle':
>> drivers/vhost/blk.c:153:12: warning: format '%ld' expects argument of type 
>> 'long int', but argument 8 has type 'ssize_t {aka int}' [-Wformat=]
  pr_debug("%s: [pid:%d %s] %s sector %lld, len %ld\n",
   ^
   include/linux/printk.h:292:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
   include/linux/printk.h:340:2: note: in expansion of macro 'dynamic_pr_debug'
 dynamic_pr_debug(fmt, ##__VA_ARGS__)
 ^~~~
>> drivers/vhost/blk.c:153:3: note: in expansion of macro 'pr_debug'
  pr_debug("%s: [pid:%d %s] %s sector %lld, len %ld\n",
  ^~~~
   cc1: some warnings being treated as errors

vim +129 drivers/vhost/blk.c

   118  
   119  static void vhost_blk_iocb_complete(struct kiocb *iocb, long ret, long 
ret2)
   120  {
   121  struct vhost_blk_req *req = container_of(iocb, struct 
vhost_blk_req,
   122   iocb);
   123  
   124  pr_debug("%s vq[%d] req->index %d ret %ld ret2 %ld\n", __func__,
   125   req->q->index, req->index, ret, ret2);
   126  
   127  req->res = (ret == req->len) ? VIRTIO_BLK_S_OK : 
VIRTIO_BLK_S_IOERR;
   128  llist_add(>list, >q->wl);
 > 129  vhost_vq_work_queue(>q->vq, >q->w);
   130  }
   131  
   132  static int vhost_blk_req_handle(struct vhost_blk_req *req)
   133  {
   134  struct vhost_blk *blk = req->q->blk;
   135  struct vhost_virtqueue *vq = >q->vq;
   136  int type = le32_to_cpu(req->hdr.type);
   137  int ret;
   138  u8 status;
   139  
   140  if ((type == VIRTIO_BLK_T_IN) || (type == VIRTIO_BLK_T_OUT)) {
   141  bool write = (type == VIRTIO_BLK_T_OUT);
   142  int nr_seg = (write ? req->out_num : req->in_num) - 1;
   143  unsigned long sector = le64_to_cpu(req->hdr.sector);
   144  ssize_t len, rem_len;
   145  
   146  if (!req->q->blk->backend) {
   147  vq_err(vq, "blk %p no backend!\n", req->q->blk);
   148  ret = -EINVAL;
   149  goto out_err;
   150  }
   151  
   152  len = iov_length(>iov[1], nr_seg);
 > 153  pr_debug("%s: [pid:%d %s] %s sector %lld, len %ld\n",
   154   __func__, current->pid, current->comm,
   155   write ? "WRITE" : "READ", req->hdr.sector, 
len);
   156  
   157  req->len = len;
   158  rem_len = len;
   159  iov_iter_init(>i, (write ? WRITE : READ),
   160write ? >out_iov[0] : 
>in_iov[0],
   161nr_seg, len);
   162  
   163  req->iocb.ki_pos = sector << 9;
   164  req->iocb.ki_filp = blk->backend;
   165  req->iocb.ki_complete = vhost_blk_iocb_complete;
   166  req->iocb.ki_flags = IOCB_DIRECT;
   167  
   168  if (write)
   169  ret = call_write_iter(blk->backend, >iocb,
   170>i);
   171  else
   172

Re: [PULL] vhost: cleanups and fixes

[Mark Rutland]

On Thu, Nov 01, 2018 at 04:06:19PM -0700, Linus Torvalds wrote:
> On Thu, Nov 1, 2018 at 4:00 PM Kees Cook  wrote:
> >
> > +   memset(, 0, sizeof(rsp));
> > +   rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED;
> > +   resp = vq->iov[out].iov_base;
> > +   ret = __copy_to_user(resp, , sizeof(rsp));
> >
> > Is it actually safe to trust that iov_base has passed an earlier
> > access_ok() check here? Why not just use copy_to_user() instead?
> 
> Good point.
> 
> We really should have removed those double-underscore things ages ago.

FWIW, on arm64 we always check/sanitize the user address as a result of
our sanitization of speculated values. Almost all of our uaccess
routines have an explicit access_ok().

All our uaccess routines mask the user pointer based on addr_limit,
which prevents speculative or architectural uaccess to kernel addresses
when addr_limit it USER_DS:

4d8efc2d5ee4c9cc ("arm64: Use pointer masking to limit uaccess speculation")

We also inhibit speculative stores to addr_limit being forwarded under
speculation:

c2f0ad4fc089cff8 ("arm64: uaccess: Prevent speculative use of the current 
addr_limit")

... and given all that, we folded explicit access_ok() checks into
__{get,put}_user():

84624087dd7e3b48 ("arm64: uaccess: Don't bother eliding access_ok checks in 
__{get, put}_user")

IMO we could/should do the same for __copy_{to,from}_user().

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

Re: [PATCH 0/2] i8253: Fix PIT shutdown quirk on Hyper-V

[Juergen Gross]

On 01/11/2018 18:30, Michael Kelley wrote:
> pit_shutdown() doesn't work on Hyper-V because of a quirk in the
> PIT emulation. This problem exists in all versions of Hyper-V and
> had not been noticed previously. When the counter register is set
> to zero, the emulated PIT continues to interrupt @18.2 HZ.
> 
> So add a test for running on Hyper-V, and use that test to skip
> setting the counter register when running on Hyper-V.
> 
> This patch replaces a previously proposed patch with a different
> approach. This new approach follows comments from Thomas Gleixner.

Did you consider using a static_key instead? You could set it in
ms_hyperv_init_platform(). This would enable you to support future
Hyper-V versions which don't require avoiding to set the count to zero.


Juergen

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

Re: [PATCH v9] virtio_blk: add discard and write zeroes support

[Stefan Hajnoczi]

On Thu, Nov 01, 2018 at 03:40:35PM -0700, Daniel Verkamp wrote:
> From: Changpeng Liu 
> 
> In commit 88c85538, "virtio-blk: add discard and write zeroes features
> to specification" (https://github.com/oasis-tcs/virtio-spec), the virtio
> block specification has been extended to add VIRTIO_BLK_T_DISCARD and
> VIRTIO_BLK_T_WRITE_ZEROES commands.  This patch enables support for
> discard and write zeroes in the virtio-blk driver when the device
> advertises the corresponding features, VIRTIO_BLK_F_DISCARD and
> VIRTIO_BLK_F_WRITE_ZEROES.
> 
> Signed-off-by: Changpeng Liu 
> Signed-off-by: Daniel Verkamp 
> ---
> dverkamp: I've picked up this patch and made a few minor changes (as
> listed below); most notably, I changed the kmalloc back to GFP_ATOMIC,
> since it can be called from a context where sleeping is not allowed.
> To prevent large allocations, I've also clamped the maximum number of
> discard segments to 256; this results in a 4K allocation and should be
> plenty of descriptors for most use cases.
> 
> I also removed most of the description from the commit message, since it
> was duplicating the comments from virtio_blk.h and quoting parts of the
> spec without adding any extra information.  I have tested this iteration
> of the patch using crosvm with modifications to enable the new features:
> https://chromium.googlesource.com/chromiumos/platform/crosvm/
> 
> v9 fixes a number of review issues; I didn't attempt to optimize the
> single-element write zeroes case, so it still does an allocation per
> request (I did not see any easy place to put the payload that would
> avoid the allocation).
> 
> CHANGELOG:
> v9: [dverkamp] fix LE types in discard struct; cleanups from Ming Lei
> v8: [dverkamp] replace shifts by 9 with SECTOR_SHIFT constant
> v7: [dverkamp] use GFP_ATOMIC for allocation that may not sleep; clarify
> descriptor flags field; comment wording cleanups.
> v6: don't set T_OUT bit to discard and write zeroes commands.
> v5: use new block layer API: blk_queue_flag_set.
> v4: several optimizations based on MST's comments, remove bit field
> usage for command descriptor.
> v3: define the virtio-blk protocol to add discard and write zeroes
> support, first version implementation based on proposed specification.
> v2: add write zeroes command support.
> v1: initial proposal implementation for discard command.
> ---
>  drivers/block/virtio_blk.c  | 83 -
>  include/uapi/linux/virtio_blk.h | 54 +
>  2 files changed, 135 insertions(+), 2 deletions(-)

Reviewed-by: Stefan Hajnoczi 


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

Re: [PULL] vhost: cleanups and fixes

[Michael S. Tsirkin]

On Thu, Nov 01, 2018 at 04:06:19PM -0700, Linus Torvalds wrote:
> On Thu, Nov 1, 2018 at 4:00 PM Kees Cook  wrote:
> >
> > +   memset(, 0, sizeof(rsp));
> > +   rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED;
> > +   resp = vq->iov[out].iov_base;
> > +   ret = __copy_to_user(resp, , sizeof(rsp));
> >
> > Is it actually safe to trust that iov_base has passed an earlier
> > access_ok() check here? Why not just use copy_to_user() instead?
> 
> Good point.
> 
> We really should have removed those double-underscore things ages ago.

Well in case of vhost there are a bunch of reasons to keep them.

One is that all access_ok checks take place
way earlier in context of the owner task. Result is saved
and then used for access repeatedly. Skipping reding access_ok twice
did seem to give a small speedup in the past.
In fact I am looking
into switching some of the uses to unsafe_put_user/unsafe_get_user
after doing something like barrier_nospec after the
access_ok checks. Seems to give a measureable speedup.


Another is that the double underscore things actually can be done
in softirq context if you do preempt_disable/preempt_enable.
IIUC Jason's looking into using that to cut down the latency
for when the access is very small.

> Also, apart from the address, what about the size? Wouldn't it be
> better to use copy_to_iter() rather than implement it badly by hand?
> 
>Linus

Generally size is checked when we retrieve the iov but I will recheck
this case and reply here.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v9] virtio_blk: add discard and write zeroes support

[Dongli Zhang]

Hi Daniel,

Other than crosvm, is there any version of qemu (e.g., repositories developed in
progress on github) where I can try with this feature?

Thank you very much!

Dongli Zhang

On 11/02/2018 06:40 AM, Daniel Verkamp wrote:
> From: Changpeng Liu 
> 
> In commit 88c85538, "virtio-blk: add discard and write zeroes features
> to specification" (https://github.com/oasis-tcs/virtio-spec), the virtio
> block specification has been extended to add VIRTIO_BLK_T_DISCARD and
> VIRTIO_BLK_T_WRITE_ZEROES commands.  This patch enables support for
> discard and write zeroes in the virtio-blk driver when the device
> advertises the corresponding features, VIRTIO_BLK_F_DISCARD and
> VIRTIO_BLK_F_WRITE_ZEROES.
> 
> Signed-off-by: Changpeng Liu 
> Signed-off-by: Daniel Verkamp 
> ---
> dverkamp: I've picked up this patch and made a few minor changes (as
> listed below); most notably, I changed the kmalloc back to GFP_ATOMIC,
> since it can be called from a context where sleeping is not allowed.
> To prevent large allocations, I've also clamped the maximum number of
> discard segments to 256; this results in a 4K allocation and should be
> plenty of descriptors for most use cases.
> 
> I also removed most of the description from the commit message, since it
> was duplicating the comments from virtio_blk.h and quoting parts of the
> spec without adding any extra information.  I have tested this iteration
> of the patch using crosvm with modifications to enable the new features:
> https://chromium.googlesource.com/chromiumos/platform/crosvm/
> 
> v9 fixes a number of review issues; I didn't attempt to optimize the
> single-element write zeroes case, so it still does an allocation per
> request (I did not see any easy place to put the payload that would
> avoid the allocation).
> 
> CHANGELOG:
> v9: [dverkamp] fix LE types in discard struct; cleanups from Ming Lei
> v8: [dverkamp] replace shifts by 9 with SECTOR_SHIFT constant
> v7: [dverkamp] use GFP_ATOMIC for allocation that may not sleep; clarify
> descriptor flags field; comment wording cleanups.
> v6: don't set T_OUT bit to discard and write zeroes commands.
> v5: use new block layer API: blk_queue_flag_set.
> v4: several optimizations based on MST's comments, remove bit field
> usage for command descriptor.
> v3: define the virtio-blk protocol to add discard and write zeroes
> support, first version implementation based on proposed specification.
> v2: add write zeroes command support.
> v1: initial proposal implementation for discard command.
> ---
>  drivers/block/virtio_blk.c  | 83 -
>  include/uapi/linux/virtio_blk.h | 54 +
>  2 files changed, 135 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 086c6bb12baa..0f39efb4b3aa 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -18,6 +18,7 @@
>  
>  #define PART_BITS 4
>  #define VQ_NAME_LEN 16
> +#define MAX_DISCARD_SEGMENTS 256u
>  
>  static int major;
>  static DEFINE_IDA(vd_index_ida);
> @@ -172,10 +173,48 @@ static int virtblk_add_req(struct virtqueue *vq, struct 
> virtblk_req *vbr,
>   return virtqueue_add_sgs(vq, sgs, num_out, num_in, vbr, GFP_ATOMIC);
>  }
>  
> +static int virtblk_setup_discard_write_zeroes(struct request *req, bool 
> unmap)
> +{
> + unsigned short segments = blk_rq_nr_discard_segments(req);
> + unsigned short n = 0;
> + struct virtio_blk_discard_write_zeroes *range;
> + struct bio *bio;
> + u32 flags = 0;
> +
> + if (unmap)
> + flags |= VIRTIO_BLK_WRITE_ZEROES_FLAG_UNMAP;
> +
> + range = kmalloc_array(segments, sizeof(*range), GFP_ATOMIC);
> + if (!range)
> + return -ENOMEM;
> +
> + __rq_for_each_bio(bio, req) {
> + u64 sector = bio->bi_iter.bi_sector;
> + u32 num_sectors = bio->bi_iter.bi_size >> SECTOR_SHIFT;
> +
> + range[n].flags = cpu_to_le32(flags);
> + range[n].num_sectors = cpu_to_le32(num_sectors);
> + range[n].sector = cpu_to_le64(sector);
> + n++;
> + }
> +
> + req->special_vec.bv_page = virt_to_page(range);
> + req->special_vec.bv_offset = offset_in_page(range);
> + req->special_vec.bv_len = sizeof(*range) * segments;
> + req->rq_flags |= RQF_SPECIAL_PAYLOAD;
> +
> + return 0;
> +}
> +
>  static inline void virtblk_request_done(struct request *req)
>  {
>   struct virtblk_req *vbr = blk_mq_rq_to_pdu(req);
>  
> + if (req->rq_flags & RQF_SPECIAL_PAYLOAD) {
> + kfree(page_address(req->special_vec.bv_page) +
> +   req->special_vec.bv_offset);
> + }
> +
>   switch (req_op(req)) {
>   case REQ_OP_SCSI_IN:
>   case REQ_OP_SCSI_OUT:
> @@ -225,6 +264,7 @@ static blk_status_t virtio_queue_rq(struct blk_mq_hw_ctx 
> *hctx,
>   int qid = hctx->queue_num;
>   int err;
>   bool notify = false;
> + bool unmap = 

Re: [PULL] vhost: cleanups and fixes

[Michael S. Tsirkin]

On Thu, Nov 01, 2018 at 04:00:23PM -0700, Kees Cook wrote:
> On Thu, Nov 1, 2018 at 2:19 PM, Michael S. Tsirkin  wrote:
> > The following changes since commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d:
> >
> >   Linux 4.19 (2018-10-22 07:37:37 +0100)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
> >
> > for you to fetch changes up to 79f800b2e76923cd8ce0aa659cb5c019d9643bc9:
> >
> >   MAINTAINERS: remove reference to bogus vsock file (2018-10-24 21:16:14 
> > -0400)
> >
> > 
> > virtio, vhost: fixes, tweaks
> >
> > virtio balloon page hinting support
> > vhost scsi control queue
> >
> > misc fixes.
> >
> > Signed-off-by: Michael S. Tsirkin 
> >
> > 
> > Bijan Mottahedeh (3):
> >   vhost/scsi: Respond to control queue operations
> 
> +static void
> +vhost_scsi_send_tmf_resp(struct vhost_scsi *vs,
> +  struct vhost_virtqueue *vq,
> +  int head, unsigned int out)
> +{
> +   struct virtio_scsi_ctrl_tmf_resp __user *resp;
> +   struct virtio_scsi_ctrl_tmf_resp rsp;
> +   int ret;
> +
> +   pr_debug("%s\n", __func__);
> +   memset(, 0, sizeof(rsp));
> +   rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED;
> +   resp = vq->iov[out].iov_base;
> +   ret = __copy_to_user(resp, , sizeof(rsp));
> 
> Is it actually safe to trust that iov_base has passed an earlier
> access_ok() check here? Why not just use copy_to_user() instead?
> 
> -Kees

I am not sure copy_to_user will do the right thing here, because all
this runs in context of a kernel thread.  We do need access_ok which
takes place way earlier in context of the task.

Another reason it is safe is because the address is not
coming from userspace at all.




> >   vhost/scsi: Extract common handling code from control queue handler
> >   vhost/scsi: Use common handling code in request queue handler
> >
> > Greg Edwards (1):
> >   vhost/scsi: truncate T10 PI iov_iter to prot_bytes
> >
> > Lénaïc Huard (1):
> >   kvm_config: add CONFIG_VIRTIO_MENU
> >
> > Stefan Hajnoczi (1):
> >   MAINTAINERS: remove reference to bogus vsock file
> >
> > Wei Wang (3):
> >   virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
> >   mm/page_poison: expose page_poisoning_enabled to kernel modules
> >   virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
> >
> >  MAINTAINERS |   1 -
> >  drivers/vhost/scsi.c| 426 
> > 
> >  drivers/virtio/virtio_balloon.c | 380 +---
> >  include/uapi/linux/virtio_balloon.h |   8 +
> >  kernel/configs/kvm_guest.config |   1 +
> >  mm/page_poison.c|   6 +
> >  6 files changed, 688 insertions(+), 134 deletions(-)
> 
> 
> 
> -- 
> Kees Cook
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PULL] vhost: cleanups and fixes

[Linus Torvalds]

On Thu, Nov 1, 2018 at 4:00 PM Kees Cook  wrote:
>
> +   memset(, 0, sizeof(rsp));
> +   rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED;
> +   resp = vq->iov[out].iov_base;
> +   ret = __copy_to_user(resp, , sizeof(rsp));
>
> Is it actually safe to trust that iov_base has passed an earlier
> access_ok() check here? Why not just use copy_to_user() instead?

Good point.

We really should have removed those double-underscore things ages ago.

Also, apart from the address, what about the size? Wouldn't it be
better to use copy_to_iter() rather than implement it badly by hand?

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

Re: [PULL] vhost: cleanups and fixes

[Kees Cook]

On Thu, Nov 1, 2018 at 2:19 PM, Michael S. Tsirkin  wrote:
> The following changes since commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d:
>
>   Linux 4.19 (2018-10-22 07:37:37 +0100)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
>
> for you to fetch changes up to 79f800b2e76923cd8ce0aa659cb5c019d9643bc9:
>
>   MAINTAINERS: remove reference to bogus vsock file (2018-10-24 21:16:14 
> -0400)
>
> 
> virtio, vhost: fixes, tweaks
>
> virtio balloon page hinting support
> vhost scsi control queue
>
> misc fixes.
>
> Signed-off-by: Michael S. Tsirkin 
>
> 
> Bijan Mottahedeh (3):
>   vhost/scsi: Respond to control queue operations

+static void
+vhost_scsi_send_tmf_resp(struct vhost_scsi *vs,
+  struct vhost_virtqueue *vq,
+  int head, unsigned int out)
+{
+   struct virtio_scsi_ctrl_tmf_resp __user *resp;
+   struct virtio_scsi_ctrl_tmf_resp rsp;
+   int ret;
+
+   pr_debug("%s\n", __func__);
+   memset(, 0, sizeof(rsp));
+   rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED;
+   resp = vq->iov[out].iov_base;
+   ret = __copy_to_user(resp, , sizeof(rsp));

Is it actually safe to trust that iov_base has passed an earlier
access_ok() check here? Why not just use copy_to_user() instead?

-Kees

>   vhost/scsi: Extract common handling code from control queue handler
>   vhost/scsi: Use common handling code in request queue handler
>
> Greg Edwards (1):
>   vhost/scsi: truncate T10 PI iov_iter to prot_bytes
>
> Lénaïc Huard (1):
>   kvm_config: add CONFIG_VIRTIO_MENU
>
> Stefan Hajnoczi (1):
>   MAINTAINERS: remove reference to bogus vsock file
>
> Wei Wang (3):
>   virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
>   mm/page_poison: expose page_poisoning_enabled to kernel modules
>   virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
>
>  MAINTAINERS |   1 -
>  drivers/vhost/scsi.c| 426 
> 
>  drivers/virtio/virtio_balloon.c | 380 +---
>  include/uapi/linux/virtio_balloon.h |   8 +
>  kernel/configs/kvm_guest.config |   1 +
>  mm/page_poison.c|   6 +
>  6 files changed, 688 insertions(+), 134 deletions(-)



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

[PATCH v9] virtio_blk: add discard and write zeroes support

[Daniel Verkamp]

From: Changpeng Liu 

In commit 88c85538, "virtio-blk: add discard and write zeroes features
to specification" (https://github.com/oasis-tcs/virtio-spec), the virtio
block specification has been extended to add VIRTIO_BLK_T_DISCARD and
VIRTIO_BLK_T_WRITE_ZEROES commands.  This patch enables support for
discard and write zeroes in the virtio-blk driver when the device
advertises the corresponding features, VIRTIO_BLK_F_DISCARD and
VIRTIO_BLK_F_WRITE_ZEROES.

Signed-off-by: Changpeng Liu 
Signed-off-by: Daniel Verkamp 
---
dverkamp: I've picked up this patch and made a few minor changes (as
listed below); most notably, I changed the kmalloc back to GFP_ATOMIC,
since it can be called from a context where sleeping is not allowed.
To prevent large allocations, I've also clamped the maximum number of
discard segments to 256; this results in a 4K allocation and should be
plenty of descriptors for most use cases.

I also removed most of the description from the commit message, since it
was duplicating the comments from virtio_blk.h and quoting parts of the
spec without adding any extra information.  I have tested this iteration
of the patch using crosvm with modifications to enable the new features:
https://chromium.googlesource.com/chromiumos/platform/crosvm/

v9 fixes a number of review issues; I didn't attempt to optimize the
single-element write zeroes case, so it still does an allocation per
request (I did not see any easy place to put the payload that would
avoid the allocation).

CHANGELOG:
v9: [dverkamp] fix LE types in discard struct; cleanups from Ming Lei
v8: [dverkamp] replace shifts by 9 with SECTOR_SHIFT constant
v7: [dverkamp] use GFP_ATOMIC for allocation that may not sleep; clarify
descriptor flags field; comment wording cleanups.
v6: don't set T_OUT bit to discard and write zeroes commands.
v5: use new block layer API: blk_queue_flag_set.
v4: several optimizations based on MST's comments, remove bit field
usage for command descriptor.
v3: define the virtio-blk protocol to add discard and write zeroes
support, first version implementation based on proposed specification.
v2: add write zeroes command support.
v1: initial proposal implementation for discard command.
---
 drivers/block/virtio_blk.c  | 83 -
 include/uapi/linux/virtio_blk.h | 54 +
 2 files changed, 135 insertions(+), 2 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 086c6bb12baa..0f39efb4b3aa 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -18,6 +18,7 @@
 
 #define PART_BITS 4
 #define VQ_NAME_LEN 16
+#define MAX_DISCARD_SEGMENTS 256u
 
 static int major;
 static DEFINE_IDA(vd_index_ida);
@@ -172,10 +173,48 @@ static int virtblk_add_req(struct virtqueue *vq, struct 
virtblk_req *vbr,
return virtqueue_add_sgs(vq, sgs, num_out, num_in, vbr, GFP_ATOMIC);
 }
 
+static int virtblk_setup_discard_write_zeroes(struct request *req, bool unmap)
+{
+   unsigned short segments = blk_rq_nr_discard_segments(req);
+   unsigned short n = 0;
+   struct virtio_blk_discard_write_zeroes *range;
+   struct bio *bio;
+   u32 flags = 0;
+
+   if (unmap)
+   flags |= VIRTIO_BLK_WRITE_ZEROES_FLAG_UNMAP;
+
+   range = kmalloc_array(segments, sizeof(*range), GFP_ATOMIC);
+   if (!range)
+   return -ENOMEM;
+
+   __rq_for_each_bio(bio, req) {
+   u64 sector = bio->bi_iter.bi_sector;
+   u32 num_sectors = bio->bi_iter.bi_size >> SECTOR_SHIFT;
+
+   range[n].flags = cpu_to_le32(flags);
+   range[n].num_sectors = cpu_to_le32(num_sectors);
+   range[n].sector = cpu_to_le64(sector);
+   n++;
+   }
+
+   req->special_vec.bv_page = virt_to_page(range);
+   req->special_vec.bv_offset = offset_in_page(range);
+   req->special_vec.bv_len = sizeof(*range) * segments;
+   req->rq_flags |= RQF_SPECIAL_PAYLOAD;
+
+   return 0;
+}
+
 static inline void virtblk_request_done(struct request *req)
 {
struct virtblk_req *vbr = blk_mq_rq_to_pdu(req);
 
+   if (req->rq_flags & RQF_SPECIAL_PAYLOAD) {
+   kfree(page_address(req->special_vec.bv_page) +
+ req->special_vec.bv_offset);
+   }
+
switch (req_op(req)) {
case REQ_OP_SCSI_IN:
case REQ_OP_SCSI_OUT:
@@ -225,6 +264,7 @@ static blk_status_t virtio_queue_rq(struct blk_mq_hw_ctx 
*hctx,
int qid = hctx->queue_num;
int err;
bool notify = false;
+   bool unmap = false;
u32 type;
 
BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems);
@@ -237,6 +277,13 @@ static blk_status_t virtio_queue_rq(struct blk_mq_hw_ctx 
*hctx,
case REQ_OP_FLUSH:
type = VIRTIO_BLK_T_FLUSH;
break;
+   case REQ_OP_DISCARD:
+   type = VIRTIO_BLK_T_DISCARD;
+   break;
+   case REQ_OP_WRITE_ZEROES:
+

Re: [PATCH v8] virtio_blk: add discard and write zeroes support

[Daniel Verkamp]

On Thu, Nov 1, 2018 at 2:25 PM Michael S. Tsirkin  wrote:
>
> On Mon, Oct 29, 2018 at 05:05:21AM +, Stefan Hajnoczi wrote:
> > On Fri, Oct 26, 2018 at 10:47:16AM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Oct 26, 2018 at 09:08:38AM +0100, Stefan Hajnoczi wrote:
> > > > On Fri, Oct 12, 2018 at 02:06:28PM -0700, Daniel Verkamp wrote:
> > > > > +   range[n].flags = cpu_to_le32(flags);
> > > > > +   range[n].num_sectors = cpu_to_le32(num_sectors);
> > > > > +   range[n].sector = cpu_to_le64(sector);
> > > > ...
> > > > > +/* Discard/write zeroes range for each request. */
> > > > > +struct virtio_blk_discard_write_zeroes {
> > > > > +   /* discard/write zeroes start sector */
> > > > > +   __virtio64 sector;
> > > > > +   /* number of discard/write zeroes sectors */
> > > > > +   __virtio32 num_sectors;
> > > > > +   /* flags for this range */
> > > > > +   __virtio32 flags;
> > > >
> > > > cpu_to_le32() is being used on __virtio32 fields instead of 
> > > > cpu_to_virtio32().
> > > >
> > > > From include/uapi/linux/virtio_types.h:
> > > >
> > > >   /*
> > > >* __virtio{16,32,64} have the following meaning:
> > > >* - __u{16,32,64} for virtio devices in legacy mode, accessed in 
> > > > native endian
> > > >* - __le{16,32,64} for standard-compliant virtio devices
> > > >*/
> > > >
> > > > From the VIRTIO specification:
> > > >
> > > >   struct virtio_blk_discard_write_zeroes {
> > > >  le64 sector;
> > > >  le32 num_sectors;
> > > >  struct {
> > > >  le32 unmap:1;
> > > >  le32 reserved:31;
> > > >  } flags;
> > > >   };
> > > >
> > > >
> > > > Since the VIRTIO spec says these fields are little-endian, I think these
> > > > fields should be declared just __u32 and __u64 instead of __virtio32 and
> > > > __virtio64.
> > > >
> > > > Stefan
> > >
> > >
> > > __le32/__le64 rather?
> >
> > Yes.
> >
> > Stefan
>
> I agree. And further using bitfields for this is questionable -
> it is preferable to set bits in a full 32 bit field using "|".

The bitfield is only in the specification, not the code - the actual
implementation in this patch (quoted above from earlier in the thread)
uses a 32-bit field with a flag #define.

I did misunderstand the meaning of __virtio32 vs __le32 - I'll fix
that up (I think the spec definition and code for these is already
correct; the structure definition just needs to change to match).

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

Re: [PULL] vhost: cleanups and fixes

[Linus Torvalds]

On Thu, Nov 1, 2018 at 2:19 PM Michael S. Tsirkin  wrote:
>
> virtio, vhost: fixes, tweaks

Pulled.

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

Re: [PATCH v8] virtio_blk: add discard and write zeroes support

[Michael S. Tsirkin]

On Mon, Oct 29, 2018 at 05:05:21AM +, Stefan Hajnoczi wrote:
> On Fri, Oct 26, 2018 at 10:47:16AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Oct 26, 2018 at 09:08:38AM +0100, Stefan Hajnoczi wrote:
> > > On Fri, Oct 12, 2018 at 02:06:28PM -0700, Daniel Verkamp wrote:
> > > > +   range[n].flags = cpu_to_le32(flags);
> > > > +   range[n].num_sectors = cpu_to_le32(num_sectors);
> > > > +   range[n].sector = cpu_to_le64(sector);
> > > ...
> > > > +/* Discard/write zeroes range for each request. */
> > > > +struct virtio_blk_discard_write_zeroes {
> > > > +   /* discard/write zeroes start sector */
> > > > +   __virtio64 sector;
> > > > +   /* number of discard/write zeroes sectors */
> > > > +   __virtio32 num_sectors;
> > > > +   /* flags for this range */
> > > > +   __virtio32 flags;
> > > 
> > > cpu_to_le32() is being used on __virtio32 fields instead of 
> > > cpu_to_virtio32().
> > > 
> > > From include/uapi/linux/virtio_types.h:
> > > 
> > >   /*
> > >* __virtio{16,32,64} have the following meaning:
> > >* - __u{16,32,64} for virtio devices in legacy mode, accessed in 
> > > native endian
> > >* - __le{16,32,64} for standard-compliant virtio devices
> > >*/
> > > 
> > > From the VIRTIO specification:
> > > 
> > >   struct virtio_blk_discard_write_zeroes {
> > >  le64 sector;
> > >  le32 num_sectors;
> > >  struct {
> > >  le32 unmap:1;
> > >  le32 reserved:31;
> > >  } flags;
> > >   };
> > > 
> > > 
> > > Since the VIRTIO spec says these fields are little-endian, I think these
> > > fields should be declared just __u32 and __u64 instead of __virtio32 and
> > > __virtio64.
> > > 
> > > Stefan
> > 
> > 
> > __le32/__le64 rather?
> 
> Yes.
> 
> Stefan

I agree. And further using bitfields for this is questionable -
it is preferable to set bits in a full 32 bit field using "|".


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