Re: [BUG] lockdep splat with kernfs lockdep annotations and slab mutex from drm patch??

2019-06-14 Thread Tejun Heo
Hello, On Fri, Jun 14, 2019 at 04:08:33PM +0100, Chris Wilson wrote: > #ifdef CONFIG_MEMCG > if (slab_state >= FULL && err >= 0 && is_root_cache(s)) { > struct kmem_cache *c; > > mutex_lock(_mutex); > > so it happens to hit the error + FULL case with the

Re: [RFC PATCH v2 4/5] drm, cgroup: Add total GEM buffer allocation limit

2019-05-16 Thread Tejun Heo
Hello, I haven't gone through the patchset yet but some quick comments. On Wed, May 15, 2019 at 10:29:21PM -0400, Kenny Ho wrote: > Given this controller is specific to the drm kernel subsystem which > uses minor to identify drm device, I don't see a need to complicate > the interfaces more by

Re: [RFC PATCH 0/5] cgroup support for GPU devices

2019-05-09 Thread Tejun Heo
Hello, On Tue, May 07, 2019 at 12:50:50PM -0700, Welty, Brian wrote: > There might still be merit in having a 'device mem' cgroup controller. > The resource model at least is then no longer mixed up with host memory. > RDMA community seemed to have some interest in a common controller at > least

Re: [RFC PATCH 0/5] cgroup support for GPU devices

2019-05-06 Thread Tejun Heo
Hello, On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote: > The patch series enables device drivers to use cgroups to control the > following resources within a GPU (or other accelerator device): > * control allocation of device memory (reuse of memcg) > and with future work, we could

