ICITS'19 - Quito, Ecuador; Deadline: September 16

2018-08-31 Thread Marle
* Proceedings by Springer, indexed in Scopus, ISI, etc.



***

ICITS'19 - The 2019 International Conference on Information Technology & Systems

Quito, Ecuador, 6 - 8 February 2019

http://www.icits.me 





ICITS'19 - The 2019 International Conference on Information Technology & 
Systems, to be held at Quito, Ecuador, 6 - 8 February 2019, is an international 
forum for researchers and practitioners to present and discuss the most recent 
innovations, trends, results, experiences and concerns in the several 
perspectives of Information Technology & Systems.

We are pleased to invite you to submit your papers to ICITS'19. They can be 
written in English, Spanish or Portuguese. All submissions will be reviewed on 
the basis of relevance, originality, importance and clarity.



Topics

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) Cybersecurity and Cyber-defense;

N) Electromagnetics, Sensors and Antennas for Security.



Submission and Decision

Submitted papers written in English (until 10-page limit) must comply with the 
format of Advances in Intelligent Systems and Computing series (see 
Instructions for Authors at Springer Website 
 or download a DOC example 
), 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 Scientific 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.

Submitted papers written in Spanish or Portuguese (until 15-page limit) must 
comply with the format of RISTI  - Revista Ibérica de 
Sistemas e Tecnologias de Informação (download instructions/template for 
authors in Spanish  or Portuguese 
), 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 Scientific Committee. This information should 
only be included in the camera-ready version, saved in Word. These file must be 
uploaded at the conference management system in a ZIP file.

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

Based on Scientific Committee evaluation, a paper can be rejected or accepted 
by the Conference Chairs. In the later case, it can be accepted as paper or 
poster.

The authors of papers accepted as posters must 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 7 minute limit per poster.

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



Publication and Indexing

To ensure that an accepted paper is published, at least one of the authors must 
be fully registered by the 9th of November 2018, and the paper must comply with 
the suggested layout and page-limit. Additionally, all recommended changes must 
be addressed by the authors before they submit the camera-ready version.

No more than one paper per registration will be published. An extra fee must be 
paid for publication of additional papers, with a maximum of one additional 
paper per registration. One registration permits only the participation of one 
author in the conference.

Papers written in English and accepted and registered will be published in 
Proceedings by Springer, 

Re: [PATCH v2 00/12] remove_conflicting_framebuffers() cleanup

2018-08-31 Thread Chris Wilson
Quoting Daniel Vetter (2018-08-31 10:04:39)
> On Thu, Aug 30, 2018 at 11:00:01PM +0200, Michał Mirosław wrote:
> > This series cleans up duplicated code for replacing firmware FB
> > driver with proper DRI driver and adds handover support to
> > Tegra driver.
> > 
> > This is a sligtly updated version of a series sent on 24 Nov 2017.
> > 
> > v2:
> >  - rebased on current drm-next
> >  - dropped staging/sm750fb changes
> >  - added kernel docs for DRM helpers
> > 
> > Michał Mirosław (12):
> >   fbdev: show fbdev number for debugging
> >   fbdev: allow apertures == NULL in remove_conflicting_framebuffers()
> >   fbdev: add remove_conflicting_pci_framebuffers()
> >   drm/amdgpu: use simpler remove_conflicting_pci_framebuffers()
> >   drm/bochs: use simpler remove_conflicting_pci_framebuffers()
> >   drm/cirrus: use simpler remove_conflicting_pci_framebuffers()
> >   drm/mgag200: use simpler remove_conflicting_pci_framebuffers()
> >   drm/radeon: use simpler remove_conflicting_pci_framebuffers()
> >   drm/virtio: use simpler remove_conflicting_pci_framebuffers()
> >   drm/vc4: use simpler remove_conflicting_framebuffers(NULL)
> >   drm/sun4i: use simpler remove_conflicting_framebuffers(NULL)
> >   drm/tegra: kick out simplefb
> 
> Looks very neat. A bit confused about the drm changes in the fbdev-titled
> patches 1&3, but I guess we can merge as-is. Up to you whether you want to
> split or not I'd say.

