All of lore.kernel.org
 help / color / mirror / Atom feed
* [ANNOUNCE] 3.12.12-rt19
@ 2014-02-23 18:47 Sebastian Andrzej Siewior
  2014-02-23 19:13 ` Pavel Vasilyev
  2014-03-02  1:48 ` Fernando Lopez-Lezcano
  0 siblings, 2 replies; 11+ messages in thread
From: Sebastian Andrzej Siewior @ 2014-02-23 18:47 UTC (permalink / raw)
  To: linux-rt-users; +Cc: LKML, Thomas Gleixner, rostedt, John Kacur

Dear RT folks!

I'm pleased to announce the v3.12.12-rt19 patch set.

Changes since v3.12.12-rt18
- fix of a newly introduced compiler warning in "hwlatdetect" due to the
  checkpatch cleanup. Spotted by Mike and now gone.
- since we use hrtimer in cpu_chill() we migh see a warning if we call
  cpu_chill() with locks hold. The current workaround is to disable the
  freezer while calling hrtimer_nanosleep(). This warning did not happen
  with the msleep() version because it did not invoke the freezer.
- Don Estabrook reported a problem where the migrate counter were not
  getting back to zero properly. The problem was specific to x86's AVX
  crypto driver and has been fixed by makeing the "fpu disable" smaller.

Known issues:

      - bcache is disabled.

The delta patch against v3.12.12-rt18 is appended below and can be found
here:
   https://www.kernel.org/pub/linux/kernel/projects/rt/3.12/incr/patch-3.12.12-rt18-rt19.patch.xz

The RT patch against 3.12.12 can be found here:

   https://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.12-rt19.patch.xz

The split quilt queue is available at:

   https://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patches-3.12.12-rt19.tar.xz

Sebastian

diff --git a/arch/x86/crypto/cast5_avx_glue.c b/arch/x86/crypto/cast5_avx_glue.c
index c663181..2d48e83 100644
--- a/arch/x86/crypto/cast5_avx_glue.c
+++ b/arch/x86/crypto/cast5_avx_glue.c
@@ -60,7 +60,7 @@ static inline void cast5_fpu_end(bool fpu_enabled)
 static int ecb_crypt(struct blkcipher_desc *desc, struct blkcipher_walk *walk,
 		     bool enc)
 {
-	bool fpu_enabled = false;
+	bool fpu_enabled;
 	struct cast5_ctx *ctx = crypto_blkcipher_ctx(desc->tfm);
 	const unsigned int bsize = CAST5_BLOCK_SIZE;
 	unsigned int nbytes;
@@ -76,7 +76,7 @@ static int ecb_crypt(struct blkcipher_desc *desc, struct blkcipher_walk *walk,
 		u8 *wsrc = walk->src.virt.addr;
 		u8 *wdst = walk->dst.virt.addr;
 
-		fpu_enabled = cast5_fpu_begin(fpu_enabled, nbytes);
+		fpu_enabled = cast5_fpu_begin(false, nbytes);
 
 		/* Process multi-block batch */
 		if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) {
@@ -104,10 +104,9 @@ static int ecb_crypt(struct blkcipher_desc *desc, struct blkcipher_walk *walk,
 		} while (nbytes >= bsize);
 
 done:
+		cast5_fpu_end(fpu_enabled);
 		err = blkcipher_walk_done(desc, walk, nbytes);
 	}
-
-	cast5_fpu_end(fpu_enabled);
 	return err;
 }
 
@@ -231,7 +230,7 @@ static unsigned int __cbc_decrypt(struct blkcipher_desc *desc,
 static int cbc_decrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
 		       struct scatterlist *src, unsigned int nbytes)
 {
-	bool fpu_enabled = false;
+	bool fpu_enabled;
 	struct blkcipher_walk walk;
 	int err;
 
@@ -240,12 +239,11 @@ static int cbc_decrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
 	desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
 
 	while ((nbytes = walk.nbytes)) {
-		fpu_enabled = cast5_fpu_begin(fpu_enabled, nbytes);
+		fpu_enabled = cast5_fpu_begin(false, nbytes);
 		nbytes = __cbc_decrypt(desc, &walk);
+		cast5_fpu_end(fpu_enabled);
 		err = blkcipher_walk_done(desc, &walk, nbytes);
 	}
-
-	cast5_fpu_end(fpu_enabled);
 	return err;
 }
 
