New Kernels: 4.4.181, 4.9.181, 4.14.125, 4.19.50, 5.1.9 - just two days after the last kernels releases. And as always, You Must Upgrade NOW

It's not unreasonable to wonder if Greg Kroah-Hartman simply put "All users of the $stablebranch kernel series must upgrade" in a template at some point and simply forgot to remove it. This is the fourth release in a row carrying this scary demand.

You must unpack and compile a new kernel NOW. Why? Who knows.

It's just been a whopping who days since the last round of kernel releases carrying a warning that users "must" upgrade without any indication as to why immediately upgrading is such important. As we said in our last article about new kernels: The fable about the boy who cried wolf comes to mind.

We actually do see a rather significant problem fixed in 4.14.125, 4.9.181 and 4.4.181 which was caused by a back-ported file-system-related change which works fine on 4.19.50 and newer but breaks some filesystems on 4.14.125, 4.9.181 and 4.4.181.

"Commit 9c225f2655e3 ("vfs: atomic f_pos accesses as per POSIX") added locking for file.f_pos access and in particular made concurrent read and write not possible - now both those functions take f_pos lock for the whole run, and so if e.g. a read is blocked waiting for data, write will deadlock waiting for that read to complete.

This caused regression for stream-like files where previously read and write could run simultaneously, but after that patch could not do so anymore. See e.g. commit 581d21a2d02a ("xenbus: fix deadlock on writes to /proc/xen/xenbus") which fixes such regression for particular case of proc/xen/xenbus."

Changelog for kernel 4.9.181

This fix is of course not present in 4.19.50 and 5.1.9 since those kernels never had that problem. Nothing really critical stands out in those kernels but those two kernels do have one change the earlier kernels do not which appears to be rather.. important to those using an AMD graphics card:

"In the case of a normal sync update, the preparation of framebuffers (be it calling drm_atomic_helper_prepare_planes() or doing setups with drm_framebuffer_get()) are performed in the new_state and the respective cleanups are performed in the old_state.

In the case of async updates, the preparation is also done in the new_state but the cleanups are done in the new_state (because updates are performed in place, i.e. in the current state).

The current code blocks async udpates when the fb is changed, turning async updates into sync updates, slowing down cursor updates and introducing regressions in igt tests with errors of type:

"CRITICAL: completed 97 cursor updated in a period of 30 flips, we expect to complete approximately 15360 updates, with the threshold set at 7680"

Fb changes in async updates were prevented to avoid the following scenario:

Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)

Where we have a single call to prepare fb2 but double cleanup call to fb2.

To solve the above problems, instead of blocking async fb changes, we place the old framebuffer in the new_state object, so when the code performs cleanups in the new_state it will cleanup the old_fb and we will have the following scenario instead:

Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2

Where calls to prepare/cleanup are balanced."

kernel 5.1.9 changelog

Nobody wants asynchronous updates turning into synchronous updates or a slowly updating cursor. There are reasons to upgrade both older kernels (file-system related on 4.4, 4.9 and 4.14 series kernels) and graphics related on 4.19 and 5.1. But does this mean you must upgrade NOW? That's up to you to decide. You can probably have lunch first and the world won't end if you don't.

You can find the announcements demanding that you immediately upgrade now here:

https://lkml.org/lkml/2019/6/11/577 :

"I'm announcing the release of the 5.1.9 kernel. All users of the 5.1 kernel series must upgrade."

https://lkml.org/lkml/2019/6/11/579 :

"I'm announcing the release of the 4.19.50 kernel. All users of the 4.19 kernel series must upgrade."

https://lkml.org/lkml/2019/6/11/581 :

"I'm announcing the release of the 4.14.125 kernel. All users of the 4.14 kernel series must upgrade."

https://lkml.org/lkml/2019/6/11/583 :

"I'm announcing the release of the 4.9.181 kernel. All users of the 4.9 kernel series must upgrade."

https://lkml.org/lkml/2019/6/11/585 :

"I'm announcing the release of the 4.4.181 kernel. All users of the 4.4 kernel series must upgrade."

You can read the full changelog's for these new stable kernels here:

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.1.9

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.50

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.125

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.181

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.181