4.18 Rebase plans

[Laura Abbott]

Hi,

As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
built for rawhide yesterday. We will be following roughly the same
rebase schedule as in the past. F28 will get the rebase first,
typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
My best guess for when this would happen would be middle of September.
As always, we'll keep you updated on any new developments.

Thanks,
Laura

P.S. As a general reminder, if you like F27 please remember to
give karma to kernels.

[Justin Forbes]

On Tue, Aug 14, 2018 at 11:14 AM, Laura Abbott <labbott(a)redhat.com&gt; wrote:

>  Hi,
>
>  As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
>  built for rawhide yesterday. We will be following roughly the same
>  rebase schedule as in the past. F28 will get the rebase first,
>  typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
>  My best guess for when this would happen would be middle of September.
>  As always, we'll keep you updated on any new developments.
>
>  Also of note, the 4.18 test day will be next Tuesday the 21st.  Anyone 
willing to
test would be a great help towards making the rebase go as
smoothly as possible.  More details can be found
https://fedoraproject.org/wiki/Test_Day:2018-08-21_Kernel_4.18_Test_Day
with images posted the day before (Monday).

Thanks,
Justin

[Reindl Harald]

Am 14.08.2018 um 19:16 schrieb Justin Forbes:
>  On Tue, Aug 14, 2018 at 11:14 AM, Laura Abbott
> <labbott(a)redhat.com&gt; wrote:
> > As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
> > built for rawhide yesterday. We will be following roughly the same
> > rebase schedule as in the past. F28 will get the rebase first,
> > typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
> > My best guess for when this would happen would be middle of September.
> > As always, we'll keep you updated on any new developments.
> >
> > Also of note, the 4.18 test day will be next Tuesday the 21st.  Anyone
>  willing to test would be a great help towards making the rebase go as
>  smoothly as possible.  More details can be found
>  https://fedoraproject.org/wiki/Test_Day:2018-08-21_Kernel_4.18_Test_Day
>  with images posted the day before (Monday) 
[root@testserver:~]$ uname -a
Linux testserver.rhsoft.net 4.18.0-1.fc29.x86_64 #1 SMP Mon Aug 13
16:10:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[root@testserver:~]$ cat /etc/redhat-release
Generic release 28 (Generic)

runs just fine with dbmail, dovecot, httpd, php, mariadb, spamassassin,
clamav....

[Hans de Goede]

Hi,

On 14-08-18 18:14, Laura Abbott wrote:
>  Hi,
>  
>  As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
>  built for rawhide yesterday. We will be following roughly the same
>  rebase schedule as in the past. F28 will get the rebase first,
>  typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
>  My best guess for when this would happen would be middle of September.
>  As always, we'll keep you updated on any new developments. 
FYI, there seems to be a problem with 4.18 as a virtualbox guest,
sometimes when the user resizes the vm-window the contents of the vm
Windows stop updating (when running a GUI) until the next resize.

This is probably an issue in the vboxvideo driver, triggered by
changes in 4.18 elsewhere. I've looking into this on my to do list.

Regards,

Hans

[Laura Abbott]

On 08/16/2018 05:27 AM, Hans de Goede wrote:
>  Hi,
>  
>  On 14-08-18 18:14, Laura Abbott wrote:
> > Hi,
> >
> > As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
> > built for rawhide yesterday. We will be following roughly the same
> > rebase schedule as in the past. F28 will get the rebase first,
> > typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
> > My best guess for when this would happen would be middle of September.
> > As always, we'll keep you updated on any new developments.
>  
>  FYI, there seems to be a problem with 4.18 as a virtualbox guest,
>  sometimes when the user resizes the vm-window the contents of the vm
>  Windows stop updating (when running a GUI) until the next resize.
>  
>  This is probably an issue in the vboxvideo driver, triggered by
>  changes in 4.18 elsewhere. I've looking into this on my to do list.
>   
Thanks for the report. I'll check back before doing the push if
I don't hear anything before that.

[Hans de Goede]

Hi,

On 16-08-18 14:27, Hans de Goede wrote:
>  Hi,
>  
>  On 14-08-18 18:14, Laura Abbott wrote:
> > Hi,
> >
> > As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
> > built for rawhide yesterday. We will be following roughly the same
> > rebase schedule as in the past. F28 will get the rebase first,
> > typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
> > My best guess for when this would happen would be middle of September.
> > As always, we'll keep you updated on any new developments.
>  
>  FYI, there seems to be a problem with 4.18 as a virtualbox guest,
>  sometimes when the user resizes the vm-window the contents of the vm
>  Windows stop updating (when running a GUI) until the next resize.
>  
>  This is probably an issue in the vboxvideo driver, triggered by
>  changes in 4.18 elsewhere. I've looking into this on my to do list. 
Never mind it turns out that this is a pre-existing problem which
got triggered due to other changes (it requires the user-session to
be GNOME on Wayland to trigger and I was mostly testing with
GNOME on Xorg).