Ahah, someone is looking at remove_conflicting_framebuffers(). May I
interest you in a use-after-free?

[  378.423513] stack segment:  [#1] PREEMPT SMP PTI
[  378.423530] CPU: 1 PID: 4338 Comm: pm_rpm Tainted: G U
4.19.0-rc1-CI-CI_DRM_4746+ #1
[  378.423548] Hardware name: To Be Filled By O.E.M. To Be Filled By 
O.E.M./J4205-ITX, BIOS P1.10 09/29/2016
[  378.423570] RIP: 0010:do_remove_conflicting_framebuffers+0x56/0x170
[  378.423587] Code: 49 8b 45 00 48 85 c0 74 50 f6 40 0a 08 74 4a 4d 85 e4 48 
8b a8 78 04 00 00 74 1f 48 85 ed 74 1a 41 8b 0c 24 31 db 85 c9 74 10 <8b> 55 00 
85 d2 75 42 83 c3 01 41 39 1c 24 77 f0 48 85 ed 74 1a 45
[  378.423620] RSP: 0018:c91dfa88 EFLAGS: 00010202
[  378.423632] RAX: 880274470008 RBX:  RCX: 0001
[  378.423646] RDX: 0001 RSI: a025c634 RDI: 88025cc3b428
[  378.423660] RBP: 6b6b6b6b6b6b6b6b R08: 1edaddfa R09: a025c634
[  378.423673] R10: c91dfae8 R11: 820de938 R12: 88025cc3b428
[  378.423687] R13: 8234ca20 R14: 8234cb20 R15: 0001
[  378.423701] FS:  7fcf03d0a980() GS:880277e8() 
knlGS:
[  378.423717] CS:  0010 DS:  ES:  CR0: 80050033
[  378.423729] CR2: 7fffece1fdb8 CR3: 0001fe32e000 CR4: 003406e0
[  378.423742] Call Trace:
[  378.423756]  remove_conflicting_framebuffers+0x28/0x40
[  378.423856]  i915_driver_load+0x7f5/0x10c0 [i915]
[  378.423873]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
[  378.423887]  ? lockdep_hardirqs_on+0xe0/0x1b0
[  378.423962]  i915_pci_probe+0x29/0xa0 [i915]
[  378.423977]  pci_device_probe+0xa1/0x130
[  378.423990]  really_probe+0x25d/0x3c0
[  378.424002]  driver_probe_device+0x10a/0x120
[  378.424013]  __driver_attach+0xdb/0x100
[  378.424025]  ? driver_probe_device+0x120/0x120
[  378.424037]  bus_for_each_dev+0x74/0xc0
[  378.424048]  bus_add_driver+0x15f/0x250
[  378.424060]  ? 0xa069d000
[  378.424070]  driver_register+0x56/0xe0
[  378.424080]  ? 0xa069d000
[  378.424090]  do_one_initcall+0x58/0x2e0
[  378.424101]  ? rcu_lockdep_current_cpu_online+0x8f/0xd0
[  378.424116]  ? do_init_module+0x1d/0x1ea
[  378.424127]  ? rcu_read_lock_sched_held+0x6f/0x80
[  378.424141]  ? kmem_cache_alloc_trace+0x264/0x290
[  378.424154]  do_init_module+0x56/0x1ea
[  378.424167]  load_module+0x26ba/0x29a0
[  378.424182]  ? vfs_read+0x122/0x140
[  378.424199]  ? __se_sys_finit_module+0xd3/0xf0
[  378.424210]  __se_sys_finit_module+0xd3/0xf0
[  378.424226]  do_syscall_64+0x55/0x190
[  378.424237]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  378.424249] RIP: 0033:0x7fcf02f9b839
[  378.424258] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
[  378.424290] RSP: 002b:7fffece21f58 EFLAGS: 0246 ORIG_RAX: 
0139
[  378.424307] RAX: ffda RBX: 56344e1a4d80 RCX: 7fcf02f9b839
[  378.424321] RDX:  RSI: 7fcf026470e5 RDI: 0003
[  378.424336] RBP: 7fcf026470e5 R08:  R09: 
[  378.424349] R10: 0003 R11: 0246 R12: 
[  378.424363] R13: 56344e1a R14:  R15: 56344e1a4d80