Re: [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices

2018-11-20 Thread Tejun Heo
Hello, On Tue, Nov 20, 2018 at 10:21:14PM +, Ho, Kenny wrote: > By this reply, are you suggesting that vendor specific resources > will never be acceptable to be managed under cgroup? Let say a user I wouldn't say never but whatever which gets included as a cgroup controller should have

Re: [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices

2018-11-20 Thread Tejun Heo
Hello, On Tue, Nov 20, 2018 at 01:58:11PM -0500, Kenny Ho wrote: > Since many parts of the DRM subsystem has vendor-specific > implementations, we introduce mechanisms for vendor to register their > specific resources and control files to the DRM cgroup subsystem. A > vendor will register itself

Re: [PATCH 02/12] blk: use for_each_if

2018-07-11 Thread Tejun Heo
On Wed, Jul 11, 2018 at 01:31:51PM -0600, Jens Axboe wrote: > I don't think there's a git easy way of sending it out outside of > just ensuring that everybody is CC'ed on everything. I don't mind > that at all. I don't subscribe to lkml, and the patches weren't > sent to linux-block. Hence all I

Re: [PATCH 03/12] cgroup: use for_each_if

2018-07-11 Thread Tejun Heo
On Mon, Jul 09, 2018 at 10:36:41AM +0200, Daniel Vetter wrote: > Avoids the need to invert the condition instead of the open-coded > version. > > Signed-off-by: Daniel Vetter > Cc: Tejun Heo > Cc: Li Zefan > Cc: Johannes Weiner > Cc: cgro...@vger.kernel.org Acked-by:

Re: [PATCH 02/12] blk: use for_each_if

2018-07-11 Thread Tejun Heo
On Wed, Jul 11, 2018 at 09:40:58AM -0700, Tejun Heo wrote: > On Mon, Jul 09, 2018 at 10:36:40AM +0200, Daniel Vetter wrote: > > Makes the macros resilient against if {} else {} blocks right > > afterwards. > > > > Signed-off-by: Daniel Vetter > > Cc: Teju

Re: [PATCH 02/12] blk: use for_each_if

2018-07-11 Thread Tejun Heo
On Mon, Jul 09, 2018 at 10:36:40AM +0200, Daniel Vetter wrote: > Makes the macros resilient against if {} else {} blocks right > afterwards. > > Signed-off-by: Daniel Vetter > Cc: Tejun Heo > Cc: Jens Axboe > Cc: Shaohua Li > Cc: Kate Stewart > Cc: Greg Kroah-Har

[PATCH] drm: fix fallouts from slow-work -> wq conversion

2018-06-19 Thread Tejun Heo
>From 9a919c46dfa48a9c1f465174609b90253eb8ffc1 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Mon, 9 Aug 2010 12:01:27 +0200 Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference betw

[PATCH wq#for-linus] drm: fix a fallout from slow-work -> wq conversion

2018-06-19 Thread Tejun Heo
fails and only uses the return value to indicate whether the work was already pending or not. This misconversion triggered spurious error messages. Remove the now unnecessary return value check and error message. Signed-off-by: Tejun Heo Reported-by: Markus Trippelsdorf Cc: David Airlie Cc: dri

Re: [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data

2018-03-13 Thread Tejun Heo
Hello, Matt. cc'ing Roman and Alexei. On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote: > There are cases where other parts of the kernel may wish to store data > associated with individual cgroups without building a full cgroup > controller. Let's add interfaces to allow them to

Re: [PATCH v3 3/6] cgroup: Introduce cgroup_permission()

2018-03-13 Thread Tejun Heo
On Tue, Mar 06, 2018 at 03:46:57PM -0800, Matt Roper wrote: > Non-controller kernel subsystems may base access restrictions for > cgroup-related syscalls/ioctls on a process' access to the cgroup. > Let's make it easy for other parts of the kernel to check these cgroup > permissions. I'm not sure

Re: [PATCH v3 2/6] cgroup: Introduce task_get_dfl_cgroup()

2018-03-13 Thread Tejun Heo
(cc'ing Roman) Hello, On Tue, Mar 06, 2018 at 03:46:56PM -0800, Matt Roper wrote: > +static inline struct cgroup * > +task_get_dfl_cgroup(struct task_struct *task) > +{ > + struct cgroup *cgrp; > + > + mutex_lock(_mutex); > + cgrp = task_dfl_cgroup(task); > + cgroup_get(cgrp); >

Re: [PATCH 1/5] workqueue: Allow retrieval of current task's work struct

2018-02-12 Thread Tejun Heo
context of the worker. > > Cc: Tejun Heo <t...@kernel.org> > Cc: Lai Jiangshan <jiangshan...@gmail.com> > Cc: Dave Airlie <airl...@redhat.com> > Cc: Ben Skeggs <bske...@redhat.com> > Cc: Alex Deucher <alexander.deuc...@amd.com> > Signed

Re: [PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership

2018-02-07 Thread Tejun Heo
Hello, On Thu, Feb 01, 2018 at 11:53:11AM -0800, Matt Roper wrote: > +/** > + * cgroup_for_driver_process - return the cgroup for a process > + * @pid: process to lookup cgroup for > + * > + * Returns the cgroup from the v2 hierarchy that a process belongs to. > + * This function is intended to

Re: [PATCH RFC v2 1/7] cgroup: Allow drivers to store data associated with a cgroup

2018-02-07 Thread Tejun Heo
Hello, On Thu, Feb 01, 2018 at 11:53:09AM -0800, Matt Roper wrote: > * Drivers may be built as modules (and unloaded/reloaded) which is not >something cgroup controllers support today. As discussed in the other subthread, this shouldn't be a concern. > * Drivers may wish to provide their

Re: [Intel-gfx] [IGT PATCH RFC] tools: Introduce intel_cgroup tool

2018-02-07 Thread Tejun Heo
Hello, Forgot to respond to one point. On Thu, Feb 01, 2018 at 03:14:38PM -0800, Matt Roper wrote: > * The drivers that want to make use of this functionality may be built >as modules rather than compiled directly into the kernel. This is >important because the cgroups subsystem

Re: [Intel-gfx] [IGT PATCH RFC] tools: Introduce intel_cgroup tool

2018-02-07 Thread Tejun Heo
Hello, Matt, Chris. On Thu, Feb 01, 2018 at 03:14:38PM -0800, Matt Roper wrote: > > Hmm. Could we not avoid drm_ioctl + well known param names and use a > > more generic tool to set cgroup attributes? Just feels wrong that a > > such a generic interface boils down to a driver specific ioctl. So,

Re: [PATCH RFC 6/9] drm: Add cgroup helper library

2018-01-22 Thread Tejun Heo
Hello, Matt. On Fri, Jan 19, 2018 at 05:51:38PM -0800, Matt Roper wrote: > Most DRM drivers will want to handle the CGROUP_SETPARAM ioctl by looking up a > driver-specific per-cgroup data structure (or allocating a new one) and > storing > the supplied parameter value into the data structure

Re: [PATCH] idr: remove WARN_ON_ONCE() when trying to replace negative ID

2017-09-07 Thread Tejun Heo
GEM_CLOSE) pass in a value from userspace to idr_replace(), > allowing the WARN_ON_ONCE to be triggered. drm_gem_handle_delete() > actually just wants idr_replace() to return an error code if the ID is > not allocated, including in the case where the ID is invalid (nega

Re: [PATCH, RESEND 02/14] ata: avoid gcc-7 warning in ata_timing_quantize

2017-07-15 Thread Tejun Heo
ontext, suggest > '&&' instead [-Wint-in-bool-context] > > This slightly rearranges the macro to simplify the code and avoid > the warning at the same time. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> If the whole series will be routed together, Acked-by: Tejun He

[RFC 00/10] implement alternative and much simpler id allocator

2016-12-12 Thread Tejun Heo
Hello, Matthew. On Mon, Dec 12, 2016 at 05:35:17PM +, Matthew Wilcox wrote: > I know the preload followed by preload_end looks wrong. I don't > think it's broken though. If we get preempted, then the worst > situation is that we'll end up with the memory we preallocated being > allocated to

[RFC 00/10] implement alternative and much simpler id allocator

2016-12-12 Thread Tejun Heo
Hello, On Fri, Dec 09, 2016 at 02:01:40PM -0800, Andrew Morton wrote: > On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes rasmusvillemoes.dk> wrote: > > > TL;DR: these patches save 250 KB of memory, with more low-hanging > > fruit ready to pick. > > > > While browsing through the lib/idr.c

[RFC 00/10] implement alternative and much simpler id allocator

2016-12-09 Thread Tejun Heo
Hello, Rasmus. On Thu, Dec 08, 2016 at 02:22:55AM +0100, Rasmus Villemoes wrote: > TL;DR: these patches save 250 KB of memory, with more low-hanging > fruit ready to pick. > > While browsing through the lib/idr.c code, I noticed that the code at > the end of ida_get_new_above() probably doesn't

[PATCH v2] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-18 Thread Tejun Heo
items, explicit concurrency > limit is unnecessary here. > > Signed-off-by: Bhaktipriya Shridhar Acked-by: Tejun Heo Thanks. -- tejun

[PATCH] drm/ttm: Remove create_singlethread_workqueue

2016-07-18 Thread Tejun Heo
Signed-off-by: Bhaktipriya Shridhar Acked-by: Tejun Heo Thanks. -- tejun

[PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-12 Thread Tejun Heo
Hello, On Fri, Jul 08, 2016 at 02:52:30PM +0900, Michel Dänzer wrote: > On 07.07.2016 16:43, Christian König wrote: > >>> Also, what kind of delays matter here? Is it millisec range or micro? > >> It can be the latter in theory, but normally rather the former. > > > > Well to be precise with

[PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-06 Thread Tejun Heo
Hello, Michel. On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote: > There is an ordering requirement between the two queues, but it's > enforced by the driver (by only queuing the unpin work once a flip has > completed, which only happens after the corresponding flip work has run).

[PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-05 Thread Tejun Heo
Hello, On Mon, Jul 04, 2016 at 12:58:32PM +0900, Michel Dänzer wrote: > On 02.07.2016 22:46, Tejun Heo wrote: > > On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote: > >> alloc_workqueue replaces deprecated create_singlethread_workqueue(). > >> >

[PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-02 Thread Tejun Heo
On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_singlethread_workqueue(). > > A dedicated workqueue has been used since work items need to be flushed > as a group rather than individually. > > Since the flip_queue workqueue is

[PATCH] drm/qxl: Remove deprecated create_singlethread_workqueue

2016-07-02 Thread Tejun Heo
increase of local concurrency > shouldn't make any difference. > > flush_work() has been called in qxl_device_fini() to ensure that there > are no pending tasks while disconnecting the driver. > > Signed-off-by: Bhaktipriya Shridhar Acked-by: Tejun Heo Thanks. -- tejun

[PATCH] drm/omap: panel-dsi-cm: Remove deprecated create_singlethread_workqueue

2016-07-02 Thread Tejun Heo
dsicm_cancel_ulps_work() which is called > in dsicm_remove() to ensure that there are no workitems pending when the > driver is disconnected. > > Signed-off-by: Bhaktipriya Shridhar Acked-by: Tejun Heo Thanks. -- tejun

[PATCH v2] gpu: host1x: hw: intr_hw: Remove create_workqueue

2016-06-20 Thread Tejun Heo
rk_sync() has been used in _host1x_free_syncpt_irq() to ensure > that no work is pending by the time exit path runs. Alternatively, this could have used alloc_workqueue() w/o WQ_MEM_RECLAIM and used it just as a flush domain. Either way is fine. Acked-by: Tejun Heo Thanks. -- tejun

[PATCH] mtip32xx: Remove deprecated create_workqueue

2016-06-20 Thread Tejun Heo
On Mon, Jun 20, 2016 at 11:01:44AM -0400, Tejun Heo wrote: > On Sat, Jun 18, 2016 at 01:52:05PM +0530, Bhaktipriya Shridhar wrote: > > alloc_workqueue replaces deprecated create_workqueue(). > > > > A dedicated workqueue has been used since the workqueue isr_workq is > &g

[PATCH] mtip32xx: Remove deprecated create_workqueue

2016-06-20 Thread Tejun Heo
On Sat, Jun 18, 2016 at 01:52:05PM +0530, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > A dedicated workqueue has been used since the workqueue isr_workq is > involved in irq handling path of block driver and requires forward > progress under memory

[PATCH v2] gpu: drm: amd: amdkfd: Remove create_workqueue()

2016-05-26 Thread Tejun Heo
rkqueue becomes empty. > > Hence flush_workqueue has been removed. > > Signed-off-by: Bhaktipriya Shridhar Acked-by: Tejun Heo Thanks. -- tejun

[PATCH] gpu: drm: amd: amdkfd: Remove create_workqueue()

2016-05-26 Thread Tejun Heo
se changes are safe and I think they're. It just needs explanations. > Signed-off-by: Bhaktipriya Shridhar Other than that, Acked-by: Tejun Heo Thanks. -- tejun

kernfs oops with i915+i2c_core in 3.14 merge window

2014-01-30 Thread Tejun Heo
On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote: > Hi All, > > I'm seeing the oops below on my MacBookPro 10,2 machine using i915 > graphics. It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) , > but we seem to have one report[1] of this happening well before that, > in

Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

2013-09-23 Thread Tejun Heo
direct write accesses to using the correct API. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tejun Heo t...@kernel.org The patch is pretty widely spread. I don't mind how it gets routed but what's the plan? Thanks. -- tejun

Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

2013-09-23 Thread Tejun Heo
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch

Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

2013-09-23 Thread Tejun Heo
Hey, On Fri, Sep 20, 2013 at 03:00:18PM +0100, Russell King - ARM Linux wrote: Another would be if subsystem maintainers are happy that I carry them, I can add the acks, and then later on towards the end of the cycle, provide a branch subsystem maintainers could pull. Or... if you can think

[PATCH 10/10] idr: Rework idr_preload()

2013-06-19 Thread Tejun Heo
On Wed, Jun 19, 2013 at 04:33:44PM -0700, Kent Overstreet wrote: > With respect to performance, strongly disagree. Leaving pointers out of > the interior nodes cuts our space requirements by a factor of _64_ - > that's huge, and with data structures the dominating factors w.r.t. > performance tend

Re: [PATCH 10/10] idr: Rework idr_preload()

2013-06-19 Thread Tejun Heo
On Wed, Jun 19, 2013 at 04:33:44PM -0700, Kent Overstreet wrote: With respect to performance, strongly disagree. Leaving pointers out of the interior nodes cuts our space requirements by a factor of _64_ - that's huge, and with data structures the dominating factors w.r.t. performance tend to

[PATCH v2 03/20] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-04-04 Thread Tejun Heo
Hello, On Sat, Mar 09, 2013 at 10:44:30PM -0800, Yinghai Lu wrote: > Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not > be used anymore. > > User should use arch_pfn_mapped or just 1UL<<(32-PAGE_SHIFT) instead. > > Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not

flushing uninitialized work item in radeon init failure path

2013-04-04 Thread Tejun Heo
Hello, The following happens on my test machine which has an on-board VGA which is not connected. The failure is expected but, in the failure path, it calls radeon_irq_kms_fini() which flushes @rdev->*_work when @rdev seemingly hasn't gone through radeon_irq_kms_init(), ending up trying to flush

flushing uninitialized work item in radeon init failure path

2013-04-04 Thread Tejun Heo
Hello, The following happens on my test machine which has an on-board VGA which is not connected. The failure is expected but, in the failure path, it calls radeon_irq_kms_fini() which flushes @rdev-*_work when @rdev seemingly hasn't gone through radeon_irq_kms_init(), ending up trying to flush

Re: [PATCH v2 03/20] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-04-04 Thread Tejun Heo
Hello, On Sat, Mar 09, 2013 at 10:44:30PM -0800, Yinghai Lu wrote: Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not be used anymore. User should use arch_pfn_mapped or just 1UL(32-PAGE_SHIFT) instead. Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not use that,

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-03-07 Thread Tejun Heo
On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu wrote: > They are not using memblock_find_in_range(), so 1ULL<< will not help. > > Really hope i915 drm guys could clean that hacks. The code isn't being used. Just leave it alone. Maybe add a comment. The change is just making things more confusing.

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-03-07 Thread Tejun Heo
On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu wrote: > On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo wrote: >> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote: >>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c >>> b/drivers/gpu/drm/i915/i915_gem_stolen.c

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-03-07 Thread Tejun Heo
On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote: > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c > b/drivers/gpu/drm/i915/i915_gem_stolen.c > index 69d97cb..7f9380b 100644 > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c > @@ -81,7

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-03-07 Thread Tejun Heo
On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote: diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index 69d97cb..7f9380b 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -81,7 +81,7 @@

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-03-07 Thread Tejun Heo
On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu ying...@kernel.org wrote: On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo t...@kernel.org wrote: On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote: diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-03-07 Thread Tejun Heo
On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu ying...@kernel.org wrote: They are not using memblock_find_in_range(), so 1ULL will not help. Really hope i915 drm guys could clean that hacks. The code isn't being used. Just leave it alone. Maybe add a comment. The change is just making things

compositing broken in -next (idr bug)

2013-02-12 Thread Tejun Heo
Hello, Jiri. On Tue, Feb 12, 2013 at 11:08:41PM +0100, Jiri Slaby wrote: > > Oh my, maybe: return ret < 0 ? ret : 0... Let's try. > > Bull's eye. Aieee > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -459,6 +459,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void

compositing broken in -next (idr bug)

2013-02-12 Thread Tejun Heo
it: > commit 430440fce7da4ad52c2af06a04a5132e5d19faaf > Author: Tejun Heo > Date: Thu Feb 7 12:31:37 2013 +1100 > > drm: convert to idr_alloc() > > > More concretely to the change in drm_gem_flink_ioctl. If I revert solely > that one, it works again. Maybe I'm blind, but I

[PATCH] drm: missing idr_preload_end in drm_gem_flink_ioctl

2013-02-12 Thread Tejun Heo
spin_unlock(>object_name_lock); > + idr_preload_end(); > ret = 0; Oops, sorry about that. Acked-by: Tejun Heo Andrew, the original patch can be found at http://article.gmane.org/gmane.linux.kernel/1439101/raw Thanks. -- tejun

Re: compositing broken in -next (idr bug)

2013-02-12 Thread Tejun Heo
430440fce7da4ad52c2af06a04a5132e5d19faaf Author: Tejun Heo t...@kernel.org Date: Thu Feb 7 12:31:37 2013 +1100 drm: convert to idr_alloc() More concretely to the change in drm_gem_flink_ioctl. If I revert solely that one, it works again. Maybe I'm blind, but I do not see why... Well I see a bug

Re: compositing broken in -next (idr bug)

2013-02-12 Thread Tejun Heo
Hello, Jiri. On Tue, Feb 12, 2013 at 11:08:41PM +0100, Jiri Slaby wrote: Oh my, maybe: return ret 0 ? ret : 0... Let's try. Bull's eye. Aieee --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -459,6 +459,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,

[PATCH 36/77] drm/vmwgfx: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm

[PATCH 35/77] drm/via: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/via/via_mm.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/via/via_mm.c b

[PATCH 34/77] drm/sis: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/sis/sis_mm.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/sis/sis_mm.c b

[PATCH 33/77] drm/i915: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Acked-by: Daniel Vetter Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/i915/i915_gem_context.c | 21 + 1 file changed, 5 insertions(+), 16 deletions

[PATCH 32/77] drm/exynos: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Cc: David Airlie Cc: Kukjin Kim Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git

[PATCH 31/77] drm: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. * drm_ctxbitmap_next() error handling in drm_addctx() seems broken. drm_ctxbitmap_next() return -errno on failure not -1. Signed-off-by: Tejun Heo Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm

[PATCH 06/77] drm: don't use idr_remove_all()

2013-02-06 Thread Tejun Heo
idr_destroy() can destroy idr by itself and idr_remove_all() is being deprecated. Drop its usage. * drm_ctxbitmap_cleanup() was calling idr_remove_all() but forgetting idr_destroy() thus leaking all buffered free idr_layers. Replace it with idr_destroy(). Signed-off-by: Tejun Heo Cc

[PATCH 06/77] drm: don't use idr_remove_all()

2013-02-06 Thread Tejun Heo
idr_destroy() can destroy idr by itself and idr_remove_all() is being deprecated. Drop its usage. * drm_ctxbitmap_cleanup() was calling idr_remove_all() but forgetting idr_destroy() thus leaking all buffered free idr_layers. Replace it with idr_destroy(). Signed-off-by: Tejun Heo t

[PATCH 31/77] drm: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. * drm_ctxbitmap_next() error handling in drm_addctx() seems broken. drm_ctxbitmap_next() return -errno on failure not -1. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: dri-devel

[PATCH 32/77] drm/exynos: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: Kukjin Kim kgene@samsung.com Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 16 +--- 1 file changed

[PATCH 33/77] drm/i915: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Acked-by: Daniel Vetter daniel.vet...@ffwll.ch Cc: David Airlie airl...@linux.ie Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/i915/i915_gem_context.c | 21

[PATCH 35/77] drm/via: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/via/via_mm.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git

[PATCH 34/77] drm/sis: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/sis/sis_mm.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git

[PATCH 36/77] drm/vmwgfx: convert to idr_alloc()

2013-02-06 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 - 1 file changed, 8 insertions(+), 9 deletions

[PATCH 20/62] drm/vmwgfx: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best to route these together through -mm. Please holler if there's any

[PATCH 19/62] drm/via: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best to route these together through -mm. Please holler if there's any

[PATCH 18/62] drm/sis: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best to route these together through -mm. Please holler if there's any

[PATCH 17/62] drm/i915: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel at lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best to route these together through -mm. Please

[PATCH 16/62] drm/exynos: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo Cc: David Airlie Cc: Kukjin Kim Cc: dri-devel at lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best to route these together through -mm. Please holler

[PATCH 15/62] drm: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. * drm_ctxbitmap_next() error handling in drm_addctx() seems broken. drm_ctxbitmap_next() return -errno on failure not -1. Signed-off-by: Tejun Heo Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- This patch depends

[PATCH 15/62] drm: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. * drm_ctxbitmap_next() error handling in drm_addctx() seems broken. drm_ctxbitmap_next() return -errno on failure not -1. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: dri-devel

[PATCH 16/62] drm/exynos: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: Kukjin Kim kgene@samsung.com Cc: dri-devel@lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best

[PATCH 17/62] drm/i915: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: dri-devel@lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best

[PATCH 18/62] drm/sis: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: dri-devel@lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best to route these together through -mm

[PATCH 19/62] drm/via: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: dri-devel@lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best to route these together through -mm

[PATCH 20/62] drm/vmwgfx: convert to idr_alloc()

2013-02-02 Thread Tejun Heo
Convert to the much saner new idr interface. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org Cc: David Airlie airl...@linux.ie Cc: dri-devel@lists.freedesktop.org --- This patch depends on an earlier idr changes and I think it would be best to route these together through -mm

[PATCH 05/14] drm: don't use idr_remove_all()

2013-01-25 Thread Tejun Heo
idr_destroy() can destroy idr by itself and idr_remove_all() is being deprecated. Drop its usage. * drm_ctxbitmap_cleanup() was calling idr_remove_all() but forgetting idr_destroy() thus leaking all buffered free idr_layers. Replace it with idr_destroy(). Signed-off-by: Tejun Heo Cc

[PATCH 05/14] drm: don't use idr_remove_all()

2013-01-25 Thread Tejun Heo
idr_destroy() can destroy idr by itself and idr_remove_all() is being deprecated. Drop its usage. * drm_ctxbitmap_cleanup() was calling idr_remove_all() but forgetting idr_destroy() thus leaking all buffered free idr_layers. Replace it with idr_destroy(). Signed-off-by: Tejun Heo t

[PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1

2012-08-23 Thread Tejun Heo
Hello, On Thu, Aug 23, 2012 at 10:43:25AM +0200, Daniel Vetter wrote: > On Thu, Aug 23, 2012 at 08:56:37AM +0100, Chris Wilson wrote: > > On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo wrote: > > > This is an equivalent conversion and will ease scheduled removal of >

Re: [PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1

2012-08-23 Thread Tejun Heo
Hello, On Thu, Aug 23, 2012 at 10:43:25AM +0200, Daniel Vetter wrote: On Thu, Aug 23, 2012 at 08:56:37AM +0100, Chris Wilson wrote: On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo t...@kernel.org wrote: This is an equivalent conversion and will ease scheduled removal of WQ_NON_REENTRANT

[PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1

2012-08-22 Thread Tejun Heo
This is an equivalent conversion and will ease scheduled removal of WQ_NON_REENTRANT. Signed-off-by: Tejun Heo --- drivers/gpu/drm/i915/i915_dma.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index

[PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1

2012-08-22 Thread Tejun Heo
This is an equivalent conversion and will ease scheduled removal of WQ_NON_REENTRANT. Signed-off-by: Tejun Heo t...@kernel.org --- drivers/gpu/drm/i915/i915_dma.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915

[PATCH] Block: use a freezable workqueue for disk-event polling

2012-02-17 Thread Tejun Heo
fixes things by creating a new system-wide, non-reentrant, > freezable workqueue and using it for disk-events polling. > > Signed-off-by: Alan Stern > CC: Tejun Heo > CC: Acked-by: Tejun Heo Thanks! -- tejun

Re: [PATCH] Block: use a freezable workqueue for disk-event polling

2012-02-17 Thread Tejun Heo
, non-reentrant, freezable workqueue and using it for disk-events polling. Signed-off-by: Alan Stern st...@rowland.harvard.edu CC: Tejun Heo t...@kernel.org CC: sta...@kernel.org Acked-by: Tejun Heo t...@kernel.org Thanks! -- tejun ___ dri-devel

system_nrt_wq, system suspend, and the freezer

2012-02-16 Thread Tejun Heo
Hello, Jeff. On Thu, Feb 16, 2012 at 01:59:45PM -0500, Jeff Layton wrote: > The other problem here is that we really ought to be submitting the > write completion handler to a workqueue that has WQ_MEM_RECLAIM set. > Since none of the public wq's have that then I guess we'll have to make > our

system_nrt_wq, system suspend, and the freezer

2012-02-16 Thread Tejun Heo
Hello, On Thu, Feb 16, 2012 at 11:37:33AM -0500, Alan Stern wrote: > Um. I don't think I can audit all the calls in the kernel that submit > block requests and determine which ones need to be allowed while a > system sleep is in progress. ??? we need to do that anyway and the ones which should

system_nrt_wq, system suspend, and the freezer

2012-02-16 Thread Tejun Heo
On Thu, Feb 16, 2012 at 04:35:51PM +, David Howells wrote: > The key_garbage_collector work item is marked neither freezable nor > unfreezable that I can see. Heh, was too brief apparently. :) I was trying to say that if it doesn't require freezing, please don't put it on a freezable

system_nrt_wq, system suspend, and the freezer

2012-02-16 Thread Tejun Heo
Hello, On Thu, Feb 16, 2012 at 10:27:28AM -0500, Jeff Layton wrote: > These should all be freezable and we might even be able to get away > with WQ_UNBOUND for some of these. In general, I would recommend specifying as few special attribute as possible. If WQ_UNBOUND is necessary (large amount

system_nrt_wq, system suspend, and the freezer

2012-02-16 Thread Tejun Heo
On Thu, Feb 16, 2012 at 03:22:24PM +, David Howells wrote: > Alan Stern wrote: > > > My question to all of you: Should system_nrt_wq be made freezable, or > > should I create a new workqueue that is both freezable and > > non-reentrant? And if I do, which of the usages above should be >

system_nrt_wq, system suspend, and the freezer

2012-02-16 Thread Tejun Heo
Hello, (cc'ing Rafael and Jens) On Thu, Feb 16, 2012 at 09:41:34AM -0500, Alan Stern wrote: > My question to all of you: Should system_nrt_wq be made freezable, or > should I create a new workqueue that is both freezable and > non-reentrant? And if I do, which of the usages above should be >

  1   2   >