All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <luis.henriques@canonical.com>
To: "Nicolai Hähnle" <nicolai.haehnle@amd.com>
Cc: Taras Prokopenko <taras.prokopenko@gmail.com>,
	christian.koenig@amd.com, stable@vger.kernel.org,
	Kamal Mostafa <kamal@canonical.com>,
	Sasha Levin <sasha.levin@oracle.com>, Jiri Slaby <jslaby@suse.cz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: Fwd: Please revert wrong kernel OOPS patch in -69 !
Date: Thu, 7 Apr 2016 14:31:57 +0100	[thread overview]
Message-ID: <20160407133157.GA2539@hercules> (raw)
In-Reply-To: <57065B31.5010503@amd.com>

On Thu, Apr 07, 2016 at 08:05:53AM -0500, Nicolai H�hnle wrote:
> Hmm, I was under the impression from an email I got that this was already
> reverted from 3.16. Clearly, communication is hard.
> 
> Let me re-iterate, to be sure: kernels 3.17 and older
> 
> 1. need to revert the backport of upstream commit
> f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb (I think most have done that
> already) and
> 
> 2. should apply the corrected backport which I am attaching yet again (seems
> like when I sent this patch around two weeks ago, it wasn't picked up).
> 

Thanks a lot for reiterating this, Nicolai.

So, you're absolutely right: this *was* reverted in the 3.16 kernel,
in version 3.16.7-ckt26 (and afaik from any other stable trees).
Unfortunately, version 3.16.7-ckt25 was actually released *before*
this regression was identified.

I'm not sure which other stable kernels were actually released with
this regression, but there was definitely a window of time where this
could have happen.

Cheers,
--
Lu�s

> Thanks,
> Nicolai
> 
> On 07.04.2016 04:15, Taras Prokopenko wrote:
> >
> >---------- Forwarded message ----------
> >From: *Taras Prokopenko* <taras.prokopenko@gmail.com
> ><mailto:taras.prokopenko@gmail.com>>
> >Date: 2016-04-07 12:04 GMT+03:00
> >Subject: Please revert wrong kernel OOPS patch in -69 !
> >To: luis.henriques@canonical.com <mailto:luis.henriques@canonical.com>
> >Cc: jslaby@suse.cz <mailto:jslaby@suse.cz>
> >
> >
> >Please test your changes! Lost 1/2 a day to figure out whats causing my
> >pc to hang.
> >
> >OopsText:
> >  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> >  IP: [<ffffffffc03b83ed>] radeon_fence_ref+0xd/0x50 [radeon]
> >  PGD 0
> >  Oops: 0002 [#1] SMP
> >
> >
> >https://lists.ubuntu.com/archives/kernel-team/2016-February/072148.html
> >
> >Damn
> >

> From ad94965f69c2681832f64473d28c23ae71b6e52f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Nicolai=20H=C3=A4hnle?= <nicolai.haehnle@amd.com>
> Date: Tue, 15 Mar 2016 12:56:45 -0500
> Subject: [PATCH] drm/radeon: hold reference to fences in radeon_sa_bo_new
>  (3.17 and older)
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> [Backport of upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb, with
>  an additional NULL pointer guard that is required for kernels 3.17 and older.
> 
>  To be precise, any kernel that does *not* have commit 954605ca3 "drm/radeon:
>  use common fence implementation for fences, v4" requires this additional
>  NULL pointer guard.]
> 
> An arbitrary amount of time can pass between spin_unlock and
> radeon_fence_wait_any, so we need to ensure that nobody frees the
> fences from under us.
> 
> Based on the analogous fix for amdgpu.
> 
> Signed-off-by: Nicolai H??hnle <nicolai.haehnle@amd.com>
> Reviewed-by: Christian K??nig <christian.koenig@amd.com> (v1 + fix)
> Tested-by: Lutz Euler <lutz.euler@freenet.de>
> Cc: stable@vger.kernel.org
> ---
>  drivers/gpu/drm/radeon/radeon_sa.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_sa.c b/drivers/gpu/drm/radeon/radeon_sa.c
> index f0bac68..8962411 100644
> --- a/drivers/gpu/drm/radeon/radeon_sa.c
> +++ b/drivers/gpu/drm/radeon/radeon_sa.c
> @@ -349,8 +349,15 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
>  			/* see if we can skip over some allocations */
>  		} while (radeon_sa_bo_next_hole(sa_manager, fences, tries));
>  
> +		for (i = 0; i < RADEON_NUM_RINGS; ++i) {
> +			if (fences[i])
> +				radeon_fence_ref(fences[i]);
> +		}
> +
>  		spin_unlock(&sa_manager->wq.lock);
>  		r = radeon_fence_wait_any(rdev, fences, false);
> +		for (i = 0; i < RADEON_NUM_RINGS; ++i)
> +			radeon_fence_unref(&fences[i]);
>  		spin_lock(&sa_manager->wq.lock);
>  		/* if we have nothing to wait for block */
>  		if (r == -ENOENT && block) {
> -- 
> 2.5.0
> 

  reply	other threads:[~2016-04-07 13:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAOT88bw_R-dcCYoS+=rYqbsw1vOgRUUoVPcPsTD1C1gc+V6Oug@mail.gmail.com>
     [not found] ` <CAOT88bz+kC2VCa5jG8oWoxNTUpuCQy1gvqLB8HTq2KfieQfohQ@mail.gmail.com>
2016-04-07 13:05   ` Fwd: Please revert wrong kernel OOPS patch in -69 ! Nicolai Hähnle
2016-04-07 13:31     ` Luis Henriques [this message]
2016-04-18  1:34     ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160407133157.GA2539@hercules \
    --to=luis.henriques@canonical.com \
    --cc=christian.koenig@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=kamal@canonical.com \
    --cc=nicolai.haehnle@amd.com \
    --cc=sasha.levin@oracle.com \
    --cc=stable@vger.kernel.org \
    --cc=taras.prokopenko@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.