https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4613/fi-bxt-j4205/dmesg0.log
-Chris
___
Virtualization mailing list

Re: [PATCH v2 02/12] fbdev: allow apertures == NULL in remove_conflicting_framebuffers()

2018-08-31 Thread Daniel Vetter
On Fri, Aug 31, 2018 at 10:56:56AM +0200, Daniel Vetter wrote:
> On Thu, Aug 30, 2018 at 11:00:05PM +0200, Michał Mirosław wrote:
> > Interpret (otherwise-invalid) NULL apertures argument to mean all-memory
> > range. This will allow to remove several duplicates of this code from
> > drivers in following patches.
> > 
> > Signed-off-by: Michał Mirosław 
> > [for v1]
> > Acked-by: Bartlomiej Zolnierkiewicz 
> > 
> > ---
> > v2: added kerneldoc to corresponding DRM helper
> > ---
> >  drivers/video/fbdev/core/fbmem.c | 14 ++
> >  include/drm/drm_fb_helper.h  | 10 ++
> >  2 files changed, 24 insertions(+)
> > 
> > diff --git a/drivers/video/fbdev/core/fbmem.c 
> > b/drivers/video/fbdev/core/fbmem.c
> > index 30a18d4c9de4..0df148eb4699 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1779,11 +1779,25 @@ int remove_conflicting_framebuffers(struct 
> > apertures_struct *a,
> > const char *name, bool primary)
> >  {
> > int ret;
> > +   bool do_free = false;
> > +
> > +   if (!a) {
> > +   a = alloc_apertures(1);
> > +   if (!a)
> > +   return -ENOMEM;
> > +
> > +   a->ranges[0].base = 0;
> > +   a->ranges[0].size = ~0;
> > +   do_free = true;
> > +   }
> >  
> > mutex_lock(_lock);
> > ret = do_remove_conflicting_framebuffers(a, name, primary);
> > mutex_unlock(_lock);
> >  
> > +   if (do_free)
> > +   kfree(a);
> > +
> > return ret;
> >  }
> >  EXPORT_SYMBOL(remove_conflicting_framebuffers);
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index b069433e7fc1..1c1e53abb25d 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -566,6 +566,16 @@ static inline void 
> > drm_fb_helper_output_poll_changed(struct drm_device *dev)
> >  
> >  #endif
> >  
> > +/**
> > + * drm_fb_helper_remove_conflicting_framebuffers - remove firmware 
> > framebuffers
> > + * @a: memory range, users of which are to be removed
> > + * @name: requesting driver name
> > + * @primary: also kick vga16fb if present
> > + *
> > + * This function removes framebuffer devices (eg. initialized by firmware)
> > + * which use memory range described by @a. If @a is NULL all such devices 
> > are
> > + * removed.
> > + */
> 
> This looks like misplaced copypasta. You only need this once I think.

Ah no, just a fixup for the lack of kerneldoc we have. Can you pls split
this out into a separate patch?

Thanks, Daniel

> -Daniel
> 
> >  static inline int
> >  drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> >   const char *name, bool primary)
> > -- 
> > 2.18.0
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: KASAN: use-after-free Read in vhost_work_queue