@@ -315,7 +313,7 @@ static unsigned int __ctr_crypt(struct blkcipher_desc *desc,
 static int ctr_crypt(struct blkcipher_desc *desc, struct scatterlist *dst,
 		     struct scatterlist *src, unsigned int nbytes)
 {
-	bool fpu_enabled = false;
+	bool fpu_enabled;
 	struct blkcipher_walk walk;
 	int err;
 
@@ -324,13 +322,12 @@ static int ctr_crypt(struct blkcipher_desc *desc, struct scatterlist *dst,
 	desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
 
 	while ((nbytes = walk.nbytes) >= CAST5_BLOCK_SIZE) {
-		fpu_enabled = cast5_fpu_begin(fpu_enabled, nbytes);
+		fpu_enabled = cast5_fpu_begin(false, nbytes);
 		nbytes = __ctr_crypt(desc, &walk);
+		cast5_fpu_end(fpu_enabled);
 		err = blkcipher_walk_done(desc, &walk, nbytes);
 	}
 
-	cast5_fpu_end(fpu_enabled);
-
 	if (walk.nbytes) {
 		ctr_crypt_final(desc, &walk);
 		err = blkcipher_walk_done(desc, &walk, 0);
diff --git a/arch/x86/crypto/glue_helper.c b/arch/x86/crypto/glue_helper.c
index 432f1d76..4a2bd21 100644
--- a/arch/x86/crypto/glue_helper.c
+++ b/arch/x86/crypto/glue_helper.c
@@ -39,7 +39,7 @@ static int __glue_ecb_crypt_128bit(const struct common_glue_ctx *gctx,
 	void *ctx = crypto_blkcipher_ctx(desc->tfm);
 	const unsigned int bsize = 128 / 8;
 	unsigned int nbytes, i, func_bytes;
-	bool fpu_enabled = false;
+	bool fpu_enabled;
 	int err;
 
 	err = blkcipher_walk_virt(desc, walk);
@@ -49,7 +49,7 @@ static int __glue_ecb_crypt_128bit(const struct common_glue_ctx *gctx,
 		u8 *wdst = walk->dst.virt.addr;
 
 		fpu_enabled = glue_fpu_begin(bsize, gctx->fpu_blocks_limit,
-					     desc, fpu_enabled, nbytes);
+					     desc, false, nbytes);
 
 		for (i = 0; i < gctx->num_funcs; i++) {
 			func_bytes = bsize * gctx->funcs[i].num_blocks;
@@ -71,10 +71,10 @@ static int __glue_ecb_crypt_128bit(const struct common_glue_ctx *gctx,
 		}
 
 done:
+		glue_fpu_end(fpu_enabled);
 		err = blkcipher_walk_done(desc, walk, nbytes);
 	}
 
-	glue_fpu_end(fpu_enabled);
 	return err;
 }
 
@@ -194,7 +194,7 @@ int glue_cbc_decrypt_128bit(const struct common_glue_ctx *gctx,
 			    struct scatterlist *src, unsigned int nbytes)
 {
 	const unsigned int bsize = 128 / 8;
-	bool fpu_enabled = false;
+	bool fpu_enabled;
 	struct blkcipher_walk walk;
 	int err;
 
@@ -203,12 +203,12 @@ int glue_cbc_decrypt_128bit(const struct common_glue_ctx *gctx,
 
 	while ((nbytes = walk.nbytes)) {
 		fpu_enabled = glue_fpu_begin(bsize, gctx->fpu_blocks_limit,
-					     desc, fpu_enabled, nbytes);
+					     desc, false, nbytes);
 		nbytes = __glue_cbc_decrypt_128bit(gctx, desc, &walk);
+		glue_fpu_end(fpu_enabled);
 		err = blkcipher_walk_done(desc, &walk, nbytes);
 	}
 
-	glue_fpu_end(fpu_enabled);
 	return err;
 }
 EXPORT_SYMBOL_GPL(glue_cbc_decrypt_128bit);
@@ -278,7 +278,7 @@ int glue_ctr_crypt_128bit(const struct common_glue_ctx *gctx,
 			  struct scatterlist *src, unsigned int nbytes)
 {
 	const unsigned int bsize = 128 / 8;
-	bool fpu_enabled = false;
+	bool fpu_enabled;
 	struct blkcipher_walk walk;
 	int err;
 
@@ -287,13 +287,12 @@ int glue_ctr_crypt_128bit(const struct common_glue_ctx *gctx,
 
 	while ((nbytes = walk.nbytes) >= bsize) {
 		fpu_enabled = glue_fpu_begin(bsize, gctx->fpu_blocks_limit,
-					     desc, fpu_enabled, nbytes);
+					     desc, false, nbytes);
 		nbytes = __glue_ctr_crypt_128bit(gctx, desc, &walk);
+		glue_fpu_end(fpu_enabled);
 		err = blkcipher_walk_done(desc, &walk, nbytes);
 	}
 
-	glue_fpu_end(fpu_enabled);
-
 	if (walk.nbytes) {
 		glue_ctr_crypt_final_128bit(
 			gctx->funcs[gctx->num_funcs - 1].fn_u.ctr, desc, &walk);
@@ -348,7 +347,7 @@ int glue_xts_crypt_128bit(const struct common_glue_ctx *gctx,
 			  void *tweak_ctx, void *crypt_ctx)
 {
 	const unsigned int bsize = 128 / 8;
-	bool fpu_enabled = false;
+	bool fpu_enabled;
 	struct blkcipher_walk walk;
 	int err;
 
@@ -361,21 +360,21 @@ int glue_xts_crypt_128bit(const struct common_glue_ctx *gctx,
 
 	/* set minimum length to bsize, for tweak_fn */
 	fpu_enabled = glue_fpu_begin(bsize, gctx->fpu_blocks_limit,
-				     desc, fpu_enabled,
+				     desc, false,
 				     nbytes < bsize ? bsize : nbytes);
-
 	/* calculate first value of T */
 	tweak_fn(tweak_ctx, walk.iv, walk.iv);
+	glue_fpu_end(fpu_enabled);
 
 	while (nbytes) {
+		fpu_enabled = glue_fpu_begin(bsize, gctx->fpu_blocks_limit,
+				desc, false, nbytes);
 		nbytes = __glue_xts_crypt_128bit(gctx, crypt_ctx, desc, &walk);
 
+		glue_fpu_end(fpu_enabled);
 		err = blkcipher_walk_done(desc, &walk, nbytes);
 		nbytes = walk.nbytes;
 	}
-
-	glue_fpu_end(fpu_enabled);
-
 	return err;
 }
 EXPORT_SYMBOL_GPL(glue_xts_crypt_128bit);
diff --git a/drivers/misc/hwlat_detector.c b/drivers/misc/hwlat_detector.c
index 577092b3a..2429c43 100644
--- a/drivers/misc/hwlat_detector.c
+++ b/drivers/misc/hwlat_detector.c
@@ -615,7 +615,7 @@ static ssize_t  debug_enable_fwrite(struct file *filp,
 		return -EFAULT;
 
 	buf[sizeof(buf)-1] = '\0';			/* just in case */
-	err = kstrtoull(buf, 10, &val);
+	err = kstrtoul(buf, 10, &val);
 	if (0 != err)
 		return -EINVAL;
 
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 5c26d2c..083815d 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1899,8 +1899,12 @@ void cpu_chill(void)
 	struct timespec tu = {
 		.tv_nsec = NSEC_PER_MSEC,
 	};
+	unsigned int freeze_flag = current->flags & PF_NOFREEZE;
 
+	current->flags |= PF_NOFREEZE;
 	hrtimer_nanosleep(&tu, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+	if (!freeze_flag)
+		current->flags &= ~PF_NOFREEZE;
 }
 EXPORT_SYMBOL(cpu_chill);
 #endif
diff --git a/localversion-rt b/localversion-rt
index 9e7cd66..483ad77 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt18
+-rt19

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [ANNOUNCE] 3.12.12-rt19
  2014-02-23 18:47 [ANNOUNCE] 3.12.12-rt19 Sebastian Andrzej Siewior
@ 2014-02-23 19:13 ` Pavel Vasilyev
  2014-02-23 19:29   ` Pavel Vasilyev
  2014-03-02  1:48 ` Fernando Lopez-Lezcano
  1 sibling, 1 reply; 11+ messages in thread
From: Pavel Vasilyev @ 2014-02-23 19:13 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior, linux-rt-users
  Cc: LKML, Thomas Gleixner, rostedt, John Kacur

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

23.02.2014 22:47, Sebastian Andrzej Siewior пишет:
> Dear RT folks!
> 
> I'm pleased to announce the v3.12.12-rt19 patch set.
Can you create new -RT number for new SUBLEVEL patch?

3.12.10-rt1
3.12.10-rt2
3.12.10-rt3
3.12.10-rt4

3.12.11-rt1
3.12.11-rt2
3.12.11-rt3
...
...
...
3.12.12-rt1
3.12.12-rt1


But not  -rt1, -rt2, -rt3 -rt4, .... -rt99

















[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ANNOUNCE] 3.12.12-rt19
  2014-02-23 19:13 ` Pavel Vasilyev
@ 2014-02-23 19:29   ` Pavel Vasilyev
  2014-02-23 21:13     ` Thomas Gleixner
  0 siblings, 1 reply; 11+ messages in thread
From: Pavel Vasilyev @ 2014-02-23 19:29 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior, linux-rt-users
  Cc: LKML, Thomas Gleixner, rostedt, John Kacur

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

23.02.2014 23:13, Pavel Vasilyev пишет:

> But not  -rt1, -rt2, -rt3 -rt4, .... -rt99

Or

3.12-rt1,
3.12-rt2,
...
3.12-rt33,
...
3.12-rt111,
...
3.12-rt999
...

Now, to have to roll back all my changes, then work -rt patch,
then impose SUBLEVEL mainline diff, then last -rt patch, then my сhanges.



-- 

                                                         Pavel.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ANNOUNCE] 3.12.12-rt19
  2014-02-23 19:29   ` Pavel Vasilyev
@ 2014-02-23 21:13     ` Thomas Gleixner
  2014-02-23 22:55       ` Pavel Vasilyev
  0 siblings, 1 reply; 11+ messages in thread
From: Thomas Gleixner @ 2014-02-23 21:13 UTC (permalink / raw)
  To: Pavel Vasilyev
  Cc: Sebastian Andrzej Siewior, linux-rt-users, LKML, rostedt, John Kacur

[-- Attachment #1: Type: TEXT/PLAIN, Size: 492 bytes --]

On Sun, 23 Feb 2014, Pavel Vasilyev wrote:
> 23.02.2014 23:13, Pavel Vasilyev пишет:
> 
> > But not  -rt1, -rt2, -rt3 -rt4, .... -rt99
> 
> Or
> 
> 3.12-rt1,
> 3.12-rt2,
> ...
> 3.12-rt33,
> ...
> 3.12-rt111,
> ...
> 3.12-rt999
> ...
> 
> Now, to have to roll back all my changes, then work -rt patch,
> then impose SUBLEVEL mainline diff, then last -rt patch, then my сhanges.

So we need a different numbering scheme just because your workflow is
completely backwards?

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ANNOUNCE] 3.12.12-rt19
  2014-02-23 21:13     ` Thomas Gleixner
@ 2014-02-23 22:55       ` Pavel Vasilyev
  2014-02-27  3:07         ` Steven Rostedt
  0 siblings, 1 reply; 11+ messages in thread
From: Pavel Vasilyev @ 2014-02-23 22:55 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Sebastian Andrzej Siewior, linux-rt-users, LKML, rostedt, John Kacur

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

24.02.2014 01:13, Thomas Gleixner пишет:
> On Sun, 23 Feb 2014, Pavel Vasilyev wrote:
>> 23.02.2014 23:13, Pavel Vasilyev пишет:
>>
>>> But not  -rt1, -rt2, -rt3 -rt4, .... -rt99
>>
>> Or
>>
>> 3.12-rt1,
>> 3.12-rt2,
>> ...
>> 3.12-rt33,
>> ...
>> 3.12-rt111,
>> ...
>> 3.12-rt999
>> ...
>>
>> Now, to have to roll back all my changes, then work -rt patch,
>> then impose SUBLEVEL mainline diff, then last -rt patch, then my сhanges.
> 
> So we need a different numbering scheme just because your workflow is
> completely backwards?

No, because in positional number systems, an increase in the senior level,
junior reset, but not stays the same. Mainline kernel and patches is senior level.



-- 

                                                         Pavel.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ANNOUNCE] 3.12.12-rt19
  2014-02-23 22:55       ` Pavel Vasilyev
@ 2014-02-27  3:07         ` Steven Rostedt
  0 siblings, 0 replies; 11+ messages in thread
From: Steven Rostedt @ 2014-02-27  3:07 UTC (permalink / raw)
  To: pavel
  Cc: Thomas Gleixner, Sebastian Andrzej Siewior, linux-rt-users, LKML,
	John Kacur

On Mon, 24 Feb 2014 02:55:20 +0400
Pavel Vasilyev <pavel@pavlinux.ru> wrote:

> No, because in positional number systems, an increase in the senior level,
> junior reset, but not stays the same. Mainline kernel and patches is senior level.

If you notice, there's no '.' between the mainline version and the rt
version. It's a dash "-rtX". What that number represents is the version
of the patch series for that release. We don't start a new version at
each stable release, but we do start a new one at each major release.

Thus, -rt19 is the 19th version of this rt patch series. When we rebase
on top of another major release, a lot of rewrites need to be done, and
we start a new version series.

Resetting the -rt number at each minor release would not be useful to
us and thus not necessary.

-- Steve

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ANNOUNCE] 3.12.12-rt19
  2014-02-23 18:47 [ANNOUNCE] 3.12.12-rt19 Sebastian Andrzej Siewior
  2014-02-23 19:13 ` Pavel Vasilyev
@ 2014-03-02  1:48 ` Fernando Lopez-Lezcano
  2014-03-07 11:18   ` nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19) Sebastian Andrzej Siewior
  1 sibling, 1 reply; 11+ messages in thread
From: Fernando Lopez-Lezcano @ 2014-03-02  1:48 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior, linux-rt-users
  Cc: nando, LKML, Thomas Gleixner, rostedt, John Kacur

[-- Attachment #1: Type: text/plain, Size: 4540 bytes --]

On 02/23/2014 10:47 AM, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v3.12.12-rt19 patch set.

Just hit this Oops in my desktop at home:

----
[22328.388996] BUG: unable to handle kernel NULL pointer dereference at 
0000000000000008
[22328.389013] IP: [<ffffffffa011a912>] 
nouveau_fence_wait_uevent.isra.2+0x22/0x440 [nouveau]
[22328.389014] PGD d85b7067 PUD df150067 PMD 0
[22328.389015] Oops: 0000 [#1] PREEMPT SMP
[22328.389026] Modules linked in: snd_hrtimer snd_usb_audio 
snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_seq_dummy fuse 
nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT 
arc4 xt_conntrack rt2800usb rt2x00usb rt2800lib rt2x00lib mac80211 
cfg80211 crc_ccitt ebtable_nat ebtable_broute bridge stp llc 
ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 
nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw 
ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 bnep nf_nat nf_conntrack iptable_mangle iptable_security 
iptable_raw w83627ehf hwmon_vid snd_hda_codec_hdmi raid1 
snd_hda_codec_realtek iTCO_wdt iTCO_vendor_support btusb bluetooth 
rfkill x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul 
crc32_pclmul crc32c_intel
[22328.389032]  ghash_clmulni_intel microcode serio_raw i2c_i801 
snd_ice1712 snd_cs8427 snd_i2c snd_ice17xx_ak4xxx snd_ak4xxx_adda 
snd_mpu401_uart snd_ac97_codec ac97_bus snd_hda_intel snd_hda_codec 
snd_hdsp snd_hwdep snd_rawmidi snd_seq snd_seq_device lpc_ich mfd_core 
snd_pcm snd_page_alloc e1000e snd_timer mei_me snd ptp mei pps_core 
soundcore shpchp nouveau firewire_ohci firewire_core crc_itu_t 
i2c_algo_bit drm_kms_helper ttm drm i2c_core mxm_wmi wmi video
[22328.389034] CPU: 3 PID: 1118 Comm: Xorg Not tainted 
3.12.12-300.rt19.1.fc20.ccrma.x86_64+rt #1
[22328.389034] Hardware name:                  /DZ77GA-70K, BIOS 
GAZ7711H.86A.0061.2012.1228.1110 12/28/2012
[22328.389035] task: ffff8807ba50ae40 ti: ffff8807c09bc000 task.ti: 
ffff8807c09bc000
[22328.389045] RIP: 0010:[<ffffffffa011a912>]  [<ffffffffa011a912>] 
nouveau_fence_wait_uevent.isra.2+0x22/0x440 [nouveau]
[22328.389046] RSP: 0018:ffff8807c09bdc20  EFLAGS: 00010282
[22328.389046] RAX: 0000000000000000 RBX: ffff8807a68f8fa8 RCX: 
0000000000000000
[22328.389046] RDX: 0000000000000001 RSI: ffff8807a68f8fb0 RDI: 
ffff8807a68f8fa8
[22328.389047] RBP: ffff8807c09bdca0 R08: 000000000000045e R09: 
000000000000e200
[22328.389047] R10: ffffffffa0157d80 R11: ffff8807c09bdde0 R12: 
0000000000000001
[22328.389047] R13: 0000000000000000 R14: ffff8807d8493a80 R15: 
ffff8807a68f8fb0
[22328.389048] FS:  00007fd3a3bc69c0(0000) GS:ffff8807fe380000(0000) 
knlGS:0000000000000000
[22328.389048] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[22328.389049] CR2: 0000000000000008 CR3: 00000000d85b6000 CR4: 
00000000001407e0
[22328.389049] Stack:
[22328.389050]  ffffffff816903f7 ffff8807c09bdde0 ffffffffa0157d80 
000000000000e200
[22328.389052]  000000000000045e 0000000000400080 0000000000000000 
0000000000000001
[22328.389053]  ffff8807a68f8fb0 ffff8807a68f8fa8 ffffffffffffff10 
ffff8807a68f8f80
[22328.389053] Call Trace:
[22328.389057]  [<ffffffff816903f7>] ? retint_kernel+0x37/0x40
[22328.389069]  [<ffffffffa011af56>] nouveau_fence_wait+0x86/0x1a0 [nouveau]
[22328.389081]  [<ffffffffa011ca35>] nouveau_bo_fence_wait+0x15/0x20 
[nouveau]
[22328.389084]  [<ffffffffa00867c6>] ttm_bo_wait+0x96/0x1a0 [ttm]
[22328.389095]  [<ffffffffa0121dac>] 
nouveau_gem_ioctl_cpu_prep+0x5c/0xf0 [nouveau]
[22328.389101]  [<ffffffffa002cd42>] drm_ioctl+0x502/0x630 [drm]
[22328.389105]  [<ffffffff810a116c>] ? migrate_enable+0x9c/0x200
[22328.389114]  [<ffffffffa01180a1>] nouveau_drm_ioctl+0x51/0x90 [nouveau]
[22328.389116]  [<ffffffff811ced55>] do_vfs_ioctl+0x2e5/0x4e0
[22328.389119]  [<ffffffff812bc7f6>] ? file_has_perm+0x86/0xa0
[22328.389120]  [<ffffffff811cefd1>] SyS_ioctl+0x81/0xa0
[22328.389122]  [<ffffffff816979a9>] system_call_fastpath+0x16/0x1b
[22328.389128] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 
e5 41 57 49 89 f7 41 56 41 55 41 54 41 89 d4 53 48 89 fb 48 83 ec 58 48 
8b 07 <48> 8b 48 08 48 8b 91 18 01 00 00 4c 8b b1 e0 07 00 00 48 8b 42
[22328.389137] RIP  [<ffffffffa011a912>] 
nouveau_fence_wait_uevent.isra.2+0x22/0x440 [nouveau]
[22328.389137]  RSP <ffff8807c09bdc20>
[22328.389138] CR2: 0000000000000008
[22328.394400] ---[ end trace 0000000000000002 ]---
----

I'm attaching the full dmesg and the configuration for this kernel...
-- Fernando

[-- Attachment #2: OOPS.txt.bz2 --]
[-- Type: application/x-bzip, Size: 22173 bytes --]

[-- Attachment #3: config-3.12.12-300.rt19.1.fc20.ccrma.x86_64+rt.bz2 --]
[-- Type: application/x-bzip, Size: 31849 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19)
  2014-03-02  1:48 ` Fernando Lopez-Lezcano
@ 2014-03-07 11:18   ` Sebastian Andrzej Siewior
  2014-03-07 11:36       ` Maarten Lankhorst
  0 siblings, 1 reply; 11+ messages in thread
From: Sebastian Andrzej Siewior @ 2014-03-07 11:18 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano, Ben Skeggs, Peter Hurley, Maarten Lankhorst
  Cc: linux-rt-users, LKML, dri-devel, Thomas Gleixner, rostedt, John Kacur

* Fernando Lopez-Lezcano | 2014-03-01 17:48:29 [-0800]:

>On 02/23/2014 10:47 AM, Sebastian Andrzej Siewior wrote:
>>Dear RT folks!
>>
>>I'm pleased to announce the v3.12.12-rt19 patch set.
>
>Just hit this Oops in my desktop at home:
>
>[22328.388996] BUG: unable to handle kernel NULL pointer dereference
>at 0000000000000008
>[22328.389013] IP: [<ffffffffa011a912>]
>nouveau_fence_wait_uevent.isra.2+0x22/0x440 [nouveau]

This is

| static int
| nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool intr)
| 
| {
|         struct nouveau_channel *chan = fence->channel;
|         struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);

and chan is NULL. 

>[22328.389046] RAX: 0000000000000000 RBX: ffff8807a68f8fa8 RCX:
>0000000000000000
>[22328.389046] RDX: 0000000000000001 RSI: ffff8807a68f8fb0 RDI:
>ffff8807a68f8fa8
>[22328.389047] RBP: ffff8807c09bdca0 R08: 000000000000045e R09:
>000000000000e200
>[22328.389047] R10: ffffffffa0157d80 R11: ffff8807c09bdde0 R12:
>0000000000000001
>[22328.389047] R13: 0000000000000000 R14: ffff8807d8493a80 R15:
>ffff8807a68f8fb0
>[22328.389053] Call Trace:
>[22328.389069]  [<ffffffffa011af56>] nouveau_fence_wait+0x86/0x1a0 [nouveau]
>[22328.389081]  [<ffffffffa011ca35>] nouveau_bo_fence_wait+0x15/0x20
>[nouveau]
>[22328.389084]  [<ffffffffa00867c6>] ttm_bo_wait+0x96/0x1a0 [ttm]
>[22328.389095]  [<ffffffffa0121dac>]
>nouveau_gem_ioctl_cpu_prep+0x5c/0xf0 [nouveau]
>[22328.389101]  [<ffffffffa002cd42>] drm_ioctl+0x502/0x630 [drm]
>[22328.389114]  [<ffffffffa01180a1>] nouveau_drm_ioctl+0x51/0x90 [nouveau]

I can't find any kind of locking so my question is what ensures that chan is
not set to NULL between nouveau_fence_done() and
nouveau_fence_wait_uevent()? There are just a few opcodes in between but
nothing that pauses nouveau_fence_signal().

Fernando, can you please check the patch below and test if the warning
or the crash appears?

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -184,14 +184,20 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool intr)
 
 {
 	struct nouveau_channel *chan = fence->channel;
-	struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
-	struct nouveau_fence_priv *priv = chan->drm->fence;
+	struct nouveau_fifo *pfifo;
+	struct nouveau_fence_priv *priv;
 	struct nouveau_fence_uevent uevent = {
 		.handler.func = nouveau_fence_wait_uevent_handler,
-		.priv = priv,
 	};
 	int ret = 0;
 
+	if (WARN_ON_ONCE(!chan))
+		return 0;
+
+	pfifo = nouveau_fifo(chan->drm->device);
+	priv = chan->drm->fence;
+	uevent.priv = priv;
+
 	nouveau_event_get(pfifo->uevent, 0, &uevent.handler);
 
 	if (fence->timeout) {

>-- Fernando

Sebastian

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19)
  2014-03-07 11:18   ` nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19) Sebastian Andrzej Siewior
@ 2014-03-07 11:36       ` Maarten Lankhorst
  0 siblings, 0 replies; 11+ messages in thread
From: Maarten Lankhorst @ 2014-03-07 11:36 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior, Fernando Lopez-Lezcano, Ben Skeggs,
	Peter Hurley
  Cc: linux-rt-users, LKML, dri-devel, Thomas Gleixner, rostedt, John Kacur

op 07-03-14 12:18, Sebastian Andrzej Siewior schreef:
> * Fernando Lopez-Lezcano | 2014-03-01 17:48:29 [-0800]:
>
>> On 02/23/2014 10:47 AM, Sebastian Andrzej Siewior wrote:
>>> Dear RT folks!
>>>
>>> I'm pleased to announce the v3.12.12-rt19 patch set.
>> Just hit this Oops in my desktop at home:
>>
>> [22328.388996] BUG: unable to handle kernel NULL pointer dereference
>> at 0000000000000008
>> [22328.389013] IP: [<ffffffffa011a912>]
>> nouveau_fence_wait_uevent.isra.2+0x22/0x440 [nouveau]
> This is
>
> | static int
> | nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool intr)
> |
> | {
> |         struct nouveau_channel *chan = fence->channel;
> |         struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
>
> and chan is NULL.
>
>> [22328.389046] RAX: 0000000000000000 RBX: ffff8807a68f8fa8 RCX:
>> 0000000000000000
>> [22328.389046] RDX: 0000000000000001 RSI: ffff8807a68f8fb0 RDI:
>> ffff8807a68f8fa8
>> [22328.389047] RBP: ffff8807c09bdca0 R08: 000000000000045e R09:
>> 000000000000e200
>> [22328.389047] R10: ffffffffa0157d80 R11: ffff8807c09bdde0 R12:
>> 0000000000000001
>> [22328.389047] R13: 0000000000000000 R14: ffff8807d8493a80 R15:
>> ffff8807a68f8fb0
>> [22328.389053] Call Trace:
>> [22328.389069]  [<ffffffffa011af56>] nouveau_fence_wait+0x86/0x1a0 [nouveau]
>> [22328.389081]  [<ffffffffa011ca35>] nouveau_bo_fence_wait+0x15/0x20
>> [nouveau]
>> [22328.389084]  [<ffffffffa00867c6>] ttm_bo_wait+0x96/0x1a0 [ttm]
>> [22328.389095]  [<ffffffffa0121dac>]
>> nouveau_gem_ioctl_cpu_prep+0x5c/0xf0 [nouveau]
>> [22328.389101]  [<ffffffffa002cd42>] drm_ioctl+0x502/0x630 [drm]
>> [22328.389114]  [<ffffffffa01180a1>] nouveau_drm_ioctl+0x51/0x90 [nouveau]
> I can't find any kind of locking so my question is what ensures that chan is
> not set to NULL between nouveau_fence_done() and
> nouveau_fence_wait_uevent()? There are just a few opcodes in between but
> nothing that pauses nouveau_fence_signal().
Absolutely nothing. :-) Worse still, there's no guarantee that channel isn't freed, but hopefully that is less likely to be an issue.

~Maarten


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19)
@ 2014-03-07 11:36       ` Maarten Lankhorst
  0 siblings, 0 replies; 11+ messages in thread
From: Maarten Lankhorst @ 2014-03-07 11:36 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior, Fernando Lopez-Lezcano, Ben Skeggs,
	Peter Hurley
  Cc: linux-rt-users, LKML, rostedt, dri-devel, John Kacur, Thomas Gleixner

op 07-03-14 12:18, Sebastian Andrzej Siewior schreef:
> * Fernando Lopez-Lezcano | 2014-03-01 17:48:29 [-0800]:
>
>> On 02/23/2014 10:47 AM, Sebastian Andrzej Siewior wrote:
>>> Dear RT folks!
>>>
>>> I'm pleased to announce the v3.12.12-rt19 patch set.
>> Just hit this Oops in my desktop at home:
>>
>> [22328.388996] BUG: unable to handle kernel NULL pointer dereference
>> at 0000000000000008
>> [22328.389013] IP: [<ffffffffa011a912>]
>> nouveau_fence_wait_uevent.isra.2+0x22/0x440 [nouveau]
> This is
>
> | static int
> | nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool intr)
> |
> | {
> |         struct nouveau_channel *chan = fence->channel;
> |         struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
>
> and chan is NULL.
>
>> [22328.389046] RAX: 0000000000000000 RBX: ffff8807a68f8fa8 RCX:
>> 0000000000000000
>> [22328.389046] RDX: 0000000000000001 RSI: ffff8807a68f8fb0 RDI:
>> ffff8807a68f8fa8
>> [22328.389047] RBP: ffff8807c09bdca0 R08: 000000000000045e R09:
>> 000000000000e200
>> [22328.389047] R10: ffffffffa0157d80 R11: ffff8807c09bdde0 R12:
>> 0000000000000001
>> [22328.389047] R13: 0000000000000000 R14: ffff8807d8493a80 R15:
>> ffff8807a68f8fb0
>> [22328.389053] Call Trace:
>> [22328.389069]  [<ffffffffa011af56>] nouveau_fence_wait+0x86/0x1a0 [nouveau]
>> [22328.389081]  [<ffffffffa011ca35>] nouveau_bo_fence_wait+0x15/0x20
>> [nouveau]
>> [22328.389084]  [<ffffffffa00867c6>] ttm_bo_wait+0x96/0x1a0 [ttm]
>> [22328.389095]  [<ffffffffa0121dac>]
>> nouveau_gem_ioctl_cpu_prep+0x5c/0xf0 [nouveau]
>> [22328.389101]  [<ffffffffa002cd42>] drm_ioctl+0x502/0x630 [drm]
>> [22328.389114]  [<ffffffffa01180a1>] nouveau_drm_ioctl+0x51/0x90 [nouveau]
> I can't find any kind of locking so my question is what ensures that chan is
> not set to NULL between nouveau_fence_done() and
> nouveau_fence_wait_uevent()? There are just a few opcodes in between but
> nothing that pauses nouveau_fence_signal().
Absolutely nothing. :-) Worse still, there's no guarantee that channel isn't freed, but hopefully that is less likely to be an issue.

~Maarten

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19)
  2014-03-07 11:36       ` Maarten Lankhorst
  (?)
@ 2014-03-07 11:53       ` Sebastian Andrzej Siewior
  -1 siblings, 0 replies; 11+ messages in thread
From: Sebastian Andrzej Siewior @ 2014-03-07 11:53 UTC (permalink / raw)
  To: Maarten Lankhorst
  Cc: Fernando Lopez-Lezcano, Ben Skeggs, Peter Hurley, linux-rt-users,
	LKML, dri-devel, Thomas Gleixner, rostedt, John Kacur

* Maarten Lankhorst | 2014-03-07 12:36:13 [+0100]:

>>I can't find any kind of locking so my question is what ensures that chan is
>>not set to NULL between nouveau_fence_done() and
>>nouveau_fence_wait_uevent()? There are just a few opcodes in between but
>>nothing that pauses nouveau_fence_signal().
>Absolutely nothing. :-) Worse still, there's no guarantee that channel isn't freed, but hopefully that is less likely to be an issue.

Okay, so I hit the correct spot. What do we do here? Do you want the
patch I posted without the WARN_ON() or do you prefer to fix this in an
other way?

>~Maarten

Sebastian

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2014-03-07 11:54 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-23 18:47 [ANNOUNCE] 3.12.12-rt19 Sebastian Andrzej Siewior
2014-02-23 19:13 ` Pavel Vasilyev
2014-02-23 19:29   ` Pavel Vasilyev
2014-02-23 21:13     ` Thomas Gleixner
2014-02-23 22:55       ` Pavel Vasilyev
2014-02-27  3:07         ` Steven Rostedt
2014-03-02  1:48 ` Fernando Lopez-Lezcano
2014-03-07 11:18   ` nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19) Sebastian Andrzej Siewior
2014-03-07 11:36     ` Maarten Lankhorst
2014-03-07 11:36       ` Maarten Lankhorst
2014-03-07 11:53       ` Sebastian Andrzej Siewior

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.