TL;DR: There still is a bug, but it is not a regression in 4.18.

Regards,

Hans

[Laura Abbott]

On 08/14/2018 09:14 AM, Laura Abbott wrote:
>  Hi,
>  
>  As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
>  built for rawhide yesterday. We will be following roughly the same
>  rebase schedule as in the past. F28 will get the rebase first,
>  typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
>  My best guess for when this would happen would be middle of September.
>  As always, we'll keep you updated on any new developments.
>  
>  Thanks,
>  Laura
>  
>  P.S. As a general reminder, if you like F27 please remember to
>  give karma to kernels. 
4.18.2 is nominally expected to be released this weekend but
stable updates have been accelerated due to needing to get
L1TF fixes out. At the very least we need to wait until the
merge window closes and the test day happens before pushing the
rebase. F29 will be up to date for anyone who wants to test
that kernel.

[Laura Abbott]

On 08/17/2018 06:57 AM, Laura Abbott wrote:
>  On 08/14/2018 09:14 AM, Laura Abbott wrote:
> > Hi,
> >
> > As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
> > built for rawhide yesterday. We will be following roughly the same
> > rebase schedule as in the past. F28 will get the rebase first,
> > typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
> > My best guess for when this would happen would be middle of September.
> > As always, we'll keep you updated on any new developments.
> >
> > Thanks,
> > Laura
> >
> > P.S. As a general reminder, if you like F27 please remember to
> > give karma to kernels.
>  
>  4.18.2 is nominally expected to be released this weekend but
>  stable updates have been accelerated due to needing to get
>  L1TF fixes out. At the very least we need to wait until the
>  merge window closes and the test day happens before pushing the
>  rebase. F29 will be up to date for anyone who wants to test
>  that kernel. 
My current plan is to push the F28 rebase early next week.
If you get a chance, please test the F29 kernel or the
package in the kernel-stabilization COPR.

Laura

[Jason L Tibbitts III]

> >>>> "LA" == Laura Abbott
> <labbott(a)redhat.com&gt; writes: 
LA> My current plan is to push the F28 rebase early next week.  If you
LA> get a chance, please test the F29 kernel or the package in the
LA> kernel-stabilization COPR.

I thought we weren't doing kernel-stabilization this time around because
the F29 kernels were sufficient, but looking now I see it's there
(though the 4.18.5 build failed).

I've been running F29 kernels (on my F28 desktop) since 4.18.0 showed up
there and everything has been well.  Currently running
kernel-4.18.5-300.fc29 from
https://koji.fedoraproject.org/koji/buildinfo?buildID=1139115 with no
issues at all.  I just had to do this:

mkdir kernel; cd kernel
koji download-build -a x86_64 kernel-4.18.5-300.fc29
dnf update *rpm

and reboot into the new kernel.

 - J<

[Laura Abbott]

On 08/29/2018 01:05 PM, Jason L Tibbitts III wrote:
> >>>>> "LA" == Laura Abbott
> <labbott(a)redhat.com&gt; writes:
>  
>  LA> My current plan is to push the F28 rebase early next week.  If you
>  LA> get a chance, please test the F29 kernel or the package in the
>  LA> kernel-stabilization COPR.
>  
>  I thought we weren't doing kernel-stabilization this time around because
>  the F29 kernels were sufficient, but looking now I see it's there
>  (though the 4.18.5 build failed).
>   
I didn't end up pushing anything to the kernel-stabilization branch
but I did use the stabilization repo to test the actual rebased
versions since the work looks slightly different between a straight
F29 branch and a rebase (dropping some patches and config options)

>  I've been running F29 kernels (on my F28 desktop) since 4.18.0
> showed up
>  there and everything has been well.  Currently running
>  kernel-4.18.5-300.fc29 from
>  https://koji.fedoraproject.org/koji/buildinfo?buildID=1139115 with no
>  issues at all.  I just had to do this:
>   
Oh I missed that. It looks like it was an infra problem. I'll
keep an eye out when I do the final rebase.