2018-08-31 Thread Stefan Hajnoczi
On Tue, Aug 28, 2018 at 11:11:21AM -0400, Michael S. Tsirkin wrote:
> On Tue, Aug 28, 2018 at 07:44:03AM -0700, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following crash on:
> > 
> > HEAD commit:33e17876ea4e Merge branch 'akpm' (patches from Andrew)
> > git tree:   upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12d8a20a40
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=40e5d6b26b73cd5b
> > dashboard link: https://syzkaller.appspot.com/bug?extid=d5a0a170c5069658b141
> > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > userspace arch: i386
> > 
> > Unfortunately, I don't have any reproducer for this crash yet.
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+d5a0a170c5069658b...@syzkaller.appspotmail.com
> > 
> > ==
> > BUG: KASAN: use-after-free in vhost_work_queue+0xc3/0xe0
> > drivers/vhost/vhost.c:258
> > Read of size 8 at addr 880193862068 by task syz-executor7/22100
> > 
> > CPU: 0 PID: 22100 Comm: syz-executor7 Not tainted 4.18.0+ #108
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:77 [inline]
> >  dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> >  print_address_description+0x6c/0x20b mm/kasan/report.c:256
> >  kasan_report_error mm/kasan/report.c:354 [inline]
> >  kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
> >  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> >  vhost_work_queue+0xc3/0xe0 drivers/vhost/vhost.c:258
> >  vhost_transport_send_pkt+0x28a/0x380 drivers/vhost/vsock.c:227
> >  virtio_transport_send_pkt_info+0x31d/0x460
> > net/vmw_vsock/virtio_transport_common.c:190
> >  virtio_transport_shutdown+0x1b1/0x270
> > net/vmw_vsock/virtio_transport_common.c:604
> >  vsock_send_shutdown net/vmw_vsock/af_vsock.c:451 [inline]
> >  vsock_shutdown+0x229/0x290 net/vmw_vsock/af_vsock.c:849
> >  __sys_shutdown+0x15c/0x2c0 net/socket.c:1964
> >  __do_sys_shutdown net/socket.c:1972 [inline]
> >  __se_sys_shutdown net/socket.c:1970 [inline]
> >  __ia32_sys_shutdown+0x54/0x80 net/socket.c:1970
> >  do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
> >  do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
> >  entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> > RIP: 0023:0xf7fa4ca9
> > Code: 55 08 8b 88 64 cd ff ff 8b 98 68 cd ff ff 89 c8 85 d2 74 02 89 0a 5b
> > 5d c3 8b 04 24 c3 8b 1c 24 c3 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90
> > 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
> > RSP: 002b:f5f7f0cc EFLAGS: 0296 ORIG_RAX: 0175
> > RAX: ffda RBX: 0009 RCX: 
> > RDX:  RSI:  RDI: 
> > RBP:  R08:  R09: 
> > R10:  R11:  R12: 
> > R13:  R14:  R15: 
> > 
> > Allocated by task 22094:
> >  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> >  set_track mm/kasan/kasan.c:460 [inline]
> >  kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> >  __do_kmalloc_node mm/slab.c:3682 [inline]
> >  __kmalloc_node+0x47/0x70 mm/slab.c:3689
> >  kmalloc_node include/linux/slab.h:555 [inline]
> >  kvmalloc_node+0xb9/0xf0 mm/util.c:423
> >  kvmalloc include/linux/mm.h:577 [inline]
> >  vhost_vsock_dev_open+0xa2/0x5a0 drivers/vhost/vsock.c:511
> >  misc_open+0x3ca/0x560 drivers/char/misc.c:141
> >  chrdev_open+0x25a/0x770 fs/char_dev.c:417
> >  do_dentry_open+0x49c/0x1140 fs/open.c:771
> >  vfs_open+0xa0/0xd0 fs/open.c:880
> >  do_last fs/namei.c:3418 [inline]
> >  path_openat+0x12fb/0x5300 fs/namei.c:3534
> >  do_filp_open+0x255/0x380 fs/namei.c:3564
> >  do_sys_open+0x584/0x720 fs/open.c:1063
> >  __do_compat_sys_openat fs/open.c:1109 [inline]
> >  __se_compat_sys_openat fs/open.c:1107 [inline]
> >  __ia32_compat_sys_openat+0x98/0xf0 fs/open.c:1107
> >  do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
> >  do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
> >  entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> > 
> > Freed by task 22093:
> >  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> >  set_track mm/kasan/kasan.c:460 [inline]
> >  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> >  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> >  __cache_free mm/slab.c:3498 [inline]
> >  kfree+0xd9/0x210 mm/slab.c:3813
> >  kvfree+0x61/0x70 mm/util.c:449
> >  vhost_vsock_free drivers/vhost/vsock.c:499 [inline]
> >  vhost_vsock_dev_release+0x4fd/0x750 drivers/vhost/vsock.c:604
> >  __fput+0x36e/0x8c0 fs/file_table.c:278
> >  fput+0x15/0x20 fs/file_table.c:309
> >  task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
> >  tracehook_notify_resume include/linux/tracehook.h:193 [inline]
> >