On 2019/05/03 5:46, Daniel Vetter wrote:
> There's the hung_task_panic sysctl, but that's a bit an extreme measure.
> As a fallback taint at least the machine.
>
> Our CI uses this to decide when a reboot is necessary, plus to figure
> out whether the kernel is still happy.
Why your CI can't watc
On 2019/05/21 19:06, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This will be used in th
On 2019/05/21 19:51, Michal Hocko wrote:
> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
>> On 2019/05/21 19:06, Daniel Vetter wrote:
>>> In some special cases we must not block, but there's not a
>>> spinlock, preempt-off, irqs-off or similar critical section alrea
On 2019/05/21 20:11, Michal Hocko wrote:
> On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
>> On 2019/05/21 19:51, Michal Hocko wrote:
>>> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
>>>> On 2019/05/21 19:06, Daniel Vetter wrote:
>>>>> In some speci
On 2019/05/21 23:44, Daniel Vetter wrote:
OOM notifiers should not depend on any locks or sleepable conditionals.
If some lock directly or indirectly depended on __GFP_DIRECT_RECLAIM,
it will deadlock. Thus, despite blocking API, this should effectively be
non-blocking. All OOM
Ping?
On 2022/06/10 23:57, Tetsuo Handa wrote:
> Then, does this flush_scheduled_work() mean to wait all
> schedule_work()/schedule_delayed_work()
> calls inside drivers/gpu/drm/i915/ directory?
On 2022/06/30 16:46, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 10/06/2022 15:57, Tetsuo Handa wrote:
>> Hello.
>>
>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
>> a macro") explains, we are removing flush_scheduled_work(
On 2022/06/30 19:17, Tvrtko Ursulin wrote:
> Could you give more context on reasoning here please? What is the difference
> between using the system_wq and flushing it from a random context? Or concern
> is about flushing from specific contexts?
Excuse me, but I couldn't catch what you want. Thus,
Hello.
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
a macro") explains, we are removing flush_scheduled_work() calls. And now
drivers/gpu/drm/i915/display/intel_display.c
drivers/gpu/drm/i915/gt/selftest_execlists.c
are the last flush_scheduled_work() callers which
On 2022/06/30 22:09, Tvrtko Ursulin wrote:
>>> On the i915 specifics, the caller in
>>> drivers/gpu/drm/i915/gt/selftest_execlists.c
>>> I am pretty sure can be removed. It is synchronized with the error capture
>>> side of
>>> things which is not required for the test to work.
>>>
>>> I can send
On 2022/02/09 6:08, Daniel Vetter wrote:
> @@ -714,6 +700,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
> struct fb_info *info,
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> if (!ops)
> err = -ENOMEM;
> +
> + INI
As of commit 47ec5303d73ea344 ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") on linux.git ,
my VMware environment cannot boot. Do I need to bisect?
[9.314496][T1] vga16fb: mapped to 0x71050562
[9.467770][T1] Console: switching to colour frame buffe
Two more worries for this patch.
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> @@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> *
> * @amn: our notifier
> */
> -static void amdgpu_mn_read_lock(struct amdgpu_mn *amn)
> +st
On 2018/08/24 20:36, Michal Hocko wrote:
>> That is, this API seems to be currently used by only out-of-tree users. Since
>> we can't check that nobody has memory allocation dependency, I think that
>> hmm_invalidate_range_start() should return -EAGAIN if blockable == false for
>> now.
>
> The co
On 2018/08/24 22:32, Michal Hocko wrote:
> On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
>> I worry that (currently
>> out-of-tree) users of this API are involving work / recursion.
>
> I do not give a slightest about out-of-tree modules. They will have to
> accomodate t
On 2018/08/24 22:52, Michal Hocko wrote:
> @@ -180,11 +180,15 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> */
> static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable)
> {
> - if (blockable)
> - mutex_lock(&amn->read_lock);
> - else if (!mutex_trylock(&amn-
On 2018/08/27 16:41, Christian König wrote:
> Am 26.08.2018 um 10:40 schrieb Tetsuo Handa:
>> I'm not following. Why don't we need to do like below (given that
>> nobody except amdgpu_mn_read_lock() holds ->read_lock) because e.g.
>> drm_sched_fence_creat
Tetsuo Handa wrote:
> Michael S. Tsirkin wrote:
> > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote:
> > > Hello.
> > >
> > > I noticed that virtio_balloon is using register_oom_notifier() and
> > > leak_balloon()
per transaction is
unsupported.",
and after all dropped at the servers. Sad...
>
> On Mon 02-10-17 06:59:12, Michael S. Tsirkin wrote:
> > On Sun, Oct 01, 2017 at 02:44:34PM +0900, Tetsuo Handa wrote:
> > > Tetsuo Handa wrote:
> > > > Michael S. Tsirkin wrote:
&g
On 2023/03/15 19:47, Luca Coelho wrote:
> On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
>> macro") says, flush_scheduled_work() is dangerous and will be forbidden.
>&g
On 2023/04/14 19:13, Jani Nikula wrote:
> On Fri, 14 Apr 2023, Tetsuo Handa wrote:
>> On 2023/03/15 19:47, Luca Coelho wrote:
>>> On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
>>>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_wo
ork()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed
On 2022/11/16 22:06, Ville Syrjälä wrote:
> On Wed, Nov 16, 2022 at 12:08:27PM +0200, Jani Nikula wrote:
>> On Sun, 06 Nov 2022, Tetsuo Handa wrote:
>>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
>>> macro") says, flush_sche
r/20220923142934.29528-1-tvrtko.ursu...@linux.intel.com
[1]
Signed-off-by: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
drivers/gpu/drm/i915/
On 2023/03/03 19:11, Tetsuo Handa wrote:
> @@ -79,6 +81,7 @@ static int __init i915_init(void)
> {
> int err, i;
>
> + i915_wq = alloc_workqueue("i915", 0, 0);
Oops. I forgot to add
if (!i915_wq)
return -ENOMEM;
here. But I'd
On 2023/03/06 20:05, Jani Nikula wrote:
> On Fri, 03 Mar 2023, Tetsuo Handa wrote:
>> On 2023/03/03 19:11, Tetsuo Handa wrote:
>>> @@ -79,6 +81,7 @@ static int __init i915_init(void)
>>> {
>>> int err, i;
>>>
>>> + i915_wq = allo
ork()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed
ork()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed
On 2023/06/08 22:35, Jani Nikula wrote:
> From: Luca Coelho
>
> Instead of using a global workqueue for the SW fence selftest,
> allocate a separate one temporarily only while running the test.
>
> Cc: Tetsuo Handa
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Reviewed-b
ly mechanical and based on Tetsuo's original
> patch[1].
>
> v6 by Jani:
> - Also create unordered_wq for mock device
>
> Link: https://patchwork.freedesktop.org/series/114608/ [1]
> Cc: Tetsuo Handa
> Cc: Tvrtko Ursulin
> Cc: Jani Nikula
> Cc: Ville Syrjälä
>
directory. Jani Nikula wants to use two workqueues in order to avoid
adding new module globals, but I'm not familiar enough to audit and
split into two workqueues.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed-off-by: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikul
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
macro") says, flush_scheduled_work() is dangerous and will be forbidden.
We are on the way for removing all flush_scheduled_work() callers from
the kernel, and there are only 4 callers remaining as of linux-20221104.
driver
32 matches
Mail list logo
