search for: in_interrupt

...> if we end up calling vfree() and have to take the mutex. > > > > FWIW __vfree already checks for atomic context and put the work into a > > deferred context. So this should be safe. It should be used as a last > > resort, though. > > Actually, it only checks for in_interrupt(). You are right. I have misremembered. You have made me look (thanks) ... > If you call vfree() under > a spinlock, you're in trouble. in_atomic() only knows if we hold a > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > in __vfree(). So we need the...

...> if we end up calling vfree() and have to take the mutex. > > > > FWIW __vfree already checks for atomic context and put the work into a > > deferred context. So this should be safe. It should be used as a last > > resort, though. > > Actually, it only checks for in_interrupt(). You are right. I have misremembered. You have made me look (thanks) ... > If you call vfree() under > a spinlock, you're in trouble. in_atomic() only knows if we hold a > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > in __vfree(). So we need the...

On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: > > On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > > v4: > > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > > so

On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: > > On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > > v4: > > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > > so

...mapping(struct gnttab_map_grant_ref *map_ops, + struct gnttab_map_grant_ref *kmap_ops, + struct page **pages, unsigned int count) +{ + int i, ret = 0; + bool lazy = false; + pte_t *pte; + + if (xen_feature(XENFEAT_auto_translated_physmap)) + return 0; + + if (kmap_ops && + !in_interrupt() && + paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) { + arch_enter_lazy_mmu_mode(); + lazy = true; + } + + for (i = 0; i < count; i++) { + unsigned long mfn, pfn; + + /* Do not add to override if the map failed. */ + if (map_ops[i].status) + continue; + + if (map_ops[i].fl...

...mapping(struct gnttab_map_grant_ref *map_ops, + struct gnttab_map_grant_ref *kmap_ops, + struct page **pages, unsigned int count) +{ + int i, ret = 0; + bool lazy = false; + pte_t *pte; + + if (xen_feature(XENFEAT_auto_translated_physmap)) + return 0; + + if (kmap_ops && + !in_interrupt() && + paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) { + arch_enter_lazy_mmu_mode(); + lazy = true; + } + + for (i = 0; i < count; i++) { + unsigned long mfn, pfn; + + /* Do not add to override if the map failed. */ + if (map_ops[i].status) + continue; + + if (map_ops[i].fl...

This patch is a significant performance improvement for the m2p_override: about 6% using the gntdev device. Each m2p_add/remove_override call issues a MULTI_grant_table_op and a __flush_tlb_single if kmap_op != NULL. Batching all the calls together is a great performance benefit because it means issuing one hypercall total rather than two hypercall per page. If paravirt_lazy_mode is set

This changes the fb name from "nouveaufb" to "nouveaudrmfb". Aside: I wonder whether the in_interrupt() check is good enough for the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed, which isn't actually working if you pick a .config without PREEMPT. For the generic fbdev defio support we've gone with offloading everything to a worker. For the non-accel callbacks (set_par, bl...

...const struct fb_fillrect *rect) -{ - struct nouveau_fbdev *fbcon = info->par; - struct nouveau_drm *drm = nouveau_drm(fbcon->helper.dev); - struct nvif_device *device = &drm->client.device; - int ret; - - if (info->state != FBINFO_STATE_RUNNING) - return; - - ret = -ENODEV; - if (!in_interrupt() && !(info->flags & FBINFO_HWACCEL_DISABLED) && - mutex_trylock(&drm->client.mutex)) { - if (device->info.family < NV_DEVICE_INFO_V0_TESLA) - ret = nv04_fbcon_fillrect(info, rect); - else - if (device->info.family < NV_DEVICE_INFO_V0_FERMI) - re...

...struct nouveau_drm *drm = nouveau_drm(fbcon->helper.dev); > - struct nvif_device *device = &drm->client.device; > - int ret; > - > - if (info->state != FBINFO_STATE_RUNNING) > - return; > - > - ret = -ENODEV; > - if (!in_interrupt() && !(info->flags & FBINFO_HWACCEL_DISABLED) && > - mutex_trylock(&drm->client.mutex)) { > - if (device->info.family < NV_DEVICE_INFO_V0_TESLA) > - ret = nv04_fbcon_fillrect(info, rect); > -...

...au_drm(fbcon->helper.dev); >> - struct nvif_device *device = &drm->client.device; >> - int ret; >> - >> - if (info->state != FBINFO_STATE_RUNNING) >> - return; >> - >> - ret = -ENODEV; >> - if (!in_interrupt() && !(info->flags & FBINFO_HWACCEL_DISABLED) && >> - mutex_trylock(&drm->client.mutex)) { >> - if (device->info.family < NV_DEVICE_INFO_V0_TESLA) >> - ret = nv04_fbcon_fillrect(info, rect); >>...

Hello, This is a question about diffserv on linux. We know, there is a file sch_dsmark in linux source code. Now, i want to add something in the function dsmark_enqueue, for example, i want to add a function which can add a class and queue automately in dsmark_enqueue. That is, not using the command tc. After adding one, it works well, but when add the second one, there is a kernel panic:

...ruct zs_pool *pool, unsigned long handle, struct page *pages[2]; void *ret; - BUG_ON(!handle); - /* * Because we use per-cpu mapping areas shared among the * pools/users, we can't allow mapping in interrupt context * because it can corrupt another users mappings. */ - BUG_ON(in_interrupt()); + WARN_ON_ONCE(in_interrupt()); /* From now on, migration cannot move the object */ pin_tag(handle); @@ -1324,8 +1322,6 @@ void zs_unmap_object(struct zs_pool *pool, unsigned long handle) struct size_class *class; struct mapping_area *area; - BUG_ON(!handle); - obj = handle_to_obj...

...const struct fb_fillrect *rect) -{ - struct nouveau_fbdev *fbcon = info->par; - struct nouveau_drm *drm = nouveau_drm(fbcon->helper.dev); - struct nvif_device *device = &drm->client.device; - int ret; - - if (info->state != FBINFO_STATE_RUNNING) - return; - - ret = -ENODEV; - if (!in_interrupt() && !(info->flags & FBINFO_HWACCEL_DISABLED) && - mutex_trylock(&drm->client.mutex)) { - if (device->info.family < NV_DEVICE_INFO_V0_TESLA) - ret = nv04_fbcon_fillrect(info, rect); - else - if (device->info.family < NV_DEVICE_INFO_V0_FERMI) - re...

...dness and bad design i915 might do from radeon. That imo doesn't invalidate the overall fence interfaces. So what about the following: - fence->enabling_signaling is restricted to be called from process context. We don't use any different yet, so would boild down to adding a WARN_ON(in_interrupt) or so to fence_enable_sw_signalling. - Make fence->signaled optional (already the case) and don't implement it in readon (i.e. reduce this patch here). Only downside is that radeon needs to correctly (i.e. without races or so) call fence_signal. And the cross-driver synchronization m...

.... That imo doesn't invalidate the overall fence interfaces. >> >> So what about the following: >> - fence->enabling_signaling is restricted to be called from process >> context. We don't use any different yet, so would boild down to adding a >> WARN_ON(in_interrupt) or so to fence_enable_sw_signalling. >> >> - Make fence->signaled optional (already the case) and don't implement it >> in readon (i.e. reduce this patch here). Only downside is that radeon >> needs to correctly (i.e. without races or so) call fence_signal. And...

This changes the fb name from "nouveaufb" to "nouveaudrmfb". Aside: I wonder whether the in_interrupt() check is good enough for the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed, which isn't actually working if you pick a .config without PREEMPT. For the generic fbdev defio support we've gone with offloading everything to a worker. For the non-accel callbacks (set_par, bl...

...we can get into trouble > > if we end up calling vfree() and have to take the mutex. > > FWIW __vfree already checks for atomic context and put the work into a > deferred context. So this should be safe. It should be used as a last > resort, though. Actually, it only checks for in_interrupt(). If you call vfree() under a spinlock, you're in trouble. in_atomic() only knows if we hold a spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() in __vfree(). So we need the warning in order that preempt people can tell those without that there is a bug here.

..._atomic() only knows if we hold a > > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > > in __vfree(). So we need the warning in order that preempt people can > > tell those without that there is a bug here. > > ... Unless I am missing something in_interrupt depends on preempt_count() as > well so neither of the two is reliable without PREEMPT_COUNT configured. preempt_count() always tracks whether we're in interrupt context, regardless of CONFIG_PREEMPT. The difference is that CONFIG_PREEMPT will track spinlock acquisitions as well.

...nce *fence) { + bool ret; + if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags)) return true; - if (fence->ops->signaled && fence->ops->signaled(fence)) { + if (!fence->ops->signaled) + return false; + + if (config_enabled(CONFIG_PROVE_LOCKING)) + WARN_ON(in_interrupt() || irqs_disabled()); + + if (config_enabled(CONFIG_DEBUG_ATOMIC_SLEEP)) + preempt_disable(); + + ret = fence->ops->signaled(fence); + + if (config_enabled(CONFIG_DEBUG_ATOMIC_SLEEP)) + preempt_enable(); + + if (ret) fence_signal(fence); - return true; - } - return false; + return re...