search for: drop_locks

On Tue, Sep 10, 2019 at 07:49:51AM +0000, Mircea CIRJALIU - MELIU wrote: > > On 05/09/19 20:09, Jerome Glisse wrote: > > > Not sure i understand, you are saying that the solution i outline > > > above does not work ? If so then i think you are wrong, in the above > > > solution the importing process mmap a device file and the resulting > > > vma is then

...ap->start, cmap->green, - cmap->len * sizeof(u16)); - memcpy(b + cmap->start, cmap->blue, - cmap->len * sizeof(u16)); + crtc = fb_helper->crtc_info[i].mode_set.crtc; + if (!crtc->funcs->gamma_set || !crtc->gamma_size) { + ret = -EINVAL; + goto drop_locks; } - for (j = 0; j < cmap->len; j++) { - u16 hred, hgreen, hblue, htransp = 0xffff; + if (cmap->start + cmap->len > crtc->gamma_size) { + ret = -EINVAL; + goto drop_locks; + } - hred = *red++; - hgreen = *green++; - hblue = *blue++; + r = crtc->gamma_stor...

On 02/10/19 21:27, Jerome Glisse wrote: > On Tue, Sep 10, 2019 at 07:49:51AM +0000, Mircea CIRJALIU - MELIU wrote: >>> On 05/09/19 20:09, Jerome Glisse wrote: >>>> Not sure i understand, you are saying that the solution i outline >>>> above does not work ? If so then i think you are wrong, in the above >>>> solution the importing process mmap a

On 02/10/19 21:27, Jerome Glisse wrote: > On Tue, Sep 10, 2019 at 07:49:51AM +0000, Mircea CIRJALIU - MELIU wrote: >>> On 05/09/19 20:09, Jerome Glisse wrote: >>>> Not sure i understand, you are saying that the solution i outline >>>> above does not work ? If so then i think you are wrong, in the above >>>> solution the importing process mmap a

...c_funcs->load_lut(crtc); + ret = crtc->funcs->gamma_set(crtc, r, g, b, + crtc->gamma_size, &ctx); + if (ret) + break; } - out: - drm_modeset_unlock_all(dev); - return rc; +out: + if (ret == -EDEADLK) { + drm_modeset_backoff(&ctx); + goto retry; + } + drm_modeset_drop_locks(&ctx); + drm_modeset_acquire_fini(&ctx); + + return ret; } EXPORT_SYMBOL(drm_fb_helper_setcmap); -- 2.1.4

On Wed, Oct 02, 2019 at 10:10:18PM +0200, Paolo Bonzini wrote: > On 02/10/19 19:04, Jerome Glisse wrote: > > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: > >>>> If the mapping of the source VMA changes, mirroring can update the > >>>> target VMA via insert_pfn. But what ensures that KVM's MMU notifier > >>>> dismantles

Hi Benjamin: I think that the following link will give you an idea for what you need to know: http://www.cisco.com/warp/customer/620/roadmap_b.shtml This is for the naming: http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_tech_note09186a0080101cda.shtml In this case 11.1CC goes to 12.0T and 12.0T migrate to 12.1 mainline. Do not you worry you will not loose anything with the new

From: Mircea C?rjaliu <mcirjaliu at bitdefender.com> The following two new mm exports are introduced: * mm_remote_map(struct mm_struct *req_mm, unsigned long req_hva, unsigned long map_hva) * mm_remote_unmap(unsigned long map_hva) * mm_remote_reset(void) * rmap_walk_remote(struct page *page, struct rmap_walk_control *rwc) This patch

On 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> If the mapping of the source VMA changes, mirroring can update the >>>> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >>>> dismantles its own existing page tables (so that they can be recreated >>>> with the new

On 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> If the mapping of the source VMA changes, mirroring can update the >>>> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >>>> dismantles its own existing page tables (so that they can be recreated >>>> with the new

This patch plugs a race between the downconvert thread and an unlock ast message. Specifically, after the downconvert worker has done its task, the dc thread needs to check whether an unlock ast made the downconvert moot. Reported-by: David Teigland <teigland at redhat.com> Signed-off-by: Sunil Mushran <sunil.mushran at oracle.com> Acked-by: Mark Fasheh <mfasheh at sus.com> ---

...0x390a0 in mbox_update_locking (mbox=0xdd100, lock_type=-4263232) at mbox-lock.c:492 ctx = {mbox = 0xdd100, lock_status = {1, 0, 0, 0}, checked_file = false, lock_type = 2, dotlock_last_stale = true} max_wait_time = -4263232 ret = 905472 i = 1169749509 drop_locks = false #6 0x3932c in mbox_lock (mbox=0xdd100, lock_type=2, lock_id_r=0xffbef3ec) at mbox-lock.c:534 ret = 905472 #7 0x3ef14 in mbox_sync (mbox=0xdd100, flags=44) at mbox-sync.c:1642 lock_type = 2 index_sync_ctx = (struct mail_index_sync_ctx *) 0x156e1302 sync_...

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 and 3 are enough to make the atmel-hlcdc driver do what I need (when patched

Not really interesting yet, this just gets us to the state where single queue boots on a current kernel. Signed-off-by: Jens Axboe <axboe at kernel.dk> --- block/Kconfig | 5 + block/Kconfig.iosched | 2 + block/blk-core.c | 427 ++++++++++++++++++-------------------- block/blk-exec.c | 14 +- block/blk-flush.c

Not really interesting yet, this just gets us to the state where single queue boots on a current kernel. Signed-off-by: Jens Axboe <axboe at kernel.dk> --- block/Kconfig | 5 + block/Kconfig.iosched | 2 + block/blk-core.c | 427 ++++++++++++++++++-------------------- block/blk-exec.c | 14 +- block/blk-flush.c