>  mkdir kernel; cd kernel
>  koji download-build -a x86_64 kernel-4.18.5-300.fc29
>  dnf update *rpm
>  
>  and reboot into the new kernel. 
Excellent, thanks for your report and support as always

[Laura Abbott]

On 08/14/2018 09:14 AM, Laura Abbott wrote:
>  Hi,
>  
>  As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
>  built for rawhide yesterday. We will be following roughly the same
>  rebase schedule as in the past. F28 will get the rebase first,
>  typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
>  My best guess for when this would happen would be middle of September.
>  As always, we'll keep you updated on any new developments.
>  
>  Thanks,
>  Laura
>  
>  P.S. As a general reminder, if you like F27 please remember to
>  give karma to kernels. 
The kernel is now in testing for F28. Please test and give karma as I
would like to push very soon.

[Jason L Tibbitts III]

> >>>> "LA" == Laura Abbott
> <labbott(a)redhat.com&gt; writes: 
LA> The kernel is now in testing for F28. Please test and give karma as
LA> I would like to push very soon.

For the record, that's
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a8b6cb002c

which can be fetched with 
   dnf update --enablerepo=updates-testing --advisory=FEDORA-2018-a8b6cb002c

 - J<

[Reindl Harald]

Am 07.09.18 um 02:41 schrieb Laura Abbott:
>  On 08/14/2018 09:14 AM, Laura Abbott wrote:
> > Hi,
> >
> > As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was
> > built for rawhide yesterday. We will be following roughly the same
> > rebase schedule as in the past. F28 will get the rebase first,
> > typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter.
> > My best guess for when this would happen would be middle of September.
> > As always, we'll keep you updated on any new developments.
> >
> > Thanks,
> > Laura
> >
> > P.S. As a general reminder, if you like F27 please remember to
> > give karma to kernels.
>  
>  The kernel is now in testing for F28. Please test and give karma as I
>  would like to push very soon. 
on virtual machines i use the f29 for some time

for the phyiscal hosts i would be thankful if someone starts a 4.18.6
build for F28 to avoid another reboot cycle the next day given the
amount of bugfixes and that even Phoronix wrote an article with "Linux
4.18.6 Rolls Out With L1TF Foreshadow Fixes"

some items in the upstream changelog may even fix the
"/sys/devices/system/cpu/vulnerabilities/l1tf:Vulnerable" on my machine
with 32 GB RAM while all others have
"/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion"
even vm's on top of the 32 GB machine which seems to be still vulnerable

https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18.6-Stab...

https://koji.fedoraproject.org/koji/packageinfo?packageID=8

kernel-4.18.6-300.fc29 	labbott 	2018-09-06 01:05:35 	
kernel-4.18.5-200.fc28 	labbott 	2018-09-04 21:12:52

[Reindl Harald]

Am 07.09.18 um 06:11 schrieb Reindl Harald:
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18.6-Stab...
>  
>  https://koji.fedoraproject.org/koji/packageinfo?packageID=8
>  
>  kernel-4.18.6-300.fc29 	labbott 	2018-09-06 01:05:35 	
>  kernel-4.18.5-200.fc28 	labbott 	2018-09-04 21:12:52 
FTR: kernel-4.18.5 shoukd have been replaced by kernel-4.18.6 and i
*really* don't get why a build for F29 got fired up but not for F28

there are machines which need it for l1tf, see changelog below

"extremely unlikely system" is nonsense, it's an ordinary "HP Compaq
Elite 8300 CMT" simply running with 32 GB

----------------

[root@srv-rhsoft:~]$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation:
Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user
pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full
generic retpoline, IBPB, IBRS_FW

[root@srv-rhsoft:~]$ uname -r
4.18.6-300.fc29.x86_64 #1 SMP Wed Sep 5 20:11:09 UTC 2018

[root@srv-rhsoft:~]$ cat /etc/redhat-release
Generic release 28 (Generic)
----------------

here you go:
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.18.6

x86/speculation/l1tf: Fix off-by-one error when warning that system has
too much RAM

commit b0a182f875689647b014bc01d36b340217792852 upstream.

Two users have reported [1] that they have an "extremely unlikely" system
with more than MAX_PA/2 memory and L1TF mitigation is not effective. In
fact it's a CPU with 36bits phys limit (64GB) and 32GB memory, but due to
holes in the e820 map, the main region is almost 500MB over the 32GB limit:

[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000081effffff] usable

Suggestions to use 'mem=32G' to enable the L1TF mitigation while losing the
500MB revealed, that there's an off-by-one error in the check in
l1tf_select_mitigation().