[ANNOUNCE] 3.18.43-rt46

[ANNOUNCE] 3.18.43-rt46

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.18.43-rt46 stable release.


This release is just an update to the new stable 3.18.43 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.18-rt
  Head SHA1: 970149ffe7b4f8e027989a8a7d4696b8d9cc64d1


Or to build 3.18.43-rt46 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.18.43.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.43-rt46.patch.xz




Enjoy,

-- Steve

RE: [ANNOUNCE] 3.18.43-rt46

[Koehrer Mathias (ETAS/ESW5)]

Hi Steven,

> Or to build 3.18.43-rt46 directly, the following patches should be applied:
> 
>   http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.tar.xz
>   http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.18.43.xz
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.43-rt46.patch.xz
I am using the patches as proposed.

However with this version I get lots of compiler warnings:

./arch/x86/include/asm/preempt.h:118:6: warning: 'tmp' may be used uninitialized in this function [-Wmaybe-uninitialized]
  tmp &= ~PREEMPT_NEED_RESCHED;
         ^
./arch/x86/include/asm/preempt.h:112:6: note: 'tmp' was declared here
  u32 tmp;
        ^

The relevant code is the following:

/*
 * Returns true when we need to resched and can (barring IRQ state).
 */
static __always_inline bool should_resched(void)
{
#ifdef CONFIG_PREEMPT_LAZY
	u32 tmp;

	if (!raw_cpu_read_4(__preempt_count))
		return true;

	/* preempt count == 0 ? */
	tmp &= ~PREEMPT_NEED_RESCHED;
	if (tmp)
		return false;
	if (current_thread_info()->preempt_lazy_count)
		return false;
	return test_thread_flag(TIF_NEED_RESCHED_LAZY);
#else
	return unlikely(!raw_cpu_read_4(__preempt_count));
#endif
}

And within this code tmp is actually not initialized, the warning is fine.
This code is new with the patch-3.18.43-rt46.patch.xz.
With the previous patch-3.18.42-rt44.patch.xz the code of should_resched
was differently (much more compact) and did not show the warnings.

Regards

Mathias

Re: [ANNOUNCE] 3.18.43-rt46

[Steven Rostedt]

On Wed, 26 Oct 2016 10:37:01 +0000
"Koehrer Mathias (ETAS/ESW5)" <mathias.koehrer@etas.com> wrote:

> Hi Steven,
> 
> > Or to build 3.18.43-rt46 directly, the following patches should be applied:
> > 
> >   http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.tar.xz
> >   http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.18.43.xz
> >   http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.43-rt46.patch.xz  
> I am using the patches as proposed.
> 
> However with this version I get lots of compiler warnings:
> 
> ./arch/x86/include/asm/preempt.h:118:6: warning: 'tmp' may be used uninitialized in this function [-Wmaybe-uninitialized]
>   tmp &= ~PREEMPT_NEED_RESCHED;
>          ^
> ./arch/x86/include/asm/preempt.h:112:6: note: 'tmp' was declared here
>   u32 tmp;
>         ^
> 
> The relevant code is the following:
> 
> /*
>  * Returns true when we need to resched and can (barring IRQ state).
>  */
> static __always_inline bool should_resched(void)
> {
> #ifdef CONFIG_PREEMPT_LAZY
> 	u32 tmp;
> 
> 	if (!raw_cpu_read_4(__preempt_count))
> 		return true;
> 
> 	/* preempt count == 0 ? */
> 	tmp &= ~PREEMPT_NEED_RESCHED;
> 	if (tmp)
> 		return false;
> 	if (current_thread_info()->preempt_lazy_count)
> 		return false;
> 	return test_thread_flag(TIF_NEED_RESCHED_LAZY);
> #else
> 	return unlikely(!raw_cpu_read_4(__preempt_count));
> #endif
> }
> 
> And within this code tmp is actually not initialized, the warning is fine.
> This code is new with the patch-3.18.43-rt46.patch.xz.
> With the previous patch-3.18.42-rt44.patch.xz the code of should_resched
> was differently (much more compact) and did not show the warnings.

Thanks for the report. I'm just finishing up the stable pull of
3.18-rt, and after that, I'll be pulling in fixes for things like this.

-- Steve