Date   
compass update

f6bvp
 

Hi,
Is there any scrip to perform download of new compass linux distro version (for example beta 13) and to burn it on a micro SD card inserted into an USB port via an adapter ?
Thanks,
Bernard, f6bvp

Re: compass update

Basil Gunn
 

Is there any scrip to perform download of new compass linux distro
version (for example beta 13) and to burn it on a micro SD card
inserted into an USB port via an adapter ?
I have a script I use, burnimage.sh that is in the 'Manufacturing'
repository which is private. I will send that script to you. It assumes
you have already downloaded the image.

You have to manually edit two variables (OUTPUT_DEVICE, IMAGE_VER) at
the top of the script.

Thanks,
Bernard, f6bvp

Re: compass update

f6bvp
 

Basil,
Thanks for providing burnimage script from « manufacturing repository ».
I am using the following command to get the last Compass image : 

wget http://nwdig.net/downloads/current_beta.zip

When unzipped the image takes around 6 Gb. So the system SD card must be a large one.
Unfortunately I noticed that when plugging a second microSD card simultaneously into one spare USB port, it is not recognized.
Any solution ?

73 de Bernard f6bvp

Le 19 mai 2019 à 16:25, Basil Gunn <basil@...> a écrit :



Is there any scrip to perform download of new compass linux distro
version (for example beta 13) and to burn it on a micro SD card
inserted into an USB port via an adapter ?

I have a script I use, burnimage.sh that is in the 'Manufacturing'
repository which is private. I will send that script to you. It assumes
you have already downloaded the image.

You have to manually edit two variables (OUTPUT_DEVICE, IMAGE_VER) at
the top of the script.

Thanks,
Bernard, f6bvp

Re: compass update

Basil Gunn
 

Thanks for providing burnimage script from « manufacturing repository ».
I am using the following command to get the last Compass image :

wget http://nwdig.net/downloads/current_beta.zip

When unzipped the image takes around 6 Gb. So the system SD card must be a large one.
Unfortunately I noticed that when plugging a second microSD card simultaneously into one spare USB port, it is not recognized.
Any solution ?
Are you plugging the second microSD card into a USB port on the RPi or
your workstation? What OS is on your workstation? Try df -h before &
after you plug the microSD card in. I don't think I am understanding
what you are doing.

I just tried it on my RPi and the microSD card shows up as device
/dev/sda1 & /dev/sda2

$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 15G 5.0G 9.1G 36% /
devtmpfs 460M 0 460M 0% /dev
tmpfs 464M 0 464M 0% /dev/shm
tmpfs 464M 13M 452M 3% /run
tmpfs 5.0M 16K 5.0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 44M 22M 22M 50% /boot
tmpfs 93M 0 93M 0% /run/user/1000
/dev/sda1 44M 23M 22M 51% /media/pi/boot
/dev/sda2 15G 4.3G 9.6G 31% /media/pi/rootfs

/Basil


73 de Bernard f6bvp

Le 19 mai 2019 à 16:25, Basil Gunn <@basil860> a écrit :



Is there any scrip to perform download of new compass linux distro
version (for example beta 13) and to burn it on a micro SD card
inserted into an USB port via an adapter ?
I have a script I use, burnimage.sh that is in the 'Manufacturing'
repository which is private. I will send that script to you. It assumes
you have already downloaded the image.

You have to manually edit two variables (OUTPUT_DEVICE, IMAGE_VER) at
the top of the script.

Thanks,
Bernard, f6bvp

Re: compass update

f6bvp
 

Basil,

I agree my description was not clear.
What you report is exactly the same as what df command reports when I plug in a microSD card into USB port of my RPi with Compass Linux.
The issue is when I add another microSD card into another USB port. This one is what I called a second SD card, not counting the Compass System one.
This last SD card is not detected and not mounted. Thus I cannot use it to save files from the other microSD.
However, I noticed that dev/sdb1 and /dev/sdb2 are reported by command fdisk -l (l for list).
I don’t know how to mount these sdb devices manually.
It would be more convenient if both additional device cards could be mounted at the same time to facilitate saving files from one place to another.

Bernard

Le 19 mai 2019 à 22:56, Basil Gunn <@basil860> a écrit :

Are you plugging the second microSD card into a USB port on the RPi or
your workstation? What OS is on your workstation? Try df -h before &
after you plug the microSD card in. I don't think I am understanding
what you are doing.

I just tried it on my RPi and the microSD card shows up as device
/dev/sda1 & /dev/sda2

$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 15G 5.0G 9.1G 36% /
devtmpfs 460M 0 460M 0% /dev
tmpfs 464M 0 464M 0% /dev/shm
tmpfs 464M 13M 452M 3% /run
tmpfs 5.0M 16K 5.0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 44M 22M 22M 50% /boot
tmpfs 93M 0 93M 0% /run/user/1000
/dev/sda1 44M 23M 22M 51% /media/pi/boot
/dev/sda2 15G 4.3G 9.6G 31% /media/pi/rootfs

/Basil

Re: compass update

 

This is Linux administration. 

In the shell type

man mount


On Mon, May 20, 2019, 04:54 f6bvp <f6bvp@...> wrote:
Basil,

I agree my description was not clear.
What you report is exactly the same as what df command reports when I plug in a microSD card into USB port of my RPi with Compass Linux.
The issue is when I add another microSD card into another USB port. This one is what I called a second SD card, not counting the Compass System one.
This last SD card is not detected and not mounted. Thus I cannot use it to save files from the other microSD.
However, I noticed that dev/sdb1 and /dev/sdb2 are reported by command fdisk -l (l for list).
I don’t know how to mount these sdb  devices manually.
It would be more convenient if both additional  device cards could be mounted at the same time to facilitate saving files from one place to another.

Bernard

> Le 19 mai 2019 à 22:56, Basil Gunn <basil@...> a écrit :
>
> Are you plugging the second microSD card into a USB port on the RPi or
> your workstation? What OS is on your workstation? Try df -h before &
> after you plug the microSD card in. I don't think I am understanding
> what you are doing.
>
> I just tried it on my RPi and the microSD card shows up as device
> /dev/sda1 & /dev/sda2
>
> $ df -h
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/root        15G  5.0G  9.1G  36% /
> devtmpfs        460M     0  460M   0% /dev
> tmpfs           464M     0  464M   0% /dev/shm
> tmpfs           464M   13M  452M   3% /run
> tmpfs           5.0M   16K  5.0M   1% /run/lock
> tmpfs           464M     0  464M   0% /sys/fs/cgroup
> /dev/mmcblk0p1   44M   22M   22M  50% /boot
> tmpfs            93M     0   93M   0% /run/user/1000
> /dev/sda1        44M   23M   22M  51% /media/pi/boot
> /dev/sda2        15G  4.3G  9.6G  31% /media/pi/rootfs
>
> /Basil
>




Re: compass update

Basil Gunn
 

Hi Bernard,
I have a solution that worked for me.

From your description you want a usb adapter with a microSD card to auto
mount when you plug it in to an RPi USB slot. When I do this on my
workstation which is a heavily modified Ubuntu distro it automounts the
two partitions, boot & rootfs to mount points /media/<user_name>/boot &
/media/<user_name/rootfs.

I have this working as described above on my RPi using a usbmount
package but not the current version in the Raspbian repo. This version
(0.0.22) only partially worked ie. it only mounted the /dev/sda1
partition and not both partitions. To get the exact functionality seen
on my workstation I had to build the latest version from this git repo:
https://github.com/rbrito/usbmount

Follow the instructions here:
Automatically Mount USB Drives On Ubuntu Or Debian Server With USBmount
https://www.linuxuprising.com/2019/04/automatically-mount-usb-drives-on.html

Precede these instructions with:
sudo apt-get install lockfile-progs

Follow these instructions with
sudo dpkg -i usbmount_0.0.24_all.deb

To test: After inserting the usb adapter I look at the last 2 lines of
'df -h', that should look like this:

/dev/sda1 44M 23M 22M 51% /media/usb1
/dev/sda2 15G 4.3G 9.6G 31% /media/usb0

Also look at the mount points in /media/pi which are symlinks to /media/usb0 and
/media/usb1 and you should see the 2 partitions used on an RPi mSD card.

ls -l /media/pi
total 7
drwxr-xr-x 3 pi pi 2560 Dec 31 1969 boot
drwxr-xr-x 21 root root 4096 Nov 18 22:45 rootfs

Let me know if this works for you. Also look at the permissions of the
directory of the mount point you want to copy or modify files on. You
will have to match those permissions.

There is a stunning amount of bad or old information on the web
regarding this topic and I went down a path of modifying my udev config
and rendered my RPi unbootable. I didn't spend time figuring out what I
did wrong so my advice is do NOT muck with udev to get this to work.

/Basil



f6bvp <f6bvp@...> writes:

Basil,

I agree my description was not clear.
What you report is exactly the same as what df command reports when I plug in a microSD card into USB port of my RPi with Compass Linux.
The issue is when I add another microSD card into another USB port. This one is what I called a second SD card, not counting the Compass System one.
This last SD card is not detected and not mounted. Thus I cannot use it to save files from the other microSD.
However, I noticed that dev/sdb1 and /dev/sdb2 are reported by command fdisk -l (l for list).
I don’t know how to mount these sdb devices manually.
It would be more convenient if both additional device cards could be mounted at the same time to facilitate saving files from one place to another.

Bernard

Le 19 mai 2019 à 22:56, Basil Gunn <@basil860> a écrit :

Are you plugging the second microSD card into a USB port on the RPi or
your workstation? What OS is on your workstation? Try df -h before &
after you plug the microSD card in. I don't think I am understanding
what you are doing.

I just tried it on my RPi and the microSD card shows up as device
/dev/sda1 & /dev/sda2

$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 15G 5.0G 9.1G 36% /
devtmpfs 460M 0 460M 0% /dev
tmpfs 464M 0 464M 0% /dev/shm
tmpfs 464M 13M 452M 3% /run
tmpfs 5.0M 16K 5.0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 44M 22M 22M 50% /boot
tmpfs 93M 0 93M 0% /run/user/1000
/dev/sda1 44M 23M 22M 51% /media/pi/boot
/dev/sda2 15G 4.3G 9.6G 31% /media/pi/rootfs

/Basil

add compass overlay to existing raspbian install?

Jon Gross
 


I have an existing raspbian install that already has a bunch of ham radio stuff configured (chirp/direwolf/pat/APRS etc. along with a bunch of networking configured for my setup), and was curious if I could add compass to it, instead of starting from a new image and re-doing all the setup?

I would assume it's simply adding to my /etc/apt/sources.list and doing an apt-get update, but my googling didn't turn up any docs about it, so I thought I'd check here.

Thanks!

--
jon, KJ7GDX

Re: add compass repository to existing raspbian install?

 

Hi Jon,

It is possible, but much more complex than you indicate, and is not recommended.  If you go ahead, make sure you have a full backup of your SD card.

Are you using this with a UDRC, UDRC-II, or DRAWS™?

Is your current install Stretch?

Here is the current state.  

Raspbian Buster has just been released, it has support for the UDRC/DRAWS™ built into the kernel and in a few weeks it will be the standard install, deprecating Compass.  Some people have been going ahead with Buster, and updating it to include the dtoverlay, sensors config, and applications on top of it.  You can follow this thread to learn more.

There are some good notes here.

On Tue, Jul 9, 2019 at 10:24 PM Jon Gross <jong@...> wrote:

I have an existing raspbian install that already has a bunch of ham radio stuff configured (chirp/direwolf/pat/APRS etc. along with a bunch of networking configured for my setup), and was curious if I could add compass to it, instead of starting from a new image and re-doing all the setup?

I would assume it's simply adding to my /etc/apt/sources.list and doing an apt-get update, but my googling didn't turn up any docs about it, so I thought I'd check here.

Thanks!

--
jon, KJ7GDX


--


John D. Hays
Director

  

Re: add compass repository to existing raspbian install?

 

Also -- https://nw-digital-radio.groups.io/g/udrc/wiki/home for general setup information.

Re: add compass repository to existing raspbian install?

Jon Gross
 

Ah!  I'm using this with DRAWS™ (well intending to, I just received my hardware in the mail yesterday).

I will proceed with the Buster based install, and do the rest manually, as I like to tinker.

Thank so much for the advice and pointers, and for your work writing the drivers in the first place!

-jon

Re: add compass repository to existing raspbian install?

 

Jon,

You are welcome to the advice, and if you like to tinker, you will have great fun.  However, all of the credit for the driver goes to Annaliese McDermond (NH6Z)!  It took months of work with the Linux kernel team for final approval and she not only coded the driver but managed the process.

On Wed, Jul 10, 2019 at 10:00 AM Jon Gross <jong@...> wrote:

Thank so much for the advice and pointers, and for your work writing the drivers in the first place!

-jon

--
John D. Hays
Kingston, WA
K7VE

 

Re: add compass repository to existing raspbian install?

Jon Gross
 

I will seek her out and thank her as well.

Cheers!

Updates to Github #github

compass@nw-digital-radio.groups.io Integration <compass@...>
 

[linux] New branch lloyd-aviation was created by mcdermj.


3370 New Commits:

[linux:lloyd-aviation] By Hans Verkuil <hverkuil-cisco@...>:
573d423a9bd7: media: videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused()

commit 5e99456c20f712dcc13d9f6ca4278937d5367355 upstream.

Userspace shouldn't set bytesused to 0 for output buffers.
vb2_warn_zero_bytesused() warns about this (only once!), but it also
calls WARN_ON(1), which is confusing since it is not immediately clear
that it warns about a 0 value for bytesused.

Just drop the WARN_ON as it serves no purpose.

Signed-off-by: Hans Verkuil <hverkuil-cisco@...>
Acked-by: Ezequiel Garcia <ezequiel@...>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...>
Cc: Matthias Maennich <maennich@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/media/common/videobuf2/videobuf2-v4l2.c


[linux:lloyd-aviation] By Hou Tao <houtao1@...>:
e08ba890dc29: 9p: use inode->i_lock to protect i_size_write() under 32-bit

commit 5e3cc1ee1405a7eb3487ed24f786dec01b4cbe1f upstream.

Use inode->i_lock to protect i_size_write(), else i_size_read() in
generic_fillattr() may loop infinitely in read_seqcount_begin() when
multiple processes invoke v9fs_vfs_getattr() or v9fs_vfs_getattr_dotl()
simultaneously under 32-bit SMP environment, and a soft lockup will be
triggered as show below:

watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [stat:2217]
Modules linked in:
CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e #4
Hardware name: Generic DT based system
PC is at generic_fillattr+0x104/0x108
LR is at 0xec497f00
pc : [<802b8898>] lr : [<ec497f00>] psr: 200c0013
sp : ec497e20 ip : ed608030 fp : ec497e3c
r10: 00000000 r9 : ec497f00 r8 : ed608030
r7 : ec497ebc r6 : ec497f00 r5 : ee5c1550 r4 : ee005780
r3 : 0000052d r2 : 00000000 r1 : ec497f00 r0 : ed608030
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: ac48006a DAC: 00000051
CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e #4
Hardware name: Generic DT based system
Backtrace:
[<8010d974>] (dump_backtrace) from [<8010dc88>] (show_stack+0x20/0x24)
[<8010dc68>] (show_stack) from [<80a1d194>] (dump_stack+0xb0/0xdc)
[<80a1d0e4>] (dump_stack) from [<80109f34>] (show_regs+0x1c/0x20)
[<80109f18>] (show_regs) from [<801d0a80>] (watchdog_timer_fn+0x280/0x2f8)
[<801d0800>] (watchdog_timer_fn) from [<80198658>] (__hrtimer_run_queues+0x18c/0x380)
[<801984cc>] (__hrtimer_run_queues) from [<80198e60>] (hrtimer_run_queues+0xb8/0xf0)
[<80198da8>] (hrtimer_run_queues) from [<801973e8>] (run_local_timers+0x28/0x64)
[<801973c0>] (run_local_timers) from [<80197460>] (update_process_times+0x3c/0x6c)
[<80197424>] (update_process_times) from [<801ab2b8>] (tick_nohz_handler+0xe0/0x1bc)
[<801ab1d8>] (tick_nohz_handler) from [<80843050>] (arch_timer_handler_virt+0x38/0x48)
[<80843018>] (arch_timer_handler_virt) from [<80180a64>] (handle_percpu_devid_irq+0x8c/0x240)
[<801809d8>] (handle_percpu_devid_irq) from [<8017ac20>] (generic_handle_irq+0x34/0x44)
[<8017abec>] (generic_handle_irq) from [<8017b344>] (__handle_domain_irq+0x6c/0xc4)
[<8017b2d8>] (__handle_domain_irq) from [<801022e0>] (gic_handle_irq+0x4c/0x88)
[<80102294>] (gic_handle_irq) from [<80101a30>] (__irq_svc+0x70/0x98)
[<802b8794>] (generic_fillattr) from [<8056b284>] (v9fs_vfs_getattr_dotl+0x74/0xa4)
[<8056b210>] (v9fs_vfs_getattr_dotl) from [<802b8904>] (vfs_getattr_nosec+0x68/0x7c)
[<802b889c>] (vfs_getattr_nosec) from [<802b895c>] (vfs_getattr+0x44/0x48)
[<802b8918>] (vfs_getattr) from [<802b8a74>] (vfs_statx+0x9c/0xec)
[<802b89d8>] (vfs_statx) from [<802b9428>] (sys_lstat64+0x48/0x78)
[<802b93e0>] (sys_lstat64) from [<80101000>] (ret_fast_syscall+0x0/0x28)

[dominique.martinet@...: updated comment to not refer to a function
in another subsystem]
Link: http://lkml.kernel.org/r/20190124063514.8571-2-houtao1@...
Cc: stable@...
Fixes: 7549ae3e81cc ("9p: Use the i_size_[read, write]() macros instead of using inode->i_size directly.")
Reported-by: Xing Gaopeng <xingaopeng@...>
Signed-off-by: Hou Tao <houtao1@...>
Signed-off-by: Dominique Martinet <dominique.martinet@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/9p/v9fs_vfs.h
Modified: fs/9p/vfs_file.c
Modified: fs/9p/vfs_inode.c
Modified: fs/9p/vfs_inode_dotl.c
Modified: fs/9p/vfs_super.c


[linux:lloyd-aviation] By zhengbin <zhengbin13@...>:
85bdc9daff40: 9p/net: fix memory leak in p9_client_create

commit bb06c388fa20ae24cfe80c52488de718a7e3a53f upstream.

If msize is less than 4096, we should close and put trans, destroy
tagpool, not just free client. This patch fixes that.

Link: http://lkml.kernel.org/m/1552464097-142659-1-git-send-email-zhengbin13@...
Cc: stable@...
Fixes: 574d356b7a02 ("9p/net: put a lower bound on msize")
Reported-by: Hulk Robot <hulkci@...>
Signed-off-by: zhengbin <zhengbin13@...>
Signed-off-by: Dominique Martinet <dominique.martinet@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/9p/client.c


[linux:lloyd-aviation] By S.j. Wang <shengjiu.wang@...>:
098e0f89a341: ASoC: fsl_esai: fix register setting issue in RIGHT_J mode

commit cc29ea007347f39f4c5a4d27b0b555955a0277f9 upstream.

The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to
wrong register, correct it.

Fixes 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Cc: <stable@...>
Signed-off-by: Shengjiu Wang <shengjiu.wang@...>
Reviewed-by: Fabio Estevam <festevam@...>
Ackedy-by: Nicolin Chen <nicoleotsuka@...>
Signed-off-by: Mark Brown <broonie@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/soc/fsl/fsl_esai.c


[linux:lloyd-aviation] By Codrin Ciubotariu <codrin.ciubotariu@...>:
7d9e07582a7f: ASoC: codecs: pcm186x: fix wrong usage of DECLARE_TLV_DB_SCALE()

commit fcf4daabf08079e6d09958a2992e7446ef8d0438 upstream.

According to DS, the gain is between -12 dB and 40 dB, with a 0.5 dB step.
Tested on pcm1863.

Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@...>
Acked-by: Andrew F. Davis <afd@...>
Signed-off-by: Mark Brown <broonie@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/soc/codecs/pcm186x.c


[linux:lloyd-aviation] By Codrin Ciubotariu <codrin.ciubotariu@...>:
3f44122e065c: ASoC: codecs: pcm186x: Fix energysense SLEEP bit

commit 05bd7fcdd06b19a10f069af1bea3ad9abac038d7 upstream.

The ADCs are sleeping when the SLEEP bit is set and running when it's
cleared, so the bit should be inverted.
Tested on pcm1863.

Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@...>
Acked-by: Andrew F. Davis <afd@...>
Signed-off-by: Mark Brown <broonie@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/soc/codecs/pcm186x.c


[linux:lloyd-aviation] By Krzysztof Kozlowski <krzk@...>:
dbcb0a590ecb: iio: adc: exynos-adc: Fix NULL pointer exception on unbind

commit 2ea8bab4dd2a9014e723b28091831fa850b82d83 upstream.

Fix NULL pointer exception on device unbind when device tree does not
contain "has-touchscreen" property. In such case the input device is
not registered so it should not be unregistered.

$ echo "12d10000.adc" > /sys/bus/platform/drivers/exynos-adc/unbind

Unable to handle kernel NULL pointer dereference at virtual address 00000474
...
(input_unregister_device) from [<c0772060>] (exynos_adc_remove+0x20/0x80)
(exynos_adc_remove) from [<c0587d5c>] (platform_drv_remove+0x20/0x40)
(platform_drv_remove) from [<c05860f0>] (device_release_driver_internal+0xdc/0x1ac)
(device_release_driver_internal) from [<c0583ecc>] (unbind_store+0x60/0xd4)
(unbind_store) from [<c031b89c>] (kernfs_fop_write+0x100/0x1e0)
(kernfs_fop_write) from [<c029709c>] (__vfs_write+0x2c/0x17c)
(__vfs_write) from [<c0297374>] (vfs_write+0xa4/0x184)
(vfs_write) from [<c0297594>] (ksys_write+0x4c/0xac)
(ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)

Fixes: 2bb8ad9b44c5 ("iio: exynos-adc: add experimental touchscreen support")
Cc: <stable@...>
Signed-off-by: Krzysztof Kozlowski <krzk@...>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/iio/adc/exynos_adc.c


[linux:lloyd-aviation] By Alexander Usyskin <alexander.usyskin@...>:
02c0c70fb36e: mei: hbm: clean the feature flags on link reset

commit 37fd0b623023484ef6df79ed46f21f06ecc611ff upstream.

The list of supported functions can be altered upon link reset,
clean the flags to allow correct selections of supported
features.

Cc: <stable@...> v4.19+
Signed-off-by: Alexander Usyskin <alexander.usyskin@...>
Signed-off-by: Tomas Winkler <tomas.winkler@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/misc/mei/hbm.c


[linux:lloyd-aviation] By Alexander Usyskin <alexander.usyskin@...>:
a253d1f3e490: mei: bus: move hw module get/put to probe/release

commit b5958faa34e2f99f3475ad89c52d98dfea079d33 upstream.

Fix unbalanced module reference counting during internal reset, which
prevents the drivers unloading.
Tracking mei_me/txe modules on mei client bus via
mei_cldev_enable/disable is error prone due to possible internal
reset flow, where clients are disconnected underneath.
Moving reference counting to probe and release of mei bus client
driver solves this issue in simplest way, as each client provides only
a single connection to a client bus driver.

Cc: <stable@...>
Signed-off-by: Alexander Usyskin <alexander.usyskin@...>
Signed-off-by: Tomas Winkler <tomas.winkler@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/misc/mei/bus.c


[linux:lloyd-aviation] By Zhi Jin <zhi.jin@...>:
dd6ce0316e70: stm class: Fix an endless loop in channel allocation

commit a1d75dad3a2c689e70a1c4e0214cca9de741d0aa upstream.

There is a bug in the channel allocation logic that leads to an endless
loop when looking for a contiguous range of channels in a range with a
mixture of free and occupied channels. For example, opening three
consequtive channels, closing the first two and requesting 4 channels in
a row will trigger this soft lockup. The bug is that the search loop
forgets to skip over the range once it detects that one channel in that
range is occupied.

Restore the original intent to the logic by fixing the omission.

Signed-off-by: Zhi Jin <zhi.jin@...>
Signed-off-by: Alexander Shishkin <alexander.shishkin@...>
Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices")
CC: stable@... # v4.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/hwtracing/stm/core.c


[linux:lloyd-aviation] By Franck LENORMAND <franck.lenormand@...>:
32eeecf7ac87: crypto: caam - fix hash context DMA unmap size

commit 65055e2108847af5e577cc7ce6bde45ea136d29a upstream.

When driver started using state->caam_ctxt for storing both running hash
and final hash, it was not updated to handle different DMA unmap
lengths.

Cc: <stable@...> # v4.19+
Fixes: c19650d6ea99 ("crypto: caam - fix DMA mapping of stack memory")
Signed-off-by: Franck LENORMAND <franck.lenormand@...>
Signed-off-by: Horia Geantă <horia.geanta@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/crypto/caam/caamhash.c


[linux:lloyd-aviation] By Gustavo A. R. Silva <gustavo@...>:
ce36d9fafb43: crypto: ccree - fix missing break in switch statement

commit b5be853181a8d4a6e20f2073ccd273d6280cad88 upstream.

Add missing break statement in order to prevent the code from falling
through to case S_DIN_to_DES.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support")
Cc: stable@...
Signed-off-by: Gustavo A. R. Silva <gustavo@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/crypto/ccree/cc_cipher.c


[linux:lloyd-aviation] By Pankaj Gupta <pankaj.gupta@...>:
74fd74e1fc8d: crypto: caam - fixed handling of sg list

commit 42e95d1f10dcf8b18b1d7f52f7068985b3dc5b79 upstream.

when the source sg contains more than 1 fragment and
destination sg contains 1 fragment, the caam driver
mishandle the buffers to be sent to caam.

Fixes: f2147b88b2b1 ("crypto: caam - Convert GCM to new AEAD interface")
Cc: <stable@...> # 4.2+
Signed-off-by: Pankaj Gupta <pankaj.gupta@...>
Signed-off-by: Arun Pathak <arun.pathak@...>
Reviewed-by: Horia Geanta <horia.geanta@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/crypto/caam/caamalg.c


[linux:lloyd-aviation] By Horia Geantă <horia.geanta@...>:
6f4c11b09770: crypto: caam - fix DMA mapping of stack memory

commit c19650d6ea99bcd903d3e55dd61860026c701339 upstream.

Roland reports the following issue and provides a root cause analysis:

"On a v4.19 i.MX6 system with IMA and CONFIG_DMA_API_DEBUG enabled, a
warning is generated when accessing files on a filesystem for which IMA
measurement is enabled:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:1181 check_for_stack.part.9+0xd0/0x120
caam_jr 2101000.jr0: DMA-API: device driver maps memory from stack [addr=b668049e]
Modules linked in:
CPU: 0 PID: 1 Comm: switch_root Not tainted 4.19.0-20181214-1 #2
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c010efb8>] (dump_backtrace) from [<c010f2d0>] (show_stack+0x20/0x24)
[<c010f2b0>] (show_stack) from [<c08b04f4>] (dump_stack+0xa0/0xcc)
[<c08b0454>] (dump_stack) from [<c012b610>] (__warn+0xf0/0x108)
[<c012b520>] (__warn) from [<c012b680>] (warn_slowpath_fmt+0x58/0x74)
[<c012b62c>] (warn_slowpath_fmt) from [<c0199acc>] (check_for_stack.part.9+0xd0/0x120)
[<c01999fc>] (check_for_stack.part.9) from [<c019a040>] (debug_dma_map_page+0x144/0x174)
[<c0199efc>] (debug_dma_map_page) from [<c065f7f4>] (ahash_final_ctx+0x5b4/0xcf0)
[<c065f240>] (ahash_final_ctx) from [<c065b3c4>] (ahash_final+0x1c/0x20)
[<c065b3a8>] (ahash_final) from [<c03fe278>] (crypto_ahash_op+0x38/0x80)
[<c03fe240>] (crypto_ahash_op) from [<c03fe2e0>] (crypto_ahash_final+0x20/0x24)
[<c03fe2c0>] (crypto_ahash_final) from [<c03f19a8>] (ima_calc_file_hash+0x29c/0xa40)
[<c03f170c>] (ima_calc_file_hash) from [<c03f2b24>] (ima_collect_measurement+0x1dc/0x240)
[<c03f2948>] (ima_collect_measurement) from [<c03f0a60>] (process_measurement+0x4c4/0x6b8)
[<c03f059c>] (process_measurement) from [<c03f0cdc>] (ima_file_check+0x88/0xa4)
[<c03f0c54>] (ima_file_check) from [<c02d8adc>] (path_openat+0x5d8/0x1364)
[<c02d8504>] (path_openat) from [<c02dad24>] (do_filp_open+0x84/0xf0)
[<c02daca0>] (do_filp_open) from [<c02cf50c>] (do_open_execat+0x84/0x1b0)
[<c02cf488>] (do_open_execat) from [<c02d1058>] (__do_execve_file+0x43c/0x890)
[<c02d0c1c>] (__do_execve_file) from [<c02d1770>] (sys_execve+0x44/0x4c)
[<c02d172c>] (sys_execve) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
---[ end trace 3455789a10e3aefd ]---

The cause is that the struct ahash_request *req is created as a
stack-local variable up in the stack (presumably somewhere in the IMA
implementation), then passed down into the CAAM driver, which tries to
dma_single_map the req->result (indirectly via map_seq_out_ptr_result)
in order to make that buffer available for the CAAM to store the result
of the following hash operation.

The calling code doesn't know how req will be used by the CAAM driver,
and there could be other such occurrences where stack memory is passed
down to the CAAM driver. Therefore we should rather fix this issue in
the CAAM driver where the requirements are known."

Fix this problem by:
-instructing the crypto engine to write the final hash in state->caam_ctx
-subsequently memcpy-ing the final hash into req->result

Cc: <stable@...> # v4.19+
Reported-by: Roland Hieber <rhi@...>
Signed-off-by: Horia Geantă <horia.geanta@...>
Tested-by: Roland Hieber <rhi@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/crypto/caam/caamhash.c


[linux:lloyd-aviation] By Hadar Gat <hadar.gat@...>:
009eeb9878b4: crypto: ccree - fix free of unallocated mlli buffer

commit a49411959ea6d4915a9fd2a7eb5ba220e6284e9a upstream.

In cc_unmap_aead_request(), call dma_pool_free() for mlli buffer only
if an item is allocated from the pool and not always if there is a
pool allocated.
This fixes a kernel panic when trying to free a non-allocated item.

Cc: stable@...
Signed-off-by: Hadar Gat <hadar.gat@...>
Signed-off-by: Gilad Ben-Yossef <gilad@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/crypto/ccree/cc_buffer_mgr.c


[linux:lloyd-aviation] By Gilad Ben-Yossef <gilad@...>:
0bdd345a3848: crypto: ccree - unmap buffer before copying IV

commit c139c72e2beb3e3db5148910b3962b7322e24374 upstream.

We were copying the last ciphertext block into the IV field
for CBC before removing the DMA mapping of the output buffer
with the result of the buffer sometime being out-of-sync cache
wise and were getting intermittent cases of bad output IV.

Fix it by moving the DMA buffer unmapping before the copy.

Signed-off-by: Gilad Ben-Yossef <gilad@...>
Fixes: 00904aa0cd59 ("crypto: ccree - fix iv handling")
Cc: <stable@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/crypto/ccree/cc_cipher.c


[linux:lloyd-aviation] By Gilad Ben-Yossef <gilad@...>:
6ed42ccca59d: crypto: ccree - don't copy zero size ciphertext

commit 2b5ac17463dcb2411fed506edcf259a89bb538ba upstream.

For decryption in CBC mode we need to save the last ciphertext block
for use as the next IV. However, we were trying to do this also with
zero sized ciphertext resulting in a panic.

Fix this by only doing the copy if the ciphertext length is at least
of IV size.

Signed-off-by: Gilad Ben-Yossef <gilad@...>
Cc: stable@...
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/crypto/ccree/cc_cipher.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
0b1871d041d3: crypto: cfb - add missing 'chunksize' property

commit 394a9e044702e6a8958a5e89d2a291605a587a2a upstream.

Like some other block cipher mode implementations, the CFB
implementation assumes that while walking through the scatterlist, a
partial block does not occur until the end. But the walk is incorrectly
being done with a blocksize of 1, as 'cra_blocksize' is set to 1 (since
CFB is a stream cipher) but no 'chunksize' is set. This bug causes
incorrect encryption/decryption for some scatterlist layouts.

Fix it by setting the 'chunksize'. Also extend the CFB test vectors to
cover this bug as well as cases where the message length is not a
multiple of the block size.

Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack mode")
Cc: <stable@...> # v4.17+
Cc: James Bottomley <James.Bottomley@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/cfb.c
Modified: crypto/testmgr.h


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
1a10e6b5bb34: crypto: cfb - remove bogus memcpy() with src == dest

commit 6c2e322b3621dc8be72e5c86d4fdb587434ba625 upstream.

The memcpy() in crypto_cfb_decrypt_inplace() uses walk->iv as both the
source and destination, which has undefined behavior. It is unneeded
because walk->iv is already used to hold the previous ciphertext block;
thus, walk->iv is already updated to its final value. So, remove it.

Also, note that in-place decryption is the only case where the previous
ciphertext block is not directly available. Therefore, as a related
cleanup I also updated crypto_cfb_encrypt_segment() to directly use the
previous ciphertext block rather than save it into walk->iv. This makes
it consistent with in-place encryption and out-of-place decryption; now
only in-place decryption is different, because it has to be.

Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack mode")
Cc: <stable@...> # v4.17+
Cc: James Bottomley <James.Bottomley@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/cfb.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
3c5d7703bbd0: crypto: ahash - fix another early termination in hash walk

commit 77568e535af7c4f97eaef1e555bf0af83772456c upstream.

Hash algorithms with an alignmask set, e.g. "xcbc(aes-aesni)" and
"michael_mic", fail the improved hash tests because they sometimes
produce the wrong digest. The bug is that in the case where a
scatterlist element crosses pages, not all the data is actually hashed
because the scatterlist walk terminates too early. This happens because
the 'nbytes' variable in crypto_hash_walk_done() is assigned the number
of bytes remaining in the page, then later interpreted as the number of
bytes remaining in the scatterlist element. Fix it.

Fixes: 900a081f6912 ("crypto: ahash - Fix early termination in hash walk")
Cc: stable@...
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/ahash.c


[linux:lloyd-aviation] By Zhang Zhijie <zhangzj@...>:
5aabf06712c2: crypto: rockchip - fix scatterlist nents error

commit 4359669a087633132203c52d67dd8c31e09e7b2e upstream.

In some cases, the nents of src scatterlist is different from
dst scatterlist. So two variables are used to handle the nents
of src&dst scatterlist.

Reported-by: Eric Biggers <ebiggers@...>
Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288")
Cc: <stable@...> # v4.5+
Signed-off-by: Zhang Zhijie <zhangzj@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/crypto/rockchip/rk3288_crypto.c
Modified: drivers/crypto/rockchip/rk3288_crypto.h
Modified: drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
Modified: drivers/crypto/rockchip/rk3288_crypto_ahash.c


[linux:lloyd-aviation] By Zhang Zhijie <zhangzj@...>:
2e0e1f9a1e41: crypto: rockchip - update new iv to device in multiple operations

commit c1c214adcb56d36433480c8fedf772498e7e539c upstream.

For chain mode in cipher(eg. AES-CBC/DES-CBC), the iv is continuously
updated in the operation. The new iv value should be written to device
register by software.

Reported-by: Eric Biggers <ebiggers@...>
Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288")
Cc: <stable@...> # v4.5+
Signed-off-by: Zhang Zhijie <zhangzj@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/crypto/rockchip/rk3288_crypto.h
Modified: drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c


[linux:lloyd-aviation] By Philipp Zabel <p.zabel@...>:
a308622febe1: drm/imx: ignore plane updates on disabled crtcs

[ Upstream commit 4fb873c9648e383206e0a91cef9b03aa54066aca ]

This patch fixes backtraces like the following when sending SIGKILL to a
process with a currently pending plane update:

[drm:ipu_plane_atomic_check] CRTC should be enabled
[drm:drm_framebuffer_remove] *ERROR* failed to commit
------------[ cut here ]------------
WARNING: CPU: 3 PID: 63 at drivers/gpu/drm/drm_framebuffer.c:926 drm_framebuffer_remove+0x47c/0x498
atomic remove_fb failed with -22

Signed-off-by: Philipp Zabel <p.zabel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/gpu/drm/imx/ipuv3-plane.c


[linux:lloyd-aviation] By Alexander Shiyan <shc_work@...>:
1640b5288615: gpu: ipu-v3: Fix i.MX51 CSI control registers offset

[ Upstream commit 2c0408dd0d8906b26fe8023889af7adf5e68b2c2 ]

The CSI0/CSI1 registers offset is at +0xe030000/+0xe038000 relative
to the control module registers on IPUv3EX.
This patch fixes wrong values for i.MX51 CSI0/CSI1.

Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")

Signed-off-by: Alexander Shiyan <shc_work@...>
Signed-off-by: Philipp Zabel <p.zabel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/gpu/ipu-v3/ipu-common.c


[linux:lloyd-aviation] By Julia Lawall <Julia.Lawall@...>:
04c5c4c47c31: drm/imx: imx-ldb: add missing of_node_puts

[ Upstream commit aa3312012f103f91f123600bbf768b11c8f431bc ]

The device node iterators perform an of_node_get on each
iteration, so a jump out of the loop requires an of_node_put.

Move the initialization channel->child = child; down to just
before the call to imx_ldb_register so that intervening failures
don't need to clear it. Add a label at the end of the function to
do all the of_node_puts.

The semantic patch that finds part of this problem is as follows
(http://coccinelle.lip6.fr):

// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@

for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
(
return child;
|
* return ...;
)
...
}
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@...>
Signed-off-by: Philipp Zabel <p.zabel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/gpu/drm/imx/imx-ldb.c


[linux:lloyd-aviation] By Steve Longerbeam <slongerbeam@...>:
35ad2e6d7e46: gpu: ipu-v3: Fix CSI offsets for imx53

[ Upstream commit bb867d219fda7fbaabea3314702474c4eac2b91d ]

The CSI offsets are wrong for both CSI0 and CSI1. They are at
physical address 0x1e030000 and 0x1e038000 respectively.

Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")

Signed-off-by: Steve Longerbeam <slongerbeam@...>
Signed-off-by: Philipp Zabel <p.zabel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/gpu/ipu-v3/ipu-common.c


[linux:lloyd-aviation] By Shuming Fan <shumingf@...>:
b2c642a1a618: ASoC: rt5682: Correct the setting while select ASRC clk for AD/DA filter

[ Upstream commit 8077ec011b1ea26abb7ca786f28ecccfb352717f ]

AD/DA ASRC function control two ASRC clock sources separately.
Whether AD/DA filter select which clock source, we enable AD/DA ASRC
function for all cases.

Signed-off-by: Shuming Fan <shumingf@...>
Signed-off-by: Mark Brown <broonie@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: sound/soc/codecs/rt5682.c


[linux:lloyd-aviation] By Tony Lindgren <tony@...>:
ac696b0176b4: clocksource: timer-ti-dm: Fix pwm dmtimer usage of fck reparenting

[ Upstream commit 983a5a43ec254cd5ddf3254db80ca96e8f8bb2a4 ]

Commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
them with ti-sysc") moved some omap4 timers to probe with ti-sysc
interconnect target module. Turns out this broke pwm-omap-dmtimer
where we now try to reparent the clock to itself with the following:

omap_dm_timer_of_set_source: failed to set parent

With ti-sysc, we can now configure the clock sources in the dts
with assigned-clocks and assigned-clock-parents. So we should be able
to remove omap_dm_timer_of_set_source with clean-up patches later on.
But for now, let's just fix it first by checking if parent and fck
are the same and bail out of so.

Fixes: 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")

Cc: Bartosz Golaszewski <bgolaszewski@...>
Cc: Daniel Lezcano <daniel.lezcano@...>
Cc: H. Nikolaus Schaller <hns@...>
Cc: Keerthy <j-keerthy@...>
Cc: Ladislav Michl <ladis@...>
Cc: Pavel Machek <pavel@...>
Cc: Sebastian Reichel <sre@...>
Cc: Tero Kristo <t-kristo@...>
Cc: Thierry Reding <thierry.reding@...>
Cc: Thomas Gleixner <tglx@...>
Reported-by: H. Nikolaus Schaller <hns@...>
Tested-By: Andreas Kemnade <andreas@...>
Tested-By: H. Nikolaus Schaller <hns@...>
Signed-off-by: Tony Lindgren <tony@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/clocksource/timer-ti-dm.c


[linux:lloyd-aviation] By Julien Thierry <julien.thierry@...>:
5f4a64b040c9: KVM: arm/arm64: vgic: Make vgic_dist->lpi_list_lock a raw_spinlock

[ Upstream commit fc3bc475231e12e9c0142f60100cf84d077c79e1 ]

vgic_dist->lpi_list_lock must always be taken with interrupts disabled as
it is used in interrupt context.

For configurations such as PREEMPT_RT_FULL, this means that it should
be a raw_spinlock since RT spinlocks are interruptible.

Signed-off-by: Julien Thierry <julien.thierry@...>
Acked-by: Christoffer Dall <christoffer.dall@...>
Acked-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Christoffer Dall <christoffer.dall@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: include/kvm/arm_vgic.h
Modified: virt/kvm/arm/vgic/vgic-init.c
Modified: virt/kvm/arm/vgic/vgic-its.c
Modified: virt/kvm/arm/vgic/vgic.c


[linux:lloyd-aviation] By Enric Balletbo i Serra <enric.balletbo@...>:
cdaf89ab8f77: arm64: dts: rockchip: fix graph_port warning on rk3399 bob kevin and excavator

[ Upstream commit 26cd8657c7e745686a4c54a5cccf721ede208a25 ]

Ports are described by child 'port' nodes contained in the device node.
'ports' is optional and is used to group all 'port' nodes which is not
the case here.

This patch fixes the following warnings:

arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts:25.9-29.5: Warning (graph_port): /edp-panel/ports: graph port node name should be 'port'
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts:46.9-50.5: Warningi (graph_port): /edp-panel/ports: graph port node name should be 'port'
arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts:94.9-98.5: Warning (graph_port): /edp-panel/ports: graph port node name should be 'port'

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@...>
Signed-off-by: Heiko Stuebner <heiko@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts
Modified: arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
Modified: arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts


[linux:lloyd-aviation] By Stefan Haberland <sth@...>:
98a137cd0484: s390/dasd: fix using offset into zero size array error

[ Upstream commit 4a8ef6999bce998fa5813023a9a6b56eea329dba ]

Dan Carpenter reported the following:

The patch 52898025cf7d: "[S390] dasd: security and PSF update patch
for EMC CKD ioctl" from Mar 8, 2010, leads to the following static
checker warning:

drivers/s390/block/dasd_eckd.c:4486 dasd_symm_io()
error: using offset into zero size array 'psf_data[]'

drivers/s390/block/dasd_eckd.c
4458 /* Copy parms from caller */
4459 rc = -EFAULT;
4460 if (copy_from_user(&usrparm, argp, sizeof(usrparm)))
^^^^^^^
The user can specify any "usrparm.psf_data_len". They choose zero by
mistake.

4461 goto out;
4462 if (is_compat_task()) {
4463 /* Make sure pointers are sane even on 31 bit. */
4464 rc = -EINVAL;
4465 if ((usrparm.psf_data >> 32) != 0)
4466 goto out;
4467 if ((usrparm.rssd_result >> 32) != 0)
4468 goto out;
4469 usrparm.psf_data &= 0x7fffffffULL;
4470 usrparm.rssd_result &= 0x7fffffffULL;
4471 }
4472 /* alloc I/O data area */
4473 psf_data = kzalloc(usrparm.psf_data_len, GFP_KERNEL
| GFP_DMA);
4474 rssd_result = kzalloc(usrparm.rssd_result_len, GFP_KERNEL
| GFP_DMA);
4475 if (!psf_data || !rssd_result) {

kzalloc() returns a ZERO_SIZE_PTR (0x16).

4476 rc = -ENOMEM;
4477 goto out_free;
4478 }
4479
4480 /* get syscall header from user space */
4481 rc = -EFAULT;
4482 if (copy_from_user(psf_data,
4483 (void __user *)(unsigned long)
usrparm.psf_data,
4484 usrparm.psf_data_len))

That all works great.

4485 goto out_free;
4486 psf0 = psf_data[0];
4487 psf1 = psf_data[1];

But now we're assuming that "->psf_data_len" was at least 2 bytes.

Fix this by checking the user specified length psf_data_len.

Fixes: 52898025cf7d ("[S390] dasd: security and PSF update patch for EMC CKD ioctl")
Reported-by: Dan Carpenter <dan.carpenter@...>
Signed-off-by: Stefan Haberland <sth@...>
Signed-off-by: Martin Schwidefsky <schwidefsky@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/s390/block/dasd_eckd.c


[linux:lloyd-aviation] By Jonathan Bakker <xc-racer2@...>:
0ed72d3f6f1d: Input: pwm-vibra - prevent unbalanced regulator

[ Upstream commit 3ca232df9921f083c3b37ba5fbc76f4d9046268b ]

pwm_vibrator_stop disables the regulator, but it can be called from
multiple places, even when the regulator is already disabled. Fix this
by using regulator_is_enabled check when starting and stopping device.

Signed-off-by: Jonathan Bakker <xc-racer2@...>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@...>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/input/misc/pwm-vibra.c


[linux:lloyd-aviation] By Paweł Chmiel <pawel.mikolaj.chmiel@...>:
bac70a89419a: Input: pwm-vibra - stop regulator after disabling pwm, not before

[ Upstream commit 94803aef3533676194c772383472636c453e3147 ]

This patch fixes order of disable calls in pwm_vibrator_stop.
Currently when starting device, we first enable vcc regulator and then
setup and enable pwm. When stopping, we should do this in oposite order,
so first disable pwm and then disable regulator.
Previously order was the same as in start.

Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@...>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/input/misc/pwm-vibra.c


[linux:lloyd-aviation] By Tony Lindgren <tony@...>:
ad4507bd2bf1: ARM: dts: Configure clock parent for pwm vibra

[ Upstream commit 0840242e887586268f665bf58d5e1a7d6ebf35ed ]

Commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
them with ti-sysc") moved some omap4 timers to probe with ti-sysc
interconnect target module. Turns out this broke pwm-omap-dmtimer
for reparenting of the timer clock.

With ti-sysc, we can now configure the clock sources in the dts with
assigned-clocks and assigned-clock-parents.

Fixes: 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")
Cc: Bartosz Golaszewski <bgolaszewski@...>
Cc: Daniel Lezcano <daniel.lezcano@...>
Cc: H. Nikolaus Schaller <hns@...>
Cc: Keerthy <j-keerthy@...>
Cc: Ladislav Michl <ladis@...>
Cc: Pavel Machek <pavel@...>
Cc: Sebastian Reichel <sre@...>
Cc: Tero Kristo <t-kristo@...>
Cc: Thierry Reding <thierry.reding@...>
Cc: Thomas Gleixner <tglx@...>
Reported-by: H. Nikolaus Schaller <hns@...>
Signed-off-by: Tony Lindgren <tony@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm/boot/dts/omap4-droid4-xt894.dts


[linux:lloyd-aviation] By Yizhuo <yzhai003@...>:
f3f7a8b6faf8: ARM: OMAP2+: Variable "reg" in function omap4_dsi_mux_pads() could be uninitialized

[ Upstream commit dc30e70391376ba3987aeb856ae6d9c0706534f1 ]

In function omap4_dsi_mux_pads(), local variable "reg" could
be uninitialized if function regmap_read() returns -EINVAL.
However, it will be used directly in the later context, which
is potentially unsafe.

Signed-off-by: Yizhuo <yzhai003@...>
Signed-off-by: Tony Lindgren <tony@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm/mach-omap2/display.c


[linux:lloyd-aviation] By Pierre-Louis Bossart <pierre-louis.bossart@...>:
e07aaaa7013e: ASoC: dapm: fix out-of-bounds accesses to DAPM lookup tables

[ Upstream commit c16e12010060c6c7a31f08b4a99513064cb53b7d ]

KASAN reports and additional traces point to out-of-bounds accesses to
the dapm_up_seq and dapm_down_seq lookup tables. The indices used are
larger than the array definition.

Fix by adding missing entries for the new widget types in these two
lookup tables, and align them with PGA values.

Also the sequences for the following widgets were not defined. Since
their values defaulted to zero, assign them explicitly

snd_soc_dapm_input
snd_soc_dapm_output
snd_soc_dapm_vmid
snd_soc_dapm_siggen
snd_soc_dapm_sink

Fixes: 8a70b4544ef4 ('ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.').
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@...>
Signed-off-by: Mark Brown <broonie@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: sound/soc/soc-dapm.c


[linux:lloyd-aviation] By Kuninori Morimoto <kuninori.morimoto.gx@...>:
20604435e2f4: ASoC: rsnd: fixup rsnd_ssi_master_clk_start() user count check

[ Upstream commit d9111d36024de07784f2e1ba2ccf70b16035f378 ]

commit 4d230d1271064 ("ASoC: rsnd: fixup not to call clk_get/set
under non-atomic") added new rsnd_ssi_prepare() and moved
rsnd_ssi_master_clk_start() to .prepare.
But, ssi user count (= ssi->usrcnt) is incremented at .init
(= rsnd_ssi_init()).
Because of these timing exchange, ssi->usrcnt check at
rsnd_ssi_master_clk_start() should be adjusted.
Otherwise, 2nd master clock setup will be no check.
This patch fixup this issue.

Fixes: commit 4d230d1271064 ("ASoC: rsnd: fixup not to call clk_get/set under non-atomic")
Reported-by: Yusuke Goda <yusuke.goda.sx@...>
Reported-by: Valentine Barshak <valentine.barshak@...>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@...>
Tested-by: Yusuke Goda <yusuke.goda.sx@...>
Signed-off-by: Mark Brown <broonie@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: sound/soc/sh/rcar/ssi.c


[linux:lloyd-aviation] By Christoffer Dall <christoffer.dall@...>:
dfe9b4d992ca: KVM: arm/arm64: Reset the VCPU without preemption and vcpu state loaded

[ Upstream commit e761a927bc9a7ee6ceb7c4f63d5922dbced87f0d ]

We have two ways to reset a vcpu:
- either through VCPU_INIT
- or through a PSCI_ON call

The first one is easy to reason about. The second one is implemented
in a more bizarre way, as it is the vcpu that handles PSCI_ON that
resets the vcpu that is being powered-on. As we need to turn the logic
around and have the target vcpu to reset itself, we must take some
preliminary steps.

Resetting the VCPU state modifies the system register state in memory,
but this may interact with vcpu_load/vcpu_put if running with preemption
disabled, which in turn may lead to corrupted system register state.

Address this by disabling preemption and doing put/load if required
around the reset logic.

Reviewed-by: Andrew Jones <drjones@...>
Signed-off-by: Christoffer Dall <christoffer.dall@...>
Signed-off-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm64/kvm/reset.c


[linux:lloyd-aviation] By Marc Zyngier <marc.zyngier@...>:
b78379c33723: arm/arm64: KVM: Allow a VCPU to fully reset itself

[ Upstream commit 358b28f09f0ab074d781df72b8a671edb1547789 ]

The current kvm_psci_vcpu_on implementation will directly try to
manipulate the state of the VCPU to reset it. However, since this is
not done on the thread that runs the VCPU, we can end up in a strangely
corrupted state when the source and target VCPUs are running at the same
time.

Fix this by factoring out all reset logic from the PSCI implementation
and forwarding the required information along with a request to the
target VCPU.

Reviewed-by: Andrew Jones <drjones@...>
Signed-off-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Christoffer Dall <christoffer.dall@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm/include/asm/kvm_host.h
Modified: arch/arm/kvm/reset.c
Modified: arch/arm64/include/asm/kvm_host.h
Modified: arch/arm64/kvm/reset.c
Modified: virt/kvm/arm/arm.c
Modified: virt/kvm/arm/psci.c


[linux:lloyd-aviation] By Marc Zyngier <marc.zyngier@...>:
c831293622b2: arm/arm64: KVM: Don't panic on failure to properly reset system registers

[ Upstream commit 20589c8cc47dce5854c8bf1b44a9fc63d798d26d ]

Failing to properly reset system registers is pretty bad. But not
quite as bad as bringing the whole machine down... So warn loudly,
but slightly more gracefully.

Signed-off-by: Marc Zyngier <marc.zyngier@...>
Acked-by: Christoffer Dall <christoffer.dall@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm/kvm/coproc.c
Modified: arch/arm64/kvm/sys_regs.c


[linux:lloyd-aviation] By Christoffer Dall <christoffer.dall@...>:
04131dfcb910: KVM: arm/arm64: vgic: Always initialize the group of private IRQs

[ Upstream commit ab2d5eb03dbb7b37a1c6356686fb48626ab0c93e ]

We currently initialize the group of private IRQs during
kvm_vgic_vcpu_init, and the value of the group depends on the GIC model
we are emulating. However, CPUs created before creating (and
initializing) the VGIC might end up with the wrong group if the VGIC
is created as GICv3 later.

Since we have no enforced ordering of creating the VGIC and creating
VCPUs, we can end up with part the VCPUs being properly intialized and
the remaining incorrectly initialized. That also means that we have no
single place to do the per-cpu data structure initialization which
depends on knowing the emulated GIC model (which is only the group
field).

This patch removes the incorrect comment from kvm_vgic_vcpu_init and
initializes the group of all previously created VCPUs's private
interrupts in vgic_init in addition to the existing initialization in
kvm_vgic_vcpu_init.

Signed-off-by: Christoffer Dall <christoffer.dall@...>
Signed-off-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: virt/kvm/arm/vgic/vgic-init.c


[linux:lloyd-aviation] By James Morse <james.morse@...>:
459058f0e329: KVM: arm64: Forbid kprobing of the VHE world-switch code

[ Upstream commit 7d82602909ed9c73b34ad26f05d10db4850a4f8c ]

On systems with VHE the kernel and KVM's world-switch code run at the
same exception level. Code that is only used on a VHE system does not
need to be annotated as __hyp_text as it can reside anywhere in the
kernel text.

__hyp_text was also used to prevent kprobes from patching breakpoint
instructions into this region, as this code runs at a different
exception level. While this is no longer true with VHE, KVM still
switches VBAR_EL1, meaning a kprobe's breakpoint executed in the
world-switch code will cause a hyp-panic.

echo "p:weasel sysreg_save_guest_state_vhe" > /sys/kernel/debug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/weasel/enable
lkvm run -k /boot/Image --console serial -p "console=ttyS0 earlycon=uart,mmio,0x3f8"

# lkvm run -k /boot/Image -m 384 -c 3 --name guest-1474
Info: Placing fdt at 0x8fe00000 - 0x8fffffff
Info: virtio-mmio.devices=0x200@0x10000:36

Info: virtio-mmio.devices=0x200@0x10200:37

Info: virtio-mmio.devices=0x200@0x10400:38

[ 614.178186] Kernel panic - not syncing: HYP panic:
[ 614.178186] PS:404003c9 PC:ffff0000100d70e0 ESR:f2000004
[ 614.178186] FAR:0000000080080000 HPFAR:0000000000800800 PAR:1d00007edbadc0de
[ 614.178186] VCPU:00000000f8de32f1
[ 614.178383] CPU: 2 PID: 1482 Comm: kvm-vcpu-0 Not tainted 5.0.0-rc2 #10799
[ 614.178446] Call trace:
[ 614.178480] dump_backtrace+0x0/0x148
[ 614.178567] show_stack+0x24/0x30
[ 614.178658] dump_stack+0x90/0xb4
[ 614.178710] panic+0x13c/0x2d8
[ 614.178793] hyp_panic+0xac/0xd8
[ 614.178880] kvm_vcpu_run_vhe+0x9c/0xe0
[ 614.178958] kvm_arch_vcpu_ioctl_run+0x454/0x798
[ 614.179038] kvm_vcpu_ioctl+0x360/0x898
[ 614.179087] do_vfs_ioctl+0xc4/0x858
[ 614.179174] ksys_ioctl+0x84/0xb8
[ 614.179261] __arm64_sys_ioctl+0x28/0x38
[ 614.179348] el0_svc_common+0x94/0x108
[ 614.179401] el0_svc_handler+0x38/0x78
[ 614.179487] el0_svc+0x8/0xc
[ 614.179558] SMP: stopping secondary CPUs
[ 614.179661] Kernel Offset: disabled
[ 614.179695] CPU features: 0x003,2a80aa38
[ 614.179758] Memory Limit: none
[ 614.179858] ---[ end Kernel panic - not syncing: HYP panic:
[ 614.179858] PS:404003c9 PC:ffff0000100d70e0 ESR:f2000004
[ 614.179858] FAR:0000000080080000 HPFAR:0000000000800800 PAR:1d00007edbadc0de
[ 614.179858] VCPU:00000000f8de32f1 ]---

Annotate the VHE world-switch functions that aren't marked
__hyp_text using NOKPROBE_SYMBOL().

Signed-off-by: James Morse <james.morse@...>
Fixes: 3f5c90b890ac ("KVM: arm64: Introduce VHE-specific kvm_vcpu_run")
Acked-by: Masami Hiramatsu <mhiramat@...>
Signed-off-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm64/kvm/hyp/switch.c
Modified: arch/arm64/kvm/hyp/sysreg-sr.c


[linux:lloyd-aviation] By Sylwester Nawrocki <s.nawrocki@...>:
8f07d76481d5: ASoC: samsung: Prevent clk_get_rate() calls in atomic context

[ Upstream commit 860b454c2c0cbda6892954f5cdbbb48931b3c8db ]

This patch moves clk_get_rate() call from trigger() to hw_params()
callback to avoid calling sleeping clk API from atomic context
and prevent deadlock as indicated below.

Before this change clk_get_rate() was being called with same
spinlock held as the one passed to the clk API when registering
clocks exposed by the I2S driver.

[ 82.109780] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
[ 82.117009] in_atomic(): 1, irqs_disabled(): 128, pid: 1554, name: speaker-test
[ 82.124235] 3 locks held by speaker-test/1554:
[ 82.128653] #0: cc8c5328 (snd_pcm_link_rwlock){...-}, at: snd_pcm_stream_lock_irq+0x20/0x38
[ 82.137058] #1: ec9eda17 (&(&substream->self_group.lock)->rlock){..-.}, at: snd_pcm_ioctl+0x900/0x1268
[ 82.146417] #2: 6ac279bf (&(&pri_dai->spinlock)->rlock){..-.}, at: i2s_trigger+0x64/0x6d4
[ 82.154650] irq event stamp: 8144
[ 82.157949] hardirqs last enabled at (8143): [<c0a0f574>] _raw_read_unlock_irq+0x24/0x5c
[ 82.166089] hardirqs last disabled at (8144): [<c0a0f6a8>] _raw_read_lock_irq+0x18/0x58
[ 82.174063] softirqs last enabled at (8004): [<c01024e4>] __do_softirq+0x3a4/0x66c
[ 82.181688] softirqs last disabled at (7997): [<c012d730>] irq_exit+0x140/0x168
[ 82.188964] Preemption disabled at:
[ 82.188967] [<00000000>] (null)
[ 82.195728] CPU: 6 PID: 1554 Comm: speaker-test Not tainted 5.0.0-rc5-00192-ga6e6caca8f03 #191
[ 82.204302] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 82.210376] [<c0111a54>] (unwind_backtrace) from [<c010d8f4>] (show_stack+0x10/0x14)
[ 82.218084] [<c010d8f4>] (show_stack) from [<c09ef004>] (dump_stack+0x90/0xc8)
[ 82.225278] [<c09ef004>] (dump_stack) from [<c0152980>] (___might_sleep+0x22c/0x2c8)
[ 82.232990] [<c0152980>] (___might_sleep) from [<c0a0a2e4>] (__mutex_lock+0x28/0xa3c)
[ 82.240788] [<c0a0a2e4>] (__mutex_lock) from [<c0a0ad80>] (mutex_lock_nested+0x1c/0x24)
[ 82.248763] [<c0a0ad80>] (mutex_lock_nested) from [<c04923dc>] (clk_prepare_lock+0x78/0xec)
[ 82.257079] [<c04923dc>] (clk_prepare_lock) from [<c049538c>] (clk_core_get_rate+0xc/0x5c)
[ 82.265309] [<c049538c>] (clk_core_get_rate) from [<c0766b18>] (i2s_trigger+0x490/0x6d4)
[ 82.273369] [<c0766b18>] (i2s_trigger) from [<c074fec4>] (soc_pcm_trigger+0x100/0x140)
[ 82.281254] [<c074fec4>] (soc_pcm_trigger) from [<c07378a0>] (snd_pcm_do_start+0x2c/0x30)
[ 82.289400] [<c07378a0>] (snd_pcm_do_start) from [<c07376cc>] (snd_pcm_action_single+0x38/0x78)
[ 82.298065] [<c07376cc>] (snd_pcm_action_single) from [<c073a450>] (snd_pcm_ioctl+0x910/0x1268)
[ 82.306734] [<c073a450>] (snd_pcm_ioctl) from [<c0292344>] (do_vfs_ioctl+0x90/0x9ec)
[ 82.314443] [<c0292344>] (do_vfs_ioctl) from [<c0292cd4>] (ksys_ioctl+0x34/0x60)
[ 82.321808] [<c0292cd4>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
[ 82.329431] Exception stack(0xeb875fa8 to 0xeb875ff0)
[ 82.334459] 5fa0: 00033c18 b6e31000 00000004 00004142 00033d80 00033d80
[ 82.342605] 5fc0: 00033c18 b6e31000 00008000 00000036 00008000 00000000 beea38a8 00008000
[ 82.350748] 5fe0: b6e3142c beea384c b6da9a30 b6c9212c
[ 82.355789]
[ 82.357245] ======================================================
[ 82.363397] WARNING: possible circular locking dependency detected
[ 82.369551] 5.0.0-rc5-00192-ga6e6caca8f03 #191 Tainted: G W
[ 82.376395] ------------------------------------------------------
[ 82.382548] speaker-test/1554 is trying to acquire lock:
[ 82.387834] 6d2007f4 (prepare_lock){+.+.}, at: clk_prepare_lock+0x78/0xec
[ 82.394593]
[ 82.394593] but task is already holding lock:
[ 82.400398] 6ac279bf (&(&pri_dai->spinlock)->rlock){..-.}, at: i2s_trigger+0x64/0x6d4
[ 82.408197]
[ 82.408197] which lock already depends on the new lock.
[ 82.416343]
[ 82.416343] the existing dependency chain (in reverse order) is:
[ 82.423795]
[ 82.423795] -> #1 (&(&pri_dai->spinlock)->rlock){..-.}:
[ 82.430472] clk_mux_set_parent+0x34/0xb8
[ 82.434975] clk_core_set_parent_nolock+0x1c4/0x52c
[ 82.440347] clk_set_parent+0x38/0x6c
[ 82.444509] of_clk_set_defaults+0xc8/0x308
[ 82.449186] of_clk_add_provider+0x84/0xd0
[ 82.453779] samsung_i2s_probe+0x408/0x5f8
[ 82.458376] platform_drv_probe+0x48/0x98
[ 82.462879] really_probe+0x224/0x3f4
[ 82.467037] driver_probe_device+0x70/0x1c4
[ 82.471716] bus_for_each_drv+0x44/0x8c
[ 82.476049] __device_attach+0xa0/0x138
[ 82.480382] bus_probe_device+0x88/0x90
[ 82.484715] deferred_probe_work_func+0x6c/0xbc
[ 82.489741] process_one_work+0x200/0x740
[ 82.494246] worker_thread+0x2c/0x4c8
[ 82.498408] kthread+0x128/0x164
[ 82.502131] ret_from_fork+0x14/0x20
[ 82.506204] (null)
[ 82.508976]
[ 82.508976] -> #0 (prepare_lock){+.+.}:
[ 82.514264] __mutex_lock+0x60/0xa3c
[ 82.518336] mutex_lock_nested+0x1c/0x24
[ 82.522756] clk_prepare_lock+0x78/0xec
[ 82.527088] clk_core_get_rate+0xc/0x5c
[ 82.531421] i2s_trigger+0x490/0x6d4
[ 82.535494] soc_pcm_trigger+0x100/0x140
[ 82.539913] snd_pcm_do_start+0x2c/0x30
[ 82.544246] snd_pcm_action_single+0x38/0x78
[ 82.549012] snd_pcm_ioctl+0x910/0x1268
[ 82.553345] do_vfs_ioctl+0x90/0x9ec
[ 82.557417] ksys_ioctl+0x34/0x60
[ 82.561229] ret_fast_syscall+0x0/0x28
[ 82.565477] 0xbeea384c
[ 82.568421]
[ 82.568421] other info that might help us debug this:
[ 82.568421]
[ 82.576394] Possible unsafe locking scenario:
[ 82.576394]
[ 82.582285] CPU0 CPU1
[ 82.586792] ---- ----
[ 82.591297] lock(&(&pri_dai->spinlock)->rlock);
[ 82.595977] lock(prepare_lock);
[ 82.601782] lock(&(&pri_dai->spinlock)->rlock);
[ 82.608975] lock(prepare_lock);
[ 82.612268]
[ 82.612268] *** DEADLOCK ***

Fixes: 647d04f8e07a ("ASoC: samsung: i2s: Ensure the RCLK rate is properly determined")
Reported-by: Krzysztof Kozłowski <krzk@...>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@...>
Signed-off-by: Mark Brown <broonie@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: sound/soc/samsung/i2s.c


[linux:lloyd-aviation] By Russell King <rmk+kernel@...>:
f49f7007de59: ARM: OMAP2+: fix lack of timer interrupts on CPU1 after hotplug

[ Upstream commit 50d6b3cf9403879911e06d69c7ef41e43f8f7b4b ]

If we have a kernel configured for periodic timer interrupts, and we
have cpuidle enabled, then we end up with CPU1 losing timer interupts
after a hotplug.

This can manifest itself in RCU stall warnings, or userspace becoming
unresponsive.

The problem is that the kernel initially wants to use the TWD timer
for interrupts, but the TWD loses context when we enter the C3 cpuidle
state. Nothing reprograms the TWD after idle.

We have solved this in the past by switching to broadcast timer ticks,
and cpuidle44xx switches to that mode at boot time. However, there is
nothing to switch from periodic mode local timers after a hotplug
operation.

We call tick_broadcast_enter() in omap_enter_idle_coupled(), which one
would expect would take care of the issue, but internally this only
deals with one-shot local timers - tick_broadcast_enable() on the other
hand only deals with periodic local timers. So, we need to call both.

Signed-off-by: Russell King <rmk+kernel@...>
[tony@...: just standardized the subject line]
Signed-off-by: Tony Lindgren <tony@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm/mach-omap2/cpuidle44xx.c


[linux:lloyd-aviation] By Dmitry Torokhov <dmitry.torokhov@...>:
4fe714b750cb: Input: cap11xx - switch to using set_brightness_blocking()

[ Upstream commit 628442880af8c201d307a45f3862a7a17df8a189 ]

Updating LED state requires access to regmap and therefore we may sleep,
so we could not do that directly form set_brightness() method.
Historically we used private work to adjust the brightness, but with the
introduction of set_brightness_blocking() we no longer need it.

As a bonus, not having our own work item means we do not have
use-after-free issue as we neglected to cancel outstanding work on
driver unbind.

Reported-by: Sven Van Asbroeck <thesven73@...>
Reviewed-by: Sven Van Asbroeck <TheSven73@...>
Acked-by: Jacek Anaszewski <jacek.anaszewski@...>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/input/keyboard/cap11xx.c


[linux:lloyd-aviation] By Dmitry Torokhov <dmitry.torokhov@...>:
e91dc2092f7f: Input: ps2-gpio - flush TX work when closing port

[ Upstream commit 33a841ce5cef4ca6c18ad333248b6d273f54c839 ]

To ensure that TX work is not running after serio port has been torn down,
let's flush it when closing the port.

Reported-by: Sven Van Asbroeck <thesven73@...>
Acked-by: Danilo Krummrich <danilokrummrich@...>
Reviewed-by: Sven Van Asbroeck <TheSven73@...>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/input/serio/ps2-gpio.c


[linux:lloyd-aviation] By Dmitry Torokhov <dmitry.torokhov@...>:
134891e124da: Input: matrix_keypad - use flush_delayed_work()

[ Upstream commit a342083abe576db43594a32d458a61fa81f7cb32 ]

We should be using flush_delayed_work() instead of flush_work() in
matrix_keypad_stop() to ensure that we are not missing work that is
scheduled but not yet put in the workqueue (i.e. its delay timer has not
expired yet).

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/input/keyboard/matrix_keypad.c


[linux:lloyd-aviation] By Johannes Berg <johannes.berg@...>:
bff33ba4f9ca: mac80211: call drv_ibss_join() on restart

[ Upstream commit 4926b51bfaa6d36bd6f398fb7698679d3962e19d ]

If a driver does any significant activity in its ibss_join method,
then it will very well expect that to be called during restart,
before any stations are added. Do that.

Signed-off-by: Johannes Berg <johannes.berg@...>
Signed-off-by: Luca Coelho <luciano.coelho@...>
Signed-off-by: Johannes Berg <johannes.berg@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/mac80211/util.c


[linux:lloyd-aviation] By Ilan Peer <ilan.peer@...>:
a5a244451145: mac80211: Fix Tx aggregation session tear down with ITXQs

[ Upstream commit 6157ca0d6bfe437691b1e98a62e2efe12b6714da ]

When mac80211 requests the low level driver to stop an ongoing
Tx aggregation, the low level driver is expected to call
ieee80211_stop_tx_ba_cb_irqsafe() to indicate that it is ready
to stop the session. The callback in turn schedules a worker
to complete the session tear down, which in turn also handles
the relevant state for the intermediate Tx queue.

However, as this flow in asynchronous, the intermediate queue
should be stopped and not continue servicing frames, as in
such a case frames that are dequeued would be marked as part
of an aggregation, although the aggregation is already been
stopped.

Fix this by stopping the intermediate Tx queue, before
calling the low level driver to stop the Tx aggregation.

Signed-off-by: Ilan Peer <ilan.peer@...>
Signed-off-by: Luca Coelho <luciano.coelho@...>
Signed-off-by: Johannes Berg <johannes.berg@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/mac80211/agg-tx.c


[linux:lloyd-aviation] By Francesco Ruggeri <fruggeri@...>:
e0e6b0d7e09c: netfilter: compat: initialize all fields in xt_init

[ Upstream commit 8d29d16d21342a0c86405d46de0c4ac5daf1760f ]

If a non zero value happens to be in xt[NFPROTO_BRIDGE].cur at init
time, the following panic can be caused by running

% ebtables -t broute -F BROUTING

from a 32-bit user level on a 64-bit kernel. This patch replaces
kmalloc_array with kcalloc when allocating xt.

[ 474.680846] BUG: unable to handle kernel paging request at 0000000009600920
[ 474.687869] PGD 2037006067 P4D 2037006067 PUD 2038938067 PMD 0
[ 474.693838] Oops: 0000 [#1] SMP
[ 474.697055] CPU: 9 PID: 4662 Comm: ebtables Kdump: loaded Not tainted 4.19.17-11302235.AroraKernelnext.fc18.x86_64 #1
[ 474.707721] Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.0 06/28/2013
[ 474.714313] RIP: 0010:xt_compat_calc_jump+0x2f/0x63 [x_tables]
[ 474.720201] Code: 40 0f b6 ff 55 31 c0 48 6b ff 70 48 03 3d dc 45 00 00 48 89 e5 8b 4f 6c 4c 8b 47 60 ff c9 39 c8 7f 2f 8d 14 08 d1 fa 48 63 fa <41> 39 34 f8 4c 8d 0c fd 00 00 00 00 73 05 8d 42 01 eb e1 76 05 8d
[ 474.739023] RSP: 0018:ffffc9000943fc58 EFLAGS: 00010207
[ 474.744296] RAX: 0000000000000000 RBX: ffffc90006465000 RCX: 0000000002580249
[ 474.751485] RDX: 00000000012c0124 RSI: fffffffff7be17e9 RDI: 00000000012c0124
[ 474.758670] RBP: ffffc9000943fc58 R08: 0000000000000000 R09: ffffffff8117cf8f
[ 474.765855] R10: ffffc90006477000 R11: 0000000000000000 R12: 0000000000000001
[ 474.773048] R13: 0000000000000000 R14: ffffc9000943fcb8 R15: ffffc9000943fcb8
[ 474.780234] FS: 0000000000000000(0000) GS:ffff88a03f840000(0063) knlGS:00000000f7ac7700
[ 474.788612] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 474.794632] CR2: 0000000009600920 CR3: 0000002037422006 CR4: 00000000000606e0
[ 474.802052] Call Trace:
[ 474.804789] compat_do_replace+0x1fb/0x2a3 [ebtables]
[ 474.810105] compat_do_ebt_set_ctl+0x69/0xe6 [ebtables]
[ 474.815605] ? try_module_get+0x37/0x42
[ 474.819716] compat_nf_setsockopt+0x4f/0x6d
[ 474.824172] compat_ip_setsockopt+0x7e/0x8c
[ 474.828641] compat_raw_setsockopt+0x16/0x3a
[ 474.833220] compat_sock_common_setsockopt+0x1d/0x24
[ 474.838458] __compat_sys_setsockopt+0x17e/0x1b1
[ 474.843343] ? __check_object_size+0x76/0x19a
[ 474.847960] __ia32_compat_sys_socketcall+0x1cb/0x25b
[ 474.853276] do_fast_syscall_32+0xaf/0xf6
[ 474.857548] entry_SYSENTER_compat+0x6b/0x7a

Signed-off-by: Francesco Ruggeri <fruggeri@...>
Acked-by: Florian Westphal <fw@...>
Signed-off-by: Pablo Neira Ayuso <pablo@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/netfilter/x_tables.c


[linux:lloyd-aviation] By Jianchao Wang <jianchao.w.wang@...>:
29452f665c2f: blk-mq: insert rq with DONTPREP to hctx dispatch list when requeue

[ Upstream commit aef1897cd36dcf5e296f1d2bae7e0d268561b685 ]

When requeue, if RQF_DONTPREP, rq has contained some driver
specific data, so insert it to hctx dispatch list to avoid any
merge. Take scsi as example, here is the trace event log (no
io scheduler, because RQF_STARTED would prevent merging),

kworker/0:1H-339 [000] ...1 2037.209289: block_rq_insert: 8,0 R 4096 () 32768 + 8 [kworker/0:1H]
scsi_inert_test-1987 [000] .... 2037.220465: block_bio_queue: 8,0 R 32776 + 8 [scsi_inert_test]
scsi_inert_test-1987 [000] ...2 2037.220466: block_bio_backmerge: 8,0 R 32776 + 8 [scsi_inert_test]
kworker/0:1H-339 [000] .... 2047.220913: block_rq_issue: 8,0 R 8192 () 32768 + 16 [kworker/0:1H]
scsi_inert_test-1996 [000] ..s1 2047.221007: block_rq_complete: 8,0 R () 32768 + 8 [0]
scsi_inert_test-1996 [000] .Ns1 2047.221045: block_rq_requeue: 8,0 R () 32776 + 8 [0]
kworker/0:1H-339 [000] ...1 2047.221054: block_rq_insert: 8,0 R 4096 () 32776 + 8 [kworker/0:1H]
kworker/0:1H-339 [000] ...1 2047.221056: block_rq_issue: 8,0 R 4096 () 32776 + 8 [kworker/0:1H]
scsi_inert_test-1986 [000] ..s1 2047.221119: block_rq_complete: 8,0 R () 32776 + 8 [0]

(32768 + 8) was requeued by scsi_queue_insert and had RQF_DONTPREP.
Then it was merged with (32776 + 8) and issued. Due to RQF_DONTPREP,
the sdb only contained the part of (32768 + 8), then only that part
was completed. The lucky thing was that scsi_io_completion detected
it and requeued the remaining part. So we didn't get corrupted data.
However, the requeue of (32776 + 8) is not expected.

Suggested-by: Jens Axboe <axboe@...>
Signed-off-by: Jianchao Wang <jianchao.w.wang@...>
Signed-off-by: Jens Axboe <axboe@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: block/blk-mq.c


[linux:lloyd-aviation] By Andrea Claudi <aclaudi@...>:
5ca2ef674d74: ipvs: fix dependency on nf_defrag_ipv6

[ Upstream commit 098e13f5b21d3398065fce8780f07a3ef62f4812 ]

ipvs relies on nf_defrag_ipv6 module to manage IPv6 fragmentation,
but lacks proper Kconfig dependencies and does not explicitly
request defrag features.

As a result, if netfilter hooks are not loaded, when IPv6 fragmented
packet are handled by ipvs only the first fragment makes through.

Fix it properly declaring the dependency on Kconfig and registering
netfilter hooks on ip_vs_add_service() and ip_vs_new_dest().

Reported-by: Li Shuang <shuali@...>
Signed-off-by: Andrea Claudi <aclaudi@...>
Acked-by: Julian Anastasov <ja@...>
Acked-by: Simon Horman <horms@...>
Signed-off-by: Pablo Neira Ayuso <pablo@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/netfilter/ipvs/Kconfig
Modified: net/netfilter/ipvs/ip_vs_core.c
Modified: net/netfilter/ipvs/ip_vs_ctl.c


[linux:lloyd-aviation] By Yufen Yu <yuyufen@...>:
e01f2b0821ea: floppy: check_events callback should not return a negative number

[ Upstream commit 96d7cb932e826219ec41ac02e5af037ffae6098c ]

floppy_check_events() is supposed to return bit flags to say which
events occured. We should return zero to say that no event flags are
set. Only BIT(0) and BIT(1) are used in the caller. And .check_events
interface also expect to return an unsigned int value.

However, after commit a0c80efe5956, it may return -EINTR (-4u).
Here, both BIT(0) and BIT(1) are cleared. So this patch shouldn't
affect runtime, but it obviously is still worth fixing.

Reviewed-by: Dan Carpenter <dan.carpenter@...>
Fixes: a0c80efe5956 ("floppy: fix lock_fdc() signal handling")
Signed-off-by: Yufen Yu <yuyufen@...>
Signed-off-by: Jens Axboe <axboe@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/block/floppy.c


[linux:lloyd-aviation] By Nicolas Morey-Chaisemartin <nmoreychaisemartin@...>:
d84bc704b91e: xprtrdma: Make sure Send CQ is allocated on an existing compvec

[ Upstream commit a4cb5bdb754afe21f3e9e7164213e8600cf69427 ]

Make sure the device has at least 2 completion vectors
before allocating to compvec#1

Fixes: a4699f5647f3 (xprtrdma: Put Send CQ in IB_POLL_WORKQUEUE mode)
Signed-off-by: Nicolas Morey-Chaisemartin <nmoreychaisemartin@...>
Reviewed-by: Chuck Lever <chuck.lever@...>
Signed-off-by: Anna Schumaker <Anna.Schumaker@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/sunrpc/xprtrdma/verbs.c


[linux:lloyd-aviation] By Benjamin Coddington <bcodding@...>:
6c023d86b364: NFS: Don't use page_file_mapping after removing the page

[ Upstream commit d2ceb7e57086750ea6198a31fd942d98099a0786 ]

If nfs_page_async_flush() removes the page from the mapping, then we can't
use page_file_mapping() on it as nfs_updatepate() is wont to do when
receiving an error. Instead, push the mapping to the stack before the page
is possibly truncated.

Fixes: 8fc75bed96bb ("NFS: Fix up return value on fatal errors in nfs_page_async_flush()")
Signed-off-by: Benjamin Coddington <bcodding@...>
Signed-off-by: Anna Schumaker <Anna.Schumaker@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/nfs/write.c


[linux:lloyd-aviation] By Yu Zhao <yuzhao@...>:
8b1a7762e0da: mm/gup: fix gup_pmd_range() for dax

[ Upstream commit 414fd080d125408cb15d04ff4907e1dd8145c8c7 ]

For dax pmd, pmd_trans_huge() returns false but pmd_huge() returns true
on x86. So the function works as long as hugetlb is configured.
However, dax doesn't depend on hugetlb.

Link: http://lkml.kernel.org/r/20190111034033.601-1-yuzhao@...
Signed-off-by: Yu Zhao <yuzhao@...>
Reviewed-by: Jan Kara <jack@...>
Cc: Dan Williams <dan.j.williams@...>
Cc: Huang Ying <ying.huang@...>
Cc: Matthew Wilcox <willy@...>
Cc: Keith Busch <keith.busch@...>
Cc: "Michael S . Tsirkin" <mst@...>
Cc: John Hubbard <jhubbard@...>
Cc: Wei Yang <richard.weiyang@...>
Cc: Mike Rapoport <rppt@...>
Cc: Andrea Arcangeli <aarcange@...>
Cc: "Kirill A . Shutemov" <kirill.shutemov@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/gup.c


[linux:lloyd-aviation] By Qian Cai <cai@...>:
53dcaeeff145: Revert "mm: use early_pfn_to_nid in page_ext_init"

[ Upstream commit 2f1ee0913ce58efe7f18fbd518bd54c598559b89 ]

This reverts commit fe53ca54270a ("mm: use early_pfn_to_nid in
page_ext_init").

When booting a system with "page_owner=on",

start_kernel
page_ext_init
invoke_init_callbacks
init_section_page_ext
init_page_owner
init_early_allocated_pages
init_zones_in_node
init_pages_in_zone
lookup_page_ext
page_to_nid

The issue here is that page_to_nid() will not work since some page flags
have no node information until later in page_alloc_init_late() due to
DEFERRED_STRUCT_PAGE_INIT. Hence, it could trigger an out-of-bounds
access with an invalid nid.

UBSAN: Undefined behaviour in ./include/linux/mm.h:1104:50
index 7 is out of range for type 'zone [5]'

Also, kernel will panic since flags were poisoned earlier with,

CONFIG_DEBUG_VM_PGFLAGS=y
CONFIG_NODE_NOT_IN_PAGE_FLAGS=n

start_kernel
setup_arch
pagetable_init
paging_init
sparse_init
sparse_init_nid
memblock_alloc_try_nid_raw

It did not handle it well in init_pages_in_zone() which ends up calling
page_to_nid().

page:ffffea0004200000 is uninitialized and poisoned
raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
page_owner info is not active (free page?)
kernel BUG at include/linux/mm.h:990!
RIP: 0010:init_page_owner+0x486/0x520

This means that assumptions behind commit fe53ca54270a ("mm: use
early_pfn_to_nid in page_ext_init") are incomplete. Therefore, revert
the commit for now. A proper way to move the page_owner initialization
to sooner is to hook into memmap initialization.

Link: http://lkml.kernel.org/r/20190115202812.75820-1-cai@...
Signed-off-by: Qian Cai <cai@...>
Acked-by: Michal Hocko <mhocko@...>
Cc: Pasha Tatashin <Pavel.Tatashin@...>
Cc: Mel Gorman <mgorman@...>
Cc: Yang Shi <yang.shi@...>
Cc: Joonsoo Kim <iamjoonsoo.kim@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: init/main.c
Modified: mm/page_ext.c


[linux:lloyd-aviation] By Bill Kuzeja <William.Kuzeja@...>:
8ab49fd5b072: scsi: qla2xxx: Fix panic from use after free in qla2x00_async_tm_cmd

[ Upstream commit 388a49959ee4e4e99f160241d9599efa62cd4299 ]

In qla2x00_async_tm_cmd, we reference off sp after it has been freed. This
caused a panic on a system running a slub debug kernel. Since fcport is
passed in anyways, just use that instead.

Signed-off-by: Bill Kuzeja <william.kuzeja@...>
Acked-by: Giridhar Malavali <gmalavali@...>
Acked-by: Himanshu Madhani <hmadhani@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/scsi/qla2xxx/qla_init.c


[linux:lloyd-aviation] By Dan Carpenter <dan.carpenter@...>:
388f3adb2729: net: dsa: bcm_sf2: potential array overflow in bcm_sf2_sw_suspend()

[ Upstream commit 8d6ea932856c7087ce8c3d0e79494b7d5386f962 ]

The value of ->num_ports comes from bcm_sf2_sw_probe() and it is less
than or equal to DSA_MAX_PORTS. The ds->ports[] array is used inside
the dsa_is_user_port() and dsa_is_cpu_port() functions. The ds->ports[]
array is allocated in dsa_switch_alloc() and it has ds->num_ports
elements so this leads to a static checker warning about a potential out
of bounds read.

Fixes: 8cfa94984c9c ("net: dsa: bcm_sf2: add suspend/resume callbacks")
Signed-off-by: Dan Carpenter <dan.carpenter@...>
Reviewed-by: Vivien Didelot <vivien.didelot@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/dsa/bcm_sf2.c


[linux:lloyd-aviation] By Rajneesh Bhardwaj <rajneesh.bhardwaj@...>:
a9503ade1bf7: x86/CPU: Add Icelake model number

[ Upstream commit 8cd8f0ce0d6aafe661cb3d6781c8b82bc696c04d ]

Add the CPUID model number of Icelake (ICL) mobile processors to the
Intel family list. Icelake U/Y series uses model number 0x7E.

Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@...>
Signed-off-by: Borislav Petkov <bp@...>
Cc: Andy Shevchenko <andriy.shevchenko@...>
Cc: Dave Hansen <dave.hansen@...>
Cc: "David E. Box" <david.e.box@...>
Cc: dvhart@...
Cc: "H. Peter Anvin" <hpa@...>
Cc: Ingo Molnar <mingo@...>
Cc: Kan Liang <kan.liang@...>
Cc: Peter Zijlstra <peterz@...>
Cc: platform-driver-x86@...
Cc: Qiuxu Zhuo <qiuxu.zhuo@...>
Cc: Srinivas Pandruvada <srinivas.pandruvada@...>
Cc: Thomas Gleixner <tglx@...>
Cc: x86-ml <x86@...>
Link: https://lkml.kernel.org/r/20190214115712.19642-2-rajneesh.bhardwaj@...
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/x86/include/asm/intel-family.h


[linux:lloyd-aviation] By Jann Horn <jannh@...>:
33e83ea302c0: mm: page_alloc: fix ref bias in page_frag_alloc() for 1-byte allocs

[ Upstream commit 2c2ade81741c66082f8211f0b96cf509cc4c0218 ]

The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum
number of references that we might need to create in the fastpath later,
the bump-allocation fastpath only has to modify the non-atomic bias value
that tracks the number of extra references we hold instead of the atomic
refcount. The maximum number of allocations we can serve (under the
assumption that no allocation is made with size 0) is nc->size, so that's
the bias used.

However, even when all memory in the allocation has been given away, a
reference to the page is still held; and in the `offset < 0` slowpath, the
page may be reused if everyone else has dropped their references.
This means that the necessary number of references is actually
`nc->size+1`.

Luckily, from a quick grep, it looks like the only path that can call
page_frag_alloc(fragsz=1) is TAP with the IFF_NAPI_FRAGS flag, which
requires CAP_NET_ADMIN in the init namespace and is only intended to be
used for kernel testing and fuzzing.

To test for this issue, put a `WARN_ON(page_ref_count(page) == 0)` in the
`offset < 0` path, below the virt_to_page() call, and then repeatedly call
writev() on a TAP device with IFF_TAP|IFF_NO_PI|IFF_NAPI_FRAGS|IFF_NAPI,
with a vector consisting of 15 elements containing 1 byte each.

Signed-off-by: Jann Horn <jannh@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/page_alloc.c


[linux:lloyd-aviation] By Huang Zijiang <huang.zijiang@...>:
8f622a7d512c: net: hns: Fix object reference leaks in hns_dsaf_roce_reset()

[ Upstream commit c969c6e7ab8cb42b5c787c567615474fdbad9d6a ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Signed-off-by: Huang Zijiang <huang.zijiang@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c


[linux:lloyd-aviation] By Shubhrajyoti Datta <shubhrajyoti.datta@...>:
d9ce9aea3f63: i2c: cadence: Fix the hold bit setting

[ Upstream commit d358def706880defa4c9e87381c5bf086a97d5f9 ]

In case the hold bit is not needed we are carrying the old values.
Fix the same by resetting the bit when not needed.

Fixes the sporadic i2c bus lockups on National Instruments
Zynq-based devices.

Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller")
Reported-by: Kyle Roeschley <kyle.roeschley@...>
Acked-by: Michal Simek <michal.simek@...>
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@...>
Tested-by: Kyle Roeschley <kyle.roeschley@...>
Signed-off-by: Wolfram Sang <wsa@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/i2c/busses/i2c-cadence.c


[linux:lloyd-aviation] By Paul Kocialkowski <paul.kocialkowski@...>:
8e770d996ea4: i2c: bcm2835: Clear current buffer pointers and counts after a transfer

[ Upstream commit f275a4659484716259cc46268d9043424e51cf0f ]

The driver's interrupt handler checks whether a message is currently
being handled with the curr_msg pointer. When it is NULL, the interrupt
is considered to be unexpected. Similarly, the i2c_start_transfer
routine checks for the remaining number of messages to handle in
num_msgs.

However, these values are never cleared and always keep the message and
number relevant to the latest transfer (which might be done already and
the underlying message memory might have been freed).

When an unexpected interrupt hits with the DONE bit set, the isr will
then try to access the flags field of the curr_msg structure, leading
to a fatal page fault.

The msg_buf and msg_buf_remaining fields are also never cleared at the
end of the transfer, which can lead to similar pitfalls.

Fix these issues by introducing a cleanup function and always calling
it after a transfer is finished.

Fixes: e2474541032d ("i2c: bcm2835: Fix hang for writing messages larger than 16 bytes")
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@...>
Acked-by: Stefan Wahren <stefan.wahren@...>
Signed-off-by: Wolfram Sang <wsa@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/i2c/busses/i2c-bcm2835.c


[linux:lloyd-aviation] By Miguel Ojeda <miguel.ojeda.sandonis@...>:
bf26feccf99c: auxdisplay: ht16k33: fix potential user-after-free on module unload

[ Upstream commit 69ef9bc54715fb1cb7786ada15774e469e822209 ]

On module unload/remove, we need to ensure that work does not run
after we have freed resources. Concretely, cancel_delayed_work()
may return while the callback function is still running.

From kernel/workqueue.c:

The work callback function may still be running on return,
unless it returns true and the work doesn't re-arm itself.
Explicitly flush or use cancel_delayed_work_sync() to wait on it.

Link: https://lore.kernel.org/lkml/20190204220952.30761-1-TheSven73@.../
Reported-by: Sven Van Asbroeck <thesven73@...>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@...>
Reviewed-by: Sven Van Asbroeck <TheSven73@...>
Acked-by: Robin van der Gracht <robin@...>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/auxdisplay/ht16k33.c


[linux:lloyd-aviation] By Gabriel Fernandez <gabriel.fernandez@...>:
5050f03ff0b1: Input: st-keyscan - fix potential zalloc NULL dereference

[ Upstream commit 2439d37e1bf8a34d437573c086572abe0f3f1b15 ]

This patch fixes the following static checker warning:

drivers/input/keyboard/st-keyscan.c:156 keyscan_probe()
error: potential zalloc NULL dereference: 'keypad_data->input_dev'

Reported-by: Dan Carpenter <dan.carpenter@...>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@...>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/input/keyboard/st-keyscan.c


[linux:lloyd-aviation] By Paul Kocialkowski <paul.kocialkowski@...>:
980f44f8dd8a: clk: sunxi-ng: v3s: Fix TCON reset de-assert bit

[ Upstream commit 5c59801f7018acba11b12de59017a3fcdcf7421d ]

According to the datasheet and the reference code from Allwinner, the
bit used to de-assert the TCON reset is bit 4, not bit 3.

Fix it in the V3s CCU driver.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@...>
Signed-off-by: Maxime Ripard <maxime.ripard@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/clk/sunxi-ng/ccu-sun8i-v3s.c


[linux:lloyd-aviation] By Eugene Loh <eugene.loh@...>:
cacf3c0d8288: kallsyms: Handle too long symbols in kallsyms.c

[ Upstream commit 6db2983cd8064808141ccefd75218f5b4345ffae ]

When checking for symbols with excessively long names,
account for null terminating character.

Fixes: f3462aa952cf ("Kbuild: Handle longer symbols in kallsyms.c")
Signed-off-by: Eugene Loh <eugene.loh@...>
Acked-by: Ard Biesheuvel <ard.biesheuvel@...>
Signed-off-by: Masahiro Yamada <yamada.masahiro@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: scripts/kallsyms.c


[linux:lloyd-aviation] By Andre Przywara <andre.przywara@...>:
2f3b4f968619: clk: sunxi: A31: Fix wrong AHB gate number

[ Upstream commit ee0b27a3a4da0b0ed2318aa092f8856896e9450b ]

According to the manual the gate clock for MMC3 is at bit 11, and NAND1
is controlled by bit 12.

Fix the gate bit definitions in the clock driver.

Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Andre Przywara <andre.przywara@...>
Signed-off-by: Maxime Ripard <maxime.ripard@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/clk/sunxi-ng/ccu-sun6i-a31.c


[linux:lloyd-aviation] By Martin Willi <martin@...>:
b92eaed36c4b: esp: Skip TX bytes accounting when sending from a request socket

[ Upstream commit 09db51241118aeb06e1c8cd393b45879ce099b36 ]

On ESP output, sk_wmem_alloc is incremented for the added padding if a
socket is associated to the skb. When replying with TCP SYNACKs over
IPsec, the associated sk is a casted request socket, only. Increasing
sk_wmem_alloc on a request socket results in a write at an arbitrary
struct offset. In the best case, this produces the following WARNING:

WARNING: CPU: 1 PID: 0 at lib/refcount.c:102 esp_output_head+0x2e4/0x308 [esp4]
refcount_t: addition on 0; use-after-free.
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.0.0-rc3 #2
Hardware name: Marvell Armada 380/385 (Device Tree)
[...]
[<bf0ff354>] (esp_output_head [esp4]) from [<bf1006a4>] (esp_output+0xb8/0x180 [esp4])
[<bf1006a4>] (esp_output [esp4]) from [<c05dee64>] (xfrm_output_resume+0x558/0x664)
[<c05dee64>] (xfrm_output_resume) from [<c05d07b0>] (xfrm4_output+0x44/0xc4)
[<c05d07b0>] (xfrm4_output) from [<c05956bc>] (tcp_v4_send_synack+0xa8/0xe8)
[<c05956bc>] (tcp_v4_send_synack) from [<c0586ad8>] (tcp_conn_request+0x7f4/0x948)
[<c0586ad8>] (tcp_conn_request) from [<c058c404>] (tcp_rcv_state_process+0x2a0/0xe64)
[<c058c404>] (tcp_rcv_state_process) from [<c05958ac>] (tcp_v4_do_rcv+0xf0/0x1f4)
[<c05958ac>] (tcp_v4_do_rcv) from [<c0598a4c>] (tcp_v4_rcv+0xdb8/0xe20)
[<c0598a4c>] (tcp_v4_rcv) from [<c056eb74>] (ip_protocol_deliver_rcu+0x2c/0x2dc)
[<c056eb74>] (ip_protocol_deliver_rcu) from [<c056ee6c>] (ip_local_deliver_finish+0x48/0x54)
[<c056ee6c>] (ip_local_deliver_finish) from [<c056eecc>] (ip_local_deliver+0x54/0xec)
[<c056eecc>] (ip_local_deliver) from [<c056efac>] (ip_rcv+0x48/0xb8)
[<c056efac>] (ip_rcv) from [<c0519c2c>] (__netif_receive_skb_one_core+0x50/0x6c)
[...]

The issue triggers only when not using TCP syncookies, as for syncookies
no socket is associated.

Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
Signed-off-by: Martin Willi <martin@...>
Signed-off-by: Steffen Klassert <steffen.klassert@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/ipv4/esp4.c
Modified: net/ipv6/esp6.c


[linux:lloyd-aviation] By Dietmar Eggemann <dietmar.eggemann@...>:
da3495301cda: ARM: 8824/1: fix a migrating irq bug when hotplug cpu

[ Upstream commit 1b5ba350784242eb1f899bcffd95d2c7cff61e84 ]

Arm TC2 fails cpu hotplug stress test.

This issue was tracked down to a missing copy of the new affinity
cpumask for the vexpress-spc interrupt into struct
irq_common_data.affinity when the interrupt is migrated in
migrate_one_irq().

Fix it by replacing the arm specific hotplug cpu migration with the
generic irq code.

This is the counterpart implementation to commit 217d453d473c ("arm64:
fix a migrating irq bug when hotplug cpu").

Tested with cpu hotplug stress test on Arm TC2 (multi_v7_defconfig plus
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y and CONFIG_ARM_VEXPRESS_SPC_CPUFREQ=y).
The vexpress-spc interrupt (irq=22) on this board is affine to CPU0.
Its affinity cpumask now changes correctly e.g. from 0 to 1-4 when
CPU0 is hotplugged out.

Suggested-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@...>
Acked-by: Marc Zyngier <marc.zyngier@...>
Reviewed-by: Linus Walleij <linus.walleij@...>
Signed-off-by: Russell King <rmk+kernel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm/Kconfig
Modified: arch/arm/include/asm/irq.h
Modified: arch/arm/kernel/irq.c
Modified: arch/arm/kernel/smp.c


[linux:lloyd-aviation] By Willem de Bruijn <willemb@...>:
413e39852082: bpf: only adjust gso_size on bytestream protocols

[ Upstream commit b90efd2258749e04e1b3f71ef0d716f2ac2337e0 ]

bpf_skb_change_proto and bpf_skb_adjust_room change skb header length.
For GSO packets they adjust gso_size to maintain the same MTU.

The gso size can only be safely adjusted on bytestream protocols.
Commit d02f51cbcf12 ("bpf: fix bpf_skb_adjust_net/bpf_skb_proto_xlat
to deal with gso sctp skbs") excluded SKB_GSO_SCTP.

Since then type SKB_GSO_UDP_L4 has been added, whose contents are one
gso_size unit per datagram. Also exclude these.

Move from a blacklist to a whitelist check to future proof against
additional such new GSO types, e.g., for fraglist based GRO.

Fixes: bec1f6f69736 ("udp: generate gso with UDP_SEGMENT")
Signed-off-by: Willem de Bruijn <willemb@...>
Signed-off-by: Alexei Starovoitov <ast@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: include/linux/skbuff.h
Modified: net/core/filter.c


[linux:lloyd-aviation] By Alexei Starovoitov <ast@...>:
c7c68a1b9a16: bpf: fix lockdep false positive in stackmap

[ Upstream commit 3defaf2f15b2bfd86c6664181ac009e91985f8ac ]

Lockdep warns about false positive:
[ 11.211460] ------------[ cut here ]------------
[ 11.211936] DEBUG_LOCKS_WARN_ON(depth <= 0)
[ 11.211985] WARNING: CPU: 0 PID: 141 at ../kernel/locking/lockdep.c:3592 lock_release+0x1ad/0x280
[ 11.213134] Modules linked in:
[ 11.214954] RIP: 0010:lock_release+0x1ad/0x280
[ 11.223508] Call Trace:
[ 11.223705] <IRQ>
[ 11.223874] ? __local_bh_enable+0x7a/0x80
[ 11.224199] up_read+0x1c/0xa0
[ 11.224446] do_up_read+0x12/0x20
[ 11.224713] irq_work_run_list+0x43/0x70
[ 11.225030] irq_work_run+0x26/0x50
[ 11.225310] smp_irq_work_interrupt+0x57/0x1f0
[ 11.225662] irq_work_interrupt+0xf/0x20

since rw_semaphore is released in a different task vs task that locked the sema.
It is expected behavior.
Fix the warning with up_read_non_owner() and rwsem_release() annotation.

Fixes: bae77c5eb5b2 ("bpf: enable stackmap with build_id in nmi context")
Signed-off-by: Alexei Starovoitov <ast@...>
Signed-off-by: Daniel Borkmann <daniel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: kernel/bpf/stackmap.c


[linux:lloyd-aviation] By Sean Tranchetti <stranche@...>:
978e0388c22b: af_key: unconditionally clone on broadcast

[ Upstream commit fc2d5cfdcfe2ab76b263d91429caa22451123085 ]

Attempting to avoid cloning the skb when broadcasting by inflating
the refcount with sock_hold/sock_put while under RCU lock is dangerous
and violates RCU principles. It leads to subtle race conditions when
attempting to free the SKB, as we may reference sockets that have
already been freed by the stack.

Unable to handle kernel paging request at virtual address 6b6b6b6b6b6c4b
[006b6b6b6b6b6c4b] address between user and kernel address ranges
Internal error: Oops: 96000004 [#1] PREEMPT SMP
task: fffffff78f65b380 task.stack: ffffff8049a88000
pc : sock_rfree+0x38/0x6c
lr : skb_release_head_state+0x6c/0xcc
Process repro (pid: 7117, stack limit = 0xffffff8049a88000)
Call trace:
sock_rfree+0x38/0x6c
skb_release_head_state+0x6c/0xcc
skb_release_all+0x1c/0x38
__kfree_skb+0x1c/0x30
kfree_skb+0xd0/0xf4
pfkey_broadcast+0x14c/0x18c
pfkey_sendmsg+0x1d8/0x408
sock_sendmsg+0x44/0x60
___sys_sendmsg+0x1d0/0x2a8
__sys_sendmsg+0x64/0xb4
SyS_sendmsg+0x34/0x4c
el0_svc_naked+0x34/0x38
Kernel panic - not syncing: Fatal exception

Suggested-by: Eric Dumazet <eric.dumazet@...>
Signed-off-by: Sean Tranchetti <stranche@...>
Signed-off-by: Steffen Klassert <steffen.klassert@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/key/af_key.c


[linux:lloyd-aviation] By Robin Murphy <robin.murphy@...>:
84657a1ba9bd: ARM: 8835/1: dma-mapping: Clear DMA ops on teardown

[ Upstream commit fc67e6f120a388b611d94cc40baf99a5cc56b283 ]

Installing the appropriate non-IOMMU DMA ops in arm_iommu_detch_device()
serves the case where IOMMU-aware drivers choose to control their own
mapping but still make DMA API calls, however it also affects the case
when the arch code itself tears down the mapping upon driver unbinding,
where the ops now get left in place and can inhibit arch_setup_dma_ops()
on subsequent re-probe attempts.

Fix the latter case by making sure that arch_teardown_dma_ops() cleans
up whenever the ops were automatically installed by its counterpart.

Reported-by: Tobias Jakobi <tjakobi@...>
Reported-by: Marek Szyprowski <m.szyprowski@...>
Fixes: 1874619a7df4 "ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()"
Tested-by: Tobias Jakobi <tjakobi@...>
Tested-by: Thierry Reding <treding@...>
Signed-off-by: Robin Murphy <robin.murphy@...>
Signed-off-by: Russell King <rmk+kernel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm/mm/dma-mapping.c


[linux:lloyd-aviation] By David Howells <dhowells@...>:
fac71ac37634: assoc_array: Fix shortcut creation

[ Upstream commit bb2ba2d75a2d673e76ddaf13a9bd30d6a8b1bb08 ]

Fix the creation of shortcuts for which the length of the index key value
is an exact multiple of the machine word size. The problem is that the
code that blanks off the unused bits of the shortcut value malfunctions if
the number of bits in the last word equals machine word size. This is due
to the "<<" operator being given a shift of zero in this case, and so the
mask that should be all zeros is all ones instead. This causes the
subsequent masking operation to clear everything rather than clearing
nothing.

Ordinarily, the presence of the hash at the beginning of the tree index key
makes the issue very hard to test for, but in this case, it was encountered
due to a development mistake that caused the hash output to be either 0
(keyring) or 1 (non-keyring) only. This made it susceptible to the
keyctl/unlink/valid test in the keyutils package.

The fix is simply to skip the blanking if the shift would be 0. For
example, an index key that is 64 bits long would produce a 0 shift and thus
a 'blank' of all 1s. This would then be inverted and AND'd onto the
index_key, incorrectly clearing the entire last word.

Fixes: 3cb989501c26 ("Add a generic associative array implementation.")
Signed-off-by: David Howells <dhowells@...>
Signed-off-by: James Morris <james.morris@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: lib/assoc_array.c


[linux:lloyd-aviation] By David Howells <dhowells@...>:
726832821903: keys: Fix dependency loop between construction record and auth key

[ Upstream commit 822ad64d7e46a8e2c8b8a796738d7b657cbb146d ]

In the request_key() upcall mechanism there's a dependency loop by which if
a key type driver overrides the ->request_key hook and the userspace side
manages to lose the authorisation key, the auth key and the internal
construction record (struct key_construction) can keep each other pinned.

Fix this by the following changes:

(1) Killing off the construction record and using the auth key instead.

(2) Including the operation name in the auth key payload and making the
payload available outside of security/keys/.

(3) The ->request_key hook is given the authkey instead of the cons
record and operation name.

Changes (2) and (3) allow the auth key to naturally be cleaned up if the
keyring it is in is destroyed or cleared or the auth key is unlinked.

Fixes: 7ee02a316600 ("keys: Fix dependency loop between construction record and auth key")
Signed-off-by: David Howells <dhowells@...>
Signed-off-by: James Morris <james.morris@...>
Signed-off-by: Sasha Levin <sashal@...>

Added: include/keys/request_key_auth-type.h
Modified: fs/nfs/nfs4idmap.c
Modified: include/linux/key-type.h
Modified: security/keys/internal.h
Modified: security/keys/keyctl.c
Modified: security/keys/process_keys.c
Modified: security/keys/request_key.c
Modified: security/keys/request_key_auth.c


[linux:lloyd-aviation] By Anoob Soman <anoob.soman@...>:
3491857f4292: scsi: libiscsi: Fix race between iscsi_xmit_task and iscsi_complete_task

[ Upstream commit 79edd00dc6a96644d76b4a1cb97d94d49e026768 ]

When a target sends Check Condition, whilst initiator is busy xmiting
re-queued data, could lead to race between iscsi_complete_task() and
iscsi_xmit_task() and eventually crashing with the following kernel
backtrace.

[3326150.987523] ALERT: BUG: unable to handle kernel NULL pointer dereference at 0000000000000078
[3326150.987549] ALERT: IP: [<ffffffffa05ce70d>] iscsi_xmit_task+0x2d/0xc0 [libiscsi]
[3326150.987571] WARN: PGD 569c8067 PUD 569c9067 PMD 0
[3326150.987582] WARN: Oops: 0002 [#1] SMP
[3326150.987593] WARN: Modules linked in: tun nfsv3 nfs fscache dm_round_robin
[3326150.987762] WARN: CPU: 2 PID: 8399 Comm: kworker/u32:1 Tainted: G O 4.4.0+2 #1
[3326150.987774] WARN: Hardware name: Dell Inc. PowerEdge R720/0W7JN5, BIOS 2.5.4 01/22/2016
[3326150.987790] WARN: Workqueue: iscsi_q_13 iscsi_xmitworker [libiscsi]
[3326150.987799] WARN: task: ffff8801d50f3800 ti: ffff8801f5458000 task.ti: ffff8801f5458000
[3326150.987810] WARN: RIP: e030:[<ffffffffa05ce70d>] [<ffffffffa05ce70d>] iscsi_xmit_task+0x2d/0xc0 [libiscsi]
[3326150.987825] WARN: RSP: e02b:ffff8801f545bdb0 EFLAGS: 00010246
[3326150.987831] WARN: RAX: 00000000ffffffc3 RBX: ffff880282d2ab20 RCX: ffff88026b6ac480
[3326150.987842] WARN: RDX: 0000000000000000 RSI: 00000000fffffe01 RDI: ffff880282d2ab20
[3326150.987852] WARN: RBP: ffff8801f545bdc8 R08: 0000000000000000 R09: 0000000000000008
[3326150.987862] WARN: R10: 0000000000000000 R11: 000000000000fe88 R12: 0000000000000000
[3326150.987872] WARN: R13: ffff880282d2abe8 R14: ffff880282d2abd8 R15: ffff880282d2ac08
[3326150.987890] WARN: FS: 00007f5a866b4840(0000) GS:ffff88028a640000(0000) knlGS:0000000000000000
[3326150.987900] WARN: CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[3326150.987907] WARN: CR2: 0000000000000078 CR3: 0000000070244000 CR4: 0000000000042660
[3326150.987918] WARN: Stack:
[3326150.987924] WARN: ffff880282d2ad58 ffff880282d2ab20 ffff880282d2abe8 ffff8801f545be18
[3326150.987938] WARN: ffffffffa05cea90 ffff880282d2abf8 ffff88026b59cc80 ffff88026b59cc00
[3326150.987951] WARN: ffff88022acf32c0 ffff880289491800 ffff880255a80800 0000000000000400
[3326150.987964] WARN: Call Trace:
[3326150.987975] WARN: [<ffffffffa05cea90>] iscsi_xmitworker+0x2f0/0x360 [libiscsi]
[3326150.987988] WARN: [<ffffffff8108862c>] process_one_work+0x1fc/0x3b0
[3326150.987997] WARN: [<ffffffff81088f95>] worker_thread+0x2a5/0x470
[3326150.988006] WARN: [<ffffffff8159cad8>] ? __schedule+0x648/0x870
[3326150.988015] WARN: [<ffffffff81088cf0>] ? rescuer_thread+0x300/0x300
[3326150.988023] WARN: [<ffffffff8108ddf5>] kthread+0xd5/0xe0
[3326150.988031] WARN: [<ffffffff8108dd20>] ? kthread_stop+0x110/0x110
[3326150.988040] WARN: [<ffffffff815a0bcf>] ret_from_fork+0x3f/0x70
[3326150.988048] WARN: [<ffffffff8108dd20>] ? kthread_stop+0x110/0x110
[3326150.988127] ALERT: RIP [<ffffffffa05ce70d>] iscsi_xmit_task+0x2d/0xc0 [libiscsi]
[3326150.988138] WARN: RSP <ffff8801f545bdb0>
[3326150.988144] WARN: CR2: 0000000000000078
[3326151.020366] WARN: ---[ end trace 1c60974d4678d81b ]---

Commit 6f8830f5bbab ("scsi: libiscsi: add lock around task lists to fix
list corruption regression") introduced "taskqueuelock" to fix list
corruption during the race, but this wasn't enough.

Re-setting of conn->task to NULL, could race with iscsi_xmit_task().
iscsi_complete_task()
{
....
if (conn->task == task)
conn->task = NULL;
}

conn->task in iscsi_xmit_task() could be NULL and so will be task.
__iscsi_get_task(task) will crash (NullPtr de-ref), trying to access
refcount.

iscsi_xmit_task()
{
struct iscsi_task *task = conn->task;

__iscsi_get_task(task);
}

This commit will take extra conn->session->back_lock in iscsi_xmit_task()
to ensure iscsi_xmit_task() waits for iscsi_complete_task(), if
iscsi_complete_task() wins the race. If iscsi_xmit_task() wins the race,
iscsi_xmit_task() increments task->refcount
(__iscsi_get_task) ensuring iscsi_complete_task() will not iscsi_free_task().

Signed-off-by: Anoob Soman <anoob.soman@...>
Signed-off-by: Bob Liu <bob.liu@...>
Acked-by: Lee Duncan <lduncan@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/scsi/libiscsi.c


[linux:lloyd-aviation] By Florian Fainelli <f.fainelli@...>:
d33f5a0febfa: net: systemport: Fix reception of BPDUs

[ Upstream commit a40061ea2e39494104602b3048751341bda374a1 ]

SYSTEMPORT has its RXCHK parser block that attempts to validate the
packet structures, unfortunately setting the L2 header check bit will
cause Bridge PDUs (BPDUs) to be incorrectly rejected because they look
like LLC/SNAP packets with a non-IPv4 or non-IPv6 Ethernet Type.

Fixes: 4e8aedfe78c7 ("net: systemport: Turn on offloads by default")
Signed-off-by: Florian Fainelli <f.fainelli@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/broadcom/bcmsysport.c


[linux:lloyd-aviation] By Florian Fainelli <f.fainelli@...>:
90a86d00af1a: net: dsa: bcm_sf2: Do not assume DSA master supports WoL

[ Upstream commit c3152ec4c0691e351f35a2f63347a464b5f35151 ]

We assume in the bcm_sf2 driver that the DSA master network device
supports ethtool_ops::{get,set}_wol operations, which is not a given.
Avoid de-referencing potentially non-existent function pointers and
check them as we should.

Fixes: 96e65d7f3f88 ("net: dsa: bcm_sf2: add support for Wake-on-LAN")
Signed-off-by: Florian Fainelli <f.fainelli@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/dsa/bcm_sf2.c


[linux:lloyd-aviation] By Martin Blumenstingl <martin.blumenstingl@...>:
13cb60c3c915: pinctrl: meson: meson8b: fix the sdxc_a data 1..3 pins

[ Upstream commit c17abcfa93bf0be5e48bb011607d237ac2bfc839 ]

Fix the mismatch between the "sdxc_d13_1_a" pin group definition from
meson8b_cbus_groups and the entry in sdxc_a_groups ("sdxc_d0_13_1_a").
This makes it possible to use "sdxc_d13_1_a" in device-tree files to
route the MMC data 1..3 pins to GPIOX_1..3.

Fixes: 0fefcb6876d0d6 ("pinctrl: Add support for Meson8b")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@...>
Signed-off-by: Linus Walleij <linus.walleij@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/pinctrl/meson/pinctrl-meson8b.c


[linux:lloyd-aviation] By Beniamino Galvani <bgalvani@...>:
a139d6a318de: qmi_wwan: apply SET_DTR quirk to Sierra WP7607

[ Upstream commit 97dc47a1308a3af46a09b1546cfb869f2e382a81 ]

The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR
quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally as
already done for other IDs shared between different devices.

Signed-off-by: Beniamino Galvani <bgalvani@...>
Acked-by: Bjørn Mork <bjorn@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/usb/qmi_wwan.c


[linux:lloyd-aviation] By Alexey Khoroshilov <khoroshilov@...>:
3a5321342361: net: mv643xx_eth: disable clk on error path in mv643xx_eth_shared_probe()

[ Upstream commit e928b5d6b75e239feb9c6d5488974b6646a0ebc8 ]

If mv643xx_eth_shared_of_probe() fails, mv643xx_eth_shared_probe()
leaves clk enabled.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/marvell/mv643xx_eth.c


[linux:lloyd-aviation] By Tobias Brunner <tobias@...>:
6ac400b7c5e8: xfrm: Fix inbound traffic via XFRM interfaces across network namespaces

[ Upstream commit 660899ddf06ae8bb5bbbd0a19418b739375430c5 ]

After moving an XFRM interface to another namespace it stays associated
with the original namespace (net in `struct xfrm_if` and the list keyed
with `xfrmi_net_id`), allowing processes in the new namespace to use
SAs/policies that were created in the original namespace. For instance,
this allows a keying daemon in one namespace to establish IPsec SAs for
other namespaces without processes there having access to the keys or IKE
credentials.

This worked fine for outbound traffic, however, for inbound traffic the
lookup for the interfaces and the policies used the incorrect namespace
(the one the XFRM interface was moved to).

Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
Signed-off-by: Tobias Brunner <tobias@...>
Signed-off-by: Steffen Klassert <steffen.klassert@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/xfrm/xfrm_interface.c
Modified: net/xfrm/xfrm_policy.c


[linux:lloyd-aviation] By Rayagonda Kokatanur <rayagonda.kokatanur@...>:
edd7b6b9be97: mailbox: bcm-flexrm-mailbox: Fix FlexRM ring flush timeout issue

[ Upstream commit d7bf31a0f85faaf63c63c39d55154825a1eaaea9 ]

RING_CONTROL reg was not written due to wrong address, hence all
the subsequent ring flush was timing out.

Fixes: a371c10ea4b3 ("mailbox: bcm-flexrm-mailbox: Fix FlexRM ring flush sequence")

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@...>
Signed-off-by: Ray Jui <ray.jui@...>
Reviewed-by: Scott Branden <scott.branden@...>
Signed-off-by: Jassi Brar <jaswinder.singh@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/mailbox/bcm-flexrm-mailbox.c


[linux:lloyd-aviation] By Bard liao <yung-chuan.liao@...>:
90fc2f95c418: ASoC: topology: free created components in tplg load error

[ Upstream commit 304017d31df36fb61eb2ed3ebf65fb6870b3c731 ]

Topology resources are no longer needed if any element failed to load.

Signed-off-by: Bard liao <yung-chuan.liao@...>
Signed-off-by: Mark Brown <broonie@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: sound/soc/soc-topology.c


[linux:lloyd-aviation] By Michal Kalderon <michal.kalderon@...>:
821c67748623: qed: Fix iWARP buffer size provided for syn packet processing.

[ Upstream commit 9addc92730df55e2c05e8d3f69267a89d65bcba8 ]

The assumption that the maximum size of a syn packet is 128 bytes
is wrong. Tunneling headers were not accounted for.
Allocate buffers large enough for mtu.

Signed-off-by: Ariel Elior <ariel.elior@...>
Signed-off-by: Michal Kalderon <michal.kalderon@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/qlogic/qed/qed_iwarp.c
Modified: drivers/net/ethernet/qlogic/qed/qed_iwarp.h


[linux:lloyd-aviation] By Michal Kalderon <michal.kalderon@...>:
e4d14f616050: qed: Fix iWARP syn packet mac address validation.

[ Upstream commit 8be3dadf04050c2907760ec1955ca1c8fbc25585 ]

The ll2 forwards all syn packets to the driver without validating the mac
address. Add validation check in the driver's iWARP listener flow and drop
the packet if it isn't intended for the device.

Signed-off-by: Ariel Elior <ariel.elior@...>
Signed-off-by: Michal Kalderon <michal.kalderon@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/qlogic/qed/qed_iwarp.c


[linux:lloyd-aviation] By Thomas Petazzoni <thomas.petazzoni@...>:
2f97f7125237: ARM: dts: armada-xp: fix Armada XP boards NAND description

[ Upstream commit 6fc979179c98d2591784937d5618edc3e5cd31c1 ]

Commit 3b79919946cd2cf4dac47842afc9a893acec4ed7 ("ARM: dts:
armada-370-xp: update NAND node with new bindings") updated some
Marvell Armada DT description to use the new NAND controller bindings,
but did it incorrectly for a number of boards: armada-xp-gp,
armada-xp-db and armada-xp-lenovo-ix4-300d. Due to this, the NAND is
no longer detected on those platforms.

This commit fixes that by properly using the new NAND DT binding. This
commit was runtime-tested on Armada XP GP, the two other platforms are
only compile-tested.

Fixes: 3b79919946cd2 ("ARM: dts: armada-370-xp: update NAND node with new bindings")
Cc: Miquel Raynal <miquel.raynal@...>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@...>
Signed-off-by: Gregory CLEMENT <gregory.clement@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm/boot/dts/armada-xp-db.dts
Modified: arch/arm/boot/dts/armada-xp-gp.dts
Modified: arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts


[linux:lloyd-aviation] By Vladimir Murzin <vladimir.murzin@...>:
f715466a3f23: arm64: Relax GIC version check during early boot

[ Upstream commit 74698f6971f25d045301139413578865fc2bd8f9 ]

Updates to the GIC architecture allow ID_AA64PFR0_EL1.GIC to have
values other than 0 or 1. At the moment, Linux is quite strict in the
way it handles this field at early boot stage (cpufeature is fine) and
will refuse to use the system register CPU interface if it doesn't
find the value 1.

Fixes: 021f653791ad17e03f98aaa7fb933816ae16f161 ("irqchip: gic-v3: Initial support for GICv3")
Reported-by: Chase Conklin <Chase.Conklin@...>
Reviewed-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Vladimir Murzin <vladimir.murzin@...>
Signed-off-by: Will Deacon <will.deacon@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm64/kernel/head.S


[linux:lloyd-aviation] By Thierry Reding <treding@...>:
e52578889c8e: ARM: tegra: Restore DT ABI on Tegra124 Chromebooks

[ Upstream commit 94d9b9337d09bdd27735005b3251d97ab29f7273 ]

Commit 482997699ef0 ("ARM: tegra: Fix unit_address_vs_reg DTC warnings
for /memory") inadventently broke device tree ABI by adding a unit-
address to the "/memory" node because the device tree compiler flagged
the missing unit-address as a warning.

Tegra124 Chromebooks (a.k.a. Nyan) use a bootloader that relies on the
full name of the memory node in device tree being exactly "/memory". It
can be argued whether this was a good decision or not, and some other
bootloaders (such as U-Boot) do accept a unit-address in the name of the
node, but the device tree is an ABI and we can't break existing setups
just because the device tree compiler considers it bad practice to omit
the unit-address nowadays.

This partially reverts the offending commit and restores device tree ABI
compatibility.

Fixes: 482997699ef0 ("ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory")
Reported-by: Tristan Bastian <tristan-c.bastian@...>
Signed-off-by: Thierry Reding <treding@...>
Tested-by: Tristan Bastian <tristan-c.bastian@...>
Signed-off-by: Arnd Bergmann <arnd@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arm/boot/dts/tegra124-nyan.dtsi


[linux:lloyd-aviation] By Russell King <rmk+kernel@...>:
f3a9c9be0eb4: net: marvell: mvneta: fix DMA debug warning

[ Upstream commit a8fef9ba58c9966ddb1fec916d8d8137c9d8bc89 ]

Booting 4.20 on SolidRun Clearfog issues this warning with DMA API
debug enabled:

WARNING: CPU: 0 PID: 555 at kernel/dma/debug.c:1230 check_sync+0x514/0x5bc
mvneta f1070000.ethernet: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000002dd7dc00] [size=240 bytes]
Modules linked in: ahci mv88e6xxx dsa_core xhci_plat_hcd xhci_hcd devlink armada_thermal marvell_cesa des_generic ehci_orion phy_armada38x_comphy mcp3021 spi_orion evbug sfp mdio_i2c ip_tables x_tables
CPU: 0 PID: 555 Comm: bridge-network- Not tainted 4.20.0+ #291
Hardware name: Marvell Armada 380/385 (Device Tree)
[<c0019638>] (unwind_backtrace) from [<c0014888>] (show_stack+0x10/0x14)
[<c0014888>] (show_stack) from [<c07f54e0>] (dump_stack+0x9c/0xd4)
[<c07f54e0>] (dump_stack) from [<c00312bc>] (__warn+0xf8/0x124)
[<c00312bc>] (__warn) from [<c00313b0>] (warn_slowpath_fmt+0x38/0x48)
[<c00313b0>] (warn_slowpath_fmt) from [<c00b0370>] (check_sync+0x514/0x5bc)
[<c00b0370>] (check_sync) from [<c00b04f8>] (debug_dma_sync_single_range_for_cpu+0x6c/0x74)
[<c00b04f8>] (debug_dma_sync_single_range_for_cpu) from [<c051bd14>] (mvneta_poll+0x298/0xf58)
[<c051bd14>] (mvneta_poll) from [<c0656194>] (net_rx_action+0x128/0x424)
[<c0656194>] (net_rx_action) from [<c000a230>] (__do_softirq+0xf0/0x540)
[<c000a230>] (__do_softirq) from [<c00386e0>] (irq_exit+0x124/0x144)
[<c00386e0>] (irq_exit) from [<c009b5e0>] (__handle_domain_irq+0x58/0xb0)
[<c009b5e0>] (__handle_domain_irq) from [<c03a63c4>] (gic_handle_irq+0x48/0x98)
[<c03a63c4>] (gic_handle_irq) from [<c0009a10>] (__irq_svc+0x70/0x98)
...

This appears to be caused by mvneta_rx_hwbm() calling
dma_sync_single_range_for_cpu() with the wrong struct device pointer,
as the buffer manager device pointer is used to map and unmap the
buffer. Fix this.

Signed-off-by: Russell King <rmk+kernel@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/marvell/mvneta.c


[linux:lloyd-aviation] By Michal Hocko <mhocko@...>:
e6e9d6e29002: mm: handle lru_add_drain_all for UP properly

[ Upstream commit 6ea183d60c469560e7b08a83c9804299e84ec9eb ]

Since for_each_cpu(cpu, mask) added by commit 2d3854a37e8b767a
("cpumask: introduce new API, without changing anything") did not
evaluate the mask argument if NR_CPUS == 1 due to CONFIG_SMP=n,
lru_add_drain_all() is hitting WARN_ON() at __flush_work() added by
commit 4d43d395fed12463 ("workqueue: Try to catch flush_work() without
INIT_WORK().") by unconditionally calling flush_work() [1].

Workaround this issue by using CONFIG_SMP=n specific lru_add_drain_all
implementation. There is no real need to defer the implementation to
the workqueue as the draining is going to happen on the local cpu. So
alias lru_add_drain_all to lru_add_drain which does all the necessary
work.

[akpm@...: fix various build warnings]
[1] https://lkml.kernel.org/r/18a30387-6aa5-6123-e67c-57579ecc3f38@...
Link: http://lkml.kernel.org/r/20190213124334.GH4525@...
Signed-off-by: Michal Hocko <mhocko@...>
Reported-by: Guenter Roeck <linux@...>
Debugged-by: Tetsuo Handa <penguin-kernel@...>
Cc: Tejun Heo <tj@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/swap.c


[linux:lloyd-aviation] By Darrick J. Wong <darrick.wong@...>:
064a61d3e7b5: tmpfs: fix link accounting when a tmpfile is linked in

[ Upstream commit 1062af920c07f5b54cf5060fde3339da6df0cf6b ]

tmpfs has a peculiarity of accounting hard links as if they were
separate inodes: so that when the number of inodes is limited, as it is
by default, a user cannot soak up an unlimited amount of unreclaimable
dcache memory just by repeatedly linking a file.

But when v3.11 added O_TMPFILE, and the ability to use linkat() on the
fd, we missed accommodating this new case in tmpfs: "df -i" shows that
an extra "inode" remains accounted after the file is unlinked and the fd
closed and the actual inode evicted. If a user repeatedly links
tmpfiles into a tmpfs, the limit will be hit (ENOSPC) even after they
are deleted.

Just skip the extra reservation from shmem_link() in this case: there's
a sense in which this first link of a tmpfile is then cheaper than a
hard link of another file, but the accounting works out, and there's
still good limiting, so no need to do anything more complicated.

Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1902182134370.7035@...
Fixes: f4e0c30c191 ("allow the temp files created by open() to be linked to")
Signed-off-by: Darrick J. Wong <darrick.wong@...>
Signed-off-by: Hugh Dickins <hughd@...>
Reported-by: Matej Kupljen <matej.kupljen@...>
Acked-by: Al Viro <viro@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/shmem.c


[linux:lloyd-aviation] By Jeff Kirsher <jeffrey.t.kirsher@...>:
2c049f195787: ixgbe: fix older devices that do not support IXGBE_MRQC_L3L4TXSWEN

[ Upstream commit 156a67a9065e3339be85f811d1b13b920e50d73b ]

The enabling L3/L4 filtering for transmit switched packets for all
devices caused unforeseen issue on older devices when trying to send UDP
traffic in an ordered sequence. This bit was originally intended for X550
devices, which supported this feature, so limit the scope of this bit to
only X550 devices.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...>
Tested-by: Andrew Bowers <andrewx.bowers@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/intel/ixgbe/ixgbe_main.c


[linux:lloyd-aviation] By Eugeniy Paltsev <eugeniy.paltsev@...>:
2fc69e55f370: ARCv2: lib: memcpy: fix doing prefetchw outside of buffer

[ Upstream commit f8a15f97664178f27dfbf86a38f780a532cb6df0 ]

ARCv2 optimized memcpy uses PREFETCHW instruction for prefetching the
next cache line but doesn't ensure that the line is not past the end of
the buffer. PRETECHW changes the line ownership and marks it dirty,
which can cause data corruption if this area is used for DMA IO.

Fix the issue by avoiding the PREFETCHW. This leads to performance
degradation but it is OK as we'll introduce new memcpy implementation
optimized for unaligned memory access using.

We also cut off all PREFETCH instructions at they are quite useless
here:
* we call PREFETCH right before LOAD instruction call.
* we copy 16 or 32 bytes of data (depending on CONFIG_ARC_HAS_LL64)
in a main logical loop. so we call PREFETCH 4 times (or 2 times)
for each L1 cache line (in case of 64B L1 cache Line which is
default case). Obviously this is not optimal.

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@...>
Signed-off-by: Vineet Gupta <vgupta@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arc/lib/memcpy-archs.S


[linux:lloyd-aviation] By Vineet Gupta <vgupta@...>:
74b4dcea6756: ARC: uacces: remove lp_start, lp_end from clobber list

[ Upstream commit d5e3c55e01d8b1774b37b4647c30fb22f1d39077 ]

Newer ARC gcc handles lp_start, lp_end in a different way and doesn't
like them in the clobber list.

Signed-off-by: Vineet Gupta <vgupta@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arc/include/asm/uaccess.h


[linux:lloyd-aviation] By Vineet Gupta <vgupta@...>:
3220aa9b0065: ARCv2: support manual regfile save on interrupts

[ Upstream commit e494239a007e601448110ac304fe055951f9de3b ]

There's a hardware bug which affects the HSDK platform, triggered by
micro-ops for auto-saving regfile on taken interrupt. The workaround is
to inhibit autosave.

Signed-off-by: Vineet Gupta <vgupta@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arc/Kconfig
Modified: arch/arc/include/asm/entry-arcv2.h
Modified: arch/arc/kernel/entry-arcv2.S
Modified: arch/arc/kernel/intc-arcv2.c
Modified: arch/arc/plat-hsdk/Kconfig


[linux:lloyd-aviation] By Vineet Gupta <vgupta@...>:
8b9187e7df64: ARCv2: don't assume core 0x54 has dual issue

[ Upstream commit 7b2e932f633bcb7b190fc7031ce6dac75f8c3472 ]

The first release of core4 (0x54) was dual issue only (HS4x).
Newer releases allow hardware to be configured as single issue (HS3x)
or dual issue.

Prevent accessing a HS4x only aux register in HS3x, which otherwise
leads to illegal instruction exceptions

Signed-off-by: Vineet Gupta <vgupta@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/arc/include/asm/arcregs.h
Modified: arch/arc/kernel/setup.c


[linux:lloyd-aviation] By Arnd Bergmann <arnd@...>:
ee01ac61d1d4: phonet: fix building with clang

[ Upstream commit 6321aa197547da397753757bd84c6ce64b3e3d89 ]

clang warns about overflowing the data[] member in the struct pnpipehdr:

net/phonet/pep.c:295:8: warning: array index 4 is past the end of the array (which contains 1 element) [-Warray-bounds]
if (hdr->data[4] == PEP_IND_READY)
^ ~
include/net/phonet/pep.h:66:3: note: array 'data' declared here
u8 data[1];

Using a flexible array member at the end of the struct avoids the
warning, but since we cannot have a flexible array member inside
of the union, each index now has to be moved back by one, which
makes it a little uglier.

Signed-off-by: Arnd Bergmann <arnd@...>
Acked-by: Rémi Denis-Courmont <remi@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: include/net/phonet/pep.h
Modified: net/phonet/pep.c


[linux:lloyd-aviation] By Li RongQing <lirongqing@...>:
c5f37906ecb7: mac80211_hwsim: propagate genlmsg_reply return code

[ Upstream commit 17407715240456448e4989bee46ffc93991add83 ]

genlmsg_reply can fail, so propagate its return code

Signed-off-by: Li RongQing <lirongqing@...>
Signed-off-by: Johannes Berg <johannes.berg@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/wireless/mac80211_hwsim.c


[linux:lloyd-aviation] By Alban Crequy <alban@...>:
02f8211b75c9: bpf, lpm: fix lookup bug in map_delete_elem

[ Upstream commit 7c0cdf0b3940f63d9777c3fcf250a2f83859ca54 ]

trie_delete_elem() was deleting an entry even though it was not matching
if the prefixlen was correct. This patch adds a check on matchlen.

Reproducer:

$ sudo bpftool map create /sys/fs/bpf/mylpm type lpm_trie key 8 value 1 entries 128 name mylpm flags 1
$ sudo bpftool map update pinned /sys/fs/bpf/mylpm key hex 10 00 00 00 aa bb cc dd value hex 01
$ sudo bpftool map dump pinned /sys/fs/bpf/mylpm
key: 10 00 00 00 aa bb cc dd value: 01
Found 1 element
$ sudo bpftool map delete pinned /sys/fs/bpf/mylpm key hex 10 00 00 00 ff ff ff ff
$ echo $?
0
$ sudo bpftool map dump pinned /sys/fs/bpf/mylpm
Found 0 elements

A similar reproducer is added in the selftests.

Without the patch:

$ sudo ./tools/testing/selftests/bpf/test_lpm_map
test_lpm_map: test_lpm_map.c:485: test_lpm_delete: Assertion `bpf_map_delete_elem(map_fd, key) == -1 && errno == ENOENT' failed.
Aborted

With the patch: test_lpm_map runs without errors.

Fixes: e454cf595853 ("bpf: Implement map_delete_elem for BPF_MAP_TYPE_LPM_TRIE")
Cc: Craig Gallek <kraig@...>
Signed-off-by: Alban Crequy <alban@...>
Acked-by: Craig Gallek <kraig@...>
Signed-off-by: Daniel Borkmann <daniel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: kernel/bpf/lpm_trie.c
Modified: tools/testing/selftests/bpf/test_lpm_map.c


[linux:lloyd-aviation] By Vadim Lomovtsev <vlomovtsev@...>:
17bc53e73d0c: net: thunderx: make CFG_DONE message to run through generic send-ack sequence

[ Upstream commit 0dd563b9a62c4cbabf5d4fd6596440c2491e72b1 ]

At the end of NIC VF initialization VF sends CFG_DONE message to PF without
using nicvf_msg_send_to_pf routine. This potentially could re-write data in
mailbox. This commit is to implement common way of sending CFG_DONE message
by the same way with other configuration messages by using
nicvf_send_msg_to_pf() routine.

Signed-off-by: Vadim Lomovtsev <vlomovtsev@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/cavium/thunder/nic_main.c
Modified: drivers/net/ethernet/cavium/thunder/nicvf_main.c


[linux:lloyd-aviation] By Vadim Lomovtsev <vlomovtsev@...>:
4523507c52b8: net: thunderx: add nicvf_send_msg_to_pf result check for set_rx_mode_task

[ Upstream commit 7db730d9d2f7b6af6aeac621b1890ea477a0cb8d ]

The rx_set_mode invokes number of messages to be send to PF for receive
mode configuration. In case if there any issues we need to stop sending
messages and release allocated memory.

This commit is to implement check of nicvf_msg_send_to_pf() result.

Signed-off-by: Vadim Lomovtsev <vlomovtsev@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/cavium/thunder/nicvf_main.c


[linux:lloyd-aviation] By Jiong Wang <jiong.wang@...>:
7ca1faa52be7: nfp: bpf: fix code-gen bug on BPF_ALU | BPF_XOR | BPF_K

[ Upstream commit 71c190249f0ced5b26377ea6bf829ab3af77a40c ]

The intended optimization should be A ^ 0 = A, not A ^ -1 = A.

Fixes: cd7df56ed3e6 ("nfp: add BPF to NFP code translator")
Reviewed-by: Jakub Kicinski <jakub.kicinski@...>
Signed-off-by: Jiong Wang <jiong.wang@...>
Signed-off-by: Daniel Borkmann <daniel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/netronome/nfp/bpf/jit.c


[linux:lloyd-aviation] By Jiong Wang <jiong.wang@...>:
a40fa9498707: nfp: bpf: fix ALU32 high bits clearance bug

[ Upstream commit f036ebd9bfbe1e91a3d855e85e05fc5ff156b641 ]

NFP BPF JIT compiler is doing a couple of small optimizations when jitting
ALU imm instructions, some of these optimizations could save code-gen, for
example:

A & -1 = A
A | 0 = A
A ^ 0 = A

However, for ALU32, high 32-bit of the 64-bit register should still be
cleared according to ISA semantics.

Fixes: cd7df56ed3e6 ("nfp: add BPF to NFP code translator")
Reviewed-by: Jakub Kicinski <jakub.kicinski@...>
Signed-off-by: Jiong Wang <jiong.wang@...>
Signed-off-by: Daniel Borkmann <daniel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/netronome/nfp/bpf/jit.c


[linux:lloyd-aviation] By Michael Chan <michael.chan@...>:
b4baeab7e084: bnxt_en: Fix typo in firmware message timeout logic.

[ Upstream commit 67681d02aaa1db9044a16df4ca9c77cde1221a3e ]

The logic that polls for the firmware message response uses a shorter
sleep interval for the first few passes. But there was a typo so it
was using the wrong counter (larger counter) for these short sleep
passes. The result is a slightly shorter timeout period for these
firmware messages than intended. Fix it by using the proper counter.

Fixes: 9751e8e71487 ("bnxt_en: reduce timeout on initial HWRM calls")
Signed-off-by: Michael Chan <michael.chan@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/broadcom/bnxt/bnxt.c


[linux:lloyd-aviation] By Michael Chan <michael.chan@...>:
29e4bfbc79b4: bnxt_en: Wait longer for the firmware message response to complete.

[ Upstream commit 0000b81a063b5f3ab82fa18041c28327ce72c312 ]

The code waits up to 20 usec for the firmware response to complete
once we've seen the valid response header in the buffer. It turns
out that in some scenarios, this wait time is not long enough.
Extend it to 150 usec and use usleep_range() instead of udelay().

Fixes: 9751e8e71487 ("bnxt_en: reduce timeout on initial HWRM calls")
Signed-off-by: Michael Chan <michael.chan@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/broadcom/bnxt/bnxt.c
Modified: drivers/net/ethernet/broadcom/bnxt/bnxt.h


[linux:lloyd-aviation] By Mao Wenan <maowenan@...>:
8cd89bf632b2: net: set static variable an initial value in atl2_probe()

[ Upstream commit 4593403fa516a5a4cffe6883c5062d60932cbfbe ]

cards_found is a static variable, but when it enters atl2_probe(),
cards_found is set to zero, the value is not consistent with last probe,
so next behavior is not our expect.

Signed-off-by: Mao Wenan <maowenan@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/atheros/atlx/atl2.c


[linux:lloyd-aviation] By Thadeu Lima de Souza Cascardo <cascardo@...>:
d3f62d3eab0b: selftests: fib_tests: sleep after changing carrier. again.

[ Upstream commit af548a27b158d548d41e56255e6eaca1658cc3be ]

Just like commit e2ba732a1681 ("selftests: fib_tests: sleep after
changing carrier"), wait one second to allow linkwatch to propagate the
carrier change to the stack.

There are two sets of carrier tests. The first slept after the carrier
was set to off, and when the second set ran, it was likely that the
linkwatch would be able to run again without much delay, reducing the
likelihood of a race. However, if you run 'fib_tests.sh -t carrier' on a
loop, you will quickly notice the failures.

Sleeping on the second set of tests make the failures go away.

Cc: David Ahern <dsahern@...>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@...>
Reviewed-by: David Ahern <dsahern@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: tools/testing/selftests/net/fib_tests.sh


[linux:lloyd-aviation] By Darrick J. Wong <darrick.wong@...>:
b3139fbb3b00: tmpfs: fix uninitialized return value in shmem_link

[ Upstream commit 29b00e609960ae0fcff382f4c7079dd0874a5311 ]

When we made the shmem_reserve_inode call in shmem_link conditional, we
forgot to update the declaration for ret so that it always has a known
value. Dan Carpenter pointed out this deficiency in the original patch.

Fixes: 1062af920c07 ("tmpfs: fix link accounting when a tmpfile is linked in")
Reported-by: Dan Carpenter <dan.carpenter@...>
Signed-off-by: Darrick J. Wong <darrick.wong@...>
Signed-off-by: Hugh Dickins <hughd@...>
Cc: Matej Kupljen <matej.kupljen@...>
Cc: Al Viro <viro@...>
Cc: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/shmem.c


[linux:lloyd-aviation] By Alexander Shishkin <alexander.shishkin@...>:
eabd7d248e21: stm class: Prevent division by zero

commit bf7cbaae0831252b416f375ca9b1027ecd4642dd upstream.

Using STP_POLICY_ID_SET ioctl command with dummy_stm device, or any STM
device that supplies zero mmio channel size, will trigger a division by
zero bug in the kernel.

Prevent this by disallowing channel widths other than 1 for such devices.

Signed-off-by: Alexander Shishkin <alexander.shishkin@...>
Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices")
CC: stable@... # v4.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/hwtracing/stm/core.c


[linux:lloyd-aviation] By Dexuan Cui <decui@...>:
8df25eb903c5: nfit: acpi_nfit_ctl(): Check out_obj->type in the right place

commit 43f89877f26671c6309cd87d7364b1a3e66e71cf upstream.

In the case of ND_CMD_CALL, we should also check out_obj->type.

The patch uses out_obj->type, which is a short alias to
out_obj->package.type.

Fixes: 31eca76ba2fc ("nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism")
Cc: <stable@...>
Signed-off-by: Dexuan Cui <decui@...>
Signed-off-by: Dan Williams <dan.j.williams@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/acpi/nfit/core.c


[linux:lloyd-aviation] By Dan Williams <dan.j.williams@...>:
f5878c4f084d: acpi/nfit: Fix bus command validation

commit ebe9f6f19d80d8978d16078dff3d5bd93ad8d102 upstream.

Commit 11189c1089da "acpi/nfit: Fix command-supported detection" broke
ND_CMD_CALL for bus-level commands. The "func = cmd" assumption is only
valid for:

ND_CMD_ARS_CAP
ND_CMD_ARS_START
ND_CMD_ARS_STATUS
ND_CMD_CLEAR_ERROR

The function number otherwise needs to be pulled from the command
payload for:

NFIT_CMD_TRANSLATE_SPA
NFIT_CMD_ARS_INJECT_SET
NFIT_CMD_ARS_INJECT_CLEAR
NFIT_CMD_ARS_INJECT_GET

Update cmd_to_func() for the bus case and call it in the common path.

Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection")
Cc: <stable@...>
Reviewed-by: Vishal Verma <vishal.l.verma@...>
Reported-by: Grzegorz Burzynski <grzegorz.burzynski@...>
Tested-by: Jeff Moyer <jmoyer@...>
Signed-off-by: Dan Williams <dan.j.williams@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/acpi/nfit/core.c


[linux:lloyd-aviation] By Dan Williams <dan.j.williams@...>:
e6defe76600b: nfit/ars: Attempt a short-ARS whenever the ARS state is idle at boot

commit c6c5df293bf1b488cf8459aac658aecfdccb13a9 upstream.

If query-ARS reports that ARS has stopped and requires continuation
attempt to retrieve short-ARS results before continuing the long
operation.

Fixes: bc6ba8085842 ("nfit, address-range-scrub: rework and simplify ARS...")
Cc: <stable@...>
Reported-by: Krzysztof Rusocki <krzysztof.rusocki@...>
Reviewed-by: Toshi Kani <toshi.kani@...>
Signed-off-by: Dan Williams <dan.j.williams@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/acpi/nfit/core.c


[linux:lloyd-aviation] By Dan Williams <dan.j.williams@...>:
f4dfb94a0754: nfit/ars: Attempt short-ARS even in the no_init_ars case

commit fa3ed4d981b1fc19acdd07fcb152a4bd3706892b upstream.

The no_init_ars option is meant to prevent long-ARS, but short-ARS
should be allowed to grab any immediate results.

Fixes: bc6ba8085842 ("nfit, address-range-scrub: rework and simplify ARS...")
Cc: <stable@...>
Reported-by: Erwin Tsaur <erwin.tsaur@...>
Reviewed-by: Toshi Kani <toshi.kani@...>
Signed-off-by: Dan Williams <dan.j.williams@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/acpi/nfit/core.c


[linux:lloyd-aviation] By Dan Williams <dan.j.williams@...>:
2b88d92ea9d2: libnvdimm/label: Clear 'updating' flag after label-set update

commit 966d23a006ca7b44ac8cf4d0c96b19785e0c3da0 upstream.

The UEFI 2.7 specification sets expectations that the 'updating' flag is
eventually cleared. To date, the libnvdimm core has never adhered to
that protocol. The policy of the core matches the policy of other
multi-device info-block formats like MD-Software-RAID that expect
administrator intervention on inconsistent info-blocks, not automatic
invalidation.

However, some pre-boot environments may unfortunately attempt to "clean
up" the labels and invalidate a set when it fails to find at least one
"non-updating" label in the set. Clear the updating flag after set
updates to minimize the window of vulnerability to aggressive pre-boot
environments.

Ideally implementations would not write to the label area outside of
creating namespaces.

Note that this only minimizes the window, it does not close it as the
system can still crash while clearing the flag and the set can be
subsequently deleted / invalidated by the pre-boot environment.

Fixes: f524bf271a5c ("libnvdimm: write pmem label set")
Cc: <stable@...>
Cc: Kelly Couch <kelly.j.couch@...>
Signed-off-by: Dan Williams <dan.j.williams@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/nvdimm/label.c


[linux:lloyd-aviation] By Wei Yang <richardw.yang@...>:
6a89ed7aa140: libnvdimm, pfn: Fix over-trim in trim_pfn_device()

commit f101ada7da6551127d192c2f1742c1e9e0f62799 upstream.

When trying to see whether current nd_region intersects with others,
trim_pfn_device() has already calculated the *size* to be expanded to
SECTION size.

Do not double append 'adjust' to 'size' when calculating whether the end
of a region collides with the next pmem region.

Fixes: ae86cbfef381 "libnvdimm, pfn: Pad pfn namespaces relative to other regions"
Cc: <stable@...>
Signed-off-by: Wei Yang <richardw.yang@...>
Signed-off-by: Dan Williams <dan.j.williams@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/nvdimm/pfn_devs.c


[linux:lloyd-aviation] By Dan Williams <dan.j.williams@...>:
696c37524beb: libnvdimm/pmem: Honor force_raw for legacy pmem regions

commit fa7d2e639cd90442d868dfc6ca1d4cc9d8bf206e upstream.

For recovery, where non-dax access is needed to a given physical address
range, and testing, allow the 'force_raw' attribute to override the
default establishment of a dev_pagemap.

Otherwise without this capability it is possible to end up with a
namespace that can not be activated due to corrupted info-block, and one
that can not be repaired due to a section collision.

Cc: <stable@...>
Fixes: 004f1afbe199 ("libnvdimm, pmem: direct map legacy pmem by default")
Signed-off-by: Dan Williams <dan.j.williams@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/nvdimm/namespace_devs.c


[linux:lloyd-aviation] By Oliver O'Halloran <oohall@...>:
3b8da135a4cc: libnvdimm: Fix altmap reservation size calculation

commit 07464e88365e9236febaca9ed1a2e2006d8bc952 upstream.

Libnvdimm reserves the first 8K of pfn and devicedax namespaces to
store a superblock describing the namespace. This 8K reservation
is contained within the altmap area which the kernel uses for the
vmemmap backing for the pages within the namespace. The altmap
allows for some pages at the start of the altmap area to be reserved
and that mechanism is used to protect the superblock from being
re-used as vmemmap backing.

The number of PFNs to reserve is calculated using:

PHYS_PFN(SZ_8K)

Which is implemented as:

#define PHYS_PFN(x) ((unsigned long)((x) >> PAGE_SHIFT))

So on systems where PAGE_SIZE is greater than 8K the reservation
size is truncated to zero and the superblock area is re-used as
vmemmap backing. As a result all the namespace information stored
in the superblock (i.e. if it's a PFN or DAX namespace) is lost
and the namespace needs to be re-created to get access to the
contents.

This patch fixes this by using PFN_UP() rather than PHYS_PFN() to ensure
that at least one page is reserved. On systems with a 4K pages size this
patch should have no effect.

Cc: stable@...
Cc: Dan Williams <dan.j.williams@...>
Fixes: ac515c084be9 ("libnvdimm, pmem, pfn: move pfn setup to the core")
Signed-off-by: Oliver O'Halloran <oohall@...>
Reviewed-by: Vishal Verma <vishal.l.verma@...>
Signed-off-by: Dan Williams <dan.j.williams@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/nvdimm/pfn_devs.c


[linux:lloyd-aviation] By Al Viro <viro@...>:
7a8b048430c1: fix cgroup_do_mount() handling of failure exits

commit 399504e21a10be16dd1408ba0147367d9d82a10c upstream.

same story as with last May fixes in sysfs (7b745a4e4051
"unfuck sysfs_mount()"); new_sb is left uninitialized
in case of early errors in kernfs_mount_ns() and papering
over it by treating any error from kernfs_mount_ns() as
equivalent to !new_ns ends up conflating the cases when
objects had never been transferred to a superblock with
ones when that has happened and resulting new superblock
had been dropped. Easily fixed (same way as in sysfs
case). Additionally, there's a superblock leak on
kernfs_node_dentry() failure *and* a dentry leak inside
kernfs_node_dentry() itself - the latter on probably
impossible errors, but the former not impossible to trigger
(as the matter of fact, injecting allocation failures
at that point *does* trigger it).

Cc: stable@...
Signed-off-by: Al Viro <viro@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/kernfs/mount.c
Modified: kernel/cgroup/cgroup.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
736807d69157: crypto: aead - set CRYPTO_TFM_NEED_KEY if ->setkey() fails

commit 6ebc97006b196aafa9df0497fdfa866cf26f259b upstream.

Some algorithms have a ->setkey() method that is not atomic, in the
sense that setting a key can fail after changes were already made to the
tfm context. In this case, if a key was already set the tfm can end up
in a state that corresponds to neither the old key nor the new key.

For example, in gcm.c, if the kzalloc() fails due to lack of memory,
then the CTR part of GCM will have the new key but GHASH will not.

It's not feasible to make all ->setkey() methods atomic, especially ones
that have to key multiple sub-tfms. Therefore, make the crypto API set
CRYPTO_TFM_NEED_KEY if ->setkey() fails, to prevent the tfm from being
used until a new key is set.

[Cc stable mainly because when introducing the NEED_KEY flag I changed
AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG
previously didn't have this problem. So these "incompletely keyed"
states became theoretically accessible via AF_ALG -- though, the
opportunities for causing real mischief seem pretty limited.]

Fixes: dc26c17f743a ("crypto: aead - prevent using AEADs without setting key")
Cc: <stable@...> # v4.16+
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/aead.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
4c152af938ce: crypto: aegis - fix handling chunked inputs

commit 0f533e67d26f228ea5dfdacc8a4bdeb487af5208 upstream.

The generic AEGIS implementations all fail the improved AEAD tests
because they produce the wrong result with some data layouts. The issue
is that they assume that if the skcipher_walk API gives 'nbytes' not
aligned to the walksize (a.k.a. walk.stride), then it is the end of the
data. In fact, this can happen before the end. Fix them.

Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD implementations")
Cc: <stable@...> # v4.18+
Cc: Ondrej Mosnacek <omosnace@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Reviewed-by: Ondrej Mosnacek <omosnace@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/aegis128.c
Modified: crypto/aegis128l.c
Modified: crypto/aegis256.c


[linux:lloyd-aviation] By Ard Biesheuvel <ard.biesheuvel@...>:
0beb34b865e3: crypto: arm/crct10dif - revert to C code for short inputs

commit 62fecf295e3c48be1b5f17c440b93875b9adb4d6 upstream.

The SIMD routine ported from x86 used to have a special code path
for inputs < 16 bytes, which got lost somewhere along the way.
Instead, the current glue code aligns the input pointer to permit
the NEON routine to use special versions of the vld1 instructions
that assume 16 byte alignment, but this could result in inputs of
less than 16 bytes to be passed in. This not only fails the new
extended tests that Eric has implemented, it also results in the
code reading past the end of the input, which could potentially
result in crashes when dealing with less than 16 bytes of input
at the end of a page which is followed by an unmapped page.

So update the glue code to only invoke the NEON routine if the
input is at least 16 bytes.

Reported-by: Eric Biggers <ebiggers@...>
Reviewed-by: Eric Biggers <ebiggers@...>
Fixes: 1d481f1cd892 ("crypto: arm/crct10dif - port x86 SSE implementation to ARM")
Cc: <stable@...> # v4.10+
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm/crypto/crct10dif-ce-core.S
Modified: arch/arm/crypto/crct10dif-ce-glue.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
4bca5a9a5dcd: crypto: arm64/aes-neonbs - fix returning final keystream block

commit 12455e320e19e9cc7ad97f4ab89c280fe297387c upstream.

The arm64 NEON bit-sliced implementation of AES-CTR fails the improved
skcipher tests because it sometimes produces the wrong ciphertext. The
bug is that the final keystream block isn't returned from the assembly
code when the number of non-final blocks is zero. This can happen if
the input data ends a few bytes after a page boundary. In this case the
last bytes get "encrypted" by XOR'ing them with uninitialized memory.

Fix the assembly code to return the final keystream block when needed.

Fixes: 88a3f582bea9 ("crypto: arm64/aes - don't use IV buffer to return final keystream block")
Cc: <stable@...> # v4.11+
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm64/crypto/aes-neonbs-core.S


[linux:lloyd-aviation] By Ard Biesheuvel <ard.biesheuvel@...>:
76f21678d64f: crypto: arm64/crct10dif - revert to C code for short inputs

commit d72b9d4acd548251f55b16843fc7a05dc5c80de8 upstream.

The SIMD routine ported from x86 used to have a special code path
for inputs < 16 bytes, which got lost somewhere along the way.
Instead, the current glue code aligns the input pointer to 16 bytes,
which is not really necessary on this architecture (although it
could be beneficial to performance to expose aligned data to the
the NEON routine), but this could result in inputs of less than
16 bytes to be passed in. This not only fails the new extended
tests that Eric has implemented, it also results in the code
reading past the end of the input, which could potentially result
in crashes when dealing with less than 16 bytes of input at the
end of a page which is followed by an unmapped page.

So update the glue code to only invoke the NEON routine if the
input is at least 16 bytes.

Reported-by: Eric Biggers <ebiggers@...>
Reviewed-by: Eric Biggers <ebiggers@...>
Fixes: 6ef5737f3931 ("crypto: arm64/crct10dif - port x86 SSE implementation to arm64")
Cc: <stable@...> # v4.10+
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm64/crypto/crct10dif-ce-glue.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
dc410d2d8405: crypto: hash - set CRYPTO_TFM_NEED_KEY if ->setkey() fails

commit ba7d7433a0e998c902132bd47330e355a1eaa894 upstream.

Some algorithms have a ->setkey() method that is not atomic, in the
sense that setting a key can fail after changes were already made to the
tfm context. In this case, if a key was already set the tfm can end up
in a state that corresponds to neither the old key nor the new key.

It's not feasible to make all ->setkey() methods atomic, especially ones
that have to key multiple sub-tfms. Therefore, make the crypto API set
CRYPTO_TFM_NEED_KEY if ->setkey() fails and the algorithm requires a
key, to prevent the tfm from being used until a new key is set.

Note: we can't set CRYPTO_TFM_NEED_KEY for OPTIONAL_KEY algorithms, so
->setkey() for those must nevertheless be atomic. That's fine for now
since only the crc32 and crc32c algorithms set OPTIONAL_KEY, and it's
not intended that OPTIONAL_KEY be used much.

[Cc stable mainly because when introducing the NEED_KEY flag I changed
AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG
previously didn't have this problem. So these "incompletely keyed"
states became theoretically accessible via AF_ALG -- though, the
opportunities for causing real mischief seem pretty limited.]

Fixes: 9fa68f620041 ("crypto: hash - prevent using keyed hashes without setting key")
Cc: stable@...
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/ahash.c
Modified: crypto/shash.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
c0bfdac6a471: crypto: morus - fix handling chunked inputs

commit d644f1c8746ed24f81075480f9e9cb3777ae8d65 upstream.

The generic MORUS implementations all fail the improved AEAD tests
because they produce the wrong result with some data layouts. The issue
is that they assume that if the skcipher_walk API gives 'nbytes' not
aligned to the walksize (a.k.a. walk.stride), then it is the end of the
data. In fact, this can happen before the end. Fix them.

Fixes: 396be41f16fd ("crypto: morus - Add generic MORUS AEAD implementations")
Cc: <stable@...> # v4.18+
Cc: Ondrej Mosnacek <omosnace@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Reviewed-by: Ondrej Mosnacek <omosnace@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/morus1280.c
Modified: crypto/morus640.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
bb1ae0aadbf1: crypto: pcbc - remove bogus memcpy()s with src == dest

commit 251b7aea34ba3c4d4fdfa9447695642eb8b8b098 upstream.

The memcpy()s in the PCBC implementation use walk->iv as both the source
and destination, which has undefined behavior. These memcpy()'s are
actually unneeded, because walk->iv is already used to hold the previous
plaintext block XOR'd with the previous ciphertext block. Thus,
walk->iv is already updated to its final value.

So remove the broken and unnecessary memcpy()s.

Fixes: 91652be5d1b9 ("[CRYPTO] pcbc: Add Propagated CBC template")
Cc: <stable@...> # v2.6.21+
Cc: David Howells <dhowells@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/pcbc.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
e6c703f15872: crypto: skcipher - set CRYPTO_TFM_NEED_KEY if ->setkey() fails

commit b1f6b4bf416b49f00f3abc49c639371cdecaaad1 upstream.

Some algorithms have a ->setkey() method that is not atomic, in the
sense that setting a key can fail after changes were already made to the
tfm context. In this case, if a key was already set the tfm can end up
in a state that corresponds to neither the old key nor the new key.

For example, in lrw.c, if gf128mul_init_64k_bbe() fails due to lack of
memory, then priv::table will be left NULL. After that, encryption with
that tfm will cause a NULL pointer dereference.

It's not feasible to make all ->setkey() methods atomic, especially ones
that have to key multiple sub-tfms. Therefore, make the crypto API set
CRYPTO_TFM_NEED_KEY if ->setkey() fails and the algorithm requires a
key, to prevent the tfm from being used until a new key is set.

[Cc stable mainly because when introducing the NEED_KEY flag I changed
AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG
previously didn't have this problem. So these "incompletely keyed"
states became theoretically accessible via AF_ALG -- though, the
opportunities for causing real mischief seem pretty limited.]

Fixes: f8d33fac8480 ("crypto: skcipher - prevent using skciphers without setting key")
Cc: <stable@...> # v4.16+
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/skcipher.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
574c19d97e6b: crypto: testmgr - skip crc32c context test for ahash algorithms

commit eb5e6730db98fcc4b51148b4a819fa4bf864ae54 upstream.

Instantiating "cryptd(crc32c)" causes a crypto self-test failure because
the crypto_alloc_shash() in alg_test_crc32c() fails. This is because
cryptd(crc32c) is an ahash algorithm, not a shash algorithm; so it can
only be accessed through the ahash API, unlike shash algorithms which
can be accessed through both the ahash and shash APIs.

As the test is testing the shash descriptor format which is only
applicable to shash algorithms, skip it for ahash algorithms.

(Note that it's still important to fix crypto self-test failures even
for weird algorithm instantiations like cryptd(crc32c) that no one
would really use; in fips_enabled mode unprivileged users can use them
to panic the kernel, and also they prevent treating a crypto self-test
failure as a bug when fuzzing the kernel.)

Fixes: 8e3ee85e68c5 ("crypto: crc32c - Test descriptor context format")
Cc: stable@...
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: crypto/testmgr.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
5d2a5172caa4: crypto: x86/aegis - fix handling chunked inputs and MAY_SLEEP

commit ba6771c0a0bc2fac9d6a8759bab8493bd1cffe3b upstream.

The x86 AEGIS implementations all fail the improved AEAD tests because
they produce the wrong result with some data layouts. The issue is that
they assume that if the skcipher_walk API gives 'nbytes' not aligned to
the walksize (a.k.a. walk.stride), then it is the end of the data. In
fact, this can happen before the end.

Also, when the CRYPTO_TFM_REQ_MAY_SLEEP flag is given, they can
incorrectly sleep in the skcipher_walk_*() functions while preemption
has been disabled by kernel_fpu_begin().

Fix these bugs.

Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations")
Cc: <stable@...> # v4.18+
Cc: Ondrej Mosnacek <omosnace@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Reviewed-by: Ondrej Mosnacek <omosnace@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/crypto/aegis128-aesni-glue.c
Modified: arch/x86/crypto/aegis128l-aesni-glue.c
Modified: arch/x86/crypto/aegis256-aesni-glue.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
8a9fcf4a9f1f: crypto: x86/aesni-gcm - fix crash on empty plaintext

commit 3af349639597fea582a93604734d717e59a0e223 upstream.

gcmaes_crypt_by_sg() dereferences the NULL pointer returned by
scatterwalk_ffwd() when encrypting an empty plaintext and the source
scatterlist ends immediately after the associated data.

Fix it by only fast-forwarding to the src/dst data scatterlists if the
data length is nonzero.

This bug is reproduced by the "rfc4543(gcm(aes))" test vectors when run
with the new AEAD test manager.

Fixes: e845520707f8 ("crypto: aesni - Update aesni-intel_glue to use scatter/gather")
Cc: <stable@...> # v4.17+
Cc: Dave Watson <davejwatson@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/crypto/aesni-intel_glue.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
66700c89f0ab: crypto: x86/morus - fix handling chunked inputs and MAY_SLEEP

commit 2060e284e9595fc3baed6e035903c05b93266555 upstream.

The x86 MORUS implementations all fail the improved AEAD tests because
they produce the wrong result with some data layouts. The issue is that
they assume that if the skcipher_walk API gives 'nbytes' not aligned to
the walksize (a.k.a. walk.stride), then it is the end of the data. In
fact, this can happen before the end.

Also, when the CRYPTO_TFM_REQ_MAY_SLEEP flag is given, they can
incorrectly sleep in the skcipher_walk_*() functions while preemption
has been disabled by kernel_fpu_begin().

Fix these bugs.

Fixes: 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for MORUS")
Cc: <stable@...> # v4.18+
Cc: Ondrej Mosnacek <omosnace@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Reviewed-by: Ondrej Mosnacek <omosnace@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/crypto/morus1280_glue.c
Modified: arch/x86/crypto/morus640_glue.c


[linux:lloyd-aviation] By Ard Biesheuvel <ard.biesheuvel@...>:
d5a5bded80a6: crypto: arm64/aes-ccm - fix logical bug in AAD MAC handling

commit eaf46edf6ea89675bd36245369c8de5063a0272c upstream.

The NEON MAC calculation routine fails to handle the case correctly
where there is some data in the buffer, and the input fills it up
exactly. In this case, we enter the loop at the end with w8 == 0,
while a negative value is assumed, and so the loop carries on until
the increment of the 32-bit counter wraps around, which is quite
obviously wrong.

So omit the loop altogether in this case, and exit right away.

Reported-by: Eric Biggers <ebiggers@...>
Fixes: a3fd82105b9d1 ("arm64/crypto: AES in CCM mode using ARMv8 Crypto ...")
Cc: stable@...
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm64/crypto/aes-ce-ccm-core.S


[linux:lloyd-aviation] By Ard Biesheuvel <ard.biesheuvel@...>:
41e2d1c43c87: crypto: arm64/aes-ccm - fix bugs in non-NEON fallback routine

commit 969e2f59d589c15f6aaf306e590dde16f12ea4b3 upstream.

Commit 5092fcf34908 ("crypto: arm64/aes-ce-ccm: add non-SIMD generic
fallback") introduced C fallback code to replace the NEON routines
when invoked from a context where the NEON is not available (i.e.,
from the context of a softirq taken while the NEON is already being
used in kernel process context)

Fix two logical flaws in the MAC calculation of the associated data.

Reported-by: Eric Biggers <ebiggers@...>
Fixes: 5092fcf34908 ("crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback")
Cc: stable@...
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm64/crypto/aes-ce-ccm-glue.c


[linux:lloyd-aviation] By Pavel Shilovsky <piastryyy@...>:
3ed9f22e28dd: CIFS: Do not reset lease state to NONE on lease break

commit 7b9b9edb49ad377b1e06abf14354c227e9ac4b06 upstream.

Currently on lease break the client sets a caching level twice:
when oplock is detected and when oplock is processed. While the
1st attempt sets the level to the value provided by the server,
the 2nd one resets the level to None unconditionally.
This happens because the oplock/lease processing code was changed
to avoid races between page cache flushes and oplock breaks.
The commit c11f1df5003d534 ("cifs: Wait for writebacks to complete
before attempting write.") fixed the races for oplocks but didn't
apply the same changes for leases resulting in overwriting the
server granted value to None. Fix this by properly processing
lease breaks.

Signed-off-by: Pavel Shilovsky <pshilov@...>
Signed-off-by: Steve French <stfrench@...>
CC: Stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/cifs/smb2misc.c
Modified: fs/cifs/smb2ops.c


[linux:lloyd-aviation] By Pavel Shilovsky <piastryyy@...>:
dc8e8ad962a8: CIFS: Do not skip SMB2 message IDs on send failures

commit c781af7e0c1fed9f1d0e0ec31b86f5b21a8dca17 upstream.

When we hit failures during constructing MIDs or sending PDUs
through the network, we end up not using message IDs assigned
to the packet. The next SMB packet will skip those message IDs
and continue with the next one. This behavior may lead to a server
not granting us credits until we use the skipped IDs. Fix this by
reverting the current ID to the original value if any errors occur
before we push the packet through the network stack.

This patch fixes the generic/310 test from the xfs-tests.

Cc: <stable@...> # 4.19.x
Signed-off-by: Pavel Shilovsky <pshilov@...>
Signed-off-by: Steve French <stfrench@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/cifs/cifsglob.h
Modified: fs/cifs/smb2ops.c
Modified: fs/cifs/smb2transport.c
Modified: fs/cifs/transport.c


[linux:lloyd-aviation] By Pavel Shilovsky <piastryyy@...>:
43eaa6cc1775: CIFS: Fix read after write for files with read caching

commit 6dfbd84684700cb58b34e8602c01c12f3d2595c8 upstream.

When we have a READ lease for a file and have just issued a write
operation to the server we need to purge the cache and set oplock/lease
level to NONE to avoid reading stale data. Currently we do that
only if a write operation succedeed thus not covering cases when
a request was sent to the server but a negative error code was
returned later for some other reasons (e.g. -EIOCBQUEUED or -EINTR).
Fix this by turning off caching regardless of the error code being
returned.

The patches fixes generic tests 075 and 112 from the xfs-tests.

Cc: <stable@...>
Signed-off-by: Pavel Shilovsky <pshilov@...>
Signed-off-by: Steve French <stfrench@...>
Reviewed-by: Ronnie Sahlberg <lsahlber@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/cifs/file.c


[linux:lloyd-aviation] By Tom Zanussi <tom.zanussi@...>:
ebca08d7e862: tracing: Use strncpy instead of memcpy for string keys in hist triggers

commit 9f0bbf3115ca9f91f43b7c74e9ac7d79f47fc6c2 upstream.

Because there may be random garbage beyond a string's null terminator,
it's not correct to copy the the complete character array for use as a
hist trigger key. This results in multiple histogram entries for the
'same' string key.

So, in the case of a string key, use strncpy instead of memcpy to
avoid copying in the extra bytes.

Before, using the gdbus entries in the following hist trigger as an
example:

# echo 'hist:key=comm' > /sys/kernel/debug/tracing/events/sched/sched_waking/trigger
# cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist

...

{ comm: ImgDecoder #4 } hitcount: 203
{ comm: gmain } hitcount: 213
{ comm: gmain } hitcount: 216
{ comm: StreamTrans #73 } hitcount: 221
{ comm: mozStorage #3 } hitcount: 230
{ comm: gdbus } hitcount: 233
{ comm: StyleThread#5 } hitcount: 253
{ comm: gdbus } hitcount: 256
{ comm: gdbus } hitcount: 260
{ comm: StyleThread#4 } hitcount: 271

...

# cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist | egrep gdbus | wc -l
51

After:

# cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist | egrep gdbus | wc -l
1

Link: http://lkml.kernel.org/r/50c35ae1267d64eee975b8125e151e600071d4dc.1549309756.git.tom.zanussi@...

Cc: Namhyung Kim <namhyung@...>
Cc: stable@...
Fixes: 79e577cbce4c4 ("tracing: Support string type key properly")
Signed-off-by: Tom Zanussi <tom.zanussi@...>
Signed-off-by: Steven Rostedt (VMware) <rostedt@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/trace/trace_events_hist.c


[linux:lloyd-aviation] By zhangyi (F) <yi.zhang@...>:
f27077e5f5c5: tracing: Do not free iter->trace in fail path of tracing_open_pipe()

commit e7f0c424d0806b05d6f47be9f202b037eb701707 upstream.

Commit d716ff71dd12 ("tracing: Remove taking of trace_types_lock in
pipe files") use the current tracer instead of the copy in
tracing_open_pipe(), but it forget to remove the freeing sentence in
the error path.

There's an error path that can call kfree(iter->trace) after the iter->trace
was assigned to tr->current_trace, which would be bad to free.

Link: http://lkml.kernel.org/r/1550060946-45984-1-git-send-email-yi.zhang@...

Cc: stable@...
Fixes: d716ff71dd12 ("tracing: Remove taking of trace_types_lock in pipe files")
Signed-off-by: zhangyi (F) <yi.zhang@...>
Signed-off-by: Steven Rostedt (VMware) <rostedt@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/trace/trace.c


[linux:lloyd-aviation] By Jann Horn <jannh@...>:
24d5097655eb: tracing/perf: Use strndup_user() instead of buggy open-coded version

commit 83540fbc8812a580b6ad8f93f4c29e62e417687e upstream.

The first version of this method was missing the check for
`ret == PATH_MAX`; then such a check was added, but it didn't call kfree()
on error, so there was still a small memory leak in the error case.
Fix it by using strndup_user() instead of open-coding it.

Link: http://lkml.kernel.org/r/20190220165443.152385-1-jannh@...

Cc: Ingo Molnar <mingo@...>
Cc: stable@...
Fixes: 0eadcc7a7bc0 ("perf/core: Fix perf_uprobe_init()")
Reviewed-by: Masami Hiramatsu <mhiramat@...>
Acked-by: Song Liu <songliubraving@...>
Signed-off-by: Jann Horn <jannh@...>
Signed-off-by: Steven Rostedt (VMware) <rostedt@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/trace/trace_event_perf.c


[linux:lloyd-aviation] By Juergen Gross <jgross@...>:
468ff43f6274: xen: fix dom0 boot on huge systems

commit 01bd2ac2f55a1916d81dace12fa8d7ae1c79b5ea upstream.

Commit f7c90c2aa40048 ("x86/xen: don't write ptes directly in 32-bit
PV guests") introduced a regression for booting dom0 on huge systems
with lots of RAM (in the TB range).

Reason is that on those hosts the p2m list needs to be moved early in
the boot process and this requires temporary page tables to be created.
Said commit modified xen_set_pte_init() to use a hypercall for writing
a PTE, but this requires the page table being in the direct mapped
area, which is not the case for the temporary page tables used in
xen_relocate_p2m().

As the page tables are completely written before being linked to the
actual address space instead of set_pte() a plain write to memory can
be used in xen_relocate_p2m().

Fixes: f7c90c2aa40048 ("x86/xen: don't write ptes directly in 32-bit PV guests")
Cc: stable@...
Signed-off-by: Juergen Gross <jgross@...>
Reviewed-by: Jan Beulich <jbeulich@...>
Signed-off-by: Juergen Gross <jgross@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/xen/mmu_pv.c


[linux:lloyd-aviation] By Andy Shevchenko <andriy.shevchenko@...>:
c19b9673487e: ACPI / device_sysfs: Avoid OF modalias creation for removed device

commit f16eb8a4b096514ac06fb25bf599dcc792899b3d upstream.

If SSDT overlay is loaded via ConfigFS and then unloaded the device,
we would like to have OF modalias for, already gone. Thus, acpi_get_name()
returns no allocated buffer for such case and kernel crashes afterwards:

ACPI: Host-directed Dynamic ACPI Table Unload
ads7950 spi-PRP0001:00: Dropping the link to regulator.0
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
#PF error: [normal kernel read fault]
PGD 80000000070d6067 P4D 80000000070d6067 PUD 70d0067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 40 Comm: kworker/u4:2 Not tainted 5.0.0+ #96
Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
Workqueue: kacpi_hotplug acpi_device_del_work_fn
RIP: 0010:create_of_modalias.isra.1+0x4c/0x150
Code: 00 00 48 89 44 24 18 31 c0 48 8d 54 24 08 48 c7 44 24 10 00 00 00 00 48 c7 44 24 08 ff ff ff ff e8 7a b0 03 00 48 8b 4c 24 10 <0f> b6 01 84 c0 74 27 48 c7 c7 00 09 f4 a5 0f b6 f0 8d 50 20 f6 04
RSP: 0000:ffffa51040297c10 EFLAGS: 00010246
RAX: 0000000000001001 RBX: 0000000000000785 RCX: 0000000000000000
RDX: 0000000000001001 RSI: 0000000000000286 RDI: ffffa2163dc042e0
RBP: ffffa216062b1196 R08: 0000000000001001 R09: ffffa21639873000
R10: ffffffffa606761d R11: 0000000000000001 R12: ffffa21639873218
R13: ffffa2163deb5060 R14: ffffa216063d1010 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa2163e000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000007114000 CR4: 00000000001006f0
Call Trace:
__acpi_device_uevent_modalias+0xb0/0x100
spi_uevent+0xd/0x40

...

In order to fix above let create_of_modalias() check the status returned
by acpi_get_name() and bail out in case of failure.

Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201381
Reported-by: Ferry Toth <fntoth@...>
Tested-by: Ferry Toth<fntoth@...>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@...>
Reviewed-by: Mika Westerberg <mika.westerberg@...>
Cc: 4.1+ <stable@...> # 4.1+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/acpi/device_sysfs.c


[linux:lloyd-aviation] By BOUGH CHEN <haibo.chen@...>:
2946910ed837: mmc: sdhci-esdhc-imx: fix HS400 timing issue

commit de0a0decf2edfc5b0c782915f4120cf990a9bd13 upstream.

Now tuning reset will be done when the timing is MMC_TIMING_LEGACY/
MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS. But for timing MMC_TIMING_MMC_HS,
we can not do tuning reset, otherwise HS400 timing is not right.

Here is the process of init HS400, first finish tuning in HS200 mode,
then switch to HS mode and 8 bit DDR mode, finally switch to HS400
mode. If we do tuning reset in HS mode, this will cause HS400 mode
lost the tuning setting, which will cause CRC error.

Signed-off-by: Haibo Chen <haibo.chen@...>
Cc: stable@... # v4.12+
Acked-by: Adrian Hunter <adrian.hunter@...>
Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card")
Signed-off-by: Ulf Hansson <ulf.hansson@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/mmc/host/sdhci-esdhc-imx.c


[linux:lloyd-aviation] By Jiong Wu <lohengrin1024@...>:
6bd9959aa110: mmc:fix a bug when max_discard is 0

commit d4721339dcca7def04909a8e60da43c19a24d8bf upstream.

The original purpose of the code I fix is to replace max_discard with
max_trim if max_trim is less than max_discard. When max_discard is 0
we should replace max_discard with max_trim as well, because
max_discard equals 0 happens only when the max_do_calc_max_discard
process is overflowed, so if mmc_can_trim(card) is true, max_discard
should be replaced by an available max_trim.
However, in the original code, there are two lines of code interfere
the right process.
1) if (max_discard && mmc_can_trim(card))
when max_discard is 0, it skips the process checking if max_discard
needs to be replaced with max_trim.
2) if (max_trim < max_discard)
the condition is false when max_discard is 0. it also skips the process
that replaces max_discard with max_trim, in fact, we should replace the
0-valued max_discard with max_trim.

Signed-off-by: Jiong Wu <Lohengrin1024@...>
Fixes: b305882fbc87 (mmc: core: optimize mmc_calc_max_discard)
Cc: stable@... # v4.17+
Signed-off-by: Ulf Hansson <ulf.hansson@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/mmc/core/core.c


[linux:lloyd-aviation] By Anders Roxell <anders.roxell@...>:
0d98ecb141a6: netfilter: ipt_CLUSTERIP: fix warning unused variable cn

commit 206b8cc514d7ff2b79dd2d5ad939adc7c493f07a upstream.

When CONFIG_PROC_FS isn't set the variable cn isn't used.

net/ipv4/netfilter/ipt_CLUSTERIP.c: In function ‘clusterip_net_exit’:
net/ipv4/netfilter/ipt_CLUSTERIP.c:849:24: warning: unused variable ‘cn’ [-Wunused-variable]
struct clusterip_net *cn = clusterip_pernet(net);
^~

Rework so the variable 'cn' is declared inside "#ifdef CONFIG_PROC_FS".

Fixes: b12f7bad5ad3 ("netfilter: ipt_CLUSTERIP: remove wrong WARN_ON_ONCE in netns exit routine")
Signed-off-by: Anders Roxell <anders.roxell@...>
Signed-off-by: Pablo Neira Ayuso <pablo@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/ipv4/netfilter/ipt_CLUSTERIP.c


[linux:lloyd-aviation] By Vignesh R <vigneshr@...>:
e51c5ec99597: spi: ti-qspi: Fix mmap read when more than one CS in use

commit 673c865efbdc5fec3cc525c46d71844d42c60072 upstream.

Commit 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") has
has got order of parameter wrong when calling regmap_update_bits() to
select CS for mmap access. Mask and value arguments are interchanged.
Code will work on a system with single slave, but fails when more than
one CS is in use. Fix this by correcting the order of parameters when
calling regmap_update_bits().

Fixes: 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support")
Cc: stable@...
Signed-off-by: Vignesh R <vigneshr@...>
Signed-off-by: Mark Brown <broonie@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/spi/spi-ti-qspi.c


[linux:lloyd-aviation] By Andy Shevchenko <andriy.shevchenko@...>:
15ead7e2a11e: spi: pxa2xx: Setup maximum supported DMA transfer length

commit ef070b4e4aa25bb5f8632ad196644026c11903bf upstream.

When the commit b6ced294fb61

("spi: pxa2xx: Switch to SPI core DMA mapping functionality")

switches to SPI core provided DMA helpers, it missed to setup maximum
supported DMA transfer length for the controller and thus users
mistakenly try to send more data than supported with the following
warning:

ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536

Setup maximum supported DMA transfer length in order to make users know
the limit.

Fixes: b6ced294fb61 ("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@...>
Signed-off-by: Mark Brown <broonie@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/spi/spi-pxa2xx.c


[linux:lloyd-aviation] By Krzysztof Kozlowski <krzk@...>:
462aee48a8a2: regulator: s2mps11: Fix steps for buck7, buck8 and LDO35

commit 56b5d4ea778c1b0989c5cdb5406d4a488144c416 upstream.

LDO35 uses 25 mV step, not 50 mV. Bucks 7 and 8 use 12.5 mV step
instead of 6.25 mV. Wrong step caused over-voltage (LDO35) or
under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420
Arndale Octa board).

Cc: <stable@...>
Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver")
Signed-off-by: Krzysztof Kozlowski <krzk@...>
Signed-off-by: Mark Brown <broonie@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/regulator/s2mps11.c


[linux:lloyd-aviation] By Mark Zhang <markz@...>:
c288e34df128: regulator: max77620: Initialize values for DT properties

commit 0ab66b3c326ef8f77dae9f528118966365757c0c upstream.

If regulator DT node doesn't exist, its of_parse_cb callback
function isn't called. Then all values for DT properties are
filled with zero. This leads to wrong register update for
FPS and POK settings.

Signed-off-by: Jinyoung Park <jinyoungp@...>
Signed-off-by: Mark Zhang <markz@...>
Signed-off-by: Mark Brown <broonie@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/regulator/max77620-regulator.c


[linux:lloyd-aviation] By Stuart Menefy <stuart.menefy@...>:
06607b1b6cc9: regulator: s2mpa01: Fix step values for some LDOs

commit 28c4f730d2a44f2591cb104091da29a38dac49fe upstream.

The step values for some of the LDOs appears to be incorrect, resulting
in incorrect voltages (or at least, ones which are different from the
Samsung 3.4 vendor kernel).

Signed-off-by: Stuart Menefy <stuart.menefy@...>
Reviewed-by: Krzysztof Kozlowski <krzk@...>
Signed-off-by: Mark Brown <broonie@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/regulator/s2mpa01.c


[linux:lloyd-aviation] By Stuart Menefy <stuart.menefy@...>:
c1f45c10df2e: clocksource/drivers/exynos_mct: Move one-shot check from tick clear to ISR

commit a5719a40aef956ba704f2aa1c7b977224d60fa96 upstream.

When a timer tick occurs and the clock is in one-shot mode, the timer
needs to be stopped to prevent it triggering subsequent interrupts.
Currently this code is in exynos4_mct_tick_clear(), but as it is
only needed when an ISR occurs move it into exynos4_mct_tick_isr(),
leaving exynos4_mct_tick_clear() just doing what its name suggests it
should.

Signed-off-by: Stuart Menefy <stuart.menefy@...>
Reviewed-by: Krzysztof Kozlowski <krzk@...>
Tested-by: Marek Szyprowski <m.szyprowski@...>
Cc: stable@... # v4.3+
Signed-off-by: Daniel Lezcano <daniel.lezcano@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/clocksource/exynos_mct.c


[linux:lloyd-aviation] By Stuart Menefy <stuart.menefy@...>:
ef8062e20614: clocksource/drivers/exynos_mct: Clear timer interrupt when shutdown

commit d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c upstream.

When shutting down the timer, ensure that after we have stopped the
timer any pending interrupts are cleared. This fixes a problem when
suspending, as interrupts are disabled before the timer is stopped,
so the timer interrupt may still be asserted, preventing the system
entering a low power state when the wfi is executed.

Signed-off-by: Stuart Menefy <stuart.menefy@...>
Reviewed-by: Krzysztof Kozlowski <krzk@...>
Tested-by: Marek Szyprowski <m.szyprowski@...>
Cc: <stable@...> # v4.3+
Signed-off-by: Daniel Lezcano <daniel.lezcano@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/clocksource/exynos_mct.c


[linux:lloyd-aviation] By Samuel Holland <samuel@...>:
e19ca3fe6cf2: clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability

commit c950ca8c35eeb32224a63adc47e12f9e226da241 upstream.

The Allwinner A64 SoC is known[1] to have an unstable architectural
timer, which manifests itself most obviously in the time jumping forward
a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
timer frequency of 24 MHz, implying that the time went slightly backward
(and this was interpreted by the kernel as it jumping forward and
wrapping around past the epoch).

Investigation revealed instability in the low bits of CNTVCT at the
point a high bit rolls over. This leads to power-of-two cycle forward
and backward jumps. (Testing shows that forward jumps are about twice as
likely as backward jumps.) Since the counter value returns to normal
after an indeterminate read, each "jump" really consists of both a
forward and backward jump from the software perspective.

Unless the kernel is trapping CNTVCT reads, a userspace program is able
to read the register in a loop faster than it changes. A test program
running on all 4 CPU cores that reported jumps larger than 100 ms was
run for 13.6 hours and reported the following:

Count | Event
-------+---------------------------
9940 | jumped backward 699ms
268 | jumped backward 1398ms
1 | jumped backward 2097ms
16020 | jumped forward 175ms
6443 | jumped forward 699ms
2976 | jumped forward 1398ms
9 | jumped forward 356516ms
9 | jumped forward 357215ms
4 | jumped forward 714430ms
1 | jumped forward 3578440ms

This works out to a jump larger than 100 ms about every 5.5 seconds on
each CPU core.

The largest jump (almost an hour!) was the following sequence of reads:
0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000

Note that the middle bits don't necessarily all read as all zeroes or
all ones during the anomalous behavior; however the low 10 bits checked
by the function in this patch have never been observed with any other
value.

Also note that smaller jumps are much more common, with backward jumps
of 2048 (2^11) cycles observed over 400 times per second on each core.
(Of course, this is partially explained by lower bits rolling over more
frequently.) Any one of these could have caused the 95 year time skip.

Similar anomalies were observed while reading CNTPCT (after patching the
kernel to allow reads from userspace). However, the CNTPCT jumps are
much less frequent, and only small jumps were observed. The same program
as before (except now reading CNTPCT) observed after 72 hours:

Count | Event
-------+---------------------------
17 | jumped backward 699ms
52 | jumped forward 175ms
2831 | jumped forward 699ms
5 | jumped forward 1398ms

Further investigation showed that the instability in CNTPCT/CNTVCT also
affected the respective timer's TVAL register. The following values were
observed immediately after writing CNVT_TVAL to 0x10000000:

CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000
0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000
0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000
0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000

The pattern of errors in CNTV_TVAL seemed to depend on exactly which
value was written to it. For example, after writing 0x10101010:

CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000
0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000
0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000
0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000
0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000
0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000

I was also twice able to reproduce the issue covered by Allwinner's
workaround[4], that writing to TVAL sometimes fails, and both CVAL and
TVAL are left with entirely bogus values. One was the following values:

CNTVCT | CNTV_TVAL | CNTV_CVAL
--------------------+------------+--------------------------------------
0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past)
Reviewed-by: Marc Zyngier <marc.zyngier@...>

========================================================================

Because the CPU can read the CNTPCT/CNTVCT registers faster than they
change, performing two reads of the register and comparing the high bits
(like other workarounds) is not a workable solution. And because the
timer can jump both forward and backward, no pair of reads can
distinguish a good value from a bad one. The only way to guarantee a
good value from consecutive reads would be to read _three_ times, and
take the middle value only if the three values are 1) each unique and
2) increasing. This takes at minimum 3 counter cycles (125 ns), or more
if an anomaly is detected.

However, since there is a distinct pattern to the bad values, we can
optimize the common case (1022/1024 of the time) to a single read by
simply ignoring values that match the error pattern. This still takes no
more than 3 cycles in the worst case, and requires much less code. As an
additional safety check, we still limit the loop iteration to the number
of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.

For the TVAL registers, the simple solution is to not use them. Instead,
read or write the CVAL and calculate the TVAL value in software.

Although the manufacturer is aware of at least part of the erratum[4],
there is no official name for it. For now, use the kernel-internal name
"UNKNOWN1".

[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
[4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272

Acked-by: Maxime Ripard <maxime.ripard@...>
Tested-by: Andre Przywara <andre.przywara@...>
Signed-off-by: Samuel Holland <samuel@...>
Cc: stable@...
Signed-off-by: Daniel Lezcano <daniel.lezcano@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: Documentation/arm64/silicon-errata.txt
Modified: drivers/clocksource/Kconfig
Modified: drivers/clocksource/arm_arch_timer.c


[linux:lloyd-aviation] By Martin Schwidefsky <schwidefsky@...>:
b52bdf53130a: s390/setup: fix early warning messages

commit 8727638426b0aea59d7f904ad8ddf483f9234f88 upstream.

The setup_lowcore() function creates a new prefix page for the boot CPU.
The PSW mask for the system_call, external interrupt, i/o interrupt and
the program check handler have the DAT bit set in this new prefix page.

At the time setup_lowcore is called the system still runs without virtual
address translation, the paging_init() function creates the kernel page
table and loads the CR13 with the kernel ASCE.

Any code between setup_lowcore() and the end of paging_init() that has
a BUG or WARN statement will create a program check that can not be
handled correctly as there is no kernel page table yet.

To allow early WARN statements initially setup the lowcore with DAT off
and set the DAT bit only after paging_init() has completed.

Cc: stable@...
Signed-off-by: Martin Schwidefsky <schwidefsky@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/s390/kernel/setup.c


[linux:lloyd-aviation] By Halil Pasic <pasic@...>:
1653307cf0e7: s390/virtio: handle find on invalid queue gracefully

commit 3438b2c039b4bf26881786a1f3450f016d66ad11 upstream.

A queue with a capacity of zero is clearly not a valid virtio queue.
Some emulators report zero queue size if queried with an invalid queue
index. Instead of crashing in this case let us just return -ENOENT. To
make that work properly, let us fix the notifier cleanup logic as well.

Cc: stable@...
Signed-off-by: Halil Pasic <pasic@...>
Signed-off-by: Cornelia Huck <cohuck@...>
Signed-off-by: Michael S. Tsirkin <mst@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/s390/virtio/virtio_ccw.c


[linux:lloyd-aviation] By Felipe Franciosi <felipe@...>:
bd8a0e656935: scsi: virtio_scsi: don't send sc payload with tmfs

commit 3722e6a52174d7c3a00e6f5efd006ca093f346c1 upstream.

The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of
device-readable records and a single device-writable response entry:

struct virtio_scsi_ctrl_tmf
{
// Device-readable part
le32 type;
le32 subtype;
u8 lun[8];
le64 id;
// Device-writable part
u8 response;
}

The above should be organised as two descriptor entries (or potentially
more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64
id" or after "u8 response".

The Linux driver doesn't respect that, with virtscsi_abort() and
virtscsi_device_reset() setting cmd->sc before calling virtscsi_tmf(). It
results in the original scsi command payload (or writable buffers) added to
the tmf.

This fixes the problem by leaving cmd->sc zeroed out, which makes
virtscsi_kick_cmd() add the tmf to the control vq without any payload.

Cc: stable@...
Signed-off-by: Felipe Franciosi <felipe@...>
Reviewed-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/scsi/virtio_scsi.c


[linux:lloyd-aviation] By Sagar Biradar <sagar.biradar@...>:
e6e738e2b5ff: scsi: aacraid: Fix performance issue on logical drives

commit 0015437cc046e5ec2b57b00ff8312b8d432eac7c upstream.

Fix performance issue where the queue depth for SmartIOC logical volumes is
set to 1, and allow the usual logical volume code to be executed

Fixes: a052865fe287 (aacraid: Set correct Queue Depth for HBA1000 RAW disks)
Cc: stable@...
Signed-off-by: Sagar Biradar <Sagar.Biradar@...>
Reviewed-by: Dave Carroll <david.carroll@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/scsi/aacraid/linit.c


[linux:lloyd-aviation] By Martin K. Petersen <martin.petersen@...>:
852a4ab292bb: scsi: sd: Optimal I/O size should be a multiple of physical block size

commit a83da8a4509d3ebfe03bb7fffce022e4d5d4764f upstream.

It was reported that some devices report an OPTIMAL TRANSFER LENGTH of
0xFFFF blocks. That looks bogus, especially for a device with a
4096-byte physical block size.

Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's
reported physical block size.

To make the sanity checking conditionals more readable--and to
facilitate printing warnings--relocate the checking to a helper
function. No functional change aside from the printks.

Cc: <stable@...>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759
Reported-by: Christoph Anton Mitterer <calestyo@...>
Reviewed-by: Christoph Hellwig <hch@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/scsi/sd.c


[linux:lloyd-aviation] By Bart Van Assche <bvanassche@...>:
f4a9fd5652d5: scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock

commit 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 upstream.

When using SCSI passthrough in combination with the iSCSI target driver
then cmd->t_state_lock may be obtained from interrupt context. Hence, all
code that obtains cmd->t_state_lock from thread context must disable
interrupts first. This patch avoids that lockdep reports the following:

WARNING: inconsistent lock state
4.18.0-dbg+ #1 Not tainted
--------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
iscsi_ttx/1800 [HC1[1]:SC0[2]:HE0:SE0] takes:
000000006e7b0ceb (&(&cmd->t_state_lock)->rlock){?...}, at: target_complete_cmd+0x47/0x2c0 [target_core_mod]
{HARDIRQ-ON-W} state was registered at:
lock_acquire+0xd2/0x260
_raw_spin_lock+0x32/0x50
iscsit_close_connection+0x97e/0x1020 [iscsi_target_mod]
iscsit_take_action_for_connection_exit+0x108/0x200 [iscsi_target_mod]
iscsi_target_rx_thread+0x180/0x190 [iscsi_target_mod]
kthread+0x1cf/0x1f0
ret_from_fork+0x24/0x30
irq event stamp: 1281
hardirqs last enabled at (1279): [<ffffffff970ade79>] __local_bh_enable_ip+0xa9/0x160
hardirqs last disabled at (1281): [<ffffffff97a008a5>] interrupt_entry+0xb5/0xd0
softirqs last enabled at (1278): [<ffffffff977cd9a1>] lock_sock_nested+0x51/0xc0
softirqs last disabled at (1280): [<ffffffffc07a6e04>] ip6_finish_output2+0x124/0xe40 [ipv6]

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0
----
lock(&(&cmd->t_state_lock)->rlock);
<Interrupt>
lock(&(&cmd->t_state_lock)->rlock);

Modified: drivers/target/iscsi/iscsi_target.c


[linux:lloyd-aviation] By Himanshu Madhani <hmadhani@...>:
d8ae662b400f: scsi: qla2xxx: Fix LUN discovery if loop id is not assigned yet by firmware

commit ec322937a7f152d68755dc8316523bf6f831b48f upstream.

This patch fixes LUN discovery when loop ID is not yet assigned by the
firmware during driver load/sg_reset operations. Driver will now search for
new loop id before retrying login.

Fixes: 48acad099074 ("scsi: qla2xxx: Fix N2N link re-connect")
Cc: stable@... #4.19
Signed-off-by: Himanshu Madhani <hmadhani@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/scsi/qla2xxx/qla_init.c


[linux:lloyd-aviation] By Varad Gautam <vrd@...>:
1c2123ff4312: fs/devpts: always delete dcache dentry-s in dput()

commit 73052b0daee0b750b39af18460dfec683e4f5887 upstream.

d_delete only unhashes an entry if it is reached with
dentry->d_lockref.count != 1. Prior to commit 8ead9dd54716 ("devpts:
more pty driver interface cleanups"), d_delete was called on a dentry
from devpts_pty_kill with two references held, which would trigger the
unhashing, and the subsequent dputs would release it.

Commit 8ead9dd54716 reworked devpts_pty_kill to stop acquiring the second
reference from d_find_alias, and the d_delete call left the dentries
still on the hashed list without actually ever being dropped from dcache
before explicit cleanup. This causes the number of negative dentries for
devpts to pile up, and an `ls /dev/pts` invocation can take seconds to
return.

Provide always_delete_dentry() from simple_dentry_operations
as .d_delete for devpts, to make the dentry be dropped from dcache.

Without this cleanup, the number of dentries in /dev/pts/ can be grown
arbitrarily as:

`python -c 'import pty; pty.spawn(["ls", "/dev/pts"])'`

A systemtap probe on dcache_readdir to count d_subdirs shows this count
to increase with each pty spawn invocation above:

probe kernel.function("dcache_readdir") {
subdirs = &@cast($file->f_path->dentry, "dentry")->d_subdirs;
p = subdirs;
p = @cast(p, "list_head")->next;
i = 0
while (p != subdirs) {
p = @cast(p, "list_head")->next;
i = i+1;
}
printf("number of dentries: %d\n", i);
}

Fixes: 8ead9dd54716 ("devpts: more pty driver interface cleanups")
Signed-off-by: Varad Gautam <vrd@...>
Reported-by: Zheng Wang <wanz@...>
Reported-by: Brandon Schwartz <bsschwar@...>
Root-caused-by: Maximilian Heyne <mheyne@...>
Root-caused-by: Nicolas Pernas Maradei <npernas@...>
CC: David Woodhouse <dwmw@...>
CC: Maximilian Heyne <mheyne@...>
CC: Stefan Nuernberger <snu@...>
CC: Amit Shah <aams@...>
CC: Linus Torvalds <torvalds@...>
CC: Greg Kroah-Hartman <gregkh@...>
CC: Al Viro <viro@...>
CC: Christian Brauner <christian.brauner@...>
CC: Eric W. Biederman <ebiederm@...>
CC: Matthew Wilcox <willy@...>
CC: Eric Biggers <ebiggers@...>
CC: <stable@...> # 4.9+
Signed-off-by: Al Viro <viro@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/devpts/inode.c


[linux:lloyd-aviation] By Jann Horn <jannh@...>:
2af926fd52fc: splice: don't merge into linked buffers

commit a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 upstream.

Before this patch, it was possible for two pipes to affect each other after
data had been transferred between them with tee():

============
$ cat tee_test.c

int main(void) {
int pipe_a[2];
if (pipe(pipe_a)) err(1, "pipe");
int pipe_b[2];
if (pipe(pipe_b)) err(1, "pipe");
if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write");
if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee");
if (write(pipe_b[1], "xx", 2) != 2) err(1, "write");

char buf[5];
if (read(pipe_a[0], buf, 4) != 4) err(1, "read");
buf[4] = 0;
printf("got back: '%s'\n", buf);
}
$ gcc -o tee_test tee_test.c
$ ./tee_test
got back: 'abxx'
$
============

As suggested by Al Viro, fix it by creating a separate type for
non-mergeable pipe buffers, then changing the types of buffers in
splice_pipe_to_pipe() and link_pipe().

Cc: <stable@...>
Fixes: 7c77f0b3f920 ("splice: implement pipe to pipe splicing")
Fixes: 70524490ee2e ("[PATCH] splice: add support for sys_tee()")
Suggested-by: Al Viro <viro@...>
Signed-off-by: Jann Horn <jannh@...>
Signed-off-by: Al Viro <viro@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/pipe.c
Modified: fs/splice.c
Modified: include/linux/pipe_fs_i.h


[linux:lloyd-aviation] By Vivek Goyal <vgoyal@...>:
6f048ae2d25f: ovl: During copy up, first copy up data and then xattrs

commit 5f32879ea35523b9842bdbdc0065e13635caada2 upstream.

If a file with capability set (and hence security.capability xattr) is
written kernel clears security.capability xattr. For overlay, during file
copy up if xattrs are copied up first and then data is, copied up. This
means data copy up will result in clearing of security.capability xattr
file on lower has. And this can result into surprises. If a lower file has
CAP_SETUID, then it should not be cleared over copy up (if nothing was
actually written to file).

This also creates problems with chown logic where it first copies up file
and then tries to clear setuid bit. But by that time security.capability
xattr is already gone (due to data copy up), and caller gets -ENODATA.
This has been reported by Giuseppe here.

https://github.com/containers/libpod/issues/2015#issuecomment-447824842

Fix this by copying up data first and then metadta. This is a regression
which has been introduced by my commit as part of metadata only copy up
patches.

TODO: There will be some corner cases where a file is copied up metadata
only and later data copy up happens and that will clear security.capability
xattr. Something needs to be done about that too.

Fixes: bd64e57586d3 ("ovl: During copy up, first copy up metadata and then data")
Cc: <stable@...> # v4.19+
Reported-by: Giuseppe Scrivano <gscrivan@...>
Signed-off-by: Vivek Goyal <vgoyal@...>
Signed-off-by: Miklos Szeredi <mszeredi@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/overlayfs/copy_up.c


[linux:lloyd-aviation] By Vivek Goyal <vgoyal@...>:
205f149f1a35: ovl: Do not lose security.capability xattr over metadata file copy-up

commit 993a0b2aec52754f0897b1dab4c453be8217cae5 upstream.

If a file has been copied up metadata only, and later data is copied up,
upper loses any security.capability xattr it has (underlying filesystem
clears it as upon file write).

From a user's point of view, this is just a file copy-up and that should
not result in losing security.capability xattr. Hence, before data copy
up, save security.capability xattr (if any) and restore it on upper after
data copy up is complete.

Signed-off-by: Vivek Goyal <vgoyal@...>
Reviewed-by: Amir Goldstein <amir73il@...>
Fixes: 0c2888749363 ("ovl: A new xattr OVL_XATTR_METACOPY for file on upper")
Cc: <stable@...> # v4.19+
Signed-off-by: Miklos Szeredi <mszeredi@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/overlayfs/copy_up.c
Modified: fs/overlayfs/overlayfs.h
Modified: fs/overlayfs/util.c


[linux:lloyd-aviation] By Finn Thain <fthain@...>:
fcbf12e23d99: m68k: Add -ffreestanding to CFLAGS

commit 28713169d879b67be2ef2f84dcf54905de238294 upstream.

This patch fixes a build failure when using GCC 8.1:

/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock':
block/partitions/ldm.c:153: undefined reference to `strcmp'

This is caused by a new optimization which effectively replaces a
strncmp() call with a strcmp() call. This affects a number of strncmp()
call sites in the kernel.

The entire class of optimizations is avoided with -fno-builtin, which
gets enabled by -ffreestanding. This may avoid possible future build
failures in case new optimizations appear in future compilers.

I haven't done any performance measurements with this patch but I did
count the function calls in a defconfig build. For example, there are now
23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the
other libc functions is smaller.

If this harms performance we can tackle that regression by optimizing
the call sites, ideally using semantic patches. That way, clang and ICC
builds might benfit too.

Cc: stable@...
Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2
Signed-off-by: Finn Thain <fthain@...>
Signed-off-by: Geert Uytterhoeven <geert@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/m68k/Makefile


[linux:lloyd-aviation] By Filipe Manana <fdmanana@...>:
61f9209676e8: Btrfs: setup a nofs context for memory allocation at btrfs_create_tree()

commit b89f6d1fcb30a8cbdc18ce00c7d93792076af453 upstream.

We are holding a transaction handle when creating a tree, therefore we can
not allocate the root using GFP_KERNEL, as we could deadlock if reclaim is
triggered by the allocation, therefore setup a nofs context.

Fixes: 74e4d82757f74 ("btrfs: let callers of btrfs_alloc_root pass gfp flags")
CC: stable@... # 4.9+
Reviewed-by: Nikolay Borisov <nborisov@...>
Signed-off-by: Filipe Manana <fdmanana@...>
Reviewed-by: David Sterba <dsterba@...>
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/disk-io.c


[linux:lloyd-aviation] By Filipe Manana <fdmanana@...>:
6e24f5a1ebb1: Btrfs: setup a nofs context for memory allocation at __btrfs_set_acl

commit a0873490660246db587849a9e172f2b7b21fa88a upstream.

We are holding a transaction handle when setting an acl, therefore we can
not allocate the xattr value buffer using GFP_KERNEL, as we could deadlock
if reclaim is triggered by the allocation, therefore setup a nofs context.

Fixes: 39a27ec1004e8 ("btrfs: use GFP_KERNEL for xattr and acl allocations")
CC: stable@... # 4.9+
Reviewed-by: Nikolay Borisov <nborisov@...>
Signed-off-by: Filipe Manana <fdmanana@...>
Reviewed-by: David Sterba <dsterba@...>
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/acl.c


[linux:lloyd-aviation] By Johannes Thumshirn <jthumshirn@...>:
1a00f7fd0fbf: btrfs: ensure that a DUP or RAID1 block group has exactly two stripes

commit 349ae63f40638a28c6fce52e8447c2d14b84cc0c upstream.

We recently had a customer issue with a corrupted filesystem. When
trying to mount this image btrfs panicked with a division by zero in
calc_stripe_length().

The corrupt chunk had a 'num_stripes' value of 1. calc_stripe_length()
takes this value and divides it by the number of copies the RAID profile
is expected to have to calculate the amount of data stripes. As a DUP
profile is expected to have 2 copies this division resulted in 1/2 = 0.
Later then the 'data_stripes' variable is used as a divisor in the
stripe length calculation which results in a division by 0 and thus a
kernel panic.

When encountering a filesystem with a DUP block group and a
'num_stripes' value unequal to 2, refuse mounting as the image is
corrupted and will lead to unexpected behaviour.

Code inspection showed a RAID1 block group has the same issues.

Fixes: e06cd3dd7cea ("Btrfs: add validadtion checks for chunk loading")
CC: stable@... # 4.4+
Reviewed-by: Qu Wenruo <wqu@...>
Reviewed-by: Nikolay Borisov <nborisov@...>
Signed-off-by: Johannes Thumshirn <jthumshirn@...>
Reviewed-by: David Sterba <dsterba@...>
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/volumes.c


[linux:lloyd-aviation] By Filipe Manana <fdmanana@...>:
898488e2988c: Btrfs: fix corruption reading shared and compressed extents after hole punching

commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.

In the past we had data corruption when reading compressed extents that
are shared within the same file and they are consecutive, this got fixed
by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and
shared extents") and by commit 808f80b46790f ("Btrfs: update fix for read
corruption of compressed and shared extents"). However there was a case
that was missing in those fixes, which is when the shared and compressed
extents are referenced with a non-zero offset. The following shell script
creates a reproducer for this issue:

#!/bin/bash

mkfs.btrfs -f /dev/sdc &> /dev/null
mount -o compress /dev/sdc /mnt/sdc

# Create a file with 3 consecutive compressed extents, each has an
# uncompressed size of 128Kb and a compressed size of 4Kb.
for ((i = 1; i <= 3; i++)); do
head -c 4096 /dev/zero
for ((j = 1; j <= 31; j++)); do
head -c 4096 /dev/zero | tr '\0' "\377"
done
done > /mnt/sdc/foobar
sync

echo "Digest after file creation: $(md5sum /mnt/sdc/foobar)"

# Clone the first extent into offsets 128K and 256K.
xfs_io -c "reflink /mnt/sdc/foobar 0 128K 128K" /mnt/sdc/foobar
xfs_io -c "reflink /mnt/sdc/foobar 0 256K 128K" /mnt/sdc/foobar
sync

echo "Digest after cloning: $(md5sum /mnt/sdc/foobar)"

# Punch holes into the regions that are already full of zeroes.
xfs_io -c "fpunch 0 4K" /mnt/sdc/foobar
xfs_io -c "fpunch 128K 4K" /mnt/sdc/foobar
xfs_io -c "fpunch 256K 4K" /mnt/sdc/foobar
sync

echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)"

echo "Dropping page cache..."
sysctl -q vm.drop_caches=1
echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)"

umount /dev/sdc

When running the script we get the following output:

Digest after file creation: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
linked 131072/131072 bytes at offset 131072
128 KiB, 1 ops; 0.0033 sec (36.960 MiB/sec and 295.6830 ops/sec)
linked 131072/131072 bytes at offset 262144
128 KiB, 1 ops; 0.0015 sec (78.567 MiB/sec and 628.5355 ops/sec)
Digest after cloning: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
Digest after hole punching: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
Dropping page cache...
Digest after hole punching: fba694ae8664ed0c2e9ff8937e7f1484 /mnt/sdc/foobar

This happens because after reading all the pages of the extent in the
range from 128K to 256K for example, we read the hole at offset 256K
and then when reading the page at offset 260K we don't submit the
existing bio, which is responsible for filling all the page in the
range 128K to 256K only, therefore adding the pages from range 260K
to 384K to the existing bio and submitting it after iterating over the
entire range. Once the bio completes, the uncompressed data fills only
the pages in the range 128K to 256K because there's no more data read
from disk, leaving the pages in the range 260K to 384K unfilled. It is
just a slightly different variant of what was solved by commit
005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared
extents").

Fix this by forcing a bio submit, during readpages(), whenever we find a
compressed extent map for a page that is different from the extent map
for the previous page or has a different starting offset (in case it's
the same compressed extent), instead of the extent map's original start
offset.

A test case for fstests follows soon.

Reported-by: Zygo Blaxell <ce3g8jdj@...>
Fixes: 808f80b46790f ("Btrfs: update fix for read corruption of compressed and shared extents")
Fixes: 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared extents")
Cc: stable@... # 4.3+
Tested-by: Zygo Blaxell <ce3g8jdj@...>
Signed-off-by: Filipe Manana <fdmanana@...>
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/extent_io.c


[linux:lloyd-aviation] By Stephen Boyd <swboyd@...>:
02c55be588b1: soc: qcom: rpmh: Avoid accessing freed memory from batch API

commit baef1c90aac7e5bf13f0360a3b334825a23d31a1 upstream.

Using the batch API from the interconnect driver sometimes leads to a
KASAN error due to an access to freed memory. This is easier to trigger
with threadirqs on the kernel commandline.

BUG: KASAN: use-after-free in rpmh_tx_done+0x114/0x12c
Read of size 1 at addr fffffff51414ad84 by task irq/110-apps_rs/57

CPU: 0 PID: 57 Comm: irq/110-apps_rs Tainted: G W 4.19.10 #72
Call trace:
dump_backtrace+0x0/0x2f8
show_stack+0x20/0x2c
__dump_stack+0x20/0x28
dump_stack+0xcc/0x10c
print_address_description+0x74/0x240
kasan_report+0x250/0x26c
__asan_report_load1_noabort+0x20/0x2c
rpmh_tx_done+0x114/0x12c
tcs_tx_done+0x450/0x768
irq_forced_thread_fn+0x58/0x9c
irq_thread+0x120/0x1dc
kthread+0x248/0x260
ret_from_fork+0x10/0x18

Allocated by task 385:
kasan_kmalloc+0xac/0x148
__kmalloc+0x170/0x1e4
rpmh_write_batch+0x174/0x540
qcom_icc_set+0x8dc/0x9ac
icc_set+0x288/0x2e8
a6xx_gmu_stop+0x320/0x3c0
a6xx_pm_suspend+0x108/0x124
adreno_suspend+0x50/0x60
pm_generic_runtime_suspend+0x60/0x78
__rpm_callback+0x214/0x32c
rpm_callback+0x54/0x184
rpm_suspend+0x3f8/0xa90
pm_runtime_work+0xb4/0x178
process_one_work+0x544/0xbc0
worker_thread+0x514/0x7d0
kthread+0x248/0x260
ret_from_fork+0x10/0x18

Freed by task 385:
__kasan_slab_free+0x12c/0x1e0
kasan_slab_free+0x10/0x1c
kfree+0x134/0x588
rpmh_write_batch+0x49c/0x540
qcom_icc_set+0x8dc/0x9ac
icc_set+0x288/0x2e8
a6xx_gmu_stop+0x320/0x3c0
a6xx_pm_suspend+0x108/0x124
adreno_suspend+0x50/0x60
cr50_spi spi5.0: SPI transfer timed out
pm_generic_runtime_suspend+0x60/0x78
__rpm_callback+0x214/0x32c
rpm_callback+0x54/0x184
rpm_suspend+0x3f8/0xa90
pm_runtime_work+0xb4/0x178
process_one_work+0x544/0xbc0
worker_thread+0x514/0x7d0
kthread+0x248/0x260
ret_from_fork+0x10/0x18

The buggy address belongs to the object at fffffff51414ac80
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 260 bytes inside of
512-byte region [fffffff51414ac80, fffffff51414ae80)
The buggy address belongs to the page:
page:ffffffbfd4505200 count:1 mapcount:0 mapping:fffffff51e00c680 index:0x0 compound_mapcount: 0
flags: 0x4000000000008100(slab|head)
raw: 4000000000008100 ffffffbfd4529008 ffffffbfd44f9208 fffffff51e00c680
raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
fffffff51414ac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
fffffff51414ad00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>fffffff51414ad80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
fffffff51414ae00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
fffffff51414ae80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

The batch API sets the same completion for each rpmh message that's sent
and then loops through all the messages and waits for that single
completion declared on the stack to be completed before returning from
the function and freeing the message structures. Unfortunately, some
messages may still be in process and 'stuck' in the TCS. At some later
point, the tcs_tx_done() interrupt will run and try to process messages
that have already been freed at the end of rpmh_write_batch(). This will
in turn access the 'needs_free' member of the rpmh_request structure and
cause KASAN to complain. Furthermore, if there's a message that's
completed in rpmh_tx_done() and freed immediately after the complete()
call is made we'll be racing with potentially freed memory when
accessing the 'needs_free' member:

CPU0 CPU1
---- ----
rpmh_tx_done()
complete(&compl)
wait_for_completion(&compl)
kfree(rpm_msg)
if (rpm_msg->needs_free)
<KASAN warning splat>

Let's fix this by allocating a chunk of completions for each message and
waiting for all of them to be completed before returning from the batch
API. Alternatively, we could wait for the last message in the batch, but
that may be a more complicated change because it looks like
tcs_tx_done() just iterates through the indices of the queue and
completes each message instead of tracking the last inserted message and
completing that first.

Fixes: c8790cb6da58 ("drivers: qcom: rpmh: add support for batch RPMH request")
Cc: Lina Iyer <ilina@...>
Cc: "Raju P.L.S.S.S.N" <rplsssn@...>
Cc: Matthias Kaehlcke <mka@...>
Cc: Evan Green <evgreen@...>
Cc: stable@...
Reviewed-by: Lina Iyer <ilina@...>
Reviewed-by: Evan Green <evgreen@...>
Signed-off-by: Stephen Boyd <swboyd@...>
Signed-off-by: Bjorn Andersson <bjorn.andersson@...>
Signed-off-by: Andy Gross <andy.gross@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/soc/qcom/rpmh.c


[linux:lloyd-aviation] By Lubomir Rintel <lkundrak@...>:
b92fad6995c3: libertas_tf: don't set URB_ZERO_PACKET on IN USB transfer

commit 607076a904c435f2677fadaadd4af546279db68b upstream.

It doesn't make sense and the USB core warns on each submit of such
URB, easily flooding the message buffer with tracebacks.

Analogous issue was fixed in regular libertas driver in commit 6528d8804780
("libertas: don't set URB_ZERO_PACKET on IN USB transfer").

Cc: stable@...
Signed-off-by: Lubomir Rintel <lkundrak@...>
Reviewed-by: Steve deRosier <derosier@...>
Signed-off-by: Kalle Valo <kvalo@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/wireless/marvell/libertas_tf/if_usb.c


[linux:lloyd-aviation] By Zenghui Yu <yuzenghui@...>:
c8666ede18ec: irqchip/gic-v3-its: Avoid parsing _indirect_ twice for Device table

commit 8d565748b6035eeda18895c213396a4c9fac6a4c upstream.

In current logic, its_parse_indirect_baser() will be invoked twice
when allocating Device tables. Add a *break* to omit the unnecessary
and annoying (might be ...) invoking.

Fixes: 32bd44dc19de ("irqchip/gic-v3-its: Fix the incorrect parsing of VCPU table size")
Cc: stable@...
Signed-off-by: Zenghui Yu <yuzenghui@...>
Signed-off-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/irqchip/irq-gic-v3-its.c


[linux:lloyd-aviation] By Doug Berger <opendmb@...>:
a477075ebab3: irqchip/brcmstb-l2: Use _irqsave locking variants in non-interrupt code

commit 33517881ede742107f416533b8c3e4abc56763da upstream.

Using the irq_gc_lock/irq_gc_unlock functions in the suspend and
resume functions creates the opportunity for a deadlock during
suspend, resume, and shutdown. Using the irq_gc_lock_irqsave/
irq_gc_unlock_irqrestore variants prevents this possible deadlock.

Cc: stable@...
Fixes: 7f646e92766e2 ("irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 interrupt controller")
Signed-off-by: Doug Berger <opendmb@...>
Signed-off-by: Florian Fainelli <f.fainelli@...>
[maz: tidied up $SUBJECT]
Signed-off-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/irqchip/irq-brcmstb-l2.c


[linux:lloyd-aviation] By Masami Hiramatsu <mhiramat@...>:
ee7d297fba24: x86/kprobes: Prohibit probing on optprobe template code

commit 0192e6535ebe9af68614198ced4fd6d37b778ebf upstream.

Prohibit probing on optprobe template code, since it is not
a code but a template instruction sequence. If we modify
this template, copied template must be broken.

Signed-off-by: Masami Hiramatsu <mhiramat@...>
Cc: Alexander Shishkin <alexander.shishkin@...>
Cc: Andrea Righi <righi.andrea@...>
Cc: Arnaldo Carvalho de Melo <acme@...>
Cc: Jiri Olsa <jolsa@...>
Cc: Linus Torvalds <torvalds@...>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...>
Cc: Peter Zijlstra <peterz@...>
Cc: Steven Rostedt <rostedt@...>
Cc: Thomas Gleixner <tglx@...>
Cc: stable@...
Fixes: 9326638cbee2 ("kprobes, x86: Use NOKPROBE_SYMBOL() instead of __kprobes annotation")
Link: http://lkml.kernel.org/r/154998787911.31052.15274376330136234452.stgit@devbox
Signed-off-by: Ingo Molnar <mingo@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/kernel/kprobes/opt.c


[linux:lloyd-aviation] By Viresh Kumar <viresh.kumar@...>:
33565a76a7b2: cpufreq: kryo: Release OPP tables on module removal

commit 0334906c06967142c8805fbe88acf787f65d3d26 upstream.

Commit 5ad7346b4ae2 ("cpufreq: kryo: Add module remove and exit") made
it possible to build the kryo cpufreq driver as a module, but it failed
to release all the resources, i.e. OPP tables, when the module is
unloaded.

This patch fixes it by releasing the OPP tables, by calling
dev_pm_opp_put_supported_hw() for them, from the
qcom_cpufreq_kryo_remove() routine. The array of pointers to the OPP
tables is also allocated dynamically now in qcom_cpufreq_kryo_probe(),
as the pointers will be required while releasing the resources.

Compile tested only.

Cc: 4.18+ <stable@...> # v4.18+
Fixes: 5ad7346b4ae2 ("cpufreq: kryo: Add module remove and exit")
Reviewed-by: Georgi Djakov <georgi.djakov@...>
Signed-off-by: Viresh Kumar <viresh.kumar@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/cpufreq/qcom-cpufreq-kryo.c


[linux:lloyd-aviation] By Yangtao Li <tiny.windzz@...>:
f65b34d0f979: cpufreq: tegra124: add missing of_node_put()

commit 446fae2bb5395f3028d8e3aae1508737e5a72ea1 upstream.

of_cpu_device_node_get() will increase the refcount of device_node,
it is necessary to call of_node_put() at the end to release the
refcount.

Fixes: 9eb15dbbfa1a2 ("cpufreq: Add cpufreq driver for Tegra124")
Cc: <stable@...> # 4.4+
Signed-off-by: Yangtao Li <tiny.windzz@...>
Acked-by: Thierry Reding <treding@...>
Signed-off-by: Viresh Kumar <viresh.kumar@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/cpufreq/tegra124-cpufreq.c


[linux:lloyd-aviation] By Arnd Bergmann <arnd@...>:
ae228aca576d: cpufreq: pxa2xx: remove incorrect __init annotation

commit 9505b98ccddc454008ca7efff90044e3e857c827 upstream.

pxa_cpufreq_init_voltages() is marked __init but usually inlined into
the non-__init pxa_cpufreq_init() function. When building with clang,
it can stay as a standalone function in a discarded section, and produce
this warning:

WARNING: vmlinux.o(.text+0x616a00): Section mismatch in reference from the function pxa_cpufreq_init() to the function .init.text:pxa_cpufreq_init_voltages()
The function pxa_cpufreq_init() references
the function __init pxa_cpufreq_init_voltages().
This is often because pxa_cpufreq_init lacks a __init
annotation or the annotation of pxa_cpufreq_init_voltages is wrong.

Fixes: 50e77fcd790e ("ARM: pxa: remove __init from cpufreq_driver->init()")
Signed-off-by: Arnd Bergmann <arnd@...>
Acked-by: Viresh Kumar <viresh.kumar@...>
Reviewed-by: Nathan Chancellor <natechancellor@...>
Acked-by: Robert Jarzmik <robert.jarzmik@...>
Cc: All applicable <stable@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/cpufreq/pxa2xx-cpufreq.c


[linux:lloyd-aviation] By yangerkun <yangerkun@...>:
cdf9941b7707: ext4: fix check of inode in swap_inode_boot_loader

commit 67a11611e1a5211f6569044fbf8150875764d1d0 upstream.

Before really do swap between inode and boot inode, something need to
check to avoid invalid or not permitted operation, like does this inode
has inline data. But the condition check should be protected by inode
lock to avoid change while swapping. Also some other condition will not
change between swapping, but there has no problem to do this under inode
lock.

Signed-off-by: yangerkun <yangerkun@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext4/ioctl.c


[linux:lloyd-aviation] By yangerkun <yangerkun@...>:
071f68163cc0: ext4: cleanup pagecache before swap i_data

commit a46c68a318b08f819047843abf349aeee5d10ac2 upstream.

While do swap, we should make sure there has no new dirty page since we
should swap i_data between two inode:
1.We should lock i_mmap_sem with write to avoid new pagecache from mmap
read/write;
2.Change filemap_flush to filemap_write_and_wait and move them to the
space protected by inode lock to avoid new pagecache from buffer read/write.

Signed-off-by: yangerkun <yangerkun@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext4/ioctl.c


[linux:lloyd-aviation] By yangerkun <yangerkun@...>:
048bfb5bc05f: ext4: update quota information while swapping boot loader inode

commit aa507b5faf38784defe49f5e64605ac3c4425e26 upstream.

While do swap between two inode, they swap i_data without update
quota information. Also, swap_inode_boot_loader can do "revert"
somtimes, so update the quota while all operations has been finished.

Signed-off-by: yangerkun <yangerkun@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext4/ioctl.c


[linux:lloyd-aviation] By yangerkun <yangerkun@...>:
a0d876c77705: ext4: add mask of ext4 flags to swap

commit abdc644e8cbac2e9b19763680e5a7cf9bab2bee7 upstream.

The reason is that while swapping two inode, we swap the flags too.
Some flags such as EXT4_JOURNAL_DATA_FL can really confuse the things
since we're not resetting the address operations structure. The
simplest way to keep things sane is to restrict the flags that can be
swapped.

Signed-off-by: yangerkun <yangerkun@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext4/ext4.h
Modified: fs/ext4/ioctl.c


[linux:lloyd-aviation] By Jan Kara <jack@...>:
8a4fdc649ca9: ext4: fix crash during online resizing

commit f96c3ac8dfc24b4e38fc4c2eba5fea2107b929d1 upstream.

When computing maximum size of filesystem possible with given number of
group descriptor blocks, we forget to include s_first_data_block into
the number of blocks. Thus for filesystems with non-zero
s_first_data_block it can happen that computed maximum filesystem size
is actually lower than current filesystem size which confuses the code
and eventually leads to a BUG_ON in ext4_alloc_group_tables() hitting on
flex_gd->count == 0. The problem can be reproduced like:

truncate -s 100g /tmp/image
mkfs.ext4 -b 1024 -E resize=262144 /tmp/image 32768
mount -t ext4 -o loop /tmp/image /mnt
resize2fs /dev/loop0 262145
resize2fs /dev/loop0 300000

Fix the problem by properly including s_first_data_block into the
computed number of filesystem blocks.

Fixes: 1c6bd7173d66 "ext4: convert file system to meta_bg if needed..."
Signed-off-by: Jan Kara <jack@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext4/resize.c


[linux:lloyd-aviation] By Bjorn Helgaas <bhelgaas@...>:
c733cf4abfba: PCI/ASPM: Use LTR if already enabled by platform

commit 10ecc818ea7319b5d0d2b4e1aa6a77323e776f76 upstream.

RussianNeuroMancer reported that the Intel 7265 wifi on a Dell Venue 11 Pro
7140 table stopped working after wakeup from suspend and bisected the
problem to 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't
have LTR"). David Ward reported the same problem on a Dell Latitude 7350.

After af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before
using it"), we don't enable LTR unless the platform has granted LTR control
to us. In addition, we don't notice if the platform had already enabled
LTR itself.

After 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have
LTR"), we avoid using LTR if we don't think the path to the device has LTR
enabled.

The combination means that if the platform itself enables LTR but declines
to give the OS control over LTR, we unnecessarily avoided using ASPM L1.2.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=201469
Fixes: 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR")
Fixes: af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it")
Reported-by: RussianNeuroMancer <russianneuromancer@...>
Reported-by: David Ward <david.ward@...>
Signed-off-by: Bjorn Helgaas <bhelgaas@...>
CC: stable@... # v4.18+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/pci/probe.c


[linux:lloyd-aviation] By Dongdong Liu <liudongdong3@...>:
13a9d14fbf1b: PCI/DPC: Fix print AER status in DPC event handling

commit 9f08a5d896ce43380314c34ed3f264c8e6075b80 upstream.

Previously dpc_handler() called aer_get_device_error_info() without
initializing info->severity, so aer_get_device_error_info() relied on
uninitialized data.

Add dpc_get_aer_uncorrect_severity() to read the port's AER status, mask,
and severity registers and set info->severity.

Also, clear the port's AER fatal error status bits.

Fixes: 8aefa9b0d910 ("PCI/DPC: Print AER status in DPC event handling")
Signed-off-by: Dongdong Liu <liudongdong3@...>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <bhelgaas@...>
Reviewed-by: Keith Busch <keith.busch@...>
Cc: stable@... # v4.19+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/pci/pcie/dpc.c


[linux:lloyd-aviation] By Lucas Stach <l.stach@...>:
09bc2f5a16a9: PCI: dwc: skip MSI init if MSIs have been explicitly disabled

commit 3afc8299f39a27b60e1519a28e18878ce878e7dd upstream.

Since 7c5925afbc58 (PCI: dwc: Move MSI IRQs allocation to IRQ domains
hierarchical API) the MSI init claims one of the controller IRQs as a
chained IRQ line for the MSI controller. On some designs, like the i.MX6,
this line is shared with a PCIe legacy IRQ. When the line is claimed for
the MSI domain, any device trying to use this legacy IRQs will fail to
request this IRQ line.

As MSI and legacy IRQs are already mutually exclusive on the DWC core,
as the core won't forward any legacy IRQs once any MSI has been enabled,
users wishing to use legacy IRQs already need to explictly disable MSI
support (usually via the pci=nomsi kernel commandline option). To avoid
any issues with MSI conflicting with legacy IRQs, just skip all of the
DWC MSI initalization, including the IRQ line claim, when MSI is disabled.

Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains hierarchical API")
Tested-by: Tim Harvey <tharvey@...>
Signed-off-by: Lucas Stach <l.stach@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Acked-by: Gustavo Pimentel <gustavo.pimentel@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/pci/controller/dwc/pcie-designware-host.c


[linux:lloyd-aviation] By Michael J. Ruhl <michael.j.ruhl@...>:
54674984d478: IB/hfi1: Close race condition on user context disable and close

commit bc5add09764c123f58942a37c8335247e683d234 upstream.

When disabling and removing a receive context, it is possible for an
asynchronous event (i.e IRQ) to occur. Because of this, there is a race
between cleaning up the context, and the context being used by the
asynchronous event.

cpu 0 (context cleanup)
rc->ref_count-- (ref_count == 0)
hfi1_rcd_free()
cpu 1 (IRQ (with rcd index))
rcd_get_by_index()
lock
ref_count+++ <-- reference count race (WARNING)
return rcd
unlock
cpu 0
hfi1_free_ctxtdata() <-- incorrect free location
lock
remove rcd from array
unlock
free rcd

This race will cause the following WARNING trace:

WARNING: CPU: 0 PID: 175027 at include/linux/kref.h:52 hfi1_rcd_get_by_index+0x84/0xa0 [hfi1]
CPU: 0 PID: 175027 Comm: IMB-MPI1 Kdump: loaded Tainted: G OE ------------ 3.10.0-957.el7.x86_64 #1
Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.11.01.0076.C4.111920150602 11/19/2015
Call Trace:
dump_stack+0x19/0x1b
__warn+0xd8/0x100
warn_slowpath_null+0x1d/0x20
hfi1_rcd_get_by_index+0x84/0xa0 [hfi1]
is_rcv_urgent_int+0x24/0x90 [hfi1]
general_interrupt+0x1b6/0x210 [hfi1]
__handle_irq_event_percpu+0x44/0x1c0
handle_irq_event_percpu+0x32/0x80
handle_irq_event+0x3c/0x60
handle_edge_irq+0x7f/0x150
handle_irq+0xe4/0x1a0
do_IRQ+0x4d/0xf0
common_interrupt+0x162/0x162

The race can also lead to a use after free which could be similar to:

general protection fault: 0000 1 SMP
CPU: 71 PID: 177147 Comm: IMB-MPI1 Kdump: loaded Tainted: G W OE ------------ 3.10.0-957.el7.x86_64 #1
Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.11.01.0076.C4.111920150602 11/19/2015
task: ffff9962a8098000 ti: ffff99717a508000 task.ti: ffff99717a508000 __kmalloc+0x94/0x230
Call Trace:
? hfi1_user_sdma_process_request+0x9c8/0x1250 [hfi1]
hfi1_user_sdma_process_request+0x9c8/0x1250 [hfi1]
hfi1_aio_write+0xba/0x110 [hfi1]
do_sync_readv_writev+0x7b/0xd0
do_readv_writev+0xce/0x260
? handle_mm_fault+0x39d/0x9b0
? pick_next_task_fair+0x5f/0x1b0
? sched_clock_cpu+0x85/0xc0
? __schedule+0x13a/0x890
vfs_writev+0x35/0x60
SyS_writev+0x7f/0x110
system_call_fastpath+0x22/0x27

Use the appropriate kref API to verify access.

Reorder context cleanup to ensure context removal before cleanup occurs
correctly.

Cc: stable@... # v4.14.0+
Fixes: f683c80ca68e ("IB/hfi1: Resolve kernel panics by reference counting receive contexts")
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@...>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@...>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@...>
Signed-off-by: Jason Gunthorpe <jgg@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/infiniband/hw/hfi1/hfi.h
Modified: drivers/infiniband/hw/hfi1/init.c


[linux:lloyd-aviation] By Vaibhav Jain <vaibhav@...>:
c335b49379b5: cxl: Wrap iterations over afu slices inside 'afu_list_lock'

commit edeb304f659792fb5bab90d7d6f3408b4c7301fb upstream.

Within cxl module, iteration over array 'adapter->afu' may be racy
at few points as it might be simultaneously read during an EEH and its
contents being set to NULL while driver is being unloaded or unbound
from the adapter. This might result in a NULL pointer to 'struct afu'
being de-referenced during an EEH thereby causing a kernel oops.

This patch fixes this by making sure that all access to the array
'adapter->afu' is wrapped within the context of spin-lock
'adapter->afu_list_lock'.

Fixes: 9e8df8a21963 ("cxl: EEH support")
Cc: stable@... # v4.3+
Acked-by: Andrew Donnellan <andrew.donnellan@...>
Acked-by: Frederic Barrat <fbarrat@...>
Acked-by: Christophe Lombard <clombard@...>
Signed-off-by: Vaibhav Jain <vaibhav@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/misc/cxl/guest.c
Modified: drivers/misc/cxl/pci.c


[linux:lloyd-aviation] By Jan Kara <jack@...>:
62600af3a7cb: ext2: Fix underflow in ext2_max_size()

commit 1c2d14212b15a60300a2d4f6364753e87394c521 upstream.

When ext2 filesystem is created with 64k block size, ext2_max_size()
will return value less than 0. Also, we cannot write any file in this fs
since the sb->maxbytes is less than 0. The core of the problem is that
the size of block index tree for such large block size is more than
i_blocks can carry. So fix the computation to count with this
possibility.

File size limits computed with the new function for the full range of
possible block sizes look like:

bits file_size
10 17247252480
11 275415851008
12 2196873666560
13 2197948973056
14 2198486220800
15 2198754754560
16 2198888906752

CC: stable@...
Reported-by: yangerkun <yangerkun@...>
Signed-off-by: Jan Kara <jack@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext2/super.c


[linux:lloyd-aviation] By Kunihiko Hayashi <hayashi.kunihiko@...>:
6e02a5f5aba3: clk: uniphier: Fix update register for CPU-gear

commit 521282237b9d78b9bff423ec818becd4c95841c2 upstream.

Need to set the update bit in UNIPHIER_CLK_CPUGEAR_UPD to update
the CPU-gear value.

Fixes: d08f1f0d596c ("clk: uniphier: add CPU-gear change (cpufreq) support")
Cc: linux-stable@...
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@...>
Acked-by: Masahiro Yamada <yamada.masahiro@...>
Signed-off-by: Stephen Boyd <sboyd@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/clk/uniphier/clk-uniphier-cpugear.c


[linux:lloyd-aviation] By Tony Lindgren <tony@...>:
9aba7a8fd163: clk: clk-twl6040: Fix imprecise external abort for pdmclk

commit 5ae51d67aec95f6f9386aa8dd5db424964895575 upstream.

I noticed that modprobe clk-twl6040 can fail after a cold boot with:
abe_cm:clk:0010:0: failed to enable
...
Unhandled fault: imprecise external abort (0x1406) at 0xbe896b20

WARNING: CPU: 1 PID: 29 at drivers/clk/clk.c:828 clk_core_disable_lock+0x18/0x24
...
(clk_core_disable_lock) from [<c0123534>] (_disable_clocks+0x18/0x90)
(_disable_clocks) from [<c0124040>] (_idle+0x17c/0x244)
(_idle) from [<c0125ad4>] (omap_hwmod_idle+0x24/0x44)
(omap_hwmod_idle) from [<c053a038>] (sysc_runtime_suspend+0x48/0x108)
(sysc_runtime_suspend) from [<c06084c4>] (__rpm_callback+0x144/0x1d8)
(__rpm_callback) from [<c0608578>] (rpm_callback+0x20/0x80)
(rpm_callback) from [<c0607034>] (rpm_suspend+0x120/0x694)
(rpm_suspend) from [<c0607a78>] (__pm_runtime_idle+0x60/0x84)
(__pm_runtime_idle) from [<c053aaf0>] (sysc_probe+0x874/0xf2c)
(sysc_probe) from [<c05fecd4>] (platform_drv_probe+0x48/0x98)

After searching around for a similar issue, I came across an earlier fix
that never got merged upstream in the Android tree for glass-omap-xrr02.
There is patch "MFD: twl6040-codec: Implement PDMCLK cold temp errata"
by Misael Lopez Cruz <misael.lopez@...>.

Based on my observations, this fix is also needed when cold booting
devices, and not just for deeper idle modes. Since we now have a clock
driver for pdmclk, let's fix the issue in twl6040_pdmclk_prepare().

Cc: Misael Lopez Cruz <misael.lopez@...>
Cc: Peter Ujfalusi <peter.ujfalusi@...>
Signed-off-by: Tony Lindgren <tony@...>
Acked-by: Peter Ujfalusi <peter.ujfalusi@...>
Cc: <stable@...>
Signed-off-by: Stephen Boyd <sboyd@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/clk/clk-twl6040.c


[linux:lloyd-aviation] By Krzysztof Kozlowski <krzk@...>:
4d1de1e6d266: clk: samsung: exynos5: Fix possible NULL pointer exception on platform_device_alloc() failure

commit 5f0b6216ea381b43c0dff88702d6cc5673d63922 upstream.

During initialization of subdevices if platform_device_alloc() failed,
returned NULL pointer will be later dereferenced. Add proper error
paths to exynos5_clk_register_subcmu(). The return value of this
function is still ignored because at this stage of init there is nothing
we can do.

Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver")
Cc: <stable@...>
Signed-off-by: Krzysztof Kozlowski <krzk@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Stephen Boyd <sboyd@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/clk/samsung/clk-exynos5-subcmu.c


[linux:lloyd-aviation] By Krzysztof Kozlowski <krzk@...>:
33e7604ac8fd: clk: samsung: exynos5: Fix kfree() of const memory on setting driver_override

commit 785c9f411eb2d9a6076d3511c631587d5e676bf3 upstream.

Platform driver driver_override field should not be initialized from
const memory because the core later kfree() it. If driver_override is
manually set later through sysfs, kfree() of old value leads to:

$ echo "new_value" > /sys/bus/platform/drivers/.../driver_override

kernel BUG at ../mm/slub.c:3960!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
...
(kfree) from [<c058e8c0>] (platform_set_driver_override+0x84/0xac)
(platform_set_driver_override) from [<c058e908>] (driver_override_store+0x20/0x34)
(driver_override_store) from [<c031f778>] (kernfs_fop_write+0x100/0x1dc)
(kernfs_fop_write) from [<c0296de8>] (__vfs_write+0x2c/0x17c)
(__vfs_write) from [<c02970c4>] (vfs_write+0xa4/0x188)
(vfs_write) from [<c02972e8>] (ksys_write+0x4c/0xac)
(ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)

The clk-exynos5-subcmu driver uses override only for the purpose of
creating meaningful names for children devices (matching names of power
domains, e.g. DISP, MFC). The driver_override was not developed for
this purpose so just switch to default names of devices to fix the
issue.

Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver")
Cc: <stable@...>
Signed-off-by: Krzysztof Kozlowski <krzk@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Stephen Boyd <sboyd@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/clk/samsung/clk-exynos5-subcmu.c


[linux:lloyd-aviation] By Paul Cercueil <paul@...>:
4a04611fc266: clk: ingenic: Fix round_rate misbehaving with non-integer dividers

commit bc5d922c93491878c44c9216e9d227c7eeb81d7f upstream.

Take a parent rate of 180 MHz, and a requested rate of 4.285715 MHz.
This results in a theorical divider of 41.999993 which is then rounded
up to 42. The .round_rate function would then return (180 MHz / 42) as
the clock, rounded down, so 4.285714 MHz.

Calling clk_set_rate on 4.285714 MHz would round the rate again, and
give a theorical divider of 42,0000028, now rounded up to 43, and the
rate returned would be (180 MHz / 43) which is 4.186046 MHz, aka. not
what we requested.

Fix this by rounding up the divisions.

Signed-off-by: Paul Cercueil <paul@...>
Tested-by: Maarten ter Huurne <maarten@...>
Cc: <stable@...>
Signed-off-by: Stephen Boyd <sboyd@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/clk/ingenic/cgu.c


[linux:lloyd-aviation] By Paul Cercueil <paul@...>:
b1c1ef7b4d63: clk: ingenic: Fix doc of ingenic_cgu_div_info

commit 7ca4c922aad2e3c46767a12f80d01c6b25337b59 upstream.

The 'div' field does not represent a number of bits used to divide
(understand: right-shift) the divider, but a number itself used to
divide the divider.

Signed-off-by: Paul Cercueil <paul@...>
Signed-off-by: Maarten ter Huurne <maarten@...>
Cc: <stable@...>
Signed-off-by: Stephen Boyd <sboyd@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/clk/ingenic/cgu.h


[linux:lloyd-aviation] By Dmitry Osipenko <digetx@...>:
8415e718a06b: usb: chipidea: tegra: Fix missed ci_hdrc_remove_device()

commit 563b9372f7ec57e44e8f9a8600c5107d7ffdd166 upstream.

The ChipIdea's platform device need to be unregistered on Tegra's driver
module removal.

Fixes: dfebb5f43a78827a ("usb: chipidea: Add support for Tegra20/30/114/124")
Signed-off-by: Dmitry Osipenko <digetx@...>
Acked-by: Peter Chen <peter.chen@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/chipidea/ci_hdrc_tegra.c


[linux:lloyd-aviation] By Nikolaus Voss <nikolaus.voss@...>:
822e21853439: usb: typec: tps6598x: handle block writes separately with plain-I2C adapters

commit 8a863a608d47fa5d9dd15cf841817f73f804cf91 upstream.

Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes) correctly also exists
with writes.

As workaround, this patch adds a block write function the same way
1a2f474d328f adds a block read function.

Fixes: 1a2f474d328f ("usb: typec: tps6598x: handle block reads separately with plain-I2C adapters")
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
Signed-off-by: Nikolaus Voss <nikolaus.voss@...>
Cc: stable <stable@...>
Reviewed-by: Guenter Roeck <linux@...>
Acked-by: Heikki Krogerus <heikki.krogerus@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/typec/tps6598x.c


[linux:lloyd-aviation] By Phuong Nguyen <phuong.nguyen.xw@...>:
c7fd1a968c5d: dmaengine: usb-dmac: Make DMAC system sleep callbacks explicit

commit d9140a0da4a230a03426d175145989667758aa6a upstream.

This commit fixes the issue that USB-DMAC hangs silently after system
resumes on R-Car Gen3 hence renesas_usbhs will not work correctly
when using USB-DMAC for bulk transfer e.g. ethernet or serial
gadgets.

The issue can be reproduced by these steps:
1. modprobe g_serial
2. Suspend and resume system.
3. connect a usb cable to host side
4. Transfer data from Host to Target
5. cat /dev/ttyGS0 (Target side)
6. echo "test" > /dev/ttyACM0 (Host side)

The 'cat' will not result anything. However, system still can work
normally.

Currently, USB-DMAC driver does not have system sleep callbacks hence
this driver relies on the PM core to force runtime suspend/resume to
suspend and reinitialize USB-DMAC during system resume. After
the commit 17218e0092f8 ("PM / genpd: Stop/start devices without
pm_runtime_force_suspend/resume()"), PM core will not force
runtime suspend/resume anymore so this issue happens.

To solve this, make system suspend resume explicit by using
pm_runtime_force_{suspend,resume}() as the system sleep callbacks.
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() is used to make sure USB-DMAC
suspended after and initialized before renesas_usbhs."

Signed-off-by: Phuong Nguyen <phuong.nguyen.xw@...>
Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@...>
Cc: <stable@...> # v4.16+
[shimoda: revise the commit log and add Cc tag]
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>
Signed-off-by: Vinod Koul <vkoul@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/dma/sh/usb-dmac.c


[linux:lloyd-aviation] By zhongjiang <zhongjiang@...>:
234c0cc98221: mm: hwpoison: fix thp split handing in soft_offline_in_use_page()

commit 46612b751c4941c5c0472ddf04027e877ae5990f upstream.

When soft_offline_in_use_page() runs on a thp tail page after pmd is
split, we trigger the following VM_BUG_ON_PAGE():

Memory failure: 0x3755ff: non anonymous thp
__get_any_page: 0x3755ff: unknown zero refcount page type 2fffff80000000
Soft offlining pfn 0x34d805 at process virtual address 0x20fff000
page:ffffea000d360140 count:0 mapcount:0 mapping:0000000000000000 index:0x1
flags: 0x2fffff80000000()
raw: 002fffff80000000 ffffea000d360108 ffffea000d360188 0000000000000000
raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
------------[ cut here ]------------
kernel BUG at ./include/linux/mm.h:519!

soft_offline_in_use_page() passed refcount and page lock from tail page
to head page, which is not needed because we can pass any subpage to
split_huge_page().

Naoya had fixed a similar issue in c3901e722b29 ("mm: hwpoison: fix thp
split handling in memory_failure()"). But he missed fixing soft
offline.

Link: http://lkml.kernel.org/r/1551452476-24000-1-git-send-email-zhongjiang@...
Fixes: 61f5d698cc97 ("mm: re-enable THP")
Signed-off-by: zhongjiang <zhongjiang@...>
Acked-by: Naoya Horiguchi <n-horiguchi@...>
Cc: Michal Hocko <mhocko@...>
Cc: Hugh Dickins <hughd@...>
Cc: Kirill A. Shutemov <kirill@...>
Cc: Andrea Arcangeli <aarcange@...>
Cc: <stable@...> [4.5+]
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: mm/memory-failure.c


[linux:lloyd-aviation] By Roman Penyaev <rpenyaev@...>:
c1ddc7b785b4: mm/vmalloc: fix size check for remap_vmalloc_range_partial()

commit 401592d2e095947344e10ec0623adbcd58934dd4 upstream.

When VM_NO_GUARD is not set area->size includes adjacent guard page,
thus for correct size checking get_vm_area_size() should be used, but
not area->size.

This fixes possible kernel oops when userspace tries to mmap an area on
1 page bigger than was allocated by vmalloc_user() call: the size check
inside remap_vmalloc_range_partial() accounts non-existing guard page
also, so check successfully passes but vmalloc_to_page() returns NULL
(guard page does not physically exist).

The following code pattern example should trigger an oops:

static int oops_mmap(struct file *file, struct vm_area_struct *vma)
{
void *mem;

mem = vmalloc_user(4096);
BUG_ON(!mem);
/* Do not care about mem leak */

return remap_vmalloc_range(vma, mem, 0);
}

And userspace simply mmaps size + PAGE_SIZE:

mmap(NULL, 8192, PROT_WRITE|PROT_READ, MAP_PRIVATE, fd, 0);

Possible candidates for oops which do not have any explicit size
checks:

*** drivers/media/usb/stkwebcam/stk-webcam.c:
v4l_stk_mmap[789] ret = remap_vmalloc_range(vma, sbuf->buffer, 0);

Or the following one:

*** drivers/video/fbdev/core/fbmem.c
static int
fb_mmap(struct file *file, struct vm_area_struct * vma)
...
res = fb->fb_mmap(info, vma);

Where fb_mmap callback calls remap_vmalloc_range() directly without any
explicit checks:

*** drivers/video/fbdev/vfb.c
static int vfb_mmap(struct fb_info *info,
struct vm_area_struct *vma)
{
return remap_vmalloc_range(vma, (void *)info->fix.smem_start, vma->vm_pgoff);
}

Link: http://lkml.kernel.org/r/20190103145954.16942-2-rpenyaev@...
Signed-off-by: Roman Penyaev <rpenyaev@...>
Acked-by: Michal Hocko <mhocko@...>
Cc: Andrey Ryabinin <aryabinin@...>
Cc: Joe Perches <joe@...>
Cc: "Luis R. Rodriguez" <mcgrof@...>
Cc: <stable@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: mm/vmalloc.c


[linux:lloyd-aviation] By Jan Stancek <jstancek@...>:
09417dd35e37: mm/memory.c: do_fault: avoid usage of stale vm_area_struct

commit fc8efd2ddfed3f343c11b693e87140ff358d7ff5 upstream.

LTP testcase mtest06 [1] can trigger a crash on s390x running 5.0.0-rc8.
This is a stress test, where one thread mmaps/writes/munmaps memory area
and other thread is trying to read from it:

CPU: 0 PID: 2611 Comm: mmap1 Not tainted 5.0.0-rc8+ #51
Hardware name: IBM 2964 N63 400 (z/VM 6.4.0)
Krnl PSW : 0404e00180000000 00000000001ac8d8 (__lock_acquire+0x7/0x7a8)
Call Trace:
([<0000000000000000>] (null))
[<00000000001adae4>] lock_acquire+0xec/0x258
[<000000000080d1ac>] _raw_spin_lock_bh+0x5c/0x98
[<000000000012a780>] page_table_free+0x48/0x1a8
[<00000000002f6e54>] do_fault+0xdc/0x670
[<00000000002fadae>] __handle_mm_fault+0x416/0x5f0
[<00000000002fb138>] handle_mm_fault+0x1b0/0x320
[<00000000001248cc>] do_dat_exception+0x19c/0x2c8
[<000000000080e5ee>] pgm_check_handler+0x19e/0x200

page_table_free() is called with NULL mm parameter, but because "0" is a
valid address on s390 (see S390_lowcore), it keeps going until it
eventually crashes in lockdep's lock_acquire. This crash is
reproducible at least since 4.14.

Problem is that "vmf->vma" used in do_fault() can become stale. Because
mmap_sem may be released, other threads can come in, call munmap() and
cause "vma" be returned to kmem cache, and get zeroed/re-initialized and
re-used:

handle_mm_fault |
__handle_mm_fault |
do_fault |
vma = vmf->vma |
do_read_fault |
__do_fault |
vma->vm_ops->fault(vmf); |
mmap_sem is released |
|
| do_munmap()
| remove_vma_list()
| remove_vma()
| vm_area_free()
| # vma is released
| ...
| # same vma is allocated
| # from kmem cache
| do_mmap()
| vm_area_alloc()
| memset(vma, 0, ...)
|
pte_free(vma->vm_mm, ...); |
page_table_free |
spin_lock_bh(&mm->context.lock);|
<crash> |

Cache mm_struct to avoid using potentially stale "vma".

[1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mtest06/mmap1.c

Link: http://lkml.kernel.org/r/5b3fdf19e2a5be460a384b936f5b56e13733f1b8.1551595137.git.jstancek@...
Signed-off-by: Jan Stancek <jstancek@...>
Reviewed-by: Andrea Arcangeli <aarcange@...>
Reviewed-by: Matthew Wilcox <willy@...>
Acked-by: Rafael Aquini <aquini@...>
Reviewed-by: Minchan Kim <minchan@...>
Acked-by: Kirill A. Shutemov <kirill.shutemov@...>
Cc: Rik van Riel <riel@...>
Cc: Michal Hocko <mhocko@...>
Cc: Huang Ying <ying.huang@...>
Cc: Souptick Joarder <jrdr.linux@...>
Cc: Jerome Glisse <jglisse@...>
Cc: Aneesh Kumar K.V <aneesh.kumar@...>
Cc: David Hildenbrand <david@...>
Cc: Andrea Arcangeli <aarcange@...>
Cc: David Rientjes <rientjes@...>
Cc: Mel Gorman <mgorman@...>
Cc: <stable@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: mm/memory.c


[linux:lloyd-aviation] By Zev Weiss <zev@...>:
93c8a44a8297: kernel/sysctl.c: add missing range check in do_proc_dointvec_minmax_conv

commit 8cf7630b29701d364f8df4a50e4f1f5e752b2778 upstream.

This bug has apparently existed since the introduction of this function
in the pre-git era (4500e91754d3 in Thomas Gleixner's history.git,
"[NET]: Add proc_dointvec_userhz_jiffies, use it for proper handling of
neighbour sysctls.").

As a minimal fix we can simply duplicate the corresponding check in
do_proc_dointvec_conv().

Link: http://lkml.kernel.org/r/20190207123426.9202-3-zev@...
Signed-off-by: Zev Weiss <zev@...>
Cc: Brendan Higgins <brendanhiggins@...>
Cc: Iurii Zaikin <yzaikin@...>
Cc: Kees Cook <keescook@...>
Cc: Luis Chamberlain <mcgrof@...>
Cc: <stable@...> [2.6.2+]
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/sysctl.c


[linux:lloyd-aviation] By Heikki Krogerus <heikki.krogerus@...>:
c835b4417c18: device property: Fix the length used in PROPERTY_ENTRY_STRING()

commit 2b6e492467c78183bb629bb0a100ea3509b615a5 upstream.

With string type property entries we need to use
sizeof(const char *) instead of the number of characters as
the length of the entry.

If the string was shorter then sizeof(const char *),
attempts to read it would have failed with -EOVERFLOW. The
problem has been hidden because all build-in string
properties have had a string longer then 8 characters until
now.

Fixes: a85f42047533 ("device property: helper macros for property entry creation")
Cc: 4.5+ <stable@...> # 4.5+
Signed-off-by: Heikki Krogerus <heikki.krogerus@...>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: include/linux/property.h


[linux:lloyd-aviation] By Alexander Shishkin <alexander.shishkin@...>:
57c29a08c4cf: intel_th: Don't reference unassigned outputs

commit 9ed3f22223c33347ed963e7c7019cf2956dd4e37 upstream.

When an output port driver is removed, also remove references to it from
any masters. Failing to do this causes a NULL ptr dereference when
configuring another output port:

BUG: unable to handle kernel NULL pointer dereference at 000000000000000d
RIP: 0010:master_attr_store+0x9d/0x160 [intel_th_gth]
Call Trace:
dev_attr_store+0x1b/0x30
sysfs_kf_write+0x3c/0x50
kernfs_fop_write+0x125/0x1a0
__vfs_write+0x3a/0x190
? __vfs_write+0x5/0x190
? _cond_resched+0x1a/0x50
? rcu_all_qs+0x5/0xb0
? __vfs_write+0x5/0x190
vfs_write+0xb8/0x1b0
ksys_write+0x55/0xc0
__x64_sys_write+0x1a/0x20
do_syscall_64+0x5a/0x140
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Alexander Shishkin <alexander.shishkin@...>
Fixes: b27a6a3f97b9 ("intel_th: Add Global Trace Hub driver")
CC: stable@... # v4.4+
Reported-by: Ammy Yi <ammy.yi@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/hwtracing/intel_th/gth.c


[linux:lloyd-aviation] By QiaoChong <qiaochong@...>:
25970b517db1: parport_pc: fix find_superio io compare code, should use equal test.

commit 21698fd57984cd28207d841dbdaa026d6061bceb upstream.

In the original code before 181bf1e815a2 the loop was continuing until
it finds the first matching superios[i].io and p->base.
But after 181bf1e815a2 the logic changed and the loop now returns the
pointer to the first mismatched array element which is then used in
get_superio_dma() and get_superio_irq() and thus returning the wrong
value.
Fix the condition so that it now returns the correct pointer.

Fixes: 181bf1e815a2 ("parport_pc: clean up the modified while loops using for")
Cc: Alan Cox <alan@...>
Cc: stable@...
Signed-off-by: QiaoChong <qiaochong@...>
[rewrite the commit message]
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/parport/parport_pc.c


[linux:lloyd-aviation] By Sowjanya Komatineni <skomatineni@...>:
5f9614d0540b: i2c: tegra: fix maximum transfer size

commit f4e3f4ae1d9c9330de355f432b69952e8cef650c upstream.

Tegra186 and prior supports maximum 4K bytes per packet transfer
including 12 bytes of packet header.

This patch fixes max write length limit to account packet header
size for transfers.

Cc: stable@... # 4.4+

Reviewed-by: Dmitry Osipenko <digetx@...>
Signed-off-by: Sowjanya Komatineni <skomatineni@...>
Signed-off-by: Wolfram Sang <wsa@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/i2c/busses/i2c-tegra.c


[linux:lloyd-aviation] By Loic Poulain <loic.poulain@...>:
e86a57ecdfac: media: i2c: ov5640: Fix post-reset delay

commit 1d4c41f3d887bcd66e82cb2fda124533dad8808a upstream.

According to the ov5640 specification (2.7 power up sequence), host can
access the sensor's registers 20ms after reset. Trying to access them
before leads to undefined behavior and result in sporadic initialization
errors.

Signed-off-by: Loic Poulain <loic.poulain@...>
Signed-off-by: Sakari Ailus <sakari.ailus@...>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...>
Cc: Adam Ford <aford173@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/media/i2c/ov5640.c


[linux:lloyd-aviation] By Mark Walton <mark.walton@...>:
6f29e4c2dbb1: gpio: pca953x: Fix dereference of irq data in shutdown

commit c378b3aa015931a46c91d6ccc2fe04d97801d060 upstream.

If a PCA953x gpio was used as an interrupt and then released,
the shutdown function was trying to extract the pca953x_chip
pointer directly from the irq_data, but in reality was getting
the gpio_chip structure.

The net effect was that the subsequent writes to the data
structure corrupted data in the gpio_chip structure, which wasn't
immediately obvious until attempting to use the GPIO again in the
future, at which point the kernel panics.

This fix correctly extracts the pca953x_chip structure via the
gpio_chip structure, as is correctly done in the other irq
functions.

Fixes: 0a70fe00efea ("gpio: pca953x: Clear irq trigger type on irq shutdown")
Cc: stable@...
Signed-off-by: Mark Walton <mark.walton@...>
Reviewed-by: Bartosz Golaszewski <bgolaszewski@...>
Signed-off-by: Linus Walleij <linus.walleij@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpio/gpio-pca953x.c


[linux:lloyd-aviation] By Marc Kleine-Budde <mkl@...>:
116a9e31237c: can: flexcan: FLEXCAN_IFLAG_MB: add () around macro argument

[ Upstream commit 22233f7bf2c99ef52ec19d30876a12d2f725972e ]

This patch fixes the following checkpatch warning:

| Macro argument 'x' may be better as '(x)' to avoid precedence issues

Fixes: cbffaf7aa09e ("can: flexcan: Always use last mailbox for TX")
Signed-off-by: Marc Kleine-Budde <mkl@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/can/flexcan.c


[linux:lloyd-aviation] By Tvrtko Ursulin <tvrtko.ursulin@...>:
206fa92c9d52: drm/i915: Relax mmap VMA check

[ Upstream commit ca22f32a6296cbfa29de56328c8505560a18cfa8 ]

Legacy behaviour was to allow non-page-aligned mmap requests, as does the
linux mmap(2) implementation by virtue of automatically rounding up for
the caller.

To avoid breaking legacy userspace relax the newly introduced fix.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@...>
Fixes: 5c4604e757ba ("drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set")
Reported-by: Guenter Roeck <linux@...>
Cc: Adam Zabrocki <adamza@...>
Cc: Joonas Lahtinen <joonas.lahtinen@...>
Cc: <stable@...> # v4.0+
Cc: Akash Goel <akash.goel@...>
Cc: Chris Wilson <chris@...>
Cc: Jani Nikula <jani.nikula@...>
Cc: Rodrigo Vivi <rodrigo.vivi@...>
Cc: intel-gfx@...
Reviewed-by: Chris Wilson <chris@...>
Link: https://patchwork.freedesktop.org/patch/msgid/20190305110409.28633-1-tvrtko.ursulin@...
(cherry picked from commit a90e1948efb648f567444f87f3c19b2a0787affd)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/gpu/drm/i915/i915_gem.c


[linux:lloyd-aviation] By Willem de Bruijn <willemb@...>:
9920eb4003c5: bpf: only test gso type on gso packets

[ Upstream commit 4c3024debf62de4c6ac6d3cb4c0063be21d4f652 ]

BPF can adjust gso only for tcp bytestreams. Fail on other gso types.

But only on gso packets. It does not touch this field if !gso_size.

Fixes: b90efd225874 ("bpf: only adjust gso_size on bytestream protocols")
Signed-off-by: Willem de Bruijn <willemb@...>
Acked-by: Yonghong Song <yhs@...>
Signed-off-by: Daniel Borkmann <daniel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: include/linux/skbuff.h
Modified: net/core/filter.c


[linux:lloyd-aviation] By Anssi Hannula <anssi.hannula@...>:
a4b021ec4b5a: serial: uartps: Fix stuck ISR if RX disabled with non-empty FIFO

commit 7abab1605139bc41442864c18f9573440f7ca105 upstream.

If RX is disabled while there are still unprocessed bytes in RX FIFO,
cdns_uart_handle_rx() called from interrupt handler will get stuck in
the receive loop as read bytes will not get removed from the RX FIFO
and CDNS_UART_SR_RXEMPTY bit will never get set.

Avoid the stuck handler by checking first if RX is disabled. port->lock
protects against race with RX-disabling functions.

This HW behavior was mentioned by Nathan Rossi in 43e98facc4a3 ("tty:
xuartps: Fix RX hang, and TX corruption in termios call") which fixed a
similar issue in cdns_uart_set_termios().
The behavior can also be easily verified by e.g. setting
CDNS_UART_CR_RX_DIS at the beginning of cdns_uart_handle_rx() - the
following loop will then get stuck.

Resetting the FIFO using RXRST would not set RXEMPTY either so simply
issuing a reset after RX-disable would not work.

I observe this frequently on a ZynqMP board during heavy RX load at 1M
baudrate when the reader process exits and thus RX gets disabled.

Fixes: 61ec9016988f ("tty/serial: add support for Xilinx PS UART")
Signed-off-by: Anssi Hannula <anssi.hannula@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/xilinx_uartps.c


[linux:lloyd-aviation] By Lubomir Rintel <lkundrak@...>:
9d0b55bb2aec: serial: 8250_of: assume reg-shift of 2 for mrvl,mmp-uart

commit f4817843e39ce78aace0195a57d4e8500a65a898 upstream.

There are two other drivers that bind to mrvl,mmp-uart and both of them
assume register shift of 2 bits. There are device trees that lack the
property and rely on that assumption.

If this driver wins the race to bind to those devices, it should behave
the same as the older deprecated driver.

Signed-off-by: Lubomir Rintel <lkundrak@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/8250/8250_of.c


[linux:lloyd-aviation] By Jay Dolan <jay.dolan@...>:
8225bb965f29: serial: 8250_pci: Fix number of ports for ACCES serial cards

commit b896b03bc7fce43a07012cc6bf5e2ab2fddf3364 upstream.

Have the correct number of ports created for ACCES serial cards. Two port
cards show up as four ports, and four port cards show up as eight.

Fixes: c8d192428f52 ("serial: 8250: added acces i/o products quad and octal serial cards")
Signed-off-by: Jay Dolan <jay.dolan@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/8250/8250_pci.c


[linux:lloyd-aviation] By Jay Dolan <jay.dolan@...>:
3545324fba52: serial: 8250_pci: Have ACCES cards that use the four port Pericom PI7C9X7954 chip use the pci_pericom_setup()

commit 78d3820b9bd39028727c6aab7297b63c093db343 upstream.

The four port Pericom chips have the fourth port at the wrong address.
Make use of quirk to fix it.

Fixes: c8d192428f52 ("serial: 8250: added acces i/o products quad and octal serial cards")
Cc: stable <stable@...>
Signed-off-by: Jay Dolan <jay.dolan@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/8250/8250_pci.c


[linux:lloyd-aviation] By zhangyi (F) <yi.zhang@...>:
dbe4bc993836: jbd2: clear dirty flag when revoking a buffer from an older transaction

commit 904cdbd41d749a476863a0ca41f6f396774f26e4 upstream.

Now, we capture a data corruption problem on ext4 while we're truncating
an extent index block. Imaging that if we are revoking a buffer which
has been journaled by the committing transaction, the buffer's jbddirty
flag will not be cleared in jbd2_journal_forget(), so the commit code
will set the buffer dirty flag again after refile the buffer.

fsx kjournald2
jbd2_journal_commit_transaction
jbd2_journal_revoke commit phase 1~5...
jbd2_journal_forget
belongs to older transaction commit phase 6
jbddirty not clear __jbd2_journal_refile_buffer
__jbd2_journal_unfile_buffer
test_clear_buffer_jbddirty
mark_buffer_dirty

Finally, if the freed extent index block was allocated again as data
block by some other files, it may corrupt the file data after writing
cached pages later, such as during unmount time. (In general,
clean_bdev_aliases() related helpers should be invoked after
re-allocation to prevent the above corruption, but unfortunately we
missed it when zeroout the head of extra extent blocks in
ext4_ext_handle_unwritten_extents()).

This patch mark buffer as freed and set j_next_transaction to the new
transaction when it already belongs to the committing transaction in
jbd2_journal_forget(), so that commit code knows it should clear dirty
bits when it is done with the buffer.

This problem can be reproduced by xfstests generic/455 easily with
seeds (3246 3247 3248 3249).

Signed-off-by: zhangyi (F) <yi.zhang@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Reviewed-by: Jan Kara <jack@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/jbd2/transaction.c


[linux:lloyd-aviation] By zhangyi (F) <yi.zhang@...>:
584f390d1039: jbd2: fix compile warning when using JBUFFER_TRACE

commit 01215d3edb0f384ddeaa5e4a22c1ae5ff634149f upstream.

The jh pointer may be used uninitialized in the two cases below and the
compiler complain about it when enabling JBUFFER_TRACE macro, fix them.

In file included from fs/jbd2/transaction.c:19:0:
fs/jbd2/transaction.c: In function ‘jbd2_journal_get_undo_access’:
./include/linux/jbd2.h:1637:38: warning: ‘jh’ is used uninitialized in this function [-Wuninitialized]
#define JBUFFER_TRACE(jh, info) do { printk("%s: %d\n", __func__, jh->b_jcount);} while (0)
^
fs/jbd2/transaction.c:1219:23: note: ‘jh’ was declared here
struct journal_head *jh;
^
In file included from fs/jbd2/transaction.c:19:0:
fs/jbd2/transaction.c: In function ‘jbd2_journal_dirty_metadata’:
./include/linux/jbd2.h:1637:38: warning: ‘jh’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define JBUFFER_TRACE(jh, info) do { printk("%s: %d\n", __func__, jh->b_jcount);} while (0)
^
fs/jbd2/transaction.c:1332:23: note: ‘jh’ was declared here
struct journal_head *jh;
^

Signed-off-by: zhangyi (F) <yi.zhang@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Cc: stable@...
Reviewed-by: Jan Kara <jack@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/jbd2/transaction.c


[linux:lloyd-aviation] By Xin Long <lucien.xin@...>:
e4f6f82c9edc: selinux: add the missing walk_size + len check in selinux_sctp_bind_connect

commit 292c997a1970f8d1e1dfa354ed770a22f7b5a434 upstream.

As does in __sctp_connect(), when checking addrs in a while loop, after
get the addr len according to sa_family, it's necessary to do the check
walk_size + af->sockaddr_len > addrs_size to make sure it won't access
an out-of-bounds addr.

The same thing is needed in selinux_sctp_bind_connect(), otherwise an
out-of-bounds issue can be triggered:

[14548.772313] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x1aa/0x1f0
[14548.927083] Call Trace:
[14548.938072] dump_stack+0x9a/0xe9
[14548.953015] print_address_description+0x65/0x22e
[14548.996524] kasan_report.cold.6+0x92/0x1a6
[14549.015335] selinux_sctp_bind_connect+0x1aa/0x1f0
[14549.036947] security_sctp_bind_connect+0x58/0x90
[14549.058142] __sctp_setsockopt_connectx+0x5a/0x150 [sctp]
[14549.081650] sctp_setsockopt.part.24+0x1322/0x3ce0 [sctp]

Cc: stable@...
Fixes: d452930fd3b9 ("selinux: Add SCTP support")
Reported-by: Chunyu Hu <chuhu@...>
Signed-off-by: Xin Long <lucien.xin@...>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@...>
Signed-off-by: Paul Moore <paul@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: security/selinux/hooks.c


[linux:lloyd-aviation] By J. Bruce Fields <bfields@...>:
c7dad095f35a: security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock

commit 3815a245b50124f0865415dcb606a034e97494d4 upstream.

In the case when we're reusing a superblock, selinux_sb_clone_mnt_opts()
fails to set set_kern_flags, with the result that
nfs_clone_sb_security() incorrectly clears NFS_CAP_SECURITY_LABEL.

The result is that if you mount the same NFS filesystem twice, NFS
security labels are turned off, even if they would work fine if you
mounted the filesystem only once.

("fixes" may be not exactly the right tag, it may be more like
"fixed-other-cases-but-missed-this-one".)

Cc: Scott Mayhew <smayhew@...>
Cc: stable@...
Fixes: 0b4d3452b8b4 "security/selinux: allow security_sb_clone_mnt_opts..."
Signed-off-by: J. Bruce Fields <bfields@...>
Acked-by: Stephen Smalley <sds@...>
Signed-off-by: Paul Moore <paul@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: security/selinux/hooks.c


[linux:lloyd-aviation] By Christophe Leroy <christophe.leroy@...>:
40b97853c200: powerpc/32: Clear on-stack exception marker upon exception return

commit 9580b71b5a7863c24a9bd18bcd2ad759b86b1eff upstream.

Clear the on-stack STACK_FRAME_REGS_MARKER on exception exit in order
to avoid confusing stacktrace like the one below.

Call Trace:
[c0e9dca0] [c01c42a0] print_address_description+0x64/0x2bc (unreliable)
[c0e9dcd0] [c01c4684] kasan_report+0xfc/0x180
[c0e9dd10] [c0895130] memchr+0x24/0x74
[c0e9dd30] [c00a9e38] msg_print_text+0x124/0x574
[c0e9dde0] [c00ab710] console_unlock+0x114/0x4f8
[c0e9de40] [c00adc60] vprintk_emit+0x188/0x1c4
--- interrupt: c0e9df00 at 0x400f330
LR = init_stack+0x1f00/0x2000
[c0e9de80] [c00ae3c4] printk+0xa8/0xcc (unreliable)
[c0e9df20] [c0c27e44] early_irq_init+0x38/0x108
[c0e9df50] [c0c15434] start_kernel+0x310/0x488
[c0e9dff0] [00003484] 0x3484

With this patch the trace becomes:

Call Trace:
[c0e9dca0] [c01c42c0] print_address_description+0x64/0x2bc (unreliable)
[c0e9dcd0] [c01c46a4] kasan_report+0xfc/0x180
[c0e9dd10] [c0895150] memchr+0x24/0x74
[c0e9dd30] [c00a9e58] msg_print_text+0x124/0x574
[c0e9dde0] [c00ab730] console_unlock+0x114/0x4f8
[c0e9de40] [c00adc80] vprintk_emit+0x188/0x1c4
[c0e9de80] [c00ae3e4] printk+0xa8/0xcc
[c0e9df20] [c0c27e44] early_irq_init+0x38/0x108
[c0e9df50] [c0c15434] start_kernel+0x310/0x488
[c0e9dff0] [00003484] 0x3484

Cc: stable@...
Signed-off-by: Christophe Leroy <christophe.leroy@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/entry_32.S


[linux:lloyd-aviation] By Christophe Leroy <christophe.leroy@...>:
9b5305504709: powerpc/wii: properly disable use of BATs when requested.

commit 6d183ca8baec983dc4208ca45ece3c36763df912 upstream.

'nobats' kernel parameter or some options like CONFIG_DEBUG_PAGEALLOC
deny the use of BATS for mapping memory.

This patch makes sure that the specific wii RAM mapping function
takes it into account as well.

Fixes: de32400dd26e ("wii: use both mem1 and mem2 as ram")
Cc: stable@...
Reviewed-by: Jonathan Neuschafer <j.neuschaefer@...>
Signed-off-by: Christophe Leroy <christophe.leroy@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/platforms/embedded6xx/wii.c


[linux:lloyd-aviation] By Jordan Niethe <jniethe5@...>:
b0934990125a: powerpc/powernv: Make opal log only readable by root

commit 7b62f9bd2246b7d3d086e571397c14ba52645ef1 upstream.

Currently the opal log is globally readable. It is kernel policy to
limit the visibility of physical addresses / kernel pointers to root.
Given this and the fact the opal log may contain this information it
would be better to limit the readability to root.

Fixes: bfc36894a48b ("powerpc/powernv: Add OPAL message log interface")
Cc: stable@... # v3.15+
Signed-off-by: Jordan Niethe <jniethe5@...>
Reviewed-by: Stewart Smith <stewart@...>
Reviewed-by: Andrew Donnellan <andrew.donnellan@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/platforms/powernv/opal-msglog.c


[linux:lloyd-aviation] By Christophe Leroy <christophe.leroy@...>:
f6f03d6078b1: powerpc/83xx: Also save/restore SPRG4-7 during suspend

commit 36da5ff0bea2dc67298150ead8d8471575c54c7d upstream.

The 83xx has 8 SPRG registers and uses at least SPRG4
for DTLB handling LRU.

Fixes: 2319f1239592 ("powerpc/mm: e300c2/c3/c4 TLB errata workaround")
Cc: stable@...
Signed-off-by: Christophe Leroy <christophe.leroy@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/platforms/83xx/suspend-asm.S


[linux:lloyd-aviation] By Paul Mackerras <paulus@...>:
3bf8ff7bc667: powerpc/powernv: Don't reprogram SLW image on every KVM guest entry/exit

commit 19f8a5b5be2898573a5e1dc1db93e8d40117606a upstream.

Commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via stop-api
only on Hotplug", 2017-07-21) added two calls to opal_slw_set_reg()
inside pnv_cpu_offline(), with the aim of changing the LPCR value in
the SLW image to disable wakeups from the decrementer while a CPU is
offline. However, pnv_cpu_offline() gets called each time a secondary
CPU thread is woken up to participate in running a KVM guest, that is,
not just when a CPU is offlined.

Since opal_slw_set_reg() is a very slow operation (with observed
execution times around 20 milliseconds), this means that an offline
secondary CPU can often be busy doing the opal_slw_set_reg() call
when the primary CPU wants to grab all the secondary threads so that
it can run a KVM guest. This leads to messages like "KVM: couldn't
grab CPU n" being printed and guest execution failing.

There is no need to reprogram the SLW image on every KVM guest entry
and exit. So that we do it only when a CPU is really transitioning
between online and offline, this moves the calls to
pnv_program_cpu_hotplug_lpcr() into pnv_smp_cpu_kill_self().

Fixes: 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via stop-api only on Hotplug")
Cc: stable@... # v4.14+
Signed-off-by: Paul Mackerras <paulus@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/include/asm/powernv.h
Modified: arch/powerpc/platforms/powernv/idle.c
Modified: arch/powerpc/platforms/powernv/smp.c


[linux:lloyd-aviation] By Mark Cave-Ayland <mark.cave-ayland@...>:
344996a835d4: powerpc: Fix 32-bit KVM-PR lockup and host crash with MacOS guest

commit fe1ef6bcdb4fca33434256a802a3ed6aacf0bd2f upstream.

Commit 8792468da5e1 "powerpc: Add the ability to save FPU without
giving it up" unexpectedly removed the MSR_FE0 and MSR_FE1 bits from
the bitmask used to update the MSR of the previous thread in
__giveup_fpu() causing a KVM-PR MacOS guest to lockup and panic the
host kernel.

Leaving FE0/1 enabled means unrelated processes might receive FPEs
when they're not expecting them and crash. In particular if this
happens to init the host will then panic.

eg (transcribed):
qemu-system-ppc[837]: unhandled signal 8 at 12cc9ce4 nip 12cc9ce4 lr 12cc9ca4 code 0
systemd[1]: unhandled signal 8 at 202f02e0 nip 202f02e0 lr 001003d4 code 0
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Reinstate these bits to the MSR bitmask to enable MacOS guests to run
under 32-bit KVM-PR once again without issue.

Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up")
Cc: stable@... # v4.6+
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/process.c


[linux:lloyd-aviation] By Michael Ellerman <mpe@...>:
9d2e929c3bae: powerpc/ptrace: Simplify vr_get/set() to avoid GCC warning

commit ca6d5149d2ad0a8d2f9c28cbe379802260a0a5e0 upstream.

GCC 8 warns about the logic in vr_get/set(), which with -Werror breaks
the build:

In function ‘user_regset_copyin’,
inlined from ‘vr_set’ at arch/powerpc/kernel/ptrace.c:628:9:
include/linux/regset.h:295:4: error: ‘memcpy’ offset [-527, -529] is
out of the bounds [0, 16] of object ‘vrsave’ with type ‘union
<anonymous>’ [-Werror=array-bounds]
arch/powerpc/kernel/ptrace.c: In function ‘vr_set’:
arch/powerpc/kernel/ptrace.c:623:5: note: ‘vrsave’ declared here
} vrsave;

This has been identified as a regression in GCC, see GCC bug 88273.

However we can avoid the warning and also simplify the logic and make
it more robust.

Currently we pass -1 as end_pos to user_regset_copyout(). This says
"copy up to the end of the regset".

The definition of the regset is:
[REGSET_VMX] = {
.core_note_type = NT_PPC_VMX, .n = 34,
.size = sizeof(vector128), .align = sizeof(vector128),
.active = vr_active, .get = vr_get, .set = vr_set
},

The end is calculated as (n * size), ie. 34 * sizeof(vector128).

In vr_get/set() we pass start_pos as 33 * sizeof(vector128), meaning
we can copy up to sizeof(vector128) into/out-of vrsave.

The on-stack vrsave is defined as:
union {
elf_vrreg_t reg;
u32 word;
} vrsave;

And elf_vrreg_t is:
typedef __vector128 elf_vrreg_t;

So there is no bug, but we rely on all those sizes lining up,
otherwise we would have a kernel stack exposure/overwrite on our
hands.

Rather than relying on that we can pass an explict end_pos based on
the sizeof(vrsave). The result should be exactly the same but it's
more obviously not over-reading/writing the stack and it avoids the
compiler warning.

Reported-by: Meelis Roos <mroos@...>
Reported-by: Mathieu Malaterre <malat@...>
Cc: stable@...
Tested-by: Mathieu Malaterre <malat@...>
Tested-by: Meelis Roos <mroos@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/ptrace.c


[linux:lloyd-aviation] By Aneesh Kumar K.V <aneesh.kumar@...>:
baed68a953ac: powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration

commit 35f2806b481f5b9207f25e1886cba5d1c4d12cc7 upstream.

We added runtime allocation of 16G pages in commit 4ae279c2c96a
("powerpc/mm/hugetlb: Allow runtime allocation of 16G.") That was done
to enable 16G allocation on PowerNV and KVM config. In case of KVM
config, we mostly would have the entire guest RAM backed by 16G
hugetlb pages for this to work. PAPR do support partial backing of
guest RAM with hugepages via ibm,expected#pages node of memory node in
the device tree. This means rest of the guest RAM won't be backed by
16G contiguous pages in the host and hence a hash page table insertion
can fail in such case.

An example error message will look like

hash-mmu: mm: Hashing failure ! EA=0x7efc00000000 access=0x8000000000000006 current=readback
hash-mmu: trap=0x300 vsid=0x67af789 ssize=1 base psize=14 psize 14 pte=0xc000000400000386
readback[12260]: unhandled signal 7 at 00007efc00000000 nip 00000000100012d0 lr 000000001000127c code 2

This patch address that by preventing runtime allocation of 16G
hugepages in LPAR config. To allocate 16G hugetlb one need to kernel
command line hugepagesz=16G hugepages=<number of 16G pages>

With radix translation mode we don't run into this issue.

This change will prevent runtime allocation of 16G hugetlb pages on
kvm with hash translation mode. However, with the current upstream it
was observed that 16G hugetlbfs backed guest doesn't boot at all.

We observe boot failure with the below message:
[131354.647546] KVM: map_vrma at 0 failed, ret=-4

That means this patch is not resulting in an observable regression.
Once we fix the boot issue with 16G hugetlb backed memory, we need to
use ibm,expected#pages memory node attribute to indicate 16G page
reservation to the guest. This will also enable partial backing of
guest RAM with 16G pages.

Fixes: 4ae279c2c96a ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.")
Cc: stable@... # v4.14+
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/include/asm/book3s/64/hugetlb.h


[linux:lloyd-aviation] By Christophe Leroy <christophe.leroy@...>:
461a52a44893: powerpc/traps: fix recoverability of machine check handling on book3s/32

commit 0bbea75c476b77fa7d7811d6be911cc7583e640f upstream.

Looks like book3s/32 doesn't set RI on machine check, so
checking RI before calling die() will always be fatal
allthought this is not an issue in most cases.

Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable interrupt")
Fixes: daf00ae71dad ("powerpc/traps: restore recoverability of machine_check interrupts")
Signed-off-by: Christophe Leroy <christophe.leroy@...>
Cc: stable@...
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/traps.c


[linux:lloyd-aviation] By Christophe Leroy <christophe.leroy@...>:
d6d004b3dd70: powerpc/traps: Fix the message printed when stack overflows

commit 9bf3d3c4e4fd82c7174f4856df372ab2a71005b9 upstream.

Today's message is useless:

[ 42.253267] Kernel stack overflow in process (ptrval), r1=c65500b0

This patch fixes it:

[ 66.905235] Kernel stack overflow in process sh[356], r1=c65560b0

Fixes: ad67b74d2469 ("printk: hash addresses printed with %p")
Cc: stable@... # v4.15+
Signed-off-by: Christophe Leroy <christophe.leroy@...>
[mpe: Use task_pid_nr()]
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/traps.c


[linux:lloyd-aviation] By Gustavo A. R. Silva <gustavo@...>:
58691e6a93d8: ARM: s3c24xx: Fix boolean expressions in osiris_dvs_notify

commit e2477233145f2156434afb799583bccd878f3e9f upstream.

Fix boolean expressions by using logical AND operator '&&' instead of
bitwise operator '&'.

This issue was detected with the help of Coccinelle.

Fixes: 4fa084af28ca ("ARM: OSIRIS: DVS (Dynamic Voltage Scaling) supoort.")
Cc: stable@...
Signed-off-by: Gustavo A. R. Silva <gustavo@...>
[krzk: Fix -Wparentheses warning]
Signed-off-by: Krzysztof Kozlowski <krzk@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm/mach-s3c24xx/mach-osiris-dvs.c


[linux:lloyd-aviation] By Julien Thierry <julien.thierry@...>:
85c8ea220f89: arm64: Fix HCR.TGE status for NMI contexts

commit 5870970b9a828d8693aa6d15742573289d7dbcd0 upstream.

When using VHE, the host needs to clear HCR_EL2.TGE bit in order
to interact with guest TLBs, switching from EL2&0 translation regime
to EL1&0.

However, some non-maskable asynchronous event could happen while TGE is
cleared like SDEI. Because of this address translation operations
relying on EL2&0 translation regime could fail (tlb invalidation,
userspace access, ...).

Fix this by properly setting HCR_EL2.TGE when entering NMI context and
clear it if necessary when returning to the interrupted context.

Signed-off-by: Julien Thierry <julien.thierry@...>
Suggested-by: Marc Zyngier <marc.zyngier@...>
Reviewed-by: Marc Zyngier <marc.zyngier@...>
Reviewed-by: James Morse <james.morse@...>
Cc: Arnd Bergmann <arnd@...>
Cc: Will Deacon <will.deacon@...>
Cc: Marc Zyngier <marc.zyngier@...>
Cc: James Morse <james.morse@...>
Cc: linux-arch@...
Cc: stable@...
Signed-off-by: Catalin Marinas <catalin.marinas@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm64/include/asm/hardirq.h
Modified: arch/arm64/kernel/irq.c
Modified: include/linux/hardirq.h


[linux:lloyd-aviation] By Will Deacon <will.deacon@...>:
c113a7fb017b: arm64: debug: Ensure debug handlers check triggering exception level

commit 6bd288569b50bc89fa5513031086746968f585cb upstream.

Debug exception handlers may be called for exceptions generated both by
user and kernel code. In many cases, this is checked explicitly, but
in other cases things either happen to work by happy accident or they
go slightly wrong. For example, executing 'brk #4' from userspace will
enter the kprobes code and be ignored, but the instruction will be
retried forever in userspace instead of delivering a SIGTRAP.

Fix this issue in the most stable-friendly fashion by simply adding
explicit checks of the triggering exception level to all of our debug
exception handlers.

Cc: <stable@...>
Reviewed-by: Mark Rutland <mark.rutland@...>
Signed-off-by: Will Deacon <will.deacon@...>
Signed-off-by: Catalin Marinas <catalin.marinas@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm64/kernel/kgdb.c
Modified: arch/arm64/kernel/probes/kprobes.c


[linux:lloyd-aviation] By Dave Martin <Dave.Martin@...>:
3cbae9fa85ce: arm64: KVM: Fix architecturally invalid reset value for FPEXC32_EL2

commit c88b093693ccbe41991ef2e9b1d251945e6e54ed upstream.

Due to what looks like a typo dating back to the original addition
of FPEXC32_EL2 handling, KVM currently initialises this register to
an architecturally invalid value.

As a result, the VECITR field (RES1) in bits [10:8] is initialised
with 0, and the two reserved (RES0) bits [6:5] are initialised with
1. (In the Common VFP Subarchitecture as specified by ARMv7-A,
these two bits were IMP DEF. ARMv8-A removes them.)

This patch changes the reset value from 0x70 to 0x700, which
reflects the architectural constraints and is presumably what was
originally intended.

Cc: <stable@...> # 4.12.x-
Cc: Christoffer Dall <christoffer.dall@...>
Fixes: 62a89c44954f ("arm64: KVM: 32bit handling of coprocessor traps")
Signed-off-by: Dave Martin <Dave.Martin@...>
Signed-off-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm64/kvm/sys_regs.c


[linux:lloyd-aviation] By Yang Yingliang <yangyingliang@...>:
a441fdaf8c30: ipmi_si: fix use-after-free of resource->name

commit 401e7e88d4ef80188ffa07095ac00456f901b8c4 upstream.

When we excute the following commands, we got oops
rmmod ipmi_si
cat /proc/ioports

[ 1623.482380] Unable to handle kernel paging request at virtual address ffff00000901d478
[ 1623.482382] Mem abort info:
[ 1623.482383] ESR = 0x96000007
[ 1623.482385] Exception class = DABT (current EL), IL = 32 bits
[ 1623.482386] SET = 0, FnV = 0
[ 1623.482387] EA = 0, S1PTW = 0
[ 1623.482388] Data abort info:
[ 1623.482389] ISV = 0, ISS = 0x00000007
[ 1623.482390] CM = 0, WnR = 0
[ 1623.482393] swapper pgtable: 4k pages, 48-bit VAs, pgdp = 00000000d7d94a66
[ 1623.482395] [ffff00000901d478] pgd=000000dffbfff003, pud=000000dffbffe003, pmd=0000003f5d06e003, pte=0000000000000000
[ 1623.482399] Internal error: Oops: 96000007 [#1] SMP
[ 1623.487407] Modules linked in: ipmi_si(E) nls_utf8 isofs rpcrdma ib_iser ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_umad rdma_cm ib_cm dm_mirror dm_region_hash dm_log iw_cm dm_mod aes_ce_blk crypto_simd cryptd aes_ce_cipher ses ghash_ce sha2_ce enclosure sha256_arm64 sg sha1_ce hisi_sas_v2_hw hibmc_drm sbsa_gwdt hisi_sas_main ip_tables mlx5_ib ib_uverbs marvell ib_core mlx5_core ixgbe mdio hns_dsaf ipmi_devintf hns_enet_drv ipmi_msghandler hns_mdio [last unloaded: ipmi_si]
[ 1623.532410] CPU: 30 PID: 11438 Comm: cat Kdump: loaded Tainted: G E 5.0.0-rc3+ #168
[ 1623.541498] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.37 11/21/2017
[ 1623.548822] pstate: a0000005 (NzCv daif -PAN -UAO)
[ 1623.553684] pc : string+0x28/0x98
[ 1623.557040] lr : vsnprintf+0x368/0x5e8
[ 1623.560837] sp : ffff000013213a80
[ 1623.564191] x29: ffff000013213a80 x28: ffff00001138abb5
[ 1623.569577] x27: ffff000013213c18 x26: ffff805f67d06049
[ 1623.574963] x25: 0000000000000000 x24: ffff00001138abb5
[ 1623.580349] x23: 0000000000000fb7 x22: ffff0000117ed000
[ 1623.585734] x21: ffff000011188fd8 x20: ffff805f67d07000
[ 1623.591119] x19: ffff805f67d06061 x18: ffffffffffffffff
[ 1623.596505] x17: 0000000000000200 x16: 0000000000000000
[ 1623.601890] x15: ffff0000117ed748 x14: ffff805f67d07000
[ 1623.607276] x13: ffff805f67d0605e x12: 0000000000000000
[ 1623.612661] x11: 0000000000000000 x10: 0000000000000000
[ 1623.618046] x9 : 0000000000000000 x8 : 000000000000000f
[ 1623.623432] x7 : ffff805f67d06061 x6 : fffffffffffffffe
[ 1623.628817] x5 : 0000000000000012 x4 : ffff00000901d478
[ 1623.634203] x3 : ffff0a00ffffff04 x2 : ffff805f67d07000
[ 1623.639588] x1 : ffff805f67d07000 x0 : ffffffffffffffff
[ 1623.644974] Process cat (pid: 11438, stack limit = 0x000000008d4cbc10)
[ 1623.651592] Call trace:
[ 1623.654068] string+0x28/0x98
[ 1623.657071] vsnprintf+0x368/0x5e8
[ 1623.660517] seq_vprintf+0x70/0x98
[ 1623.668009] seq_printf+0x7c/0xa0
[ 1623.675530] r_show+0xc8/0xf8
[ 1623.682558] seq_read+0x330/0x440
[ 1623.689877] proc_reg_read+0x78/0xd0
[ 1623.697346] __vfs_read+0x60/0x1a0
[ 1623.704564] vfs_read+0x94/0x150
[ 1623.711339] ksys_read+0x6c/0xd8
[ 1623.717939] __arm64_sys_read+0x24/0x30
[ 1623.725077] el0_svc_common+0x120/0x148
[ 1623.732035] el0_svc_handler+0x30/0x40
[ 1623.738757] el0_svc+0x8/0xc
[ 1623.744520] Code: d1000406 aa0103e2 54000149 b4000080 (39400085)
[ 1623.753441] ---[ end trace f91b6a4937de9835 ]---
[ 1623.760871] Kernel panic - not syncing: Fatal exception
[ 1623.768935] SMP: stopping secondary CPUs
[ 1623.775718] Kernel Offset: disabled
[ 1623.781998] CPU features: 0x002,21006008
[ 1623.788777] Memory Limit: none
[ 1623.798329] Starting crashdump kernel...
[ 1623.805202] Bye!

If io_setup is called successful in try_smi_init() but try_smi_init()
goes out_err before calling ipmi_register_smi(), so ipmi_unregister_smi()
will not be called while removing module. It leads to the resource that
allocated in io_setup() can not be freed, but the name(DEVICE_NAME) of
resource is freed while removing the module. It causes use-after-free
when cat /proc/ioports.

Fix this by calling io_cleanup() while try_smi_init() goes to out_err.
and don't call io_cleanup() until io_setup() returns successful to avoid
warning prints.

Fixes: 93c303d2045b ("ipmi_si: Clean up shutdown a bit")
Cc: stable@...
Reported-by: NuoHan Qiao <qiaonuohan@...>
Suggested-by: Corey Minyard <cminyard@...>
Signed-off-by: Yang Yingliang <yangyingliang@...>
Signed-off-by: Corey Minyard <cminyard@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/char/ipmi/ipmi_si_intf.c
Modified: drivers/char/ipmi/ipmi_si_mem_io.c
Modified: drivers/char/ipmi/ipmi_si_port_io.c


[linux:lloyd-aviation] By NeilBrown <neil@...>:
7668d6e45f3a: dm: fix to_sector() for 32bit

commit 0bdb50c531f7377a9da80d3ce2d61f389c84cb30 upstream.

A dm-raid array with devices larger than 4GB won't assemble on
a 32 bit host since _check_data_dev_sectors() was added in 4.16.
This is because to_sector() treats its argument as an "unsigned long"
which is 32bits (4GB) on a 32bit host. Using "unsigned long long"
is more correct.

Kernels as early as 4.2 can have other problems due to to_sector()
being used on the size of a device.

Fixes: 0cf4503174c1 ("dm raid: add support for the MD RAID0 personality")
cc: stable@... (v4.2+)
Reported-and-tested-by: Guillaume Perréal <gperreal@...>
Signed-off-by: NeilBrown <neil@...>
Signed-off-by: Mike Snitzer <snitzer@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: include/linux/device-mapper.h


[linux:lloyd-aviation] By Mikulas Patocka <mpatocka@...>:
5579d97e92f7: dm integrity: limit the rate of error messages

commit 225557446856448039a9e495da37b72c20071ef2 upstream.

When using dm-integrity underneath md-raid, some tests with raid
auto-correction trigger large amounts of integrity failures - and all
these failures print an error message. These messages can bring the
system to a halt if the system is using serial console.

Fix this by limiting the rate of error messages - it improves the speed
of raid recovery and avoids the hang.

Fixes: 7eada909bfd7a ("dm: add integrity target")
Cc: stable@... # v4.12+
Signed-off-by: Mikulas Patocka <mpatocka@...>
Signed-off-by: Mike Snitzer <snitzer@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/md/dm-integrity.c


[linux:lloyd-aviation] By Gustavo A. R. Silva <gustavo@...>:
ce02d82c4e1a: mfd: sm501: Fix potential NULL pointer dereference

commit ae7b8eda27b33b1f688dfdebe4d46f690a8f9162 upstream.

There is a potential NULL pointer dereference in case devm_kzalloc()
fails and returns NULL.

Fix this by adding a NULL check on *lookup*

This bug was detected with the help of Coccinelle.

Fixes: b2e63555592f ("i2c: gpio: Convert to use descriptors")
Cc: stable@...
Signed-off-by: Gustavo A. R. Silva <gustavo@...>
Signed-off-by: Lee Jones <lee.jones@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/mfd/sm501.c


[linux:lloyd-aviation] By Pavel Machek <pavel@...>:
4ea4f347662c: cpcap-charger: generate events for userspace

commit fd10606f93a149a9f3d37574e5385b083b4a7b32 upstream.

The driver doesn't generate uevents on charger connect/disconnect.
This leads to UPower not detecting when AC is on or off... and that is
bad.

Reported by Arthur D. on github (
https://github.com/maemo-leste/bugtracker/issues/206 ), thanks to
Merlijn Wajer for suggesting a fix.

Cc: stable@...
Signed-off-by: Pavel Machek <pavel@...>
Acked-by: Tony Lindgren <tony@...>
Signed-off-by: Sebastian Reichel <sebastian.reichel@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/power/supply/cpcap-charger.c


[linux:lloyd-aviation] By Trond Myklebust <trond.myklebust@...>:
be74fddc976e: NFS: Fix I/O request leakages

commit f57dcf4c72113c745d83f1c65f7291299f65c14f upstream.

When we fail to add the request to the I/O queue, we currently leave it
to the caller to free the failed request. However since some of the
requests that fail are actually created by nfs_pageio_add_request()
itself, and are not passed back the caller, this leads to a leakage
issue, which can again cause page locks to leak.

This commit addresses the leakage by freeing the created requests on
error, using desc->pg_completion_ops->error_cleanup()

Signed-off-by: Trond Myklebust <trond.myklebust@...>
Fixes: a7d42ddb30997 ("nfs: add mirroring support to pgio layer")
Cc: stable@... # v4.0: c18b96a1b862: nfs: clean up rest of reqs
Cc: stable@... # v4.0: d600ad1f2bdb: NFS41: pop some layoutget
Cc: stable@... # v4.0+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/nfs/pagelist.c


[linux:lloyd-aviation] By Trond Myklebust <trond.myklebust@...>:
63b0ee126f7e: NFS: Fix an I/O request leakage in nfs_do_recoalesce

commit 4d91969ed4dbcefd0e78f77494f0cb8fada9048a upstream.

Whether we need to exit early, or just reprocess the list, we
must not lost track of the request which failed to get recoalesced.

Fixes: 03d5eb65b538 ("NFS: Fix a memory leak in nfs_do_recoalesce")
Signed-off-by: Trond Myklebust <trond.myklebust@...>
Cc: stable@... # v4.0+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/nfs/pagelist.c


[linux:lloyd-aviation] By Trond Myklebust <trond.myklebust@...>:
2c648caf630d: NFS: Don't recoalesce on error in nfs_pageio_complete_mirror()

commit 8127d82705998568b52ac724e28e00941538083d upstream.

If the I/O completion failed with a fatal error, then we should just
exit nfs_pageio_complete_mirror() rather than try to recoalesce.

Fixes: a7d42ddb3099 ("nfs: add mirroring support to pgio layer")
Signed-off-by: Trond Myklebust <trond.myklebust@...>
Cc: stable@... # v4.0+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/nfs/pagelist.c


[linux:lloyd-aviation] By J. Bruce Fields <bfields@...>:
10a68cdf1035: nfsd: fix performance-limiting session calculation

commit c54f24e338ed2a35218f117a4a1afb5f9e2b4e64 upstream.

We're unintentionally limiting the number of slots per nfsv4.1 session
to 10. Often more than 10 simultaneous RPCs are needed for the best
performance.

This calculation was meant to prevent any one client from using up more
than a third of the limit we set for total memory use across all clients
and sessions. Instead, it's limiting the client to a third of the
maximum for a single session.

Fix this.

Reported-by: Chris Tracy <ctracy@...>
Cc: stable@...
Fixes: de766e570413 "nfsd: give out fewer session slots as limit approaches"
Signed-off-by: J. Bruce Fields <bfields@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/nfsd/nfs4state.c


[linux:lloyd-aviation] By NeilBrown <neilb@...>:
8056912c1c75: nfsd: fix memory corruption caused by readdir

commit b602345da6cbb135ba68cf042df8ec9a73da7981 upstream.

If the result of an NFSv3 readdir{,plus} request results in the
"offset" on one entry having to be split across 2 pages, and is sized
so that the next directory entry doesn't fit in the requested size,
then memory corruption can happen.

When encode_entry() is called after encoding the last entry that fits,
it notices that ->offset and ->offset1 are set, and so stores the
offset value in the two pages as required. It clears ->offset1 but
*does not* clear ->offset.

Normally this omission doesn't matter as encode_entry_baggage() will
be called, and will set ->offset to a suitable value (not on a page
boundary).
But in the case where cd->buflen < elen and nfserr_toosmall is
returned, ->offset is not reset.

This means that nfsd3proc_readdirplus will see ->offset with a value 4
bytes before the end of a page, and ->offset1 set to NULL.
It will try to write 8bytes to ->offset.
If we are lucky, the next page will be read-only, and the system will
BUG: unable to handle kernel paging request at...

If we are unlucky, some innocent page will have the first 4 bytes
corrupted.

nfsd3proc_readdir() doesn't even check for ->offset1, it just blindly
writes 8 bytes to the offset wherever it is.

Fix this by clearing ->offset after it is used, and copying the
->offset handling code from nfsd3_proc_readdirplus into
nfsd3_proc_readdir.

(Note that the commit hash in the Fixes tag is from the 'history'
tree - this bug predates git).

Fixes: 0b1d57cf7654 ("[PATCH] kNFSd: Fix nfs3 dentry encoding")
Fixes-URL: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=0b1d57cf7654
Cc: stable@... (v2.6.12+)
Signed-off-by: NeilBrown <neilb@...>
Signed-off-by: J. Bruce Fields <bfields@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/nfsd/nfs3proc.c
Modified: fs/nfsd/nfs3xdr.c


[linux:lloyd-aviation] By Yihao Wu <wuyihao@...>:
ecab6ab1c227: nfsd: fix wrong check in write_v4_end_grace()

commit dd838821f0a29781b185cd8fb8e48d5c177bd838 upstream.

Commit 62a063b8e7d1 "nfsd4: fix crash on writing v4_end_grace before
nfsd startup" is trying to fix a NULL dereference issue, but it
mistakenly checks if the nfsd server is started. So fix it.

Fixes: 62a063b8e7d1 "nfsd4: fix crash on writing v4_end_grace before nfsd startup"
Cc: stable@...
Reviewed-by: Joseph Qi <joseph.qi@...>
Signed-off-by: Yihao Wu <wuyihao@...>
Signed-off-by: J. Bruce Fields <bfields@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/nfsd/nfsctl.c


[linux:lloyd-aviation] By Trond Myklebust <trond.myklebust@...>:
4af185feb9df: NFSv4.1: Reinitialise sequence results before retransmitting a request

commit c1dffe0bf7f9c3d57d9f237a7cb2a81e62babd2b upstream.

If we have to retransmit a request, we should ensure that we reinitialise
the sequence results structure, since in the event of a signal
we need to treat the request as if it had not been sent.

Signed-off-by: Trond Myklebust <trond.myklebust@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/nfs/nfs4proc.c


[linux:lloyd-aviation] By J. Bruce Fields <bfields@...>:
43bceddcd7e2: svcrpc: fix UDP on servers with lots of threads

commit b7e5034cbecf5a65b7bfdc2b20a8378039577706 upstream.

James Pearson found that an NFS server stopped responding to UDP
requests if started with more than 1017 threads.

sv_max_mesg is about 2^20, so that is probably where the calculation
performed by

svc_sock_setbufsize(svsk->sk_sock,
(serv->sv_nrthreads+3) * serv->sv_max_mesg,
(serv->sv_nrthreads+3) * serv->sv_max_mesg);

starts to overflow an int.

Reported-by: James Pearson <jcpearson@...>
Tested-by: James Pearson <jcpearson@...>
Cc: stable@...
Signed-off-by: J. Bruce Fields <bfields@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/sunrpc/svcsock.c


[linux:lloyd-aviation] By Viresh Kumar <viresh.kumar@...>:
cd73824636cb: PM / wakeup: Rework wakeup source timer cancellation

commit 1fad17fb1bbcd73159c2b992668a6957ecc5af8a upstream.

If wakeup_source_add() is called right after wakeup_source_remove()
for the same wakeup source, timer_setup() may be called for a
potentially scheduled timer which is incorrect.

To avoid that, move the wakeup source timer cancellation from
wakeup_source_drop() to wakeup_source_remove().

Moreover, make wakeup_source_remove() clear the timer function after
canceling the timer to let wakeup_source_not_registered() treat
unregistered wakeup sources in the same way as the ones that have
never been registered.

Signed-off-by: Viresh Kumar <viresh.kumar@...>
Cc: 4.4+ <stable@...> # 4.4+
[ rjw: Subject, changelog, merged two patches together ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/base/power/wakeup.c


[linux:lloyd-aviation] By Daniel Axtens <dja@...>:
622afe5c7449: bcache: never writeback a discard operation

commit 9951379b0ca88c95876ad9778b9099e19a95d566 upstream.

Some users see panics like the following when performing fstrim on a
bcached volume:

[ 529.803060] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 530.183928] #PF error: [normal kernel read fault]
[ 530.412392] PGD 8000001f42163067 P4D 8000001f42163067 PUD 1f42168067 PMD 0
[ 530.750887] Oops: 0000 [#1] SMP PTI
[ 530.920869] CPU: 10 PID: 4167 Comm: fstrim Kdump: loaded Not tainted 5.0.0-rc1+ #3
[ 531.290204] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 12/27/2015
[ 531.693137] RIP: 0010:blk_queue_split+0x148/0x620
[ 531.922205] Code: 60 38 89 55 a0 45 31 db 45 31 f6 45 31 c9 31 ff 89 4d 98 85 db 0f 84 7f 04 00 00 44 8b 6d 98 4c 89 ee 48 c1 e6 04 49 03 70 78 <8b> 46 08 44 8b 56 0c 48
8b 16 44 29 e0 39 d8 48 89 55 a8 0f 47 c3
[ 532.838634] RSP: 0018:ffffb9b708df39b0 EFLAGS: 00010246
[ 533.093571] RAX: 00000000ffffffff RBX: 0000000000046000 RCX: 0000000000000000
[ 533.441865] RDX: 0000000000000200 RSI: 0000000000000000 RDI: 0000000000000000
[ 533.789922] RBP: ffffb9b708df3a48 R08: ffff940d3b3fdd20 R09: 0000000000000000
[ 534.137512] R10: ffffb9b708df3958 R11: 0000000000000000 R12: 0000000000000000
[ 534.485329] R13: 0000000000000000 R14: 0000000000000000 R15: ffff940d39212020
[ 534.833319] FS: 00007efec26e3840(0000) GS:ffff940d1f480000(0000) knlGS:0000000000000000
[ 535.224098] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 535.504318] CR2: 0000000000000008 CR3: 0000001f4e256004 CR4: 00000000001606e0
[ 535.851759] Call Trace:
[ 535.970308] ? mempool_alloc_slab+0x15/0x20
[ 536.174152] ? bch_data_insert+0x42/0xd0 [bcache]
[ 536.403399] blk_mq_make_request+0x97/0x4f0
[ 536.607036] generic_make_request+0x1e2/0x410
[ 536.819164] submit_bio+0x73/0x150
[ 536.980168] ? submit_bio+0x73/0x150
[ 537.149731] ? bio_associate_blkg_from_css+0x3b/0x60
[ 537.391595] ? _cond_resched+0x1a/0x50
[ 537.573774] submit_bio_wait+0x59/0x90
[ 537.756105] blkdev_issue_discard+0x80/0xd0
[ 537.959590] ext4_trim_fs+0x4a9/0x9e0
[ 538.137636] ? ext4_trim_fs+0x4a9/0x9e0
[ 538.324087] ext4_ioctl+0xea4/0x1530
[ 538.497712] ? _copy_to_user+0x2a/0x40
[ 538.679632] do_vfs_ioctl+0xa6/0x600
[ 538.853127] ? __do_sys_newfstat+0x44/0x70
[ 539.051951] ksys_ioctl+0x6d/0x80
[ 539.212785] __x64_sys_ioctl+0x1a/0x20
[ 539.394918] do_syscall_64+0x5a/0x110
[ 539.568674] entry_SYSCALL_64_after_hwframe+0x44/0xa9

We have observed it where both:
1) LVM/devmapper is involved (bcache backing device is LVM volume) and
2) writeback cache is involved (bcache cache_mode is writeback)

On one machine, we can reliably reproduce it with:

# echo writeback > /sys/block/bcache0/bcache/cache_mode
(not sure whether above line is required)
# mount /dev/bcache0 /test
# for i in {0..10}; do
file="$(mktemp /test/zero.XXX)"
dd if=/dev/zero of="$file" bs=1M count=256
sync
rm $file
done
# fstrim -v /test

Observing this with tracepoints on, we see the following writes:

fstrim-18019 [022] .... 91107.302026: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4260112 + 196352 hit 0 bypass 1
fstrim-18019 [022] .... 91107.302050: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4456464 + 262144 hit 0 bypass 1
fstrim-18019 [022] .... 91107.302075: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4718608 + 81920 hit 0 bypass 1
fstrim-18019 [022] .... 91107.302094: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5324816 + 180224 hit 0 bypass 1
fstrim-18019 [022] .... 91107.302121: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5505040 + 262144 hit 0 bypass 1
fstrim-18019 [022] .... 91107.302145: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5767184 + 81920 hit 0 bypass 1
fstrim-18019 [022] .... 91107.308777: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 6373392 + 180224 hit 1 bypass 0
<crash>

Note the final one has different hit/bypass flags.

This is because in should_writeback(), we were hitting a case where
the partial stripe condition was returning true and so
should_writeback() was returning true early.

If that hadn't been the case, it would have hit the would_skip test, and
as would_skip == s->iop.bypass == true, should_writeback() would have
returned false.

Looking at the git history from 'commit 72c270612bd3 ("bcache: Write out
full stripes")', it looks like the idea was to optimise for raid5/6:

* If a stripe is already dirty, force writes to that stripe to
writeback mode - to help build up full stripes of dirty data

To fix this issue, make sure that should_writeback() on a discard op
never returns true.

More details of debugging:
https://www.spinics.net/lists/linux-bcache/msg06996.html

Previous reports:
- https://bugzilla.kernel.org/show_bug.cgi?id=201051
- https://bugzilla.kernel.org/show_bug.cgi?id=196103
- https://www.spinics.net/lists/linux-bcache/msg06885.html

(Coly Li: minor modification to follow maximum 75 chars per line rule)

Cc: Kent Overstreet <koverstreet@...>
Cc: stable@...
Fixes: 72c270612bd3 ("bcache: Write out full stripes")
Signed-off-by: Daniel Axtens <dja@...>
Signed-off-by: Coly Li <colyli@...>
Signed-off-by: Jens Axboe <axboe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/md/bcache/writeback.h


[linux:lloyd-aviation] By Greg Kroah-Hartman <gregkh@...>:
2ca85aac1213: stable-kernel-rules.rst: add link to networking patch queue

commit a41e8f25fa8f8f67360d88eb0eebbabe95a64bdf upstream.

The networking maintainer keeps a public list of the patches being
queued up for the next round of stable releases. Be sure to check there
before asking for a patch to be applied so that you do not waste
people's time.

Signed-off-by: Greg Kroah-Hartman <gregkh@...>
Acked-by: David S. Miller <davem@...>
Signed-off-by: Jonathan Corbet <corbet@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: Documentation/process/stable-kernel-rules.rst


[linux:lloyd-aviation] By Nicolas Pitre <nicolas.pitre@...>:
b05581b8ba9c: vt: perform safe console erase in the right order

commit a6dbe442755999960ca54a9b8ecfd9606be0ea75 upstream.

Commit 4b4ecd9cb853 ("vt: Perform safe console erase only once") removed
what appeared to be an extra call to scr_memsetw(). This missed the fact
that set_origin() must be called before clearing the screen otherwise
old screen content gets restored on the screen when using vgacon. Let's
fix that by moving all the scrollback handling to flush_scrollback()
where it logically belongs, and invoking it before the actual screen
clearing in csi_J(), making the code simpler in the end.

Reported-by: Matthew Whitehead <tedheadster@...>
Signed-off-by: Nicolas Pitre <nico@...>
Tested-by: Matthew Whitehead <tedheadster@...>
Fixes: 4b4ecd9cb853 ("vt: Perform safe console erase only once")
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/vt/vt.c


[linux:lloyd-aviation] By Josh Poimboeuf <jpoimboe@...>:
3e5a054b0f70: x86/unwind/orc: Fix ORC unwind table alignment

commit f76a16adc485699f95bb71fce114f97c832fe664 upstream.

The .orc_unwind section is a packed array of 6-byte structs. It's
currently aligned to 6 bytes, which is causing warnings in the LLD
linker.

Six isn't a power of two, so it's not a valid alignment value. The
actual alignment doesn't matter much because it's an array of packed
structs. An alignment of two is sufficient. In reality it always gets
aligned to four bytes because it comes immediately after the
4-byte-aligned .orc_unwind_ip section.

Fixes: ee9f8fce9964 ("x86/unwind: Add the ORC unwinder")
Reported-by: Nick Desaulniers <ndesaulniers@...>
Reported-by: Dmitry Golovin <dima@...>
Reported-by: Sedat Dilek <sedat.dilek@...>
Signed-off-by: Josh Poimboeuf <jpoimboe@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Tested-by: Sedat Dilek <sedat.dilek@...>
Cc: Peter Zijlstra <peterz@...>
Cc: stable@...
Link: https://github.com/ClangBuiltLinux/linux/issues/218
Link: https://lkml.kernel.org/r/d55027ee95fe73e952dcd8be90aebd31b0095c45.1551892041.git.jpoimboe@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: include/asm-generic/vmlinux.lds.h


[linux:lloyd-aviation] By Adrian Hunter <adrian.hunter@...>:
e25353a0ac44: perf intel-pt: Fix CYC timestamp calculation after OVF

commit 03997612904866abe7cdcc992784ef65cb3a4b81 upstream.

CYC packet timestamp calculation depends upon CBR which was being
cleared upon overflow (OVF). That can cause errors due to failing to
synchronize with sideband events. Even if a CBR change has been lost,
the old CBR is still a better estimate than zero. So remove the clearing
of CBR.

Signed-off-by: Adrian Hunter <adrian.hunter@...>
Cc: Jiri Olsa <jolsa@...>
Cc: stable@...
Link: http://lkml.kernel.org/r/20190206103947.15750-4-adrian.hunter@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: tools/perf/util/intel-pt-decoder/intel-pt-decoder.c


[linux:lloyd-aviation] By Adrian Hunter <adrian.hunter@...>:
d8f691f29d91: perf tools: Fix split_kallsyms_for_kcore() for trampoline symbols

commit d6d457451eb94fa747dc202765592eb8885a7352 upstream.

Kallsyms symbols do not have a size, so the size becomes the distance to
the next symbol.

Consequently the recently added trampoline symbols end up with large
sizes because the trampolines are some distance from one another and the
main kernel map.

However, symbols that end outside their map can disrupt the symbol tree
because, after mapping, it can appear incorrectly that they overlap
other symbols.

Add logic to truncate symbol size to the end of the corresponding map.

Signed-off-by: Adrian Hunter <adrian.hunter@...>
Acked-by: Jiri Olsa <jolsa@...>
Cc: stable@...
Fixes: d83212d5dd67 ("kallsyms, x86: Export addresses of PTI entry trampolines")
Link: http://lkml.kernel.org/r/20190109091835.5570-2-adrian.hunter@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: tools/perf/util/symbol.c


[linux:lloyd-aviation] By Adrian Hunter <adrian.hunter@...>:
fa592fc0bde5: perf auxtrace: Define auxtrace record alignment

commit c3fcadf0bb765faf45d6d562246e1d08885466df upstream.

Define auxtrace record alignment so that it can be referenced elsewhere.

Note this is preparation for patch "perf intel-pt: Fix overlap calculation
for padding"

Signed-off-by: Adrian Hunter <adrian.hunter@...>
Cc: Jiri Olsa <jolsa@...>
Cc: stable@...
Link: http://lkml.kernel.org/r/20190206103947.15750-2-adrian.hunter@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: tools/perf/util/auxtrace.c
Modified: tools/perf/util/auxtrace.h


[linux:lloyd-aviation] By Adrian Hunter <adrian.hunter@...>:
a46a8cdfea3c: perf intel-pt: Fix overlap calculation for padding

commit 5a99d99e3310a565b0cf63f785b347be9ee0da45 upstream.

Auxtrace records might have up to 7 bytes of padding appended. Adjust
the overlap accordingly.

Signed-off-by: Adrian Hunter <adrian.hunter@...>
Cc: Jiri Olsa <jolsa@...>
Cc: stable@...
Link: http://lkml.kernel.org/r/20190206103947.15750-3-adrian.hunter@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: tools/perf/util/intel-pt-decoder/intel-pt-decoder.c


[linux:lloyd-aviation] By Kan Liang <kan.liang@...>:
30cedf18d1e2: perf/x86/intel/uncore: Fix client IMC events return huge result

commit 8041ffd36f42d8521d66dd1e236feb58cecd68bc upstream.

The client IMC bandwidth events currently return very large values:

$ perf stat -e uncore_imc/data_reads/ -e uncore_imc/data_writes/ -I 10000 -a

10.000117222 34,788.76 MiB uncore_imc/data_reads/
10.000117222 8.26 MiB uncore_imc/data_writes/
20.000374584 34,842.89 MiB uncore_imc/data_reads/
20.000374584 10.45 MiB uncore_imc/data_writes/
30.000633299 37,965.29 MiB uncore_imc/data_reads/
30.000633299 323.62 MiB uncore_imc/data_writes/
40.000891548 41,012.88 MiB uncore_imc/data_reads/
40.000891548 6.98 MiB uncore_imc/data_writes/
50.001142480 1,125,899,906,621,494.75 MiB uncore_imc/data_reads/
50.001142480 6.97 MiB uncore_imc/data_writes/

The client IMC events are freerunning counters. They still use the
old event encoding format (0x1 for data_read and 0x2 for data write).
The counter bit width is calculated by common code, which assume that
the standard encoding format is used for the freerunning counters.
Error bit width information is calculated.

The patch intends to convert the old client IMC event encoding to the
standard encoding format.

Current common code uses event->attr.config which directly copy from
user space. We should not implicitly modify it for a converted event.
The event->hw.config is used to replace the event->attr.config in
common code.

For client IMC events, the event->attr.config is used to calculate a
converted event with standard encoding format in the custom
event_init(). The converted event is stored in event->hw.config.
For other events of freerunning counters, they already use the standard
encoding format. The same value as event->attr.config is assigned to
event->hw.config in common event_init().

Reported-by: Jin Yao <yao.jin@...>
Tested-by: Jin Yao <yao.jin@...>
Signed-off-by: Kan Liang <kan.liang@...>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...>
Cc: Alexander Shishkin <alexander.shishkin@...>
Cc: Andy Lutomirski <luto@...>
Cc: Arnaldo Carvalho de Melo <acme@...>
Cc: Borislav Petkov <bp@...>
Cc: Dave Hansen <dave.hansen@...>
Cc: H. Peter Anvin <hpa@...>
Cc: Jiri Olsa <jolsa@...>
Cc: Linus Torvalds <torvalds@...>
Cc: Peter Zijlstra <peterz@...>
Cc: Rik van Riel <riel@...>
Cc: Stephane Eranian <eranian@...>
Cc: Thomas Gleixner <tglx@...>
Cc: Vince Weaver <vincent.weaver@...>
Cc: stable@... # v4.18+
Fixes: 9aae1780e7e8 ("perf/x86/intel/uncore: Clean up client IMC uncore")
Link: https://lkml.kernel.org/r/20190227165729.1861-1-kan.liang@...
Signed-off-by: Ingo Molnar <mingo@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/events/intel/uncore.c
Modified: arch/x86/events/intel/uncore.h
Modified: arch/x86/events/intel/uncore_snb.c


[linux:lloyd-aviation] By Adrian Hunter <adrian.hunter@...>:
01088750f25e: perf intel-pt: Fix divide by zero when TSC is not available

commit 076333870c2f5bdd9b6d31e7ca1909cf0c84cbfa upstream.

When TSC is not available, "timeless" decoding is used but a divide by
zero occurs if perf_time_to_tsc() is called.

Ensure the divisor is not zero.

Signed-off-by: Adrian Hunter <adrian.hunter@...>
Cc: Jiri Olsa <jolsa@...>
Cc: stable@... # v4.9+
Link: https://lkml.kernel.org/n/tip-1i4j0wqoc8vlbkcizqqxpsf4@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: tools/perf/util/intel-pt.c


[linux:lloyd-aviation] By Aditya Pakki <pakki001@...>:
cc3b79d487e8: md: Fix failed allocation of md_register_thread

commit e406f12dde1a8375d77ea02d91f313fb1a9c6aec upstream.

mddev->sync_thread can be set to NULL on kzalloc failure downstream.
The patch checks for such a scenario and frees allocated resources.

Committer node:

Added similar fix to raid5.c, as suggested by Guoqing.

Cc: stable@... # v3.16+
Acked-by: Guoqing Jiang <gqjiang@...>
Signed-off-by: Aditya Pakki <pakki001@...>
Signed-off-by: Song Liu <songliubraving@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/md/raid10.c
Modified: drivers/md/raid5.c


[linux:lloyd-aviation] By Jarkko Sakkinen <jarkko.sakkinen@...>:
af0c1bd0c5e9: tpm/tpm_crb: Avoid unaligned reads in crb_recv()

commit 3d7a850fdc1a2e4d2adbc95cc0fc962974725e88 upstream.

The current approach to read first 6 bytes from the response and then tail
of the response, can cause the 2nd memcpy_fromio() to do an unaligned read
(e.g. read 32-bit word from address aligned to a 16-bits), depending on how
memcpy_fromio() is implemented. If this happens, the read will fail and the
memory controller will fill the read with 1's.

This was triggered by 170d13ca3a2f, which should be probably refined to
check and react to the address alignment. Before that commit, on x86
memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
thing (from tpm_crb's perspective) for us so far, but we should not rely on
that. Thus, it makes sense to fix this also in tpm_crb, not least because
the fix can be then backported to stable kernels and make them more robust
when compiled in differing environments.

Cc: stable@...
Cc: James Morris <jmorris@...>
Cc: Tomas Winkler <tomas.winkler@...>
Cc: Jerry Snitselaar <jsnitsel@...>
Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...>
Reviewed-by: Jerry Snitselaar <jsnitsel@...>
Acked-by: Tomas Winkler <tomas.winkler@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/char/tpm/tpm_crb.c


[linux:lloyd-aviation] By Jarkko Sakkinen <jarkko.sakkinen@...>:
bce45a547546: tpm: Unify the send callback behaviour

commit f5595f5baa30e009bf54d0d7653a9a0cc465be60 upstream.

The send() callback should never return length as it does not in every
driver except tpm_crb in the success case. The reason is that the main
transmit functionality only cares about whether the transmit was
successful or not and ignores the count completely.

Suggested-by: Stefan Berger <stefanb@...>
Cc: stable@...
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...>
Reviewed-by: Stefan Berger <stefanb@...>
Reviewed-by: Jerry Snitselaar <jsnitsel@...>
Tested-by: Alexander Steffen <Alexander.Steffen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/char/tpm/st33zp24/st33zp24.c
Modified: drivers/char/tpm/tpm-interface.c
Modified: drivers/char/tpm/tpm_atmel.c
Modified: drivers/char/tpm/tpm_i2c_atmel.c
Modified: drivers/char/tpm/tpm_i2c_infineon.c
Modified: drivers/char/tpm/tpm_i2c_nuvoton.c
Modified: drivers/char/tpm/tpm_ibmvtpm.c
Modified: drivers/char/tpm/tpm_infineon.c
Modified: drivers/char/tpm/tpm_nsc.c
Modified: drivers/char/tpm/tpm_tis_core.c
Modified: drivers/char/tpm/tpm_vtpm_proxy.c
Modified: drivers/char/tpm/xen-tpmfront.c


[linux:lloyd-aviation] By Zhang, Jun <jun.zhang@...>:
e97a32a5a3bc: rcu: Do RCU GP kthread self-wakeup from softirq and interrupt

commit 1d1f898df6586c5ea9aeaf349f13089c6fa37903 upstream.

The rcu_gp_kthread_wake() function is invoked when it might be necessary
to wake the RCU grace-period kthread. Because self-wakeups are normally
a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from
this kthread, it naturally refuses to do the wakeup.

Unfortunately, natural though it might be, this heuristic fails when
rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler
that interrupted the grace-period kthread just after the final check of
the wait-event condition but just before the schedule() call. In this
case, a wakeup is required, even though the call to rcu_gp_kthread_wake()
is within the RCU grace-period kthread's context. Failing to provide
this wakeup can result in grace periods failing to start, which in turn
results in out-of-memory conditions.

This race window is quite narrow, but it actually did happen during real
testing. It would of course need to be fixed even if it was strictly
theoretical in nature.

This patch does not Cc stable because it does not apply cleanly to
earlier kernel versions.

Fixes: 48a7639ce80c ("rcu: Make callers awaken grace-period kthread")
Reported-by: "He, Bo" <bo.he@...>
Co-developed-by: "Zhang, Jun" <jun.zhang@...>
Co-developed-by: "He, Bo" <bo.he@...>
Co-developed-by: "xiao, jin" <jin.xiao@...>
Co-developed-by: Bai, Jie A <jie.a.bai@...>
Signed-off: "Zhang, Jun" <jun.zhang@...>
Signed-off: "He, Bo" <bo.he@...>
Signed-off: "xiao, jin" <jin.xiao@...>
Signed-off: Bai, Jie A <jie.a.bai@...>
Signed-off-by: "Zhang, Jun" <jun.zhang@...>
[ paulmck: Switch from !in_softirq() to "!in_interrupt() &&
!in_serving_softirq() to avoid redundant wakeups and to also handle the
interrupt-handler scenario as well as the softirq-handler scenario that
actually occurred in testing. ]
Signed-off-by: Paul E. McKenney <paulmck@...>
Link: https://lkml.kernel.org/r/CD6925E8781EFD4D8E11882D20FC406D52A11F61@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/rcu/tree.c


[linux:lloyd-aviation] By Steve Longerbeam <slongerbeam@...>:
6039128dc6bf: media: imx: prpencvf: Stop upstream before disabling IDMA channel

commit a19c22677377b87e4354f7306f46ad99bc982a9f upstream.

Upstream must be stopped immediately after receiving the last EOF and
before disabling the IDMA channel. This can be accomplished by moving
upstream stream off to just after receiving the last EOF completion in
prp_stop(). For symmetry also move upstream stream on to end of
prp_start().

This fixes a complete system hard lockup on the SabreAuto when streaming
from the ADV7180, by repeatedly sending a stream off immediately followed
by stream on:

while true; do v4l2-ctl -d1 --stream-mmap --stream-count=3; done

Eventually this either causes the system lockup or EOF timeouts at all
subsequent stream on, until a system reset.

The lockup occurs when disabling the IDMA channel at stream off. Stopping
the video data stream entering the IDMA channel before disabling the
channel itself appears to be a reliable fix for the hard lockup.

Fixes: f0d9c8924e2c3 ("[media] media: imx: Add IC subdev drivers")

Reported-by: Gaël PORTAY <gael.portay@...>
Tested-by: Gaël PORTAY <gael.portay@...>
Signed-off-by: Steve Longerbeam <slongerbeam@...>
Cc: stable@... # for 4.13 and up
Signed-off-by: Hans Verkuil <hverkuil-cisco@...>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/media/imx/imx-ic-prpencvf.c


[linux:lloyd-aviation] By French, Nicholas A <naf@...>:
77b4e7454bbd: media: lgdt330x: fix lock status reporting

commit 1b4fd9de6ec7f3722c2b3e08cc5ad171c11f93be upstream.

A typo in code cleanup commit db9c1007bc07 ("media: lgdt330x: do
some cleanups at status logic") broke the FE_HAS_LOCK reporting
for 3303 chips by inadvertently modifying the register mask.

The broken lock status is critial as it prevents video capture
cards from reporting signal strength, scanning for channels,
and capturing video.

Fix regression by reverting mask change.

Cc: stable@... # Kernel 4.17+
Fixes: db9c1007bc07 ("media: lgdt330x: do some cleanups at status logic")
Signed-off-by: Nick French <naf@...>
Reviewed-by: Laurent Pinchart <laurent.pinchart@...>
Tested-by: Adam Stylinski <kungfujesus06@...>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/media/dvb-frontends/lgdt330x.c


[linux:lloyd-aviation] By Sakari Ailus <sakari.ailus@...>:
29e8c9ae99c7: media: uvcvideo: Avoid NULL pointer dereference at the end of streaming

commit 9dd0627d8d62a7ddb001a75f63942d92b5336561 upstream.

The UVC video driver converts the timestamp from hardware specific unit
to one known by the kernel at the time when the buffer is dequeued. This
is fine in general, but the streamoff operation consists of the
following steps (among other things):

1. uvc_video_clock_cleanup --- the hardware clock sample array is
released and the pointer to the array is set to NULL,

2. buffers in active state are returned to the user and

3. buf_finish callback is called on buffers that are prepared.
buf_finish includes calling uvc_video_clock_update that accesses the
hardware clock sample array.

The above is serialised by a queue specific mutex. Address the problem
by skipping the clock conversion if the hardware clock sample array is
already released.

Fixes: 9c0863b1cc48 ("[media] vb2: call buf_finish from __queue_cancel")

Reported-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@...>
Tested-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@...>
Signed-off-by: Sakari Ailus <sakari.ailus@...>
Cc: stable@...
Signed-off-by: Laurent Pinchart <laurent.pinchart@...>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/media/usb/uvc/uvc_video.c


[linux:lloyd-aviation] By Lucas A. M. Magalhães <lucmaga@...>:
73236bf581e9: media: vimc: Add vimc-streamer for stream control

commit adc589d2a20808fb99d46a78175cd023f2040338 upstream.

Add a linear pipeline logic for the stream control. It's created by
walking backwards on the entity graph. When the stream starts it will
simply loop through the pipeline calling the respective process_frame
function of each entity.

Fixes: f2fe89061d797 ("vimc: Virtual Media Controller core, capture
and sensor")

Cc: stable@... # for v4.20
Signed-off-by: Lucas A. M. Magalhães <lucmaga@...>
Acked-by: Helen Koike <helen.koike@...>
Signed-off-by: Hans Verkuil <hverkuil-cisco@...>
[hverkuil-cisco@...: fixed small space-after-tab issue in the patch]
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Added: drivers/media/platform/vimc/vimc-streamer.c
Added: drivers/media/platform/vimc/vimc-streamer.h
Modified: drivers/media/platform/vimc/Makefile
Modified: drivers/media/platform/vimc/vimc-capture.c
Modified: drivers/media/platform/vimc/vimc-common.c
Modified: drivers/media/platform/vimc/vimc-common.h
Modified: drivers/media/platform/vimc/vimc-debayer.c
Modified: drivers/media/platform/vimc/vimc-scaler.c
Modified: drivers/media/platform/vimc/vimc-sensor.c


[linux:lloyd-aviation] By Steve Longerbeam <slongerbeam@...>:
54b941202391: media: imx: csi: Disable CSI immediately after last EOF

commit 2e0fe66e0a136252f4d89dbbccdcb26deb867eb8 upstream.

Disable the CSI immediately after receiving the last EOF before stream
off (and thus before disabling the IDMA channel). Do this by moving the
wait for EOF completion into a new function csi_idmac_wait_last_eof().

This fixes a complete system hard lockup on the SabreAuto when streaming
from the ADV7180, by repeatedly sending a stream off immediately followed
by stream on:

while true; do v4l2-ctl -d4 --stream-mmap --stream-count=3; done

Eventually this either causes the system lockup or EOF timeouts at all
subsequent stream on, until a system reset.

The lockup occurs when disabling the IDMA channel at stream off. Disabling
the CSI before disabling the IDMA channel appears to be a reliable fix for
the hard lockup.

Fixes: 4a34ec8e470cb ("[media] media: imx: Add CSI subdev driver")

Reported-by: Gaël PORTAY <gael.portay@...>
Signed-off-by: Steve Longerbeam <slongerbeam@...>
Cc: stable@... # for 4.13 and up
Signed-off-by: Hans Verkuil <hverkuil-cisco@...>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/media/imx/imx-media-csi.c


[linux:lloyd-aviation] By Steve Longerbeam <slongerbeam@...>:
87bfc7b695bd: media: imx: csi: Stop upstream before disabling IDMA channel

commit 4bc1ab41eee9d02ad2483bf8f51a7b72e3504eba upstream.

Move upstream stream off to just after receiving the last EOF completion
and disabling the CSI (and thus before disabling the IDMA channel) in
csi_stop(). For symmetry also move upstream stream on to beginning of
csi_start().

Doing this makes csi_s_stream() more symmetric with prp_s_stream() which
will require the same change to fix a hard lockup.

Signed-off-by: Steve Longerbeam <slongerbeam@...>
Cc: stable@... # for 4.13 and up
Signed-off-by: Hans Verkuil <hverkuil-cisco@...>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/media/imx/imx-media-csi.c


[linux:lloyd-aviation] By Noralf Trønnes <noralf@...>:
9bc6e5673949: drm/fb-helper: generic: Fix drm_fbdev_client_restore()

commit 78de14c23e031420aa5f61973583635eccd6cd2a upstream.

If fbdev setup has failed, lastclose will give a NULL pointer deref:

[ 77.794295] [drm:drm_lastclose]
[ 77.794414] [drm:drm_lastclose] driver lastclose completed
[ 77.794660] Unable to handle kernel NULL pointer dereference at virtual address 00000014
[ 77.809460] pgd = b376b71b
[ 77.818275] [00000014] *pgd=175ba831, *pte=00000000, *ppte=00000000
[ 77.830813] Internal error: Oops: 17 [#1] ARM
[ 77.840963] Modules linked in: mi0283qt mipi_dbi tinydrm raspberrypi_hwmon gpio_backlight backlight snd_bcm2835(C) bcm2835_rng rng_core
[ 77.865203] CPU: 0 PID: 527 Comm: lt-modetest Tainted: G C 5.0.0-rc1+ #1
[ 77.879525] Hardware name: BCM2835
[ 77.889185] PC is at restore_fbdev_mode+0x20/0x164
[ 77.900261] LR is at drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c
[ 78.002446] Process lt-modetest (pid: 527, stack limit = 0x7a3d5c14)
[ 78.291030] Backtrace:
[ 78.300815] [<c04f2d0c>] (restore_fbdev_mode) from [<c04f4708>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c)
[ 78.319095] r9:d8a8a288 r8:d891acf0 r7:d7697910 r6:00000000 r5:d891ac00 r4:d891ac00
[ 78.334432] [<c04f46b4>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c04f47e8>] (drm_fbdev_client_restore+0x18/0x20)
[ 78.353296] r8:d76978c0 r7:d7697910 r6:d7697950 r5:d7697800 r4:d891ac00 r3:c04f47d0
[ 78.368689] [<c04f47d0>] (drm_fbdev_client_restore) from [<c051b6b4>] (drm_client_dev_restore+0x7c/0xc0)
[ 78.385982] [<c051b638>] (drm_client_dev_restore) from [<c04f8fd0>] (drm_lastclose+0xc4/0xd4)
[ 78.402332] r8:d76978c0 r7:d7471080 r6:c0e0c088 r5:d8a85e00 r4:d7697800
[ 78.416688] [<c04f8f0c>] (drm_lastclose) from [<c04f9088>] (drm_release+0xa8/0x10c)
[ 78.431929] r5:d8a85e00 r4:d7697800
[ 78.442989] [<c04f8fe0>] (drm_release) from [<c02640c4>] (__fput+0x104/0x1c8)
[ 78.457740] r8:d5ccea10 r7:d96cfb10 r6:00000008 r5:d74c1b90 r4:d8a8a280
[ 78.472043] [<c0263fc0>] (__fput) from [<c02641ec>] (____fput+0x18/0x1c)
[ 78.486363] r10:00000006 r9:d7722000 r8:c01011c4 r7:00000000 r6:c0ebac6c r5:d892a340
[ 78.501869] r4:d8a8a280
[ 78.512002] [<c02641d4>] (____fput) from [<c013ef1c>] (task_work_run+0x98/0xac)
[ 78.527186] [<c013ee84>] (task_work_run) from [<c010cc54>] (do_work_pending+0x4f8/0x570)
[ 78.543238] r7:d7722030 r6:00000004 r5:d7723fb0 r4:00000000
[ 78.556825] [<c010c75c>] (do_work_pending) from [<c0101034>] (slow_work_pending+0xc/0x20)
[ 78.674256] ---[ end trace 70d3a60cf739be3b ]---

Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use.

Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation")
Cc: stable@...
Signed-off-by: Noralf Trønnes <noralf@...>
Reviewed-by: Gerd Hoffmann <kraxel@...>
Link: https://patchwork.freedesktop.org/patch/msgid/20190125150300.33268-1-noralf@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/drm_fb_helper.c


[linux:lloyd-aviation] By Gustavo A. R. Silva <gustavo@...>:
808b1c1e28e8: drm/radeon/evergreen_cs: fix missing break in switch statement

commit cc5034a5d293dd620484d1d836aa16c6764a1c8c upstream.

Add missing break statement in order to prevent the code from falling
through to case CB_TARGET_MASK.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: dd220a00e8bd ("drm/radeon/kms: add support for streamout v7")
Cc: stable@...
Signed-off-by: Gustavo A. R. Silva <gustavo@...>
Signed-off-by: Alex Deucher <alexander.deucher@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/radeon/evergreen_cs.c


[linux:lloyd-aviation] By Evan Quan <evan.quan@...>:
17982c6a649b: drm/amd/powerplay: correct power reading on fiji

commit f5742ec36422a39b57f0256e4847f61b3c432f8c upstream.

Set sampling period as 500ms to provide a smooth power
reading output. Also, correct the register for power
reading.

Signed-off-by: Evan Quan <evan.quan@...>
Reviewed-by: Feifei Xu <Feifei.Xu@...>
Signed-off-by: Alex Deucher <alexander.deucher@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c


[linux:lloyd-aviation] By Harry Wentland <harry.wentland@...>:
585715ef18bf: drm/amd/display: don't call dm_pp_ function from an fpu block

commit 59d3191f14dc18881fec1172c7096b7863622803 upstream.

Powerplay functions called from dm_pp_* functions tend to do a
mutex_lock which isn't safe to do inside a kernel_fpu_begin/end block as
those will disable/enable preemption.

Rearrange the dm_pp_get_clock_levels_by_type_with_voltage calls to make
sure they happen outside of kernel_fpu_begin/end.

Cc: stable@...
Acked-by: Alex Deucher <alexander.deucher@...>
Signed-off-by: Harry Wentland <harry.wentland@...>
Signed-off-by: Alex Deucher <alexander.deucher@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c


[linux:lloyd-aviation] By Sean Christopherson <sean.j.christopherson@...>:
23ad135ae66f: KVM: Call kvm_arch_memslots_updated() before updating memslots

commit 152482580a1b0accb60676063a1ac57b2d12daf6 upstream.

kvm_arch_memslots_updated() is at this point in time an x86-specific
hook for handling MMIO generation wraparound. x86 stashes 19 bits of
the memslots generation number in its MMIO sptes in order to avoid
full page fault walks for repeat faults on emulated MMIO addresses.
Because only 19 bits are used, wrapping the MMIO generation number is
possible, if unlikely. kvm_arch_memslots_updated() alerts x86 that
the generation has changed so that it can invalidate all MMIO sptes in
case the effective MMIO generation has wrapped so as to avoid using a
stale spte, e.g. a (very) old spte that was created with generation==0.

Given that the purpose of kvm_arch_memslots_updated() is to prevent
consuming stale entries, it needs to be called before the new generation
is propagated to memslots. Invalidating the MMIO sptes after updating
memslots means that there is a window where a vCPU could dereference
the new memslots generation, e.g. 0, and incorrectly reuse an old MMIO
spte that was created with (pre-wrap) generation==0.

Fixes: e59dbe09f8e6 ("KVM: Introduce kvm_arch_memslots_updated()")
Cc: <stable@...>
Signed-off-by: Sean Christopherson <sean.j.christopherson@...>
Signed-off-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/mips/include/asm/kvm_host.h
Modified: arch/powerpc/include/asm/kvm_host.h
Modified: arch/s390/include/asm/kvm_host.h
Modified: arch/x86/include/asm/kvm_host.h
Modified: arch/x86/kvm/mmu.c
Modified: arch/x86/kvm/x86.c
Modified: include/linux/kvm_host.h
Modified: virt/kvm/arm/mmu.c
Modified: virt/kvm/kvm_main.c


[linux:lloyd-aviation] By Sean Christopherson <sean.j.christopherson@...>:
656e9e5d5529: KVM: x86/mmu: Detect MMIO generation wrap in any address space

commit e1359e2beb8b0a1188abc997273acbaedc8ee791 upstream.

The check to detect a wrap of the MMIO generation explicitly looks for a
generation number of zero. Now that unique memslots generation numbers
are assigned to each address space, only address space 0 will get a
generation number of exactly zero when wrapping. E.g. when address
space 1 goes from 0x7fffe to 0x80002, the MMIO generation number will
wrap to 0x2. Adjust the MMIO generation to strip the address space
modifier prior to checking for a wrap.

Fixes: 4bd518f1598d ("KVM: use separate generations for each address space")
Cc: <stable@...>
Signed-off-by: Sean Christopherson <sean.j.christopherson@...>
Signed-off-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/kvm/mmu.c


[linux:lloyd-aviation] By Sean Christopherson <sean.j.christopherson@...>:
c235af5a10f2: KVM: x86/mmu: Do not cache MMIO accesses while memslots are in flux

commit ddfd1730fd829743e41213e32ccc8b4aa6dc8325 upstream.

When installing new memslots, KVM sets bit 0 of the generation number to
indicate that an update is in-progress. Until the update is complete,
there are no guarantees as to whether a vCPU will see the old or the new
memslots. Explicity prevent caching MMIO accesses so as to avoid using
an access cached from the old memslots after the new memslots have been
installed.

Note that it is unclear whether or not disabling caching during the
update window is strictly necessary as there is no definitive
documentation as to what ordering guarantees KVM provides with respect
to updating memslots. That being said, the MMIO spte code does not
allow reusing sptes created while an update is in-progress, and the
associated documentation explicitly states:

We do not want to use an MMIO sptes created with an odd generation
number, ... If KVM is unlucky and creates an MMIO spte while the
low bit is 1, the next access to the spte will always be a cache miss.

At the very least, disabling the per-vCPU MMIO cache during updates will
make its behavior consistent with the MMIO spte behavior and
documentation.

Fixes: 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug")
Cc: <stable@...>
Signed-off-by: Sean Christopherson <sean.j.christopherson@...>
Signed-off-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/kvm/x86.h


[linux:lloyd-aviation] By Sean Christopherson <sean.j.christopherson@...>:
9ce0ffeb68b6: KVM: nVMX: Sign extend displacements of VMX instr's mem operands

commit 946c522b603f281195af1df91837a1d4d1eb3bc9 upstream.

The VMCS.EXIT_QUALIFCATION field reports the displacements of memory
operands for various instructions, including VMX instructions, as a
naturally sized unsigned value, but masks the value by the addr size,
e.g. given a ModRM encoded as -0x28(%ebp), the -0x28 displacement is
reported as 0xffffffd8 for a 32-bit address size. Despite some weird
wording regarding sign extension, the SDM explicitly states that bits
beyond the instructions address size are undefined:

In all cases, bits of this field beyond the instruction’s address
size are undefined.

Failure to sign extend the displacement results in KVM incorrectly
treating a negative displacement as a large positive displacement when
the address size of the VMX instruction is smaller than KVM's native
size, e.g. a 32-bit address size on a 64-bit KVM.

The very original decoding, added by commit 064aea774768 ("KVM: nVMX:
Decoding memory operands of VMX instructions"), sort of modeled sign
extension by truncating the final virtual/linear address for a 32-bit
address size. I.e. it messed up the effective address but made it work
by adjusting the final address.

When segmentation checks were added, the truncation logic was kept
as-is and no sign extension logic was introduced. In other words, it
kept calculating the wrong effective address while mostly generating
the correct virtual/linear address. As the effective address is what's
used in the segment limit checks, this results in KVM incorreclty
injecting #GP/#SS faults due to non-existent segment violations when
a nested VMM uses negative displacements with an address size smaller
than KVM's native address size.

Using the -0x28(%ebp) example, an EBP value of 0x1000 will result in
KVM using 0x100000fd8 as the effective address when checking for a
segment limit violation. This causes a 100% failure rate when running
a 32-bit KVM build as L1 on top of a 64-bit KVM L0.

Fixes: f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions")
Cc: stable@...
Signed-off-by: Sean Christopherson <sean.j.christopherson@...>
Signed-off-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/kvm/vmx.c


[linux:lloyd-aviation] By Sean Christopherson <sean.j.christopherson@...>:
29b515c27c0a: KVM: nVMX: Apply addr size mask to effective address for VMX instructions

commit 8570f9e881e3fde98801bb3a47eef84dd934d405 upstream.

The address size of an instruction affects the effective address, not
the virtual/linear address. The final address may still be truncated,
e.g. to 32-bits outside of long mode, but that happens irrespective of
the address size, e.g. a 32-bit address size can yield a 64-bit virtual
address when using FS/GS with a non-zero base.

Fixes: 064aea774768 ("KVM: nVMX: Decoding memory operands of VMX instructions")
Cc: stable@...
Signed-off-by: Sean Christopherson <sean.j.christopherson@...>
Signed-off-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/kvm/vmx.c


[linux:lloyd-aviation] By Sean Christopherson <sean.j.christopherson@...>:
5ffb710b03d5: KVM: nVMX: Ignore limit checks on VMX instructions using flat segments

commit 34333cc6c2cb021662fd32e24e618d1b86de95bf upstream.

Regarding segments with a limit==0xffffffff, the SDM officially states:

When the effective limit is FFFFFFFFH (4 GBytes), these accesses may
or may not cause the indicated exceptions. Behavior is
implementation-specific and may vary from one execution to another.

In practice, all CPUs that support VMX ignore limit checks for "flat
segments", i.e. an expand-up data or code segment with base=0 and
limit=0xffffffff. This is subtly different than wrapping the effective
address calculation based on the address size, as the flat segment
behavior also applies to accesses that would wrap the 4g boundary, e.g.
a 4-byte access starting at 0xffffffff will access linear addresses
0xffffffff, 0x0, 0x1 and 0x2.

Fixes: f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions")
Cc: stable@...
Signed-off-by: Sean Christopherson <sean.j.christopherson@...>
Signed-off-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/kvm/vmx.c


[linux:lloyd-aviation] By Coly Li <colyli@...>:
e578f90d8a9c: bcache: use (REQ_META|REQ_PRIO) to indicate bio for metadata

commit dc7292a5bcb4c878b076fca2ac3fc22f81b8f8df upstream.

In 'commit 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for
metadata")' REQ_META is replaced by REQ_PRIO to indicate metadata bio.
This assumption is not always correct, e.g. XFS uses REQ_META to mark
metadata bio other than REQ_PRIO. This is why Nix noticed that bcache
does not cache metadata for XFS after the above commit.

Thanks to Dave Chinner, he explains the difference between REQ_META and
REQ_PRIO from view of file system developer. Here I quote part of his
explanation from mailing list,
REQ_META is used for metadata. REQ_PRIO is used to communicate to
the lower layers that the submitter considers this IO to be more
important that non REQ_PRIO IO and so dispatch should be expedited.

IOWs, if the filesystem considers metadata IO to be more important
that user data IO, then it will use REQ_PRIO | REQ_META rather than
just REQ_META.

Then it seems bios with REQ_META or REQ_PRIO should both be cached for
performance optimation, because they are all probably low I/O latency
demand by upper layer (e.g. file system).

So in this patch, when we want to decide whether to bypass the cache,
REQ_META and REQ_PRIO are both checked. Then both metadata and
high priority I/O requests will be handled properly.

Reported-by: Nix <nix@...>
Signed-off-by: Coly Li <colyli@...>
Reviewed-by: Andre Noll <maan@...>
Tested-by: Nix <nix@...>
Cc: stable@...
Cc: Dave Chinner <david@...>
Cc: Christoph Hellwig <hch@...>
Signed-off-by: Jens Axboe <axboe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/md/bcache/request.c


[linux:lloyd-aviation] By Martin Schwidefsky <schwidefsky@...>:
3053cb9701cd: s390/setup: fix boot crash for machine without EDAT-1

commit 86a86804e4f18fc3880541b3d5a07f4df0fe29cb upstream.

The fix to make WARN work in the early boot code created a problem
on older machines without EDAT-1. The setup_lowcore_dat_on function
uses the pointer from lowcore_ptr[0] to set the DAT bit in the new
PSWs. That does not work if the kernel page table is set up with
4K pages as the prefix address maps to absolute zero.

To make this work the PSWs need to be changed with via address 0 in
form of the S390_lowcore definition.

Reported-by: Guenter Roeck <linux@...>
Tested-by: Cornelia Huck <cohuck@...>
Fixes: 94f85ed3e2f8 ("s390/setup: fix early warning messages")
Signed-off-by: Martin Schwidefsky <schwidefsky@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/s390/kernel/setup.c


[linux:lloyd-aviation] By Greg Kroah-Hartman <gregkh@...>:
a2cddfe2ce6e: Linux 4.19.31

Modified: Makefile


[linux:lloyd-aviation] By Jaroslav Kysela <perex@...>:
023a1b28cf72: ALSA: hda - add Lenovo IdeaCentre B550 to the power_save_blacklist

commit 721f1e6c1fd137e7e2053d8e103b666faaa2d50c upstream.

Another machine which does not like the power saving (noise):
https://bugzilla.redhat.com/show_bug.cgi?id=1689623

Also, reorder the Lenovo C50 entry to keep the table sorted.

Reported-by: hs.guimaraes@...
Signed-off-by: Jaroslav Kysela <perex@...>
Cc: <stable@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/hda_intel.c


[linux:lloyd-aviation] By Takashi Sakamoto <o-takashi@...>:
6339cc5181c0: ALSA: firewire-motu: use 'version' field of unit directory to identify model

commit 2d012c65a9ca26a0ef87ea0a42f1653dd37155f5 upstream.

Current ALSA firewire-motu driver uses the value of 'model' field
of unit directory in configuration ROM for modalias for MOTU
FireWire models. However, as long as I checked, Pre8 and
828mk3(Hybrid) have the same value for the field (=0x100800).

unit | version | model
--------------- | --------- | ----------
828mkII | 0x000003 | 0x101800
Traveler | 0x000009 | 0x107800
Pre8 | 0x00000f | 0x100800 <-
828mk3(FW) | 0x000015 | 0x106800
AudioExpress | 0x000033 | 0x104800
828mk3(Hybrid) | 0x000035 | 0x100800 <-

When updating firmware for MOTU 8pre FireWire from v1.0.0 to v1.0.3,
I got change of the value from 0x100800 to 0x103800. On the other
hand, the value of 'version' field is fixed to 0x00000f. As a quick
glance, the higher 12 bits of the value of 'version' field represent
firmware version, while the lower 12 bits is unknown.

By induction, the value of 'version' field represents actual model.

This commit changes modalias to match the value of 'version' field,
instead of 'model' field. For degug, long name of added sound card
includes hexadecimal value of 'model' field.

Fixes: 6c5e1ac0e144 ("ALSA: firewire-motu: add support for Motu Traveler")
Signed-off-by: Takashi Sakamoto <o-takashi@...>
Cc: <stable@...> # v4.19+
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/firewire/motu/motu.c


[linux:lloyd-aviation] By Arnd Bergmann <arnd@...>:
3b6870159e2e: mmc: pxamci: fix enum type confusion

commit e60a582bcde01158a64ff948fb799f21f5d31a11 upstream.

clang points out several instances of mismatched types in this drivers,
all coming from a single declaration:

drivers/mmc/host/pxamci.c:193:15: error: implicit conversion from enumeration type 'enum dma_transfer_direction' to
different enumeration type 'enum dma_data_direction' [-Werror,-Wenum-conversion]
direction = DMA_DEV_TO_MEM;
~ ^~~~~~~~~~~~~~
drivers/mmc/host/pxamci.c:212:62: error: implicit conversion from enumeration type 'enum dma_data_direction' to
different enumeration type 'enum dma_transfer_direction' [-Werror,-Wenum-conversion]
tx = dmaengine_prep_slave_sg(chan, data->sg, host->dma_len, direction,

The behavior is correct, so this must be a simply typo from
dma_data_direction and dma_transfer_direction being similarly named
types with a similar purpose.

Fixes: 6464b7140951 ("mmc: pxamci: switch over to dmaengine use")
Signed-off-by: Arnd Bergmann <arnd@...>
Reviewed-by: Nathan Chancellor <natechancellor@...>
Acked-by: Robert Jarzmik <robert.jarzmik@...>
Cc: stable@...
Signed-off-by: Ulf Hansson <ulf.hansson@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/mmc/host/pxamci.c


[linux:lloyd-aviation] By Alexander Shiyan <shc_work@...>:
65a5c93687b7: mmc: mxcmmc: "Revert mmc: mxcmmc: handle highmem pages"

commit 2b77158ffa92b820a0c5da9a3c6ead7aa069c71c upstream.

This reverts commit b189e7589f6d3411e85c6b7ae6eef158f08f388f.

Unable to handle kernel paging request at virtual address c8358000
pgd = efa405c3
[c8358000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT ARM
CPU: 0 PID: 711 Comm: kworker/0:2 Not tainted 4.20.0+ #30
Hardware name: Freescale i.MX27 (Device Tree Support)
Workqueue: events mxcmci_datawork
PC is at mxcmci_datawork+0xbc/0x2ac
LR is at mxcmci_datawork+0xac/0x2ac
pc : [<c04e33c8>] lr : [<c04e33b8>] psr: 60000013
sp : c6c93f08 ip : 24004180 fp : 00000008
r10: c8358000 r9 : c78b3e24 r8 : c6c92000
r7 : 00000000 r6 : c7bb8680 r5 : c7bb86d4 r4 : c78b3de0
r3 : 00002502 r2 : c090b2e0 r1 : 00000880 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: a68a8000 DAC: 00000055
Process kworker/0:2 (pid: 711, stack limit = 0x389543bc)
Stack: (0xc6c93f08 to 0xc6c94000)
3f00: c7bb86d4 00000000 00000000 c6cbfde0 c7bb86d4 c7ee4200
3f20: 00000000 c0907ea8 00000000 c7bb86d8 c0907ea8 c012077c c6cbfde0 c7bb86d4
3f40: c6cbfde0 c6c92000 c6cbfdf4 c09280ba c0907ea8 c090b2e0 c0907ebc c0120c18
3f60: c6cbfde0 00000000 00000000 c6cbb580 c7ba7c40 c7837edc c6cbb598 00000000
3f80: c6cbfde0 c01208f8 00000000 c01254fc c7ba7c40 c0125400 00000000 00000000
3fa0: 00000000 00000000 00000000 c01010d0 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c04e33c8>] (mxcmci_datawork) from [<c012077c>] (process_one_work+0x1f0/0x338)
[<c012077c>] (process_one_work) from [<c0120c18>] (worker_thread+0x320/0x474)
[<c0120c18>] (worker_thread) from [<c01254fc>] (kthread+0xfc/0x118)
[<c01254fc>] (kthread) from [<c01010d0>] (ret_from_fork+0x14/0x24)
Exception stack(0xc6c93fb0 to 0xc6c93ff8)
3fa0: 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e3500000 1a000059 e5153050 e5933038 (e48a3004)
---[ end trace 54ca629b75f0e737 ]---
note: kworker/0:2[711] exited with preempt_count 1

Signed-off-by: Alexander Shiyan <shc_work@...>
Fixes: b189e7589f6d ("mmc: mxcmmc: handle highmem pages")
Cc: stable@...
Signed-off-by: Ulf Hansson <ulf.hansson@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/mmc/host/mxcmmc.c


[linux:lloyd-aviation] By Wolfram Sang <wsa+renesas@...>:
42f358b2d48c: mmc: renesas_sdhi: limit block count to 16 bit for old revisions

commit c9a9497ccef205ed4ed2e247011382627876d831 upstream.

R-Car Gen2 has two different SDHI incarnations in the same chip. The
older one does not support the recently introduced 32 bit register
access to the block count register. Make sure we use this feature only
after the first known version.

Thanks to the Renesas Testing team for this bug report!

Fixes: 5603731a15ef ("mmc: tmio: fix access width of Block Count Register")
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>
Signed-off-by: Wolfram Sang <wsa+renesas@...>
Reviewed-by: Simon Horman <horms+renesas@...>
Tested-by: Phong Hoang <phong.hoang.wz@...>
Cc: stable@...
Signed-off-by: Ulf Hansson <ulf.hansson@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/mmc/host/renesas_sdhi_core.c


[linux:lloyd-aviation] By Thomas Zimmermann <tzimmermann@...>:
ab483d1ca7ae: drm/vmwgfx: Don't double-free the mode stored in par->set_mode

commit c2d311553855395764e2e5bf401d987ba65c2056 upstream.

When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
twice. The first free is in vmw_fb_kms_detach(), the second is near the
end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
only works correctly if the mode doesn't actually change. Removing
'old_mode' in favor of using par->set_mode directly fixes the problem.

Cc: <stable@...>
Fixes: a278724aa23c ("drm/vmwgfx: Implement fbdev on kms v2")
Signed-off-by: Thomas Zimmermann <tzimmermann@...>
Reviewed-by: Deepak Rawat <drawat@...>
Signed-off-by: Thomas Hellstrom <thellstrom@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/vmwgfx/vmwgfx_fb.c


[linux:lloyd-aviation] By Deepak Rawat <drawat@...>:
69e26237ed1e: drm/vmwgfx: Return 0 when gmrid::get_node runs out of ID's

commit 4b9ce3a651a37c60527101db4451a315a8b9588f upstream.

If it's not a system error and get_node implementation accommodate the
buffer object then it should return 0 with memm::mm_node set to NULL.

v2: Test for id != -ENOMEM instead of id == -ENOSPC.

Cc: <stable@...>
Fixes: 4eb085e42fde ("drm/vmwgfx: Convert to new IDA API")
Signed-off-by: Deepak Rawat <drawat@...>
Reviewed-by: Thomas Hellstrom <thellstrom@...>
Signed-off-by: Thomas Hellstrom <thellstrom@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c


[linux:lloyd-aviation] By Stanislaw Gruszka <sgruszka@...>:
869157135003: iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE

commit 4e50ce03976fbc8ae995a000c4b10c737467beaa upstream.

Take into account that sg->offset can be bigger than PAGE_SIZE when
setting segment sg->dma_address. Otherwise sg->dma_address will point
at diffrent page, what makes DMA not possible with erros like this:

xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa70c0 flags=0x0020]
xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7040 flags=0x0020]
xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7080 flags=0x0020]
xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7100 flags=0x0020]
xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7000 flags=0x0020]

Additinally with wrong sg->dma_address unmap_sg will free wrong pages,
what what can cause crashes like this:

Feb 28 19:27:45 kernel: BUG: Bad page state in process cinnamon pfn:39e8b1
Feb 28 19:27:45 kernel: Disabling lock debugging due to kernel taint
Feb 28 19:27:45 kernel: flags: 0x2ffff0000000000()
Feb 28 19:27:45 kernel: raw: 02ffff0000000000 0000000000000000 ffffffff00000301 0000000000000000
Feb 28 19:27:45 kernel: raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
Feb 28 19:27:45 kernel: page dumped because: nonzero _refcount
Feb 28 19:27:45 kernel: Modules linked in: ccm fuse arc4 nct6775 hwmon_vid amdgpu nls_iso8859_1 nls_cp437 edac_mce_amd vfat fat kvm_amd ccp rng_core kvm mt76x0u mt76x0_common mt76x02_usb irqbypass mt76_usb mt76x02_lib mt76 crct10dif_pclmul crc32_pclmul chash mac80211 amd_iommu_v2 ghash_clmulni_intel gpu_sched i2c_algo_bit ttm wmi_bmof snd_hda_codec_realtek snd_hda_codec_generic drm_kms_helper snd_hda_codec_hdmi snd_hda_intel drm snd_hda_codec aesni_intel snd_hda_core snd_hwdep aes_x86_64 crypto_simd snd_pcm cfg80211 cryptd mousedev snd_timer glue_helper pcspkr r8169 input_leds realtek agpgart libphy rfkill snd syscopyarea sysfillrect sysimgblt fb_sys_fops soundcore sp5100_tco k10temp i2c_piix4 wmi evdev gpio_amdpt pinctrl_amd mac_hid pcc_cpufreq acpi_cpufreq sg ip_tables x_tables ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) sd_mod(E) hid_generic(E) usbhid(E) hid(E) dm_mod(E) serio_raw(E) atkbd(E) libps2(E) crc32c_intel(E) ahci(E) libahci(E) libata(E) xhci_pci(E) xhci_hcd(E)
Feb 28 19:27:45 kernel: scsi_mod(E) i8042(E) serio(E) bcache(E) crc64(E)
Feb 28 19:27:45 kernel: CPU: 2 PID: 896 Comm: cinnamon Tainted: G B W E 4.20.12-arch1-1-custom #1
Feb 28 19:27:45 kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P1.20 06/26/2018
Feb 28 19:27:45 kernel: Call Trace:
Feb 28 19:27:45 kernel: dump_stack+0x5c/0x80
Feb 28 19:27:45 kernel: bad_page.cold.29+0x7f/0xb2
Feb 28 19:27:45 kernel: __free_pages_ok+0x2c0/0x2d0
Feb 28 19:27:45 kernel: skb_release_data+0x96/0x180
Feb 28 19:27:45 kernel: __kfree_skb+0xe/0x20
Feb 28 19:27:45 kernel: tcp_recvmsg+0x894/0xc60
Feb 28 19:27:45 kernel: ? reuse_swap_page+0x120/0x340
Feb 28 19:27:45 kernel: ? ptep_set_access_flags+0x23/0x30
Feb 28 19:27:45 kernel: inet_recvmsg+0x5b/0x100
Feb 28 19:27:45 kernel: __sys_recvfrom+0xc3/0x180
Feb 28 19:27:45 kernel: ? handle_mm_fault+0x10a/0x250
Feb 28 19:27:45 kernel: ? syscall_trace_enter+0x1d3/0x2d0
Feb 28 19:27:45 kernel: ? __audit_syscall_exit+0x22a/0x290
Feb 28 19:27:45 kernel: __x64_sys_recvfrom+0x24/0x30
Feb 28 19:27:45 kernel: do_syscall_64+0x5b/0x170
Feb 28 19:27:45 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9

Cc: stable@...
Reported-and-tested-by: Jan Viktorin <jan.viktorin@...>
Reviewed-by: Alexander Duyck <alexander.h.duyck@...>
Signed-off-by: Stanislaw Gruszka <sgruszka@...>
Fixes: 80187fd39dcb ('iommu/amd: Optimize map_sg and unmap_sg')
Signed-off-by: Joerg Roedel <jroedel@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/iommu/amd_iommu.c


[linux:lloyd-aviation] By Ilya Dryomov <idryomov@...>:
9cae232a8706: libceph: wait for latest osdmap in ceph_monc_blacklist_add()

commit bb229bbb3bf63d23128e851a1f3b85c083178fa1 upstream.

Because map updates are distributed lazily, an OSD may not know about
the new blacklist for quite some time after "osd blacklist add" command
is completed. This makes it possible for a blacklisted but still alive
client to overwrite a post-blacklist update, resulting in data
corruption.

Waiting for latest osdmap in ceph_monc_blacklist_add() and thus using
the post-blacklist epoch for all post-blacklist requests ensures that
all such requests "wait" for the blacklist to come into force on their
respective OSDs.

Cc: stable@...
Fixes: 6305a3b41515 ("libceph: support for blacklisting clients")
Signed-off-by: Ilya Dryomov <idryomov@...>
Reviewed-by: Jason Dillaman <dillaman@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: include/linux/ceph/libceph.h
Modified: net/ceph/ceph_common.c
Modified: net/ceph/mon_client.c


[linux:lloyd-aviation] By Jan Kara <jack@...>:
c72e90d94a14: udf: Fix crash on IO error during truncate

commit d3ca4651d05c0ff7259d087d8c949bcf3e14fb46 upstream.

When truncate(2) hits IO error when reading indirect extent block the
code just bugs with:

kernel BUG at linux-4.15.0/fs/udf/truncate.c:249!
...

Fix the problem by bailing out cleanly in case of IO error.

CC: stable@...
Reported-by: jean-luc malet <jeanluc.malet@...>
Signed-off-by: Jan Kara <jack@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/udf/truncate.c


[linux:lloyd-aviation] By Yifeng Li <tomli@...>:
56bcf3df2552: mips: loongson64: lemote-2f: Add IRQF_NO_SUSPEND to "cascade" irqaction.

commit 5f5f67da9781770df0403269bc57d7aae608fecd upstream.

Timekeeping IRQs from CS5536 MFGPT are routed to i8259, which then
triggers the "cascade" IRQ on MIPS CPU. Without IRQF_NO_SUSPEND in
cascade_irqaction, MFGPT interrupts will be masked in suspend mode,
and the machine would be unable to resume once suspended.

Previously, MIPS IRQs were not disabled properly, so the original
code appeared to work. Commit a3e6c1eff5 ("MIPS: IRQ: Fix disable_irq on
CPU IRQs") uncovers the bug. To fix it, add IRQF_NO_SUSPEND to
cascade_irqaction.

This commit is functionally identical to 0add9c2f1cff ("MIPS:
Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction"), but it forgot
to apply the same fix to Loongson2.

Signed-off-by: Yifeng Li <tomli@...>
Signed-off-by: Paul Burton <paul.burton@...>
Cc: linux-mips@...
Cc: Jiaxun Yang <jiaxun.yang@...>
Cc: Huacai Chen <chenhc@...>
Cc: Ralf Baechle <ralf@...>
Cc: James Hogan <jhogan@...>
Cc: linux-kernel@...
Cc: stable@... # v3.19+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/mips/loongson64/lemote-2f/irq.c


[linux:lloyd-aviation] By Yasha Cherikovsky <yasha.che3@...>:
6e74961bd67d: MIPS: Ensure ELF appended dtb is relocated

commit 3f0a53bc6482fb09770982a8447981260ea258dc upstream.

This fixes booting with the combination of CONFIG_RELOCATABLE=y
and CONFIG_MIPS_ELF_APPENDED_DTB=y.

Sections that appear after the relocation table are not relocated
on system boot (except .bss, which has special handling).

With CONFIG_MIPS_ELF_APPENDED_DTB, the dtb is part of the
vmlinux ELF, so it must be relocated together with everything else.

Fixes: 069fd766271d ("MIPS: Reserve space for relocation table")
Signed-off-by: Yasha Cherikovsky <yasha.che3@...>
Signed-off-by: Paul Burton <paul.burton@...>
Cc: Ralf Baechle <ralf@...>
Cc: Paul Burton <paul.burton@...>
Cc: James Hogan <jhogan@...>
Cc: linux-mips@...
Cc: linux-kernel@...
Cc: stable@... # v4.7+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/mips/kernel/vmlinux.lds.S


[linux:lloyd-aviation] By Archer Yan <ayan@...>:
9d91069f48cc: MIPS: Fix kernel crash for R6 in jump label branch function

commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.

Insert Branch instruction instead of NOP to make sure assembler don't
patch code in forbidden slot. In jump label function, it might
be possible to patch Control Transfer Instructions(CTIs) into
forbidden slot, which will generate Reserved Instruction exception
in MIPS release 6.

Signed-off-by: Archer Yan <ayan@...>
Reviewed-by: Paul Burton <paul.burton@...>
[paul.burton@...:
- Add MIPS prefix to subject.
- Mark for stable from v4.0, which introduced r6 support, onwards.]
Signed-off-by: Paul Burton <paul.burton@...>
Cc: linux-mips@...
Cc: stable@... # v4.0+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/mips/include/asm/jump_label.h


[linux:lloyd-aviation] By Michael Ellerman <mpe@...>:
b8ea151a7ab5: powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038

commit b5b4453e7912f056da1ca7572574cada32ecb60c upstream.

Jakub Drnec reported:
Setting the realtime clock can sometimes make the monotonic clock go
back by over a hundred years. Decreasing the realtime clock across
the y2k38 threshold is one reliable way to reproduce. Allegedly this
can also happen just by running ntpd, I have not managed to
reproduce that other than booting with rtc at >2038 and then running
ntp. When this happens, anything with timers (e.g. openjdk) breaks
rather badly.

And included a test case (slightly edited for brevity):
#define _POSIX_C_SOURCE 199309L
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <unistd.h>

long get_time(void) {
struct timespec tp;
clock_gettime(CLOCK_MONOTONIC, &tp);
return tp.tv_sec + tp.tv_nsec / 1000000000;
}

int main(void) {
long last = get_time();
while(1) {
long now = get_time();
if (now < last) {
printf("clock went backwards by %ld seconds!\n", last - now);
}
last = now;
sleep(1);
}
return 0;
}

Which when run concurrently with:
# date -s 2040-1-1
# date -s 2037-1-1

Will detect the clock going backward.

The root cause is that wtom_clock_sec in struct vdso_data is only a
32-bit signed value, even though we set its value to be equal to
tk->wall_to_monotonic.tv_sec which is 64-bits.

Because the monotonic clock starts at zero when the system boots the
wall_to_montonic.tv_sec offset is negative for current and future
dates. Currently on a freshly booted system the offset will be in the
vicinity of negative 1.5 billion seconds.

However if the wall clock is set past the Y2038 boundary, the offset
from wall to monotonic becomes less than negative 2^31, and no longer
fits in 32-bits. When that value is assigned to wtom_clock_sec it is
truncated and becomes positive, causing the VDSO assembly code to
calculate CLOCK_MONOTONIC incorrectly.

That causes CLOCK_MONOTONIC to jump ahead by ~4 billion seconds which
it is not meant to do. Worse, if the time is then set back before the
Y2038 boundary CLOCK_MONOTONIC will jump backward.

We can fix it simply by storing the full 64-bit offset in the
vdso_data, and using that in the VDSO assembly code. We also shuffle
some of the fields in vdso_data to avoid creating a hole.

The original commit that added the CLOCK_MONOTONIC support to the VDSO
did actually use a 64-bit value for wtom_clock_sec, see commit
a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to
32 bits kernel") (Nov 2005). However just 3 days later it was
converted to 32-bits in commit 0c37ec2aa88b ("[PATCH] powerpc: vdso
fixes (take #2)"), and the bug has existed since then AFAICS.

Fixes: 0c37ec2aa88b ("[PATCH] powerpc: vdso fixes (take #2)")
Cc: stable@... # v2.6.15+
Link: http://lkml.kernel.org/r/HaC.ZfES.62bwlnvAvMP.1STMMj@...
Reported-by: Jakub Drnec <jaydee@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/include/asm/vdso_datapage.h
Modified: arch/powerpc/kernel/vdso64/gettimeofday.S


[linux:lloyd-aviation] By Tyrel Datwyler <tyreld@...>:
04809b226e79: scsi: ibmvscsi: Protect ibmvscsi_head from concurrent modificaiton

commit 7205981e045e752ccf96cf6ddd703a98c59d4339 upstream.

For each ibmvscsi host created during a probe or destroyed during a remove
we either add or remove that host to/from the global ibmvscsi_head
list. This runs the risk of concurrent modification.

This patch adds a simple spinlock around the list modification calls to
prevent concurrent updates as is done similarly in the ibmvfc driver and
ipr driver.

Fixes: 32d6e4b6e4ea ("scsi: ibmvscsi: add vscsi hosts to global list_head")
Cc: <stable@...> # v4.10+
Signed-off-by: Tyrel Datwyler <tyreld@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/scsi/ibmvscsi/ibmvscsi.c


[linux:lloyd-aviation] By Tyrel Datwyler <tyreld@...>:
837becb30c3b: scsi: ibmvscsi: Fix empty event pool access during host removal

commit 7f5203c13ba8a7b7f9f6ecfe5a4d5567188d7835 upstream.

The event pool used for queueing commands is destroyed fairly early in the
ibmvscsi_remove() code path. Since, this happens prior to the call so
scsi_remove_host() it is possible for further calls to queuecommand to be
processed which manifest as a panic due to a NULL pointer dereference as
seen here:

PANIC: "Unable to handle kernel paging request for data at address
0x00000000"

Context process backtrace:

DSISR: 0000000042000000 ????Syscall Result: 0000000000000000
4 [c000000002cb3820] memcpy_power7 at c000000000064204
[Link Register] [c000000002cb3820] ibmvscsi_send_srp_event at d000000003ed14a4
5 [c000000002cb3920] ibmvscsi_send_srp_event at d000000003ed14a4 [ibmvscsi] ?(unreliable)
6 [c000000002cb39c0] ibmvscsi_queuecommand at d000000003ed2388 [ibmvscsi]
7 [c000000002cb3a70] scsi_dispatch_cmd at d00000000395c2d8 [scsi_mod]
8 [c000000002cb3af0] scsi_request_fn at d00000000395ef88 [scsi_mod]
9 [c000000002cb3be0] __blk_run_queue at c000000000429860
10 [c000000002cb3c10] blk_delay_work at c00000000042a0ec
11 [c000000002cb3c40] process_one_work at c0000000000dac30
12 [c000000002cb3cd0] worker_thread at c0000000000db110
13 [c000000002cb3d80] kthread at c0000000000e3378
14 [c000000002cb3e30] ret_from_kernel_thread at c00000000000982c

The kernel buffer log is overfilled with this log:

[11261.952732] ibmvscsi: found no event struct in pool!

This patch reorders the operations during host teardown. Start by calling
the SRP transport and Scsi_Host remove functions to flush any outstanding
work and set the host offline. LLDD teardown follows including destruction
of the event pool, freeing the Command Response Queue (CRQ), and unmapping
any persistent buffers. The event pool destruction is protected by the
scsi_host lock, and the pool is purged prior of any requests for which we
never received a response. Finally, move the removal of the scsi host from
our global list to the end so that the host is easily locatable for
debugging purposes during teardown.

Cc: <stable@...> # v2.6.12+
Signed-off-by: Tyrel Datwyler <tyreld@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/scsi/ibmvscsi/ibmvscsi.c


[linux:lloyd-aviation] By Chen Jie <chenjie6@...>:
36d52f5bcd57: futex: Ensure that futex address is aligned in handle_futex_death()

commit 5a07168d8d89b00fe1760120714378175b3ef992 upstream.

The futex code requires that the user space addresses of futexes are 32bit
aligned. sys_futex() checks this in futex_get_keys() but the robust list
code has no alignment check in place.

As a consequence the kernel crashes on architectures with strict alignment
requirements in handle_futex_death() when trying to cmpxchg() on an
unaligned futex address which was retrieved from the robust list.

[ tglx: Rewrote changelog, proper sizeof() based alignement check and add
comment ]

Fixes: 0771dfefc9e5 ("[PATCH] lightweight robust futexes: core")
Signed-off-by: Chen Jie <chenjie6@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Cc: <dvhart@...>
Cc: <peterz@...>
Cc: <zengweilin@...>
Cc: stable@...
Link: https://lkml.kernel.org/r/1552621478-119787-1-git-send-email-chenjie6@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/futex.c


[linux:lloyd-aviation] By Ronnie Sahlberg <lsahlber@...>:
14c52acaac86: cifs: allow guest mounts to work for smb3.11

commit e71ab2aa06f731a944993120b0eef1556c63b81c upstream.

Fix Guest/Anonymous sessions so that they work with SMB 3.11.

The commit noted below tightened the conditions and forced signing for
the SMB2-TreeConnect commands as per MS-SMB2.
However, this should only apply to normal user sessions and not for
Guest/Anonumous sessions.

Fixes: 6188f28bf608 ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares")

Signed-off-by: Ronnie Sahlberg <lsahlber@...>
CC: Stable <stable@...>
Signed-off-by: Steve French <stfrench@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/cifs/smb2pdu.c


[linux:lloyd-aviation] By Adrian Hunter <adrian.hunter@...>:
37c6f8089806: perf probe: Fix getting the kernel map

commit eaeffeb9838a7c0dec981d258666bfcc0fa6a947 upstream.

Since commit 4d99e4136580 ("perf machine: Workaround missing maps for
x86 PTI entry trampolines"), perf tools has been creating more than one
kernel map, however 'perf probe' assumed there could be only one.

Fix by using machine__kernel_map() to get the main kernel map.

Signed-off-by: Adrian Hunter <adrian.hunter@...>
Tested-by: Joseph Qi <joseph.qi@...>
Acked-by: Masami Hiramatsu <mhiramat@...>
Cc: Alexander Shishkin <alexander.shishkin@...>
Cc: Andy Lutomirski <luto@...>
Cc: Greg Kroah-Hartman <gregkh@...>
Cc: Jiufei Xue <jiufei.xue@...>
Cc: Peter Zijlstra <peterz@...>
Cc: stable@...
Cc: Xu Yu <xuyu@...>
Fixes: 4d99e4136580 ("perf machine: Workaround missing maps for x86 PTI entry trampolines")
Fixes: d83212d5dd67 ("kallsyms, x86: Export addresses of PTI entry trampolines")
Link: http://lkml.kernel.org/r/2ed432de-e904-85d2-5c36-5897ddc5b23b@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: tools/perf/util/probe-event.c


[linux:lloyd-aviation] By Josh Poimboeuf <jpoimboe@...>:
daaeeca918e7: objtool: Move objtool_file struct off the stack

commit 0c671812f152b628bd87c0af49da032cc2a2c319 upstream.

Objtool uses over 512k of stack, thanks to the hash table embedded in
the objtool_file struct. This causes an unnecessarily large stack
allocation and breaks users with low stack limits.

Move the struct off the stack.

Fixes: 042ba73fe7eb ("objtool: Add several performance improvements")
Reported-by: Vassili Karpov <moosotc@...>
Signed-off-by: Josh Poimboeuf <jpoimboe@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Cc: Peter Zijlstra <peterz@...>
Cc: stable@...
Link: https://lkml.kernel.org/r/df92dcbc4b84b02ffa252f46876df125fb56e2d7.1552954176.git.jpoimboe@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: tools/objtool/check.c


[linux:lloyd-aviation] By Rasmus Villemoes <linux@...>:
aacf2cc814c2: irqchip/gic-v3-its: Fix comparison logic in lpi_range_cmp

commit 89dc891792c2e046b030f87600109c22209da32e upstream.

The lpi_range_list is supposed to be sorted in ascending order of
->base_id (at least if the range merging is to work), but the current
comparison function returns a positive value if rb->base_id >
ra->base_id, which means that list_sort() will put A after B in that
case - and vice versa, of course.

Fixes: 880cb3cddd16 (irqchip/gic-v3-its: Refactor LPI allocator)
Cc: stable@... (v4.19+)
Signed-off-by: Rasmus Villemoes <linux@...>
Signed-off-by: Marc Zyngier <marc.zyngier@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/irqchip/irq-gic-v3-its.c


[linux:lloyd-aviation] By Steve French <stfrench@...>:
38bd575b9aef: SMB3: Fix SMB3.1.1 guest mounts to Samba

commit 8c11a607d1d9cd6e7f01fd6b03923597fb0ef95a upstream.

Workaround problem with Samba responses to SMB3.1.1
null user (guest) mounts. The server doesn't set the
expected flag in the session setup response so we have
to do a similar check to what is done in smb3_validate_negotiate
where we also check if the user is a null user (but not sec=krb5
since username might not be passed in on mount for Kerberos case).

Note that the commit below tightened the conditions and forced signing
for the SMB2-TreeConnect commands as per MS-SMB2.
However, this should only apply to normal user sessions and not for
cases where there is no user (even if server forgets to set the flag
in the response) since we don't have anything useful to sign with.
This is especially important now that the more secure SMB3.1.1 protocol
is in the default dialect list.

An earlier patch ("cifs: allow guest mounts to work for smb3.11") fixed
the guest mounts to Windows.

Fixes: 6188f28bf608 ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares")

Reviewed-by: Ronnie Sahlberg <lsahlber@...>
Reviewed-by: Paulo Alcantara <palcantara@...>
CC: Stable <stable@...>
Signed-off-by: Steve French <stfrench@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/cifs/smb2pdu.c


[linux:lloyd-aviation] By Ville Syrjälä <ville.syrjala@...>:
4a767459389a: ALSA: x86: Fix runtime PM for hdmi-lpe-audio

commit 8dfb839cfe737a17def8e5f88ee13c295230364a upstream.

Commit 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as
"no callbacks"") broke runtime PM with lpe audio. We can no longer
runtime suspend the GPU since the sysfs power/control for the
lpe-audio device no longer exists and the device is considered
always active. We can fix this by not marking the device as
active.

Cc: Chris Wilson <chris@...>
Cc: Takashi Iwai <tiwai@...>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@...>
Fixes: 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as "no callbacks"")
Signed-off-by: Ville Syrjälä <ville.syrjala@...>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024154825.18185-1-ville.syrjala@...
Reviewed-by: Chris Wilson <chris@...>
Acked-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/x86/intel_hdmi_audio.c


[linux:lloyd-aviation] By Arnd Bergmann <arnd@...>:
c8e91d756703: ALSA: hda/ca0132 - make pci_iounmap() call conditional

commit 1e73359a24fad529b0794515b46cbfff99e5fbe6 upstream.

When building without CONFIG_PCI, we can (depending on the architecture)
get a link failure:

ERROR: "pci_iounmap" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!

Adding a compile-time check for PCI gets it to work correctly on
32-bit ARM.

Fixes: d99501b8575d ("ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()")
Signed-off-by: Arnd Bergmann <arnd@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_ca0132.c


[linux:lloyd-aviation] By Takashi Iwai <tiwai@...>:
ff7a1f81c20e: ALSA: ac97: Fix of-node refcount unbalance

commit 31d2350d602511efc9ef626b848fe521233b0387 upstream.

ac97_of_get_child_device() take the refcount of the node explicitly
via of_node_get(), but this leads to an unbalance. The
for_each_child_of_node() loop itself takes the refcount for each
iteration node, hence you don't need to take the extra refcount
again.

Fixes: 2225a3e6af78 ("ALSA: ac97: add codecs devicetree binding")
Reviewed-by: Robert Jarzmik <robert.jarzmik@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/ac97/bus.c


[linux:lloyd-aviation] By Jiufei Xue <jiufei.xue@...>:
558331d0205b: ext4: fix NULL pointer dereference while journal is aborted

commit fa30dde38aa8628c73a6dded7cb0bba38c27b576 upstream.

We see the following NULL pointer dereference while running xfstests
generic/475:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
PGD 8000000c84bad067 P4D 8000000c84bad067 PUD c84e62067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 7 PID: 9886 Comm: fsstress Kdump: loaded Not tainted 5.0.0-rc8 #10
RIP: 0010:ext4_do_update_inode+0x4ec/0x760
...
Call Trace:
? jbd2_journal_get_write_access+0x42/0x50
? __ext4_journal_get_write_access+0x2c/0x70
? ext4_truncate+0x186/0x3f0
ext4_mark_iloc_dirty+0x61/0x80
ext4_mark_inode_dirty+0x62/0x1b0
ext4_truncate+0x186/0x3f0
? unmap_mapping_pages+0x56/0x100
ext4_setattr+0x817/0x8b0
notify_change+0x1df/0x430
do_truncate+0x5e/0x90
? generic_permission+0x12b/0x1a0

This is triggered because the NULL pointer handle->h_transaction was
dereferenced in function ext4_update_inode_fsync_trans().
I found that the h_transaction was set to NULL in jbd2__journal_restart
but failed to attached to a new transaction while the journal is aborted.

Fix this by checking the handle before updating the inode.

Fixes: b436b9bef84d ("ext4: Wait for proper transaction commit on fsync")
Signed-off-by: Jiufei Xue <jiufei.xue@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Reviewed-by: Joseph Qi <joseph.qi@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext4/ext4_jbd2.h


[linux:lloyd-aviation] By Lukas Czerner <lczerner@...>:
76c9ee6bd5d2: ext4: fix data corruption caused by unaligned direct AIO

commit 372a03e01853f860560eade508794dd274e9b390 upstream.

Ext4 needs to serialize unaligned direct AIO because the zeroing of
partial blocks of two competing unaligned AIOs can result in data
corruption.

However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still into the same block, it has
the potential of corrupting the previous unaligned write to the same
block.

This is (very simplified) reproducer from Frank

// 41472 = (10 * 4096) + 512
// 37376 = 41472 - 4096

ftruncate(fd, 41472);
io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376);
io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472);

io_submit(io_ctx, 1, &iocbs[1]);
io_submit(io_ctx, 1, &iocbs[2]);

io_getevents(io_ctx, 2, 2, events, NULL);

Without this patch the 512B range from 40960 up to the start of the
second unaligned write (41472) is going to be zeroed overwriting the data
written by the first write. This is a data corruption.

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31

With this patch the data corruption is avoided because we will recognize
the unaligned_aio and wait for the unwritten extent conversion.

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
*
0000b200

Reported-by: Frank Sorenson <fsorenso@...>
Signed-off-by: Lukas Czerner <lczerner@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO")
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext4/file.c


[linux:lloyd-aviation] By zhangyi (F) <yi.zhang@...>:
d12d86411c03: ext4: brelse all indirect buffer in ext4_ind_remove_space()

commit 674a2b27234d1b7afcb0a9162e81b2e53aeef217 upstream.

All indirect buffers get by ext4_find_shared() should be released no
mater the branch should be freed or not. But now, we forget to release
the lower depth indirect buffers when removing space from the same
higher depth indirect block. It will lead to buffer leak and futher
more, it may lead to quota information corruption when using old quota,
consider the following case.

- Create and mount an empty ext4 filesystem without extent and quota
features,
- quotacheck and enable the user & group quota,
- Create some files and write some data to them, and then punch hole
to some files of them, it may trigger the buffer leak problem
mentioned above.
- Disable quota and run quotacheck again, it will create two new
aquota files and write the checked quota information to them, which
probably may reuse the freed indirect block(the buffer and page
cache was not freed) as data block.
- Enable quota again, it will invoke
vfs_load_quota_inode()->invalidate_bdev() to try to clean unused
buffers and pagecache. Unfortunately, because of the buffer of quota
data block is still referenced, quota code cannot read the up to date
quota info from the device and lead to quota information corruption.

This problem can be reproduced by xfstests generic/231 on ext3 file
system or ext4 file system without extent and quota features.

This patch fix this problem by releasing the missing indirect buffers,
in ext4_ind_remove_space().

Reported-by: Hulk Robot <hulkci@...>
Signed-off-by: zhangyi (F) <yi.zhang@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Reviewed-by: Jan Kara <jack@...>
Cc: stable@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext4/indirect.c


[linux:lloyd-aviation] By Hans Verkuil <hverkuil@...>:
6bef442eea18: media: v4l2-ctrls.c/uvc: zero v4l2_event

commit f45f3f753b0a3d739acda8e311b4f744d82dc52a upstream.

Control events can leak kernel memory since they do not fully zero the
event. The same code is present in both v4l2-ctrls.c and uvc_ctrl.c, so
fix both.

It appears that all other event code is properly zeroing the structure,
it's these two places.

Signed-off-by: Hans Verkuil <hverkuil-cisco@...>
Reported-by: syzbot+4f021cf3697781dbd9fb@...
Reviewed-by: Laurent Pinchart <laurent.pinchart@...>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/media/usb/uvc/uvc_ctrl.c
Modified: drivers/media/v4l2-core/v4l2-ctrls.c


[linux:lloyd-aviation] By Myungho Jung <mhjungk@...>:
4e0ca4bfa2bc: Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf()

commit 1dc2d785156cbdc80806c32e8d2c7c735d0b4721 upstream.

h4_recv_buf() callers store the return value to socket buffer and
recursively pass the buffer to h4_recv_buf() without protection. So,
ERR_PTR returned from h4_recv_buf() can be dereferenced, if called again
before setting the socket buffer to NULL from previous error. Check if
skb is ERR_PTR in h4_recv_buf().

Reported-by: syzbot+017a32f149406df32703@...
Signed-off-by: Myungho Jung <mhjungk@...>
Signed-off-by: Marcel Holtmann <marcel@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/bluetooth/h4_recv.h
Modified: drivers/bluetooth/hci_h4.c


[linux:lloyd-aviation] By Myungho Jung <mhjungk@...>:
4b39051363a0: Bluetooth: Fix decrementing reference count twice in releasing socket

commit e20a2e9c42c9e4002d9e338d74e7819e88d77162 upstream.

When releasing socket, it is possible to enter hci_sock_release() and
hci_sock_dev_event(HCI_DEV_UNREG) at the same time in different thread.
The reference count of hdev should be decremented only once from one of
them but if storing hdev to local variable in hci_sock_release() before
detached from socket and setting to NULL in hci_sock_dev_event(),
hci_dev_put(hdev) is unexpectedly called twice. This is resolved by
referencing hdev from socket after bt_sock_unlink() in
hci_sock_release().

Reported-by: syzbot+fdc00003f4efff43bc5b@...
Signed-off-by: Myungho Jung <mhjungk@...>
Signed-off-by: Marcel Holtmann <marcel@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/bluetooth/hci_sock.c


[linux:lloyd-aviation] By Jeremy Cline <jcline@...>:
f67202f78fe3: Bluetooth: hci_ldisc: Initialize hci_dev before open()

commit 32a7b4cbe93b0a0ef7e63d31ca69ce54736c4412 upstream.

The hci_dev struct hdev is referenced in work queues and timers started
by open() in some protocols. This creates a race between the
initialization function and the work or timer which can result hdev
being dereferenced while it is still null.

The syzbot report contains a reliable reproducer which causes a null
pointer dereference of hdev in hci_uart_write_work() by making the
memory allocation for hdev fail.

To fix this, ensure hdev is valid from before calling a protocol's
open() until after calling a protocol's close().

Reported-by: syzbot+257790c15bcdef6fe00c@...
Signed-off-by: Jeremy Cline <jcline@...>
Signed-off-by: Marcel Holtmann <marcel@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/bluetooth/hci_ldisc.c


[linux:lloyd-aviation] By Kefeng Wang <wangkefeng.wang@...>:
e365b94086f9: Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto()

commit 56897b217a1d0a91c9920cb418d6b3fe922f590a upstream.

task A: task B:
hci_uart_set_proto flush_to_ldisc
- p->open(hu) -> h5_open //alloc h5 - receive_buf
- set_bit HCI_UART_PROTO_READY - tty_port_default_receive_buf
- hci_uart_register_dev - tty_ldisc_receive_buf
- hci_uart_tty_receive
- test_bit HCI_UART_PROTO_READY
- h5_recv
- clear_bit HCI_UART_PROTO_READY while() {
- p->open(hu) -> h5_close //free h5
- h5_rx_3wire_hdr
- h5_reset() //use-after-free
}

It could use ioctl to set hci uart proto, but there is
a use-after-free issue when hci_uart_register_dev() fail in
hci_uart_set_proto(), see stack above, fix this by setting
HCI_UART_PROTO_READY bit only when hci_uart_register_dev()
return success.

Reported-by: syzbot+899a33dc0fa0dbaf06a6@...
Signed-off-by: Kefeng Wang <wangkefeng.wang@...>
Reviewed-by: Jeremy Cline <jcline@...>
Signed-off-by: Marcel Holtmann <marcel@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/bluetooth/hci_ldisc.c


[linux:lloyd-aviation] By Chris Wilson <chris@...>:
015b828bd66d: drm: Reorder set_property_atomic to avoid returning with an active ww_ctx

commit 227ad6d957898a88b1746e30234ece64d305f066 upstream.

Delay the drm_modeset_acquire_init() until after we check for an
allocation failure so that we can return immediately upon error without
having to unwind.

WARNING: lock held when returning to user space!
4.20.0+ #174 Not tainted
------------------------------------------------
syz-executor556/8153 is leaving the kernel with locks still held!
1 lock held by syz-executor556/8153:
#0: 000000005100c85c (crtc_ww_class_acquire){+.+.}, at:
set_property_atomic+0xb3/0x330 drivers/gpu/drm/drm_mode_object.c:462

Reported-by: syzbot+6ea337c427f5083ebdf2@...
Fixes: 144a7999d633 ("drm: Handle properties in the core for atomic drivers")
Signed-off-by: Chris Wilson <chris@...>
Cc: Daniel Vetter <daniel.vetter@...>
Cc: Maarten Lankhorst <maarten.lankhorst@...>
Cc: Sean Paul <sean@...>
Cc: David Airlie <airlied@...>
Cc: <stable@...> # v4.14+
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@...>
Link: https://patchwork.freedesktop.org/patch/msgid/20181230122842.21917-1-chris@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/drm_mode_object.c


[linux:lloyd-aviation] By Myungho Jung <mhjungk@...>:
9dd5053c8cd5: RDMA/cma: Rollback source IP address if failing to acquire device

commit 5fc01fb846bce8fa6d5f95e2625b8ce0f8e86810 upstream.

If cma_acquire_dev_by_src_ip() returns error in addr_handler(), the
device state changes back to RDMA_CM_ADDR_BOUND but the resolved source
IP address is still left. After that, if rdma_destroy_id() is called
after rdma_listen(), the device is freed without removed from
listen_any_list in cma_cancel_operation(). Revert to the previous IP
address if acquiring device fails.

Reported-by: syzbot+f3ce716af730c8f96637@...
Signed-off-by: Myungho Jung <mhjungk@...>
Reviewed-by: Parav Pandit <parav@...>
Signed-off-by: Jason Gunthorpe <jgg@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/infiniband/core/cma.c


[linux:lloyd-aviation] By Chao Yu <yuchao0@...>:
1fd916e879a9: f2fs: fix to avoid deadlock of atomic file operations

commit 48432984d718c95cf13e26d487c2d1b697c3c01f upstream.

Thread A Thread B
- __fput
- f2fs_release_file
- drop_inmem_pages
- mutex_lock(&fi->inmem_lock)
- __revoke_inmem_pages
- lock_page(page)
- open
- f2fs_setattr
- truncate_setsize
- truncate_inode_pages_range
- lock_page(page)
- truncate_cleanup_page
- f2fs_invalidate_page
- drop_inmem_page
- mutex_lock(&fi->inmem_lock);

We may encounter above ABBA deadlock as reported by Kyungtae Kim:

I'm reporting a bug in linux-4.17.19: "INFO: task hung in
drop_inmem_page" (no reproducer)

I think this might be somehow related to the following:
https://groups.google.com/forum/#!searchin/syzkaller-bugs/INFO$3A$20task$20hung$20in$20%7Csort:date/syzkaller-bugs/c6soBTrdaIo/AjAzPeIzCgAJ

=========================================
INFO: task syz-executor7:10822 blocked for more than 120 seconds.
Not tainted 4.17.19 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor7 D27024 10822 6346 0x00000004
Call Trace:
context_switch kernel/sched/core.c:2867 [inline]
__schedule+0x721/0x1e60 kernel/sched/core.c:3515
schedule+0x88/0x1c0 kernel/sched/core.c:3559
schedule_preempt_disabled+0x18/0x30 kernel/sched/core.c:3617
__mutex_lock_common kernel/locking/mutex.c:833 [inline]
__mutex_lock+0x5bd/0x1410 kernel/locking/mutex.c:893
mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:908
drop_inmem_page+0xcb/0x810 fs/f2fs/segment.c:327
f2fs_invalidate_page+0x337/0x5e0 fs/f2fs/data.c:2401
do_invalidatepage mm/truncate.c:165 [inline]
truncate_cleanup_page+0x261/0x330 mm/truncate.c:187
truncate_inode_pages_range+0x552/0x1610 mm/truncate.c:367
truncate_inode_pages mm/truncate.c:478 [inline]
truncate_pagecache+0x6d/0x90 mm/truncate.c:801
truncate_setsize+0x81/0xa0 mm/truncate.c:826
f2fs_setattr+0x44f/0x1270 fs/f2fs/file.c:781
notify_change+0xa62/0xe80 fs/attr.c:313
do_truncate+0x12e/0x1e0 fs/open.c:63
do_last fs/namei.c:2955 [inline]
path_openat+0x2042/0x29f0 fs/namei.c:3505
do_filp_open+0x1bd/0x2c0 fs/namei.c:3540
do_sys_open+0x35e/0x4e0 fs/open.c:1101
__do_sys_open fs/open.c:1119 [inline]
__se_sys_open fs/open.c:1114 [inline]
__x64_sys_open+0x89/0xc0 fs/open.c:1114
do_syscall_64+0xc4/0x4e0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
RSP: 002b:00007f734e459c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007f734e45a6cc RCX: 00000000004497b9
RDX: 0000000000000104 RSI: 00000000000a8280 RDI: 0000000020000080
RBP: 000000000071bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000007230 R14: 00000000006f02d0 R15: 00007f734e45a700
INFO: task syz-executor7:10858 blocked for more than 120 seconds.
Not tainted 4.17.19 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor7 D28880 10858 6346 0x00000004
Call Trace:
context_switch kernel/sched/core.c:2867 [inline]
__schedule+0x721/0x1e60 kernel/sched/core.c:3515
schedule+0x88/0x1c0 kernel/sched/core.c:3559
__rwsem_down_write_failed_common kernel/locking/rwsem-xadd.c:565 [inline]
rwsem_down_write_failed+0x5e6/0xc90 kernel/locking/rwsem-xadd.c:594
call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117
__down_write arch/x86/include/asm/rwsem.h:142 [inline]
down_write+0x58/0xa0 kernel/locking/rwsem.c:72
inode_lock include/linux/fs.h:713 [inline]
do_truncate+0x120/0x1e0 fs/open.c:61
do_last fs/namei.c:2955 [inline]
path_openat+0x2042/0x29f0 fs/namei.c:3505
do_filp_open+0x1bd/0x2c0 fs/namei.c:3540
do_sys_open+0x35e/0x4e0 fs/open.c:1101
__do_sys_open fs/open.c:1119 [inline]
__se_sys_open fs/open.c:1114 [inline]
__x64_sys_open+0x89/0xc0 fs/open.c:1114
do_syscall_64+0xc4/0x4e0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
RSP: 002b:00007f734e3b4c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007f734e3b56cc RCX: 00000000004497b9
RDX: 0000000000000104 RSI: 00000000000a8280 RDI: 0000000020000080
RBP: 000000000071c238 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000007230 R14: 00000000006f02d0 R15: 00007f734e3b5700
INFO: task syz-executor5:10829 blocked for more than 120 seconds.
Not tainted 4.17.19 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor5 D28760 10829 6308 0x80000002
Call Trace:
context_switch kernel/sched/core.c:2867 [inline]
__schedule+0x721/0x1e60 kernel/sched/core.c:3515
schedule+0x88/0x1c0 kernel/sched/core.c:3559
io_schedule+0x21/0x80 kernel/sched/core.c:5179
wait_on_page_bit_common mm/filemap.c:1100 [inline]
__lock_page+0x2b5/0x390 mm/filemap.c:1273
lock_page include/linux/pagemap.h:483 [inline]
__revoke_inmem_pages+0xb35/0x11c0 fs/f2fs/segment.c:231
drop_inmem_pages+0xa3/0x3e0 fs/f2fs/segment.c:306
f2fs_release_file+0x2c7/0x330 fs/f2fs/file.c:1556
__fput+0x2c7/0x780 fs/file_table.c:209
____fput+0x1a/0x20 fs/file_table.c:243
task_work_run+0x151/0x1d0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x8ba/0x30a0 kernel/exit.c:865
do_group_exit+0x13b/0x3a0 kernel/exit.c:968
get_signal+0x6bb/0x1650 kernel/signal.c:2482
do_signal+0x84/0x1b70 arch/x86/kernel/signal.c:810
exit_to_usermode_loop+0x155/0x190 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x445/0x4e0 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
RSP: 002b:00007f1c68e74ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 000000000071bf80 RCX: 00000000004497b9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000071bf80
RBP: 000000000071bf80 R08: 0000000000000000 R09: 000000000071bf58
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f1c68e759c0 R15: 00007f1c68e75700

This patch tries to use trylock_page to mitigate such deadlock condition
for fix.

Signed-off-by: Chao Yu <yuchao0@...>
Signed-off-by: Jaegeuk Kim <jaegeuk@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/f2fs/segment.c


[linux:lloyd-aviation] By Florian Westphal <fw@...>:
35cdcdc5c49d: netfilter: ebtables: remove BUGPRINT messages

commit d824548dae220820bdf69b2d1561b7c4b072783f upstream.

They are however frequently triggered by syzkaller, so remove them.

ebtables userspace should never trigger any of these, so there is little
value in making them pr_debug (or ratelimited).

Signed-off-by: Florian Westphal <fw@...>
Signed-off-by: Pablo Neira Ayuso <pablo@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/bridge/netfilter/ebtables.c


[linux:lloyd-aviation] By Dongli Zhang <dongli.zhang@...>:
3254dd301f80: loop: access lo_backing_file only when the loop device is Lo_bound

commit f7c8a4120eedf24c36090b7542b179ff7a649219 upstream.

Commit 758a58d0bc67 ("loop: set GENHD_FL_NO_PART_SCAN after
blkdev_reread_part()") separates "lo->lo_backing_file = NULL" and
"lo->lo_state = Lo_unbound" into different critical regions protected by
loop_ctl_mutex.

However, there is below race that the NULL lo->lo_backing_file would be
accessed when the backend of a loop is another loop device, e.g., loop0's
backend is a file, while loop1's backend is loop0.

loop0's backend is file loop1's backend is loop0

__loop_clr_fd()
mutex_lock(&loop_ctl_mutex);
lo->lo_backing_file = NULL; --> set to NULL
mutex_unlock(&loop_ctl_mutex);
loop_set_fd()
mutex_lock_killable(&loop_ctl_mutex);
loop_validate_file()
f = l->lo_backing_file; --> NULL
access if loop0 is not Lo_unbound
mutex_lock(&loop_ctl_mutex);
lo->lo_state = Lo_unbound;
mutex_unlock(&loop_ctl_mutex);

lo->lo_backing_file should be accessed only when the loop device is
Lo_bound.

In fact, the problem has been introduced already in commit 7ccd0791d985
("loop: Push loop_ctl_mutex down into loop_clr_fd()") after which
loop_validate_file() could see devices in Lo_rundown state with which it
did not count. It was harmless at that point but still.

Fixes: 7ccd0791d985 ("loop: Push loop_ctl_mutex down into loop_clr_fd()")
Reported-by: syzbot+9bdc1adc1c55e7fe765b@...
Signed-off-by: Dongli Zhang <dongli.zhang@...>
Reviewed-by: Jan Kara <jack@...>
Signed-off-by: Jens Axboe <axboe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/block/loop.c


[linux:lloyd-aviation] By Jann Horn <jannh@...>:
367ccafbcbfe: x86/unwind: Handle NULL pointer calls better in frame unwinder

commit f4f34e1b82eb4219d8eaa1c7e2e17ca219a6a2b5 upstream.

When the frame unwinder is invoked for an oops caused by a call to NULL, it
currently skips the parent function because BP still points to the parent's
stack frame; the (nonexistent) current function only has the first half of
a stack frame, and BP doesn't point to it yet.

Add a special case for IP==0 that calculates a fake BP from SP, then uses
the real BP for the next frame.

Note that this handles first_frame specially: Return information about the
parent function as long as the saved IP is >=first_frame, even if the fake
BP points below it.

With an artificially-added NULL call in prctl_set_seccomp(), before this
patch, the trace is:

Call Trace:
? prctl_set_seccomp+0x3a/0x50
__x64_sys_prctl+0x457/0x6f0
? __ia32_sys_prctl+0x750/0x750
do_syscall_64+0x72/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9

After this patch, the trace is:

Call Trace:
prctl_set_seccomp+0x3a/0x50
__x64_sys_prctl+0x457/0x6f0
? __ia32_sys_prctl+0x750/0x750
do_syscall_64+0x72/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Jann Horn <jannh@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Acked-by: Josh Poimboeuf <jpoimboe@...>
Cc: Borislav Petkov <bp@...>
Cc: Andrew Morton <akpm@...>
Cc: syzbot <syzbot+ca95b2b7aef9e7cbd6ab@...>
Cc: "H. Peter Anvin" <hpa@...>
Cc: Masahiro Yamada <yamada.masahiro@...>
Cc: Michal Marek <michal.lkml@...>
Cc: linux-kbuild@...
Link: https://lkml.kernel.org/r/20190301031201.7416-1-jannh@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/include/asm/unwind.h
Modified: arch/x86/kernel/unwind_frame.c


[linux:lloyd-aviation] By Jann Horn <jannh@...>:
206a76a684a7: x86/unwind: Add hardcoded ORC entry for NULL

commit ac5ceccce5501e43d217c596e4ee859f2a3fef79 upstream.

When the ORC unwinder is invoked for an oops caused by IP==0,
it currently has no idea what to do because there is no debug information
for the stack frame of NULL.

But if RIP is NULL, it is very likely that the last successfully executed
instruction was an indirect CALL/JMP, and it is possible to unwind out in
the same way as for the first instruction of a normal function. Hardcode
a corresponding ORC entry.

With an artificially-added NULL call in prctl_set_seccomp(), before this
patch, the trace is:

Call Trace:
? __x64_sys_prctl+0x402/0x680
? __ia32_sys_prctl+0x6e0/0x6e0
? __do_page_fault+0x457/0x620
? do_syscall_64+0x6d/0x160
? entry_SYSCALL_64_after_hwframe+0x44/0xa9

After this patch, the trace looks like this:

Call Trace:
__x64_sys_prctl+0x402/0x680
? __ia32_sys_prctl+0x6e0/0x6e0
? __do_page_fault+0x457/0x620
do_syscall_64+0x6d/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9

prctl_set_seccomp() still doesn't show up in the trace because for some
reason, tail call optimization is only disabled in builds that use the
frame pointer unwinder.

Signed-off-by: Jann Horn <jannh@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Acked-by: Josh Poimboeuf <jpoimboe@...>
Cc: Borislav Petkov <bp@...>
Cc: Andrew Morton <akpm@...>
Cc: syzbot <syzbot+ca95b2b7aef9e7cbd6ab@...>
Cc: "H. Peter Anvin" <hpa@...>
Cc: Masahiro Yamada <yamada.masahiro@...>
Cc: Michal Marek <michal.lkml@...>
Cc: linux-kbuild@...
Link: https://lkml.kernel.org/r/20190301031201.7416-2-jannh@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/kernel/unwind_orc.c


[linux:lloyd-aviation] By Waiman Long <longman@...>:
0e0f7b307212: locking/lockdep: Add debug_locks check in __lock_downgrade()

commit 71492580571467fb7177aade19c18ce7486267f5 upstream.

Tetsuo Handa had reported he saw an incorrect "downgrading a read lock"
warning right after a previous lockdep warning. It is likely that the
previous warning turned off lock debugging causing the lockdep to have
inconsistency states leading to the lock downgrade warning.

Fix that by add a check for debug_locks at the beginning of
__lock_downgrade().

Debugged-by: Tetsuo Handa <penguin-kernel@...>
Reported-by: Tetsuo Handa <penguin-kernel@...>
Reported-by: syzbot+53383ae265fb161ef488@...
Signed-off-by: Waiman Long <longman@...>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...>
Cc: Andrew Morton <akpm@...>
Cc: Linus Torvalds <torvalds@...>
Cc: Paul E. McKenney <paulmck@...>
Cc: Peter Zijlstra <peterz@...>
Cc: Thomas Gleixner <tglx@...>
Cc: Will Deacon <will.deacon@...>
Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@...
Signed-off-by: Ingo Molnar <mingo@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/locking/lockdep.c


[linux:lloyd-aviation] By Takashi Iwai <tiwai@...>:
156ba57f4ba6: ALSA: hda - Record the current power state before suspend/resume calls

commit 98081ca62cbac31fb0f7efaf90b2e7384ce22257 upstream.

Currently we deal with single codec and suspend codec callbacks for
all S3, S4 and runtime PM handling. But it turned out that we want
distinguish the call patterns sometimes, e.g. for applying some init
sequence only at probing and restoring from hibernate.

This patch slightly modifies the common PM callbacks for HD-audio
codec and stores the currently processed PM event in power_state of
the codec's device.power field, which is currently unused. The codec
callback can take a look at this event value and judges which purpose
it's being called.

Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/hda_codec.c


[linux:lloyd-aviation] By Hui Wang <hui.wang@...>:
19184190b029: ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec

commit b5a236c175b0d984552a5f7c9d35141024c2b261 upstream.

Recently we found the audio jack detection stop working after suspend
on many machines with Realtek codec. Sometimes the audio selection
dialogue didn't show up after users plugged headhphone/headset into
the headset jack, sometimes after uses plugged headphone/headset, then
click the sound icon on the upper-right corner of gnome-desktop, it
also showed the speaker rather than the headphone.

The root cause is that before suspend, the codec already call the
runtime_suspend since this codec is not used by any apps, then in
resume, it will not call runtime_resume for this codec. But for some
realtek codec (so far, alc236, alc255 and alc891) with the specific
BIOS, if it doesn't run runtime_resume after suspend, all codec
functions including jack detection stop working anymore.

This problem existed for a long time, but it was not exposed, that is
because when problem happens, if users play sound or open
sound-setting to check audio device, this will trigger calling to
runtime_resume (via snd_hda_power_up), then the codec starts working
again before users notice this problem.

Since we don't know how many codec and BIOS combinations have this
problem, to fix it, let the driver call runtime_resume for all codecs
in pm_resume, maybe for some codecs, this is not needed, but it is
harmless. After a codec is runtime resumed, if it is not used by any
apps, it will be runtime suspended soon and furthermore we don't run
suspend frequently, this change will not add much power consumption.

Fixes: cc72da7d4d06 ("ALSA: hda - Use standard runtime PM for codec power-save control")
Signed-off-by: Hui Wang <hui.wang@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/hda_codec.c


[linux:lloyd-aviation] By Baolin Wang <baolin.wang@...>:
33bd347fee01: power: supply: charger-manager: Fix incorrect return value

commit f25a646fbe2051527ad9721853e892d13a99199e upstream.

Fix incorrect return value.

Signed-off-by: Baolin Wang <baolin.wang@...>
Signed-off-by: Sebastian Reichel <sebastian.reichel@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/power/supply/charger-manager.c


[linux:lloyd-aviation] By Greg Kroah-Hartman <gregkh@...>:
3a2156c839c7: Linux 4.19.32

Modified: Makefile


[linux:lloyd-aviation] By Marcel Holtmann <marcel@...>:
2318c0e4b87e: Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt

commit af3d5d1c87664a4f150fcf3534c6567cb19909b0 upstream.

When doing option parsing for standard type values of 1, 2 or 4 octets,
the value is converted directly into a variable instead of a pointer. To
avoid being tricked into being a pointer, check that for these option
types that sizes actually match. In L2CAP every option is fixed size and
thus it is prudent anyway to ensure that the remote side sends us the
right option size along with option paramters.

If the option size is not matching the option type, then that option is
silently ignored. It is a protocol violation and instead of trying to
give the remote attacker any further hints just pretend that option is
not present and proceed with the default values. Implementation
following the specification and its qualification procedures will always
use the correct size and thus not being impacted here.

To keep the code readable and consistent accross all options, a few
cosmetic changes were also required.

Signed-off-by: Marcel Holtmann <marcel@...>
Reviewed-by: Greg Kroah-Hartman <gregkh@...>
Signed-off-by: Johan Hedberg <johan.hedberg@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/bluetooth/l2cap_core.c


[linux:lloyd-aviation] By Marcel Holtmann <marcel@...>:
15d6538a0d6e: Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer

commit 7c9cbd0b5e38a1672fcd137894ace3b042dfbf69 upstream.

The function l2cap_get_conf_opt will return L2CAP_CONF_OPT_SIZE + opt->len
as length value. The opt->len however is in control over the remote user
and can be used by an attacker to gain access beyond the bounds of the
actual packet.

To prevent any potential leak of heap memory, it is enough to check that
the resulting len calculation after calling l2cap_get_conf_opt is not
below zero. A well formed packet will always return >= 0 here and will
end with the length value being zero after the last option has been
parsed. In case of malformed packets messing with the opt->len field the
length value will become negative. If that is the case, then just abort
and ignore the option.

In case an attacker uses a too short opt->len value, then garbage will
be parsed, but that is protected by the unknown option handling and also
the option parameter size checks.

Signed-off-by: Marcel Holtmann <marcel@...>
Reviewed-by: Greg Kroah-Hartman <gregkh@...>
Signed-off-by: Johan Hedberg <johan.hedberg@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/bluetooth/l2cap_core.c


[linux:lloyd-aviation] By Corey Minyard <cminyard@...>:
6bba17f6bce3: ipmi_si: Fix crash when using hard-coded device

Backport from 41b766d661bf94a364960862cfc248a78313dbd3

When excuting a command like:
modprobe ipmi_si ports=0xffc0e3 type=bt
The system would get an oops.

The trouble here is that ipmi_si_hardcode_find_bmc() is called before
ipmi_si_platform_init(), but initialization of the hard-coded device
creates an IPMI platform device, which won't be initialized yet.

The real trouble is that hard-coded devices aren't created with
any device, and the fixup is done later. So do it right, create the
hard-coded devices as normal platform devices.

This required adding some new resource types to the IPMI platform
code for passing information required by the hard-coded device
and adding some code to remove the hard-coded platform devices
on module removal.

To enforce the "hard-coded devices passed by the user take priority
over firmware devices" rule, some special code was added to check
and see if a hard-coded device already exists.

The backport required some minor fixups and adding the device
id table that had been added in another change and was used
in this one.

Reported-by: Yang Yingliang <yangyingliang@...>
Cc: stable@... # v4.15+
Signed-off-by: Corey Minyard <cminyard@...>
Tested-by: Yang Yingliang <yangyingliang@...>
Signed-off-by: Sasha Levin <sashal@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/char/ipmi/ipmi_si.h
Modified: drivers/char/ipmi/ipmi_si_hardcode.c
Modified: drivers/char/ipmi/ipmi_si_intf.c
Modified: drivers/char/ipmi/ipmi_si_platform.c


[linux:lloyd-aviation] By Eric Dumazet <edumazet@...>:
321461f2497f: dccp: do not use ipv6 header for ipv4 flow

[ Upstream commit e0aa67709f89d08c8d8e5bdd9e0b649df61d0090 ]

When a dual stack dccp listener accepts an ipv4 flow,
it should not attempt to use an ipv6 header or
inet6_iif() helper.

Fixes: 3df80d9320bc ("[DCCP]: Introduce DCCPv6")
Signed-off-by: Eric Dumazet <edumazet@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/dccp/ipv6.c


[linux:lloyd-aviation] By YueHaibing <yuehaibing@...>:
9b8ef421b481: genetlink: Fix a memory leak on error path

[ Upstream commit ceabee6c59943bdd5e1da1a6a20dc7ee5f8113a2 ]

In genl_register_family(), when idr_alloc() fails,
we forget to free the memory we possibly allocate for
family->attrbuf.

Reported-by: Hulk Robot <hulkci@...>
Fixes: 2ae0f17df1cd ("genetlink: use idr to track families")
Signed-off-by: YueHaibing <yuehaibing@...>
Reviewed-by: Kirill Tkhai <ktkhai@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/netlink/genetlink.c


[linux:lloyd-aviation] By Matteo Croce <mcroce@...>:
53adaacbbadb: gtp: change NET_UDP_TUNNEL dependency to select

[ Upstream commit c22da36688d6298f2e546dcc43fdc1ad35036467 ]

Similarly to commit a7603ac1fc8c ("geneve: change NET_UDP_TUNNEL
dependency to select"), GTP has a dependency on NET_UDP_TUNNEL which
makes impossible to compile it if no other protocol depending on
NET_UDP_TUNNEL is selected.

Fix this by changing the depends to a select, and drop NET_IP_TUNNEL from
the select list, as it already depends on NET_UDP_TUNNEL.

Signed-off-by: Matteo Croce <mcroce@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/Kconfig


[linux:lloyd-aviation] By Xin Long <lucien.xin@...>:
be09211384c2: ipv6: make ip6_create_rt_rcu return ip6_null_entry instead of NULL

[ Upstream commit 1c87e79a002f6a159396138cd3f3ab554a2a8887 ]

Jianlin reported a crash:

[ 381.484332] BUG: unable to handle kernel NULL pointer dereference at 0000000000000068
[ 381.619802] RIP: 0010:fib6_rule_lookup+0xa3/0x160
[ 382.009615] Call Trace:
[ 382.020762] <IRQ>
[ 382.030174] ip6_route_redirect.isra.52+0xc9/0xf0
[ 382.050984] ip6_redirect+0xb6/0xf0
[ 382.066731] icmpv6_notify+0xca/0x190
[ 382.083185] ndisc_redirect_rcv+0x10f/0x160
[ 382.102569] ndisc_rcv+0xfb/0x100
[ 382.117725] icmpv6_rcv+0x3f2/0x520
[ 382.133637] ip6_input_finish+0xbf/0x460
[ 382.151634] ip6_input+0x3b/0xb0
[ 382.166097] ipv6_rcv+0x378/0x4e0

It was caused by the lookup function __ip6_route_redirect() returns NULL in
fib6_rule_lookup() when ip6_create_rt_rcu() returns NULL.

So we fix it by simply making ip6_create_rt_rcu() return ip6_null_entry
instead of NULL.

v1->v2:
- move down 'fallback:' to make it more readable.

Fixes: e873e4b9cc7e ("ipv6: use fib6_info_hold_safe() when necessary")
Reported-by: Jianlin Shi <jishi@...>
Suggested-by: Paolo Abeni <pabeni@...>
Signed-off-by: Xin Long <lucien.xin@...>
Reviewed-by: David Ahern <dsahern@...>
Acked-by: Wei Wang <weiwan@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/ipv6/route.c


[linux:lloyd-aviation] By Finn Thain <fthain@...>:
e0f8c06f45c3: mac8390: Fix mmio access size probe

[ Upstream commit bb9e5c5bcd76f4474eac3baf643d7a39f7bac7bb ]

The bug that Stan reported is as follows. After a restart, a 16-bit NIC
may be incorrectly identified as a 32-bit NIC and stop working.

mac8390 slot.E: Memory length resource not found, probing
mac8390 slot.E: Farallon EtherMac II-C (type farallon)
mac8390 slot.E: MAC 00:00:c5:30:c2:99, IRQ 61, 32 KB shared memory at 0xfeed0000, 32-bit access.

The bug never arises after a cold start and only intermittently after a
warm start. (I didn't investigate why the bug is intermittent.)

It turns out that memcpy_toio() is deprecated and memcmp_withio() also
has issues. Replacing these calls with mmio accessors fixes the problem.

Reported-and-tested-by: Stan Johnson <userm57@...>
Fixes: 2964db0f5904 ("m68k: Mac DP8390 update")
Signed-off-by: Finn Thain <fthain@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/ethernet/8390/mac8390.c


[linux:lloyd-aviation] By Bjorn Helgaas <bhelgaas@...>:
c408426292ee: mISDN: hfcpci: Test both vendor & device ID for Digium HFC4S

[ Upstream commit fae846e2b7124d4b076ef17791c73addf3b26350 ]

The device ID alone does not uniquely identify a device. Test both the
vendor and device ID to make sure we don't mistakenly think some other
vendor's 0xB410 device is a Digium HFC4S. Also, instead of the bare hex
ID, use the same constant (PCI_DEVICE_ID_DIGIUM_HFC4S) used in the device
ID table.

No functional change intended.

Signed-off-by: Bjorn Helgaas <bhelgaas@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/isdn/hardware/mISDN/hfcmulti.c


[linux:lloyd-aviation] By Dmitry Bogdanov <dmitry.bogdanov@...>:
e4ff39e1ba80: net: aquantia: fix rx checksum offload for UDP/TCP over IPv6

[ Upstream commit a7faaa0c5dc7d091cc9f72b870d7edcdd6f43f12 ]

TCP/UDP checksum validity was propagated to skb
only if IP checksum is valid.
But for IPv6 there is no validity as there is no checksum in IPv6.
This patch propagates TCP/UDP checksum validity regardless of IP checksum.

Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
Signed-off-by: Igor Russkikh <igor.russkikh@...>
Signed-off-by: Nikita Danilov <nikita.danilov@...>
Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/ethernet/aquantia/atlantic/aq_ring.c


[linux:lloyd-aviation] By Paolo Abeni <pabeni@...>:
88c64f9c7d3f: net: datagram: fix unbounded loop in __skb_try_recv_datagram()

[ Upstream commit 0b91bce1ebfc797ff3de60c8f4a1e6219a8a3187 ]

Christoph reported a stall while peeking datagram with an offset when
busy polling is enabled. __skb_try_recv_datagram() uses as the loop
termination condition 'queue empty'. When peeking, the socket
queue can be not empty, even when no additional packets are received.

Address the issue explicitly checking for receive queue changes,
as currently done by __skb_wait_for_more_packets().

Fixes: 2b5cd0dfa384 ("net: Change return type of sk_busy_loop from bool to void")
Reported-and-tested-by: Christoph Paasch <cpaasch@...>
Signed-off-by: Paolo Abeni <pabeni@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/core/datagram.c


[linux:lloyd-aviation] By Christoph Paasch <cpaasch@...>:
85ef72d829eb: net/packet: Set __GFP_NOWARN upon allocation in alloc_pg_vec

[ Upstream commit 398f0132c14754fcd03c1c4f8e7176d001ce8ea1 ]

Since commit fc62814d690c ("net/packet: fix 4gb buffer limit due to overflow check")
one can now allocate packet ring buffers >= UINT_MAX. However, syzkaller
found that that triggers a warning:

[ 21.100000] WARNING: CPU: 2 PID: 2075 at mm/page_alloc.c:4584 __alloc_pages_nod0
[ 21.101490] Modules linked in:
[ 21.101921] CPU: 2 PID: 2075 Comm: syz-executor.0 Not tainted 5.0.0 #146
[ 21.102784] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
[ 21.103887] RIP: 0010:__alloc_pages_nodemask+0x2a0/0x630
[ 21.104640] Code: fe ff ff 65 48 8b 04 25 c0 de 01 00 48 05 90 0f 00 00 41 bd 01 00 00 00 48 89 44 24 48 e9 9c fe 3
[ 21.107121] RSP: 0018:ffff88805e1cf920 EFLAGS: 00010246
[ 21.107819] RAX: 0000000000000000 RBX: ffffffff85a488a0 RCX: 0000000000000000
[ 21.108753] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000000
[ 21.109699] RBP: 1ffff1100bc39f28 R08: ffffed100bcefb67 R09: ffffed100bcefb67
[ 21.110646] R10: 0000000000000001 R11: ffffed100bcefb66 R12: 000000000000000d
[ 21.111623] R13: 0000000000000000 R14: ffff88805e77d888 R15: 000000000000000d
[ 21.112552] FS: 00007f7c7de05700(0000) GS:ffff88806d100000(0000) knlGS:0000000000000000
[ 21.113612] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 21.114405] CR2: 000000000065c000 CR3: 000000005e58e006 CR4: 00000000001606e0
[ 21.115367] Call Trace:
[ 21.115705] ? __alloc_pages_slowpath+0x21c0/0x21c0
[ 21.116362] alloc_pages_current+0xac/0x1e0
[ 21.116923] kmalloc_order+0x18/0x70
[ 21.117393] kmalloc_order_trace+0x18/0x110
[ 21.117949] packet_set_ring+0x9d5/0x1770
[ 21.118524] ? packet_rcv_spkt+0x440/0x440
[ 21.119094] ? lock_downgrade+0x620/0x620
[ 21.119646] ? __might_fault+0x177/0x1b0
[ 21.120177] packet_setsockopt+0x981/0x2940
[ 21.120753] ? __fget+0x2fb/0x4b0
[ 21.121209] ? packet_release+0xab0/0xab0
[ 21.121740] ? sock_has_perm+0x1cd/0x260
[ 21.122297] ? selinux_secmark_relabel_packet+0xd0/0xd0
[ 21.123013] ? __fget+0x324/0x4b0
[ 21.123451] ? selinux_netlbl_socket_setsockopt+0x101/0x320
[ 21.124186] ? selinux_netlbl_sock_rcv_skb+0x3a0/0x3a0
[ 21.124908] ? __lock_acquire+0x529/0x3200
[ 21.125453] ? selinux_socket_setsockopt+0x5d/0x70
[ 21.126075] ? __sys_setsockopt+0x131/0x210
[ 21.126533] ? packet_release+0xab0/0xab0
[ 21.127004] __sys_setsockopt+0x131/0x210
[ 21.127449] ? kernel_accept+0x2f0/0x2f0
[ 21.127911] ? ret_from_fork+0x8/0x50
[ 21.128313] ? do_raw_spin_lock+0x11b/0x280
[ 21.128800] __x64_sys_setsockopt+0xba/0x150
[ 21.129271] ? lockdep_hardirqs_on+0x37f/0x560
[ 21.129769] do_syscall_64+0x9f/0x450
[ 21.130182] entry_SYSCALL_64_after_hwframe+0x49/0xbe

We should allocate with __GFP_NOWARN to handle this.

Cc: Kal Conley <kal.conley@...>
Cc: Andrey Konovalov <andreyknvl@...>
Fixes: fc62814d690c ("net/packet: fix 4gb buffer limit due to overflow check")
Signed-off-by: Christoph Paasch <cpaasch@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/packet/af_packet.c


[linux:lloyd-aviation] By Jerome Brunet <jbrunet@...>:
a6f0168e6681: net: phy: meson-gxl: fix interrupt support

[ Upstream commit daa5c4d0167a308306525fd5ab9a5e18e21f4f74 ]

If an interrupt is already pending when the interrupt is enabled on the
GXL phy, no IRQ will ever be triggered.

The fix is simply to make sure pending IRQs are cleared before setting
up the irq mask.

Fixes: cf127ff20af1 ("net: phy: meson-gxl: add interrupt support")
Signed-off-by: Jerome Brunet <jbrunet@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/phy/meson-gxl.c


[linux:lloyd-aviation] By Eric Dumazet <edumazet@...>:
7eeb12edf637: net: rose: fix a possible stack overflow

[ Upstream commit e5dcc0c3223c45c94100f05f28d8ef814db3d82c ]

rose_write_internal() uses a temp buffer of 100 bytes, but a manual
inspection showed that given arbitrary input, rose_create_facilities()
can fill up to 110 bytes.

Lets use a tailroom of 256 bytes for peace of mind, and remove
the bounce buffer : we can simply allocate a big enough skb
and adjust its length as needed.

syzbot report :

BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:352 [inline]
BUG: KASAN: stack-out-of-bounds in rose_create_facilities net/rose/rose_subr.c:521 [inline]
BUG: KASAN: stack-out-of-bounds in rose_write_internal+0x597/0x15d0 net/rose/rose_subr.c:116
Write of size 7 at addr ffff88808b1ffbef by task syz-executor.0/24854

CPU: 0 PID: 24854 Comm: syz-executor.0 Not tainted 5.0.0+ #97
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x123/0x190 mm/kasan/generic.c:191
memcpy+0x38/0x50 mm/kasan/common.c:131
memcpy include/linux/string.h:352 [inline]
rose_create_facilities net/rose/rose_subr.c:521 [inline]
rose_write_internal+0x597/0x15d0 net/rose/rose_subr.c:116
rose_connect+0x7cb/0x1510 net/rose/af_rose.c:826
__sys_connect+0x266/0x330 net/socket.c:1685
__do_sys_connect net/socket.c:1696 [inline]
__se_sys_connect net/socket.c:1693 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1693
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x458079
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f47b8d9dc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458079
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000004
RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f47b8d9e6d4
R13: 00000000004be4a4 R14: 00000000004ceca8 R15: 00000000ffffffff

The buggy address belongs to the page:
page:ffffea00022c7fc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x1fffc0000000000()
raw: 01fffc0000000000 0000000000000000 ffffffff022c0101 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff88808b1ffa80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88808b1ffb00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 03

ffff88808b1ffb80: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 04 f3
^
ffff88808b1ffc00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
ffff88808b1ffc80: 00 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 01 f2 01

Signed-off-by: Eric Dumazet <edumazet@...>
Reported-by: syzbot <syzkaller@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/rose/rose_subr.c


[linux:lloyd-aviation] By Aaro Koskinen <aaro.koskinen@...>:
8dcf078d92ae: net: stmmac: fix memory corruption with large MTUs

[ Upstream commit 223a960c01227e4dbcb6f9fa06b47d73bda21274 ]

When using 16K DMA buffers and ring mode, the DES3 refill is not working
correctly as the function is using a bogus pointer for checking the
private data. As a result stale pointers will remain in the RX descriptor
ring, so DMA will now likely overwrite/corrupt some already freed memory.

As simple reproducer, just receive some UDP traffic:

# ifconfig eth0 down; ifconfig eth0 mtu 9000; ifconfig eth0 up
# iperf3 -c 192.168.253.40 -u -b 0 -R

If you didn't crash by now check the RX descriptors to find non-contiguous
RX buffers:

cat /sys/kernel/debug/stmmaceth/eth0/descriptors_status
[...]
1 [0x2be5020]: 0xa3220321 0x9ffc1ffc 0x72d70082 0x130e207e
^^^^^^^^^^^^^^^^^^^^^
2 [0x2be5040]: 0xa3220321 0x9ffc1ffc 0x72998082 0x1311a07e
^^^^^^^^^^^^^^^^^^^^^

A simple ping test will now report bad data:

# ping -s 8200 192.168.253.40
PING 192.168.253.40 (192.168.253.40) 8200(8228) bytes of data.
8208 bytes from 192.168.253.40: icmp_seq=1 ttl=64 time=1.00 ms
wrong data byte #8144 should be 0xd0 but was 0x88

Fix the wrong pointer. Also we must refill DES3 only if the DMA buffer
size is 16K.

Fixes: 54139cf3bb33 ("net: stmmac: adding multiple buffers for rx")
Signed-off-by: Aaro Koskinen <aaro.koskinen@...>
Acked-by: Jose Abreu <joabreu@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/ethernet/stmicro/stmmac/ring_mode.c


[linux:lloyd-aviation] By YueHaibing <yuehaibing@...>:
d9d215be3a3a: net-sysfs: call dev_hold if kobject_init_and_add success

[ Upstream commit a3e23f719f5c4a38ffb3d30c8d7632a4ed8ccd9e ]

In netdev_queue_add_kobject and rx_queue_add_kobject,
if sysfs_create_group failed, kobject_put will call
netdev_queue_release to decrease dev refcont, however
dev_hold has not be called. So we will see this while
unregistering dev:

unregister_netdevice: waiting for bcsh0 to become free. Usage count = -1

Reported-by: Hulk Robot <hulkci@...>
Fixes: d0d668371679 ("net: don't decrement kobj reference count on init failure")
Signed-off-by: YueHaibing <yuehaibing@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/core/net-sysfs.c


[linux:lloyd-aviation] By Maxime Chevallier <maxime.chevallier@...>:
69cea7cf3170: packets: Always register packet sk in the same order

[ Upstream commit a4dc6a49156b1f8d6e17251ffda17c9e6a5db78a ]

When using fanouts with AF_PACKET, the demux functions such as
fanout_demux_cpu will return an index in the fanout socket array, which
corresponds to the selected socket.

The ordering of this array depends on the order the sockets were added
to a given fanout group, so for FANOUT_CPU this means sockets are bound
to cpus in the order they are configured, which is OK.

However, when stopping then restarting the interface these sockets are
bound to, the sockets are reassigned to the fanout group in the reverse
order, due to the fact that they were inserted at the head of the
interface's AF_PACKET socket list.

This means that traffic that was directed to the first socket in the
fanout group is now directed to the last one after an interface restart.

In the case of FANOUT_CPU, traffic from CPU0 will be directed to the
socket that used to receive traffic from the last CPU after an interface
restart.

This commit introduces a helper to add a socket at the tail of a list,
then uses it to register AF_PACKET sockets.

Note that this changes the order in which sockets are listed in /proc and
with sock_diag.

Fixes: dc99f600698d ("packet: Add fanout support")
Signed-off-by: Maxime Chevallier <maxime.chevallier@...>
Acked-by: Willem de Bruijn <willemb@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: include/net/sock.h
Modified: net/packet/af_packet.c


[linux:lloyd-aviation] By Herbert Xu <herbert@...>:
cf86f7a97561: rhashtable: Still do rehash when we get EEXIST

[ Upstream commit 408f13ef358aa5ad56dc6230c2c7deb92cf462b1 ]

As it stands if a shrink is delayed because of an outstanding
rehash, we will go into a rescheduling loop without ever doing
the rehash.

This patch fixes this by still carrying out the rehash and then
rescheduling so that we can shrink after the completion of the
rehash should it still be necessary.

The return value of EEXIST captures this case and other cases
(e.g., another thread expanded/rehashed the table at the same
time) where we should still proceed with the rehash.

Fixes: da20420f83ea ("rhashtable: Add nested tables")
Reported-by: Josh Elsasser <jelsasser@...>
Signed-off-by: Herbert Xu <herbert@...>
Tested-by: Josh Elsasser <jelsasser@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: lib/rhashtable.c


[linux:lloyd-aviation] By Xin Long <lucien.xin@...>:
97265479d7ca: sctp: get sctphdr by offset in sctp_compute_cksum

[ Upstream commit 273160ffc6b993c7c91627f5a84799c66dfe4dee ]

sctp_hdr(skb) only works when skb->transport_header is set properly.

But in Netfilter, skb->transport_header for ipv6 is not guaranteed
to be right value for sctphdr. It would cause to fail to check the
checksum for sctp packets.

So fix it by using offset, which is always right in all places.

v1->v2:
- Fix the changelog.

Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code")
Reported-by: Li Shuang <shuali@...>
Signed-off-by: Xin Long <lucien.xin@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: include/net/sctp/checksum.h


[linux:lloyd-aviation] By Xin Long <lucien.xin@...>:
cab576f1b00f: sctp: use memdup_user instead of vmemdup_user

[ Upstream commit ef82bcfa671b9a635bab5fa669005663d8b177c5 ]

In sctp_setsockopt_bindx()/__sctp_setsockopt_connectx(), it allocates
memory with addrs_size which is passed from userspace. We used flag
GFP_USER to put some more restrictions on it in Commit cacc06215271
("sctp: use GFP_USER for user-controlled kmalloc").

However, since Commit c981f254cc82 ("sctp: use vmemdup_user() rather
than badly open-coding memdup_user()"), vmemdup_user() has been used,
which doesn't check GFP_USER flag when goes to vmalloc_*(). So when
addrs_size is a huge value, it could exhaust memory and even trigger
oom killer.

This patch is to use memdup_user() instead, in which GFP_USER would
work to limit the memory allocation with a huge addrs_size.

Note we can't fix it by limiting 'addrs_size', as there's no demand
for it from RFC.

Reported-by: syzbot+ec1b7575afef85a0e5ca@...
Fixes: c981f254cc82 ("sctp: use vmemdup_user() rather than badly open-coding memdup_user()")
Signed-off-by: Xin Long <lucien.xin@...>
Acked-by: Neil Horman <nhorman@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/sctp/socket.c


[linux:lloyd-aviation] By Eric Dumazet <edumazet@...>:
7115df614b09: tcp: do not use ipv6 header for ipv4 flow

[ Upstream commit 89e4130939a20304f4059ab72179da81f5347528 ]

When a dual stack tcp listener accepts an ipv4 flow,
it should not attempt to use an ipv6 header or tcp_v6_iif() helper.

Fixes: 1397ed35f22d ("ipv6: add flowinfo for tcp6 pkt_options for all cases")
Fixes: df3687ffc665 ("ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/ipv6/tcp_ipv6.c


[linux:lloyd-aviation] By Erik Hugne <erik.hugne@...>:
24d1a6259706: tipc: allow service ranges to be connect()'ed on RDM/DGRAM

[ Upstream commit ea239314fe42ace880bdd834256834679346c80e ]

We move the check that prevents connecting service ranges to after
the RDM/DGRAM check, and move address sanity control to a separate
function that also validates the service range.

Fixes: 23998835be98 ("tipc: improve address sanity check in tipc_connect()")
Signed-off-by: Erik Hugne <erik.hugne@...>
Signed-off-by: Jon Maloy <jon.maloy@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/tipc/socket.c


[linux:lloyd-aviation] By Xin Long <lucien.xin@...>:
1be6c0c737e4: tipc: change to check tipc_own_id to return in tipc_net_stop

[ Upstream commit 9926cb5f8b0f0aea535735185600d74db7608550 ]

When running a syz script, a panic occurred:

[ 156.088228] BUG: KASAN: use-after-free in tipc_disc_timeout+0x9c9/0xb20 [tipc]
[ 156.094315] Call Trace:
[ 156.094844] <IRQ>
[ 156.095306] dump_stack+0x7c/0xc0
[ 156.097346] print_address_description+0x65/0x22e
[ 156.100445] kasan_report.cold.3+0x37/0x7a
[ 156.102402] tipc_disc_timeout+0x9c9/0xb20 [tipc]
[ 156.106517] call_timer_fn+0x19a/0x610
[ 156.112749] run_timer_softirq+0xb51/0x1090

It was caused by the netns freed without deleting the discoverer timer,
while later on the netns would be accessed in the timer handler.

The timer should have been deleted by tipc_net_stop() when cleaning up a
netns. However, tipc has been able to enable a bearer and start d->timer
without the local node_addr set since Commit 52dfae5c85a4 ("tipc: obtain
node identity from interface by default"), which caused the timer not to
be deleted in tipc_net_stop() then.

So fix it in tipc_net_stop() by changing to check local node_id instead
of local node_addr, as Jon suggested.

While at it, remove the calling of tipc_nametbl_withdraw() there, since
tipc_nametbl_stop() will take of the nametbl's freeing after.

Fixes: 52dfae5c85a4 ("tipc: obtain node identity from interface by default")
Reported-by: syzbot+a25307ad099309f1c2b9@...
Signed-off-by: Xin Long <lucien.xin@...>
Acked-by: Ying Xue <ying.xue@...>
Acked-by: Jon Maloy <jon.maloy@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/tipc/net.c


[linux:lloyd-aviation] By Erik Hugne <erik.hugne@...>:
52a7505c91a1: tipc: fix cancellation of topology subscriptions

[ Upstream commit 33872d79f5d1cbedaaab79669cc38f16097a9450 ]

When cancelling a subscription, we have to clear the cancel bit in the
request before iterating over any established subscriptions with memcmp.
Otherwise no subscription will ever be found, and it will not be
possible to explicitly unsubscribe individual subscriptions.

Fixes: 8985ecc7c1e0 ("tipc: simplify endianness handling in topology subscriber")
Signed-off-by: Erik Hugne <erik.hugne@...>
Signed-off-by: Jon Maloy <jon.maloy@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/tipc/topsrv.c


[linux:lloyd-aviation] By Eric Dumazet <edumazet@...>:
8ea78da1aa3e: tun: properly test for IFF_UP

[ Upstream commit 4477138fa0ae4e1b699786ef0600863ea6e6c61c ]

Same reasons than the ones explained in commit 4179cb5a4c92
("vxlan: test dev->flags & IFF_UP before calling netif_rx()")

netif_rx_ni() or napi_gro_frags() must be called under a strict contract.

At device dismantle phase, core networking clears IFF_UP
and flush_all_backlogs() is called after rcu grace period
to make sure no incoming packet might be in a cpu backlog
and still referencing the device.

A similar protocol is used for gro layer.

Most drivers call netif_rx() from their interrupt handler,
and since the interrupts are disabled at device dismantle,
netif_rx() does not have to check dev->flags & IFF_UP

Virtual drivers do not have this guarantee, and must
therefore make the check themselves.

Fixes: 1bd4978a88ac ("tun: honor IFF_UP in tun_get_user()")
Signed-off-by: Eric Dumazet <edumazet@...>
Reported-by: syzbot <syzkaller@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/tun.c


[linux:lloyd-aviation] By Sabrina Dubroca <sd@...>:
3b1386beeef4: vrf: prevent adding upper devices

[ Upstream commit 1017e0987117c32783ba7c10fe2e7ff1456ba1dc ]

VRF devices don't work with upper devices. Currently, it's possible to
add a VRF device to a bridge or team, and to create macvlan, macsec, or
ipvlan devices on top of a VRF (bond and vlan are prevented respectively
by the lack of an ndo_set_mac_address op and the NETIF_F_VLAN_CHALLENGED
feature flag).

Fix this by setting the IFF_NO_RX_HANDLER flag (introduced in commit
f5426250a6ec ("net: introduce IFF_NO_RX_HANDLER")).

Cc: David Ahern <dsahern@...>
Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
Signed-off-by: Sabrina Dubroca <sd@...>
Acked-by: David Ahern <dsahern@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/vrf.c


[linux:lloyd-aviation] By Zhiqiang Liu <liuzhiqiang26@...>:
979f8a675d3b: vxlan: Don't call gro_cells_destroy() before device is unregistered

[ Upstream commit cc4807bb609230d8959fd732b0bf3bd4c2de8eac ]

Commit ad6c9986bcb62 ("vxlan: Fix GRO cells race condition between
receive and link delete") fixed a race condition for the typical case a vxlan
device is dismantled from the current netns. But if a netns is dismantled,
vxlan_destroy_tunnels() is called to schedule a unregister_netdevice_queue()
of all the vxlan tunnels that are related to this netns.

In vxlan_destroy_tunnels(), gro_cells_destroy() is called and finished before
unregister_netdevice_queue(). This means that the gro_cells_destroy() call is
done too soon, for the same reasons explained in above commit.

So we need to fully respect the RCU rules, and thus must remove the
gro_cells_destroy() call or risk use after-free.

Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer")
Signed-off-by: Suanming.Mou <mousuanming@...>
Suggested-by: Eric Dumazet <eric.dumazet@...>
Reviewed-by: Stefano Brivio <sbrivio@...>
Reviewed-by: Zhiqiang Liu <liuzhiqiang26@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/vxlan.c


[linux:lloyd-aviation] By Herbert Xu <herbert@...>:
7254ad094f4a: ila: Fix rhashtable walker list corruption

[ Upstream commit b5f9bd15b88563b55a99ed588416881367a0ce5f ]

ila_xlat_nl_cmd_flush uses rhashtable walkers allocated from the
stack but it never frees them. This corrupts the walker list of
the hash table.

This patch fixes it.

Reported-by: syzbot+dae72a112334aa65a159@...
Fixes: b6e71bdebb12 ("ila: Flush netlink command to clear xlat...")
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/ipv6/ila/ila_xlat.c


[linux:lloyd-aviation] By John Hurley <john.hurley@...>:
a491de9041b4: net: sched: fix cleanup NULL pointer exception in act_mirr

[ Upstream commit 064c5d6881e897077639e04973de26440ee205e6 ]

A new mirred action is created by the tcf_mirred_init function. This
contains a list head struct which is inserted into a global list on
successful creation of a new action. However, after a creation, it is
still possible to error out and call the tcf_idr_release function. This,
in turn, calls the act_mirr cleanup function via __tcf_idr_release and
__tcf_action_put. This cleanup function tries to delete the list entry
which is as yet uninitialised, leading to a NULL pointer exception.

Fix this by initialising the list entry on creation of a new action.

Bug report:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
PGD 8000000840c73067 P4D 8000000840c73067 PUD 858dcc067 PMD 0
Oops: 0002 [#1] SMP PTI
CPU: 32 PID: 5636 Comm: handler194 Tainted: G OE 5.0.0+ #186
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.3.6 06/03/2015
RIP: 0010:tcf_mirred_release+0x42/0xa7 [act_mirred]
Code: f0 90 39 c0 e8 52 04 57 c8 48 c7 c7 b8 80 39 c0 e8 94 fa d4 c7 48 8b 93 d0 00 00 00 48 8b 83 d8 00 00 00 48 c7 c7 f0 90 39 c0 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 d0 00
RSP: 0018:ffffac4aa059f688 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9dcd1b214d00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9dcd1fa165f8 RDI: ffffffffc03990f0
RBP: ffff9dccf9c7af80 R08: 0000000000000a3b R09: 0000000000000000
R10: ffff9dccfa11f420 R11: 0000000000000000 R12: 0000000000000001
R13: ffff9dcd16b433c0 R14: ffff9dcd1b214d80 R15: 0000000000000000
FS: 00007f441bfff700(0000) GS:ffff9dcd1fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 0000000839e64004 CR4: 00000000001606e0
Call Trace:
tcf_action_cleanup+0x59/0xca
__tcf_action_put+0x54/0x6b
__tcf_idr_release.cold.33+0x9/0x12
tcf_mirred_init.cold.20+0x22e/0x3b0 [act_mirred]
tcf_action_init_1+0x3d0/0x4c0
tcf_action_init+0x9c/0x130
tcf_exts_validate+0xab/0xc0
fl_change+0x1ca/0x982 [cls_flower]
tc_new_tfilter+0x647/0x8d0
? load_balance+0x14b/0x9e0
rtnetlink_rcv_msg+0xe3/0x370
? __switch_to_asm+0x40/0x70
? __switch_to_asm+0x34/0x70
? _cond_resched+0x15/0x30
? __kmalloc_node_track_caller+0x1d4/0x2b0
? rtnl_calcit.isra.31+0xf0/0xf0
netlink_rcv_skb+0x49/0x110
netlink_unicast+0x16f/0x210
netlink_sendmsg+0x1df/0x390
sock_sendmsg+0x36/0x40
___sys_sendmsg+0x27b/0x2c0
? futex_wake+0x80/0x140
? do_futex+0x2b9/0xac0
? ep_scan_ready_list.constprop.22+0x1f2/0x210
? ep_poll+0x7a/0x430
__sys_sendmsg+0x47/0x80
do_syscall_64+0x55/0x100
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 4e232818bd32 ("net: sched: act_mirred: remove dependency on rtnl lock")
Signed-off-by: John Hurley <john.hurley@...>
Reviewed-by: Jakub Kicinski <jakub.kicinski@...>
Acked-by: Cong Wang <xiyou.wangcong@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: net/sched/act_mirred.c


[linux:lloyd-aviation] By Dean Nelson <dnelson@...>:
ac8411d75962: thunderx: enable page recycling for non-XDP case

[ Upstream commit b3e208069477588c06f4d5d986164b435bb06e6d ]

Commit 773225388dae15e72790 ("net: thunderx: Optimize page recycling for XDP")
added code to nicvf_alloc_page() that inadvertently disables receive buffer
page recycling for the non-XDP case by always NULL'ng the page pointer.

This patch corrects two if-conditionals to allow for the recycling of non-XDP
mode pages by only setting the page pointer to NULL when the page is not ready
for recycling.

Fixes: 773225388dae ("net: thunderx: Optimize page recycling for XDP")
Signed-off-by: Dean Nelson <dnelson@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/ethernet/cavium/thunder/nicvf_queues.c


[linux:lloyd-aviation] By Dean Nelson <dnelson@...>:
6bdb5fdc4787: thunderx: eliminate extra calls to put_page() for pages held for recycling

[ Upstream commit cd35ef91490ad8049dd180bb060aff7ee192eda9 ]

For the non-XDP case, commit 773225388dae15e72790 ("net: thunderx: Optimize
page recycling for XDP") added code to nicvf_free_rbdr() that, when releasing
the additional receive buffer page reference held for recycling, repeatedly
calls put_page() until the page's _refcount goes to zero. Which results in
the page being freed.

This is not okay if the page's _refcount was greater than 1 (in the non-XDP
case), because nicvf_free_rbdr() should not be subtracting more than what
nicvf_alloc_page() had previously added to the page's _refcount, which was
only 1 (in the non-XDP case).

This can arise if a received packet is still being processed and the receive
buffer (i.e., skb->head) has not yet been freed via skb_free_head() when
nicvf_free_rbdr() is spinning through the aforementioned put_page() loop.

If this should occur, when the received packet finishes processing and
skb_free_head() is called, various problems can ensue. Exactly what, depends on
whether the page has already been reallocated or not, anything from "BUG: Bad
page state ... ", to "Unable to handle kernel NULL pointer dereference ..." or
"Unable to handle kernel paging request...".

So this patch changes nicvf_free_rbdr() to only call put_page() once for pages
held for recycling (in the non-XDP case).

Fixes: 773225388dae ("net: thunderx: Optimize page recycling for XDP")
Signed-off-by: Dean Nelson <dnelson@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/ethernet/cavium/thunder/nicvf_queues.c


[linux:lloyd-aviation] By Eric Dumazet <edumazet@...>:
e044d21c2999: tun: add a missing rcu_read_unlock() in error path

commit 9180bb4f046064dfa4541488102703b402bb04e1 upstream.

In my latest patch I missed one rcu_read_unlock(), in case
device is down.

Fixes: 4477138fa0ae ("tun: properly test for IFF_UP")
Signed-off-by: Eric Dumazet <edumazet@...>
Reported-by: syzbot <syzkaller@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/tun.c


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
d67ab3d9a1b7: powerpc/fsl: Add infrastructure to fixup branch predictor flush

commit 76a5eaa38b15dda92cd6964248c39b5a6f3a4e9d upstream.

In order to protect against speculation attacks (Spectre
variant 2) on NXP PowerPC platforms, the branch predictor
should be flushed when the privillege level is changed.
This patch is adding the infrastructure to fixup at runtime
the code sections that are performing the branch predictor flush
depending on a boot arg parameter which is added later in a
separate patch.

Signed-off-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/include/asm/feature-fixups.h
Modified: arch/powerpc/include/asm/setup.h
Modified: arch/powerpc/kernel/vmlinux.lds.S
Modified: arch/powerpc/lib/feature-fixups.c


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
4944f1d48d71: powerpc/fsl: Add macro to flush the branch predictor

commit 1cbf8990d79ff69da8ad09e8a3df014e1494462b upstream.

The BUCSR register can be used to invalidate the entries in the
branch prediction mechanisms.

Signed-off-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/include/asm/ppc_asm.h


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
4a6a2287e0e6: powerpc/fsl: Emulate SPRN_BUCSR register

commit 98518c4d8728656db349f875fcbbc7c126d4c973 upstream.

In order to flush the branch predictor the guest kernel performs
writes to the BUCSR register which is hypervisor privilleged. However,
the branch predictor is flushed at each KVM entry, so the branch
predictor has been already flushed, so just return as soon as possible
to guest.

Signed-off-by: Diana Craciun <diana.craciun@...>
[mpe: Tweak comment formatting]
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kvm/e500_emulate.c


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
020e5f13805b: powerpc/fsl: Add nospectre_v2 command line argument

commit f633a8ad636efb5d4bba1a047d4a0f1ef719aa06 upstream.

When the command line argument is present, the Spectre variant 2
mitigations are disabled.

Signed-off-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/include/asm/setup.h
Modified: arch/powerpc/kernel/security.c


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
cf72dad924cb: powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)

commit 10c5e83afd4a3f01712d97d3bb1ae34d5b74a185 upstream.

In order to protect against speculation attacks on
indirect branches, the branch predictor is flushed at
kernel entry to protect for the following situations:
- userspace process attacking another userspace process
- userspace process attacking the kernel
Basically when the privillege level change (i.e. the
kernel is entered), the branch predictor state is flushed.

Signed-off-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/entry_64.S
Modified: arch/powerpc/kernel/exceptions-64e.S
Modified: arch/powerpc/mm/tlb_low_64e.S


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
3cb931c709d0: powerpc/fsl: Flush the branch predictor at each kernel entry (32 bit)

commit 7fef436295bf6c05effe682c8797dfcb0deb112a upstream.

In order to protect against speculation attacks on
indirect branches, the branch predictor is flushed at
kernel entry to protect for the following situations:
- userspace process attacking another userspace process
- userspace process attacking the kernel
Basically when the privillege level change (i.e.the kernel
is entered), the branch predictor state is flushed.

Signed-off-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/head_booke.h
Modified: arch/powerpc/kernel/head_fsl_booke.S


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
a46a50382639: powerpc/fsl: Flush branch predictor when entering KVM

commit e7aa61f47b23afbec41031bc47ca8d6cb6516abc upstream.

Switching from the guest to host is another place
where the speculative accesses can be exploited.
Flush the branch predictor when entering KVM.

Signed-off-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kvm/bookehv_interrupts.S


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
43f40620d7a5: powerpc/fsl: Enable runtime patching if nospectre_v2 boot arg is used

commit 3bc8ea8603ae4c1e09aca8de229ad38b8091fcb3 upstream.

If the user choses not to use the mitigations, replace
the code sequence with nops.

Signed-off-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/setup-common.c


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
632d839296bd: powerpc/fsl: Update Spectre v2 reporting

commit dfa88658fb0583abb92e062c7a9cd5a5b94f2a46 upstream.

Report branch predictor state flush as a mitigation for
Spectre variant 2.

Signed-off-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/security.c


[linux:lloyd-aviation] By Diana Craciun <diana.craciun@...>:
b848d19c483a: powerpc/fsl: Fixed warning: orphan section `__btb_flush_fixup'

commit 039daac5526932ec731e4499613018d263af8b3e upstream.

Fixed the following build warning:
powerpc-linux-gnu-ld: warning: orphan section `__btb_flush_fixup' from
`arch/powerpc/kernel/head_44x.o' being placed in section
`__btb_flush_fixup'.

Signed-off-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/head_booke.h


[linux:lloyd-aviation] By Christophe Leroy <christophe.leroy@...>:
986f0c656749: powerpc/fsl: Fix the flush of branch predictor.

commit 27da80719ef132cf8c80eb406d5aeb37dddf78cc upstream.

The commit identified below adds MC_BTB_FLUSH macro only when
CONFIG_PPC_FSL_BOOK3E is defined. This results in the following error
on some configs (seen several times with kisskb randconfig_defconfig)

arch/powerpc/kernel/exceptions-64e.S:576: Error: Unrecognized opcode: `mc_btb_flush'
make[3]: *** [scripts/Makefile.build:367: arch/powerpc/kernel/exceptions-64e.o] Error 1
make[2]: *** [scripts/Makefile.build:492: arch/powerpc/kernel] Error 2
make[1]: *** [Makefile:1043: arch/powerpc] Error 2
make: *** [Makefile:152: sub-make] Error 2

This patch adds a blank definition of MC_BTB_FLUSH for other cases.

Fixes: 10c5e83afd4a ("powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)")
Cc: Diana Craciun <diana.craciun@...>
Signed-off-by: Christophe Leroy <christophe.leroy@...>
Reviewed-by: Daniel Axtens <dja@...>
Reviewed-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/exceptions-64e.S


[linux:lloyd-aviation] By Michael Ellerman <mpe@...>:
a1df5db3a9f1: powerpc/security: Fix spectre_v2 reporting

commit 92edf8df0ff2ae86cc632eeca0e651fd8431d40d upstream.

When I updated the spectre_v2 reporting to handle software count cache
flush I got the logic wrong when there's no software count cache
enabled at all.

The result is that on systems with the software count cache flush
disabled we print:

Mitigation: Indirect branch cache disabled, Software count cache flush

Which correctly indicates that the count cache is disabled, but
incorrectly says the software count cache flush is enabled.

The root of the problem is that we are trying to handle all
combinations of options. But we know now that we only expect to see
the software count cache flush enabled if the other options are false.

So split the two cases, which simplifies the logic and fixes the bug.
We were also missing a space before "(hardware accelerated)".

The result is we see one of:

Mitigation: Indirect branch serialisation (kernel only)
Mitigation: Indirect branch cache disabled
Mitigation: Software count cache flush
Mitigation: Software count cache flush (hardware accelerated)

Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush")
Cc: stable@... # v4.19+
Signed-off-by: Michael Ellerman <mpe@...>
Reviewed-by: Michael Neuling <mikey@...>
Reviewed-by: Diana Craciun <diana.craciun@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/kernel/security.c


[linux:lloyd-aviation] By Filipe Manana <fdmanana@...>:
22dcb30fb9d8: Btrfs: fix incorrect file size after shrinking truncate and fsync

commit bf504110bc8aa05df48b0e5f0aa84bfb81e0574b upstream.

If we do a shrinking truncate against an inode which is already present
in the respective log tree and then rename it, as part of logging the new
name we end up logging an inode item that reflects the old size of the
file (the one which we previously logged) and not the new smaller size.
The decision to preserve the size previously logged was added by commit
1a4bcf470c886b ("Btrfs: fix fsync data loss after adding hard link to
inode") in order to avoid data loss after replaying the log. However that
decision is only needed for the case the logged inode size is smaller then
the current size of the inode, as explained in that commit's change log.
If the current size of the inode is smaller then the previously logged
size, we know a shrinking truncate happened and therefore need to use
that smaller size.

Example to trigger the problem:

$ mkfs.btrfs -f /dev/sdb
$ mount /dev/sdb /mnt

$ xfs_io -f -c "pwrite -S 0xab 0 8000" /mnt/foo
$ xfs_io -c "fsync" /mnt/foo
$ xfs_io -c "truncate 3000" /mnt/foo

$ mv /mnt/foo /mnt/bar
$ xfs_io -c "fsync" /mnt/bar

<power failure>

$ mount /dev/sdb /mnt
$ od -t x1 -A d /mnt/bar
0000000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
*
0008000

Once we rename the file, we log its name (and inode item), and because
the inode was already logged before in the current transaction, we log it
with a size of 8000 bytes because that is the size we previously logged
(with the first fsync). As part of the rename, besides logging the inode,
we do also sync the log, which is done since commit d4682ba03ef618
("Btrfs: sync log after logging new name"), so the next fsync against our
inode is effectively a no-op, since no new changes happened since the
rename operation. Even if did not sync the log during the rename
operation, the same problem (fize size of 8000 bytes instead of 3000
bytes) would be visible after replaying the log if the log ended up
getting synced to disk through some other means, such as for example by
fsyncing some other modified file. In the example above the fsync after
the rename operation is there just because not every filesystem may
guarantee logging/journalling the inode (and syncing the log/journal)
during the rename operation, for example it is needed for f2fs, but not
for ext4 and xfs.

Fix this scenario by, when logging a new name (which is triggered by
rename and link operations), using the current size of the inode instead
of the previously logged inode size.

A test case for fstests follows soon.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202695
CC: stable@... # 4.4+
Reported-by: Seulbae Kim <seulbae@...>
Signed-off-by: Filipe Manana <fdmanana@...>
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/tree-log.c


[linux:lloyd-aviation] By Josef Bacik <josef@...>:
b57220cc9820: btrfs: remove WARN_ON in log_dir_items

commit 2cc8334270e281815c3850c3adea363c51f21e0d upstream.

When Filipe added the recursive directory logging stuff in
2f2ff0ee5e430 ("Btrfs: fix metadata inconsistencies after directory
fsync") he specifically didn't take the directory i_mutex for the
children directories that we need to log because of lockdep. This is
generally fine, but can lead to this WARN_ON() tripping if we happen to
run delayed deletion's in between our first search and our second search
of dir_item/dir_indexes for this directory. We expect this to happen,
so the WARN_ON() isn't necessary. Drop the WARN_ON() and add a comment
so we know why this case can happen.

CC: stable@... # 4.4+
Reviewed-by: Filipe Manana <fdmanana@...>
Signed-off-by: Josef Bacik <josef@...>
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/tree-log.c


[linux:lloyd-aviation] By David Sterba <dsterba@...>:
d952c337b25d: btrfs: don't report readahead errors and don't update statistics

commit 0cc068e6ee59c1fffbfa977d8bf868b7551d80ac upstream.

As readahead is an optimization, all errors are usually filtered out,
but still properly handled when the real read call is done. The commit
5e9d398240b2 ("btrfs: readpages() should submit IO as read-ahead") added
REQ_RAHEAD to readpages() because that's only used for readahead
(despite what one would expect from the callback name).

This causes a flood of messages and inflated read error stats, so skip
reporting in case it's readahead.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202403
Reported-by: LimeTech <tomm@...>
Fixes: 5e9d398240b2 ("btrfs: readpages() should submit IO as read-ahead")
CC: stable@... # 4.19+
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/volumes.c


[linux:lloyd-aviation] By Andrea Righi <andrea.righi@...>:
1cf4ab01eb5a: btrfs: raid56: properly unmap parity page in finish_parity_scrub()

commit 3897b6f0a859288c22fb793fad11ec2327e60fcd upstream.

Parity page is incorrectly unmapped in finish_parity_scrub(), triggering
a reference counter bug on i386, i.e.:

[ 157.662401] kernel BUG at mm/highmem.c:349!
[ 157.666725] invalid opcode: 0000 [#1] SMP PTI

The reason is that kunmap(p_page) was completely left out, so we never
did an unmap for the p_page and the loop unmapping the rbio page was
iterating over the wrong number of stripes: unmapping should be done
with nr_data instead of rbio->real_stripes.

Test case to reproduce the bug:

- create a raid5 btrfs filesystem:
# mkfs.btrfs -m raid5 -d raid5 /dev/sdb /dev/sdc /dev/sdd /dev/sde

- mount it:
# mount /dev/sdb /mnt

- run btrfs scrub in a loop:
# while :; do btrfs scrub start -BR /mnt; done

BugLink: https://bugs.launchpad.net/bugs/1812845
Fixes: 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56")
CC: stable@... # 4.4+
Reviewed-by: Johannes Thumshirn <jthumshirn@...>
Signed-off-by: Andrea Righi <andrea.righi@...>
Reviewed-by: David Sterba <dsterba@...>
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/raid56.c


[linux:lloyd-aviation] By Nikolay Borisov <nborisov@...>:
0ae3b84b3fa6: btrfs: Avoid possible qgroup_rsv_size overflow in btrfs_calculate_inode_block_rsv_size

commit 139a56170de67101791d6e6c8e940c6328393fe9 upstream.

qgroup_rsv_size is calculated as the product of
outstanding_extent * fs_info->nodesize. The product is calculated with
32 bit precision since both variables are defined as u32. Yet
qgroup_rsv_size expects a 64 bit result.

Avoid possible multiplication overflow by casting outstanding_extent to
u64. Such overflow would in the worst case (64K nodesize) require more
than 65536 extents, which is quite large and i'ts not likely that it
would happen in practice.

Fixes-coverity-id: 1435101
Fixes: ff6bc37eb7f6 ("btrfs: qgroup: Use independent and accurate per inode qgroup rsv")
CC: stable@... # 4.19+
Reviewed-by: Qu Wenruo <wqu@...>
Signed-off-by: Nikolay Borisov <nborisov@...>
Reviewed-by: David Sterba <dsterba@...>
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/extent-tree.c


[linux:lloyd-aviation] By Filipe Manana <fdmanana@...>:
fd1b25364fef: Btrfs: fix assertion failure on fsync with NO_HOLES enabled

commit 0ccc3876e4b2a1559a4dbe3126dda4459d38a83b upstream.

Back in commit a89ca6f24ffe4 ("Btrfs: fix fsync after truncate when
no_holes feature is enabled") I added an assertion that is triggered when
an inline extent is found to assert that the length of the (uncompressed)
data the extent represents is the same as the i_size of the inode, since
that is true most of the time I couldn't find or didn't remembered about
any exception at that time. Later on the assertion was expanded twice to
deal with a case of a compressed inline extent representing a range that
matches the sector size followed by an expanding truncate, and another
case where fallocate can update the i_size of the inode without adding
or updating existing extents (if the fallocate range falls entirely within
the first block of the file). These two expansion/fixes of the assertion
were done by commit 7ed586d0a8241 ("Btrfs: fix assertion on fsync of
regular file when using no-holes feature") and commit 6399fb5a0b69a
("Btrfs: fix assertion failure during fsync in no-holes mode").
These however missed the case where an falloc expands the i_size of an
inode to exactly the sector size and inline extent exists, for example:

$ mkfs.btrfs -f -O no-holes /dev/sdc
$ mount /dev/sdc /mnt

$ xfs_io -f -c "pwrite -S 0xab 0 1096" /mnt/foobar
wrote 1096/1096 bytes at offset 0
1 KiB, 1 ops; 0.0002 sec (4.448 MiB/sec and 4255.3191 ops/sec)

$ xfs_io -c "falloc 1096 3000" /mnt/foobar
$ xfs_io -c "fsync" /mnt/foobar
Segmentation fault

$ dmesg
[701253.602385] assertion failed: len == i_size || (len == fs_info->sectorsize && btrfs_file_extent_compression(leaf, extent) != BTRFS_COMPRESS_NONE) || (len < i_size && i_size < fs_info->sectorsize), file: fs/btrfs/tree-log.c, line: 4727
[701253.602962] ------------[ cut here ]------------
[701253.603224] kernel BUG at fs/btrfs/ctree.h:3533!
[701253.603503] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
[701253.603774] CPU: 2 PID: 7192 Comm: xfs_io Tainted: G W 5.0.0-rc8-btrfs-next-45 #1
[701253.604054] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014
[701253.604650] RIP: 0010:assfail.constprop.23+0x18/0x1a [btrfs]
(...)
[701253.605591] RSP: 0018:ffffbb48c186bc48 EFLAGS: 00010286
[701253.605914] RAX: 00000000000000de RBX: ffff921d0a7afc08 RCX: 0000000000000000
[701253.606244] RDX: 0000000000000000 RSI: ffff921d36b16868 RDI: ffff921d36b16868
[701253.606580] RBP: ffffbb48c186bcf0 R08: 0000000000000000 R09: 0000000000000000
[701253.606913] R10: 0000000000000003 R11: 0000000000000000 R12: ffff921d05d2de18
[701253.607247] R13: ffff921d03b54000 R14: 0000000000000448 R15: ffff921d059ecf80
[701253.607769] FS: 00007f14da906700(0000) GS:ffff921d36b00000(0000) knlGS:0000000000000000
[701253.608163] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[701253.608516] CR2: 000056087ea9f278 CR3: 00000002268e8001 CR4: 00000000003606e0
[701253.608880] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[701253.609250] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[701253.609608] Call Trace:
[701253.609994] btrfs_log_inode+0xdfb/0xe40 [btrfs]
[701253.610383] btrfs_log_inode_parent+0x2be/0xa60 [btrfs]
[701253.610770] ? do_raw_spin_unlock+0x49/0xc0
[701253.611150] btrfs_log_dentry_safe+0x4a/0x70 [btrfs]
[701253.611537] btrfs_sync_file+0x3b2/0x440 [btrfs]
[701253.612010] ? do_sysinfo+0xb0/0xf0
[701253.612552] do_fsync+0x38/0x60
[701253.612988] __x64_sys_fsync+0x10/0x20
[701253.613360] do_syscall_64+0x60/0x1b0
[701253.613733] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[701253.614103] RIP: 0033:0x7f14da4e66d0
(...)
[701253.615250] RSP: 002b:00007fffa670fdb8 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
[701253.615647] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f14da4e66d0
[701253.616047] RDX: 000056087ea9c260 RSI: 000056087ea9c260 RDI: 0000000000000003
[701253.616450] RBP: 0000000000000001 R08: 0000000000000020 R09: 0000000000000010
[701253.616854] R10: 000000000000009b R11: 0000000000000246 R12: 000056087ea9c260
[701253.617257] R13: 000056087ea9c240 R14: 0000000000000000 R15: 000056087ea9dd10
(...)
[701253.619941] ---[ end trace e088d74f132b6da5 ]---

Updating the assertion again to allow for this particular case would result
in a meaningless assertion, plus there is currently no risk of logging
content that would result in any corruption after a log replay if the size
of the data encoded in an inline extent is greater than the inode's i_size
(which is not currently possibe either with or without compression),
therefore just remove the assertion.

CC: stable@... # 4.4+
Signed-off-by: Filipe Manana <fdmanana@...>
Signed-off-by: David Sterba <dsterba@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/btrfs/tree-log.c


[linux:lloyd-aviation] By Kohji Okuno <okuno.kohji@...>:
9397f0d9948c: ARM: imx6q: cpuidle: fix bug that CPU might not wake up at expected time

commit 91740fc8242b4f260cfa4d4536d8551804777fae upstream.

In the current cpuidle implementation for i.MX6q, the CPU that sets
'WAIT_UNCLOCKED' and the CPU that returns to 'WAIT_CLOCKED' are always
the same. While the CPU that sets 'WAIT_UNCLOCKED' is in IDLE state of
"WAIT", if the other CPU wakes up and enters IDLE state of "WFI"
istead of "WAIT", this CPU can not wake up at expired time.
Because, in the case of "WFI", the CPU must be waked up by the local
timer interrupt. But, while 'WAIT_UNCLOCKED' is set, the local timer
is stopped, when all CPUs execute "wfi" instruction. As a result, the
local timer interrupt is not fired.
In this situation, this CPU will wake up by IRQ different from local
timer. (e.g. broacast timer)

So, this fix changes CPU to return to 'WAIT_CLOCKED'.

Signed-off-by: Kohji Okuno <okuno.kohji@...>
Fixes: e5f9dec8ff5f ("ARM: imx6q: support WAIT mode using cpuidle")
Cc: <stable@...>
Signed-off-by: Shawn Guo <shawnguo@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm/mach-imx/cpuidle-imx6q.c


[linux:lloyd-aviation] By Naveen N. Rao <naveen.n.rao@...>:
92d4ee2e8276: powerpc: bpf: Fix generation of load/store DW instructions

commit 86be36f6502c52ddb4b85938145324fd07332da1 upstream.

Yauheni Kaliuta pointed out that PTR_TO_STACK store/load verifier test
was failing on powerpc64 BE, and rightfully indicated that the PPC_LD()
macro is not masking away the last two bits of the offset per the ISA,
resulting in the generation of 'lwa' instruction instead of the intended
'ld' instruction.

Segher also pointed out that we can't simply mask away the last two bits
as that will result in loading/storing from/to a memory location that
was not intended.

This patch addresses this by using ldx/stdx if the offset is not
word-aligned. We load the offset into a temporary register (TMP_REG_2)
and use that as the index register in a subsequent ldx/stdx. We fix
PPC_LD() macro to mask off the last two bits, but enhance PPC_BPF_LL()
and PPC_BPF_STL() to factor in the offset value and generate the proper
instruction sequence. We also convert all existing users of PPC_LD() and
PPC_STD() to use these macros. All existing uses of these macros have
been audited to ensure that TMP_REG_2 can be clobbered.

Fixes: 156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
Cc: stable@... # v4.9+

Reported-by: Yauheni Kaliuta <yauheni.kaliuta@...>
Signed-off-by: Naveen N. Rao <naveen.n.rao@...>
Signed-off-by: Daniel Borkmann <daniel@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/include/asm/ppc-opcode.h
Modified: arch/powerpc/net/bpf_jit.h
Modified: arch/powerpc/net/bpf_jit32.h
Modified: arch/powerpc/net/bpf_jit64.h
Modified: arch/powerpc/net/bpf_jit_comp64.c


[linux:lloyd-aviation] By Cornelia Huck <cohuck@...>:
0f273f0c3064: vfio: ccw: only free cp on final interrupt

commit 50b7f1b7236bab08ebbbecf90521e84b068d7a17 upstream.

When we get an interrupt for a channel program, it is not
necessarily the final interrupt; for example, the issuing
guest may request an intermediate interrupt by specifying
the program-controlled-interrupt flag on a ccw.

We must not switch the state to idle if the interrupt is not
yet final; even more importantly, we must not free the translated
channel program if the interrupt is not yet final, or the host
can crash during cp rewind.

Fixes: e5f84dbaea59 ("vfio: ccw: return I/O results asynchronously")
Cc: stable@... # v4.12+
Reviewed-by: Eric Farman <farman@...>
Signed-off-by: Cornelia Huck <cohuck@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/s390/cio/vfio_ccw_drv.c


[linux:lloyd-aviation] By NeilBrown <neilb@...>:
da57cba4f3f1: NFS: fix mount/umount race in nlmclnt.

commit 4a9be28c45bf02fa0436808bb6c0baeba30e120e upstream.

If the last NFSv3 unmount from a given host races with a mount from the
same host, we can destroy an nlm_host that is still in use.

Specifically nlmclnt_lookup_host() can increment h_count on
an nlm_host that nlmclnt_release_host() has just successfully called
refcount_dec_and_test() on.
Once nlmclnt_lookup_host() drops the mutex, nlm_destroy_host_lock()
will be called to destroy the nlmclnt which is now in use again.

The cause of the problem is that the dec_and_test happens outside the
locked region. This is easily fixed by using
refcount_dec_and_mutex_lock().

Fixes: 8ea6ecc8b075 ("lockd: Create client-side nlm_host cache")
Cc: stable@... (v2.6.38+)
Signed-off-by: NeilBrown <neilb@...>
Signed-off-by: Trond Myklebust <trond.myklebust@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/lockd/host.c


[linux:lloyd-aviation] By Olga Kornievskaia <kolga@...>:
64751542d3f3: NFSv4.1 don't free interrupted slot on open

commit 0cb98abb5bd13b9a636bde603d952d722688b428 upstream.

Allow the async rpc task for finish and update the open state if needed,
then free the slot. Otherwise, the async rpc unable to decode the reply.

Signed-off-by: Olga Kornievskaia <kolga@...>
Fixes: ae55e59da0e4 ("pnfs: Don't release the sequence slot...")
Cc: stable@... # v4.18+
Signed-off-by: Trond Myklebust <trond.myklebust@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/nfs/nfs4proc.c


[linux:lloyd-aviation] By Christian Lamparter <chunkeey@...>:
a485919fe4cc: net: dsa: qca8k: remove leftover phy accessors

commit 1eec7151ae0e134bd42e3f128066b2ff8da21393 upstream.

This belated patch implements Andrew Lunn's request of
"remove the phy_read() and phy_write() functions."
<https://lore.kernel.org/patchwork/comment/902734/>

While seemingly harmless, this causes the switch's user
port PHYs to get registered twice. This is because the
DSA subsystem will create a slave mdio-bus not knowing
that the qca8k_phy_(read|write) accessors operate on
the external mdio-bus. So the same "bus" gets effectively
duplicated.

Cc: stable@...
Fixes: 6b93fb46480a ("net-next: dsa: add new driver for qca8xxx family")
Signed-off-by: Christian Lamparter <chunkeey@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/net/dsa/qca8k.c


[linux:lloyd-aviation] By Gustavo A. R. Silva <gustavo@...>:
bd55e6727a33: ALSA: rawmidi: Fix potential Spectre v1 vulnerability

commit 2b1d9c8f87235f593826b9cf46ec10247741fff9 upstream.

info->stream is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre issue 'rmidi->streams' [r] (local cap)

Fix this by sanitizing info->stream before using it to index
rmidi->streams.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@.../

Cc: stable@...
Signed-off-by: Gustavo A. R. Silva <gustavo@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/core/rawmidi.c


[linux:lloyd-aviation] By Gustavo A. R. Silva <gustavo@...>:
b425f45295dd: ALSA: seq: oss: Fix Spectre v1 vulnerability

commit c709f14f0616482b67f9fbcb965e1493a03ff30b upstream.

dev is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap)

Fix this by sanitizing dev before using it to index dp->synths.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@.../

Cc: stable@...
Signed-off-by: Gustavo A. R. Silva <gustavo@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/core/seq/oss/seq_oss_synth.c


[linux:lloyd-aviation] By Takashi Iwai <tiwai@...>:
7fc6064dc3b2: ALSA: pcm: Fix possible OOB access in PCM oss plugins

commit ca0214ee2802dd47239a4e39fb21c5b00ef61b22 upstream.

The PCM OSS emulation converts and transfers the data on the fly via
"plugins". The data is converted over the dynamically allocated
buffer for each plugin, and recently syzkaller caught OOB in this
flow.

Although the bisection by syzbot pointed out to the commit
65766ee0bf7f ("ALSA: oss: Use kvzalloc() for local buffer
allocations"), this is merely a commit to replace vmalloc() with
kvmalloc(), hence it can't be the cause. The further debug action
revealed that this happens in the case where a slave PCM doesn't
support only the stereo channels while the OSS stream is set up for a
mono channel. Below is a brief explanation:

At each OSS parameter change, the driver sets up the PCM hw_params
again in snd_pcm_oss_change_params_lock(). This is also the place
where plugins are created and local buffers are allocated. The
problem is that the plugins are created before the final hw_params is
determined. Namely, two snd_pcm_hw_param_near() calls for setting the
period size and periods may influence on the final result of channels,
rates, etc, too, while the current code has already created plugins
beforehand with the premature values. So, the plugin believes that
channels=1, while the actual I/O is with channels=2, which makes the
driver reading/writing over the allocated buffer size.

The fix is simply to move the plugin allocation code after the final
hw_params call.

Reported-by: syzbot+d4503ae45b65c5bc1194@...
Cc: <stable@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/core/oss/pcm_oss.c


[linux:lloyd-aviation] By Takashi Iwai <tiwai@...>:
5b93302bbc4e: ALSA: pcm: Don't suspend stream in unrecoverable PCM state

commit 113ce08109f8e3b091399e7cc32486df1cff48e7 upstream.

Currently PCM core sets each opened stream forcibly to SUSPENDED state
via snd_pcm_suspend_all() call, and the user-space is responsible for
re-triggering the resume manually either via snd_pcm_resume() or
prepare call. The scheme works fine usually, but there are corner
cases where the stream can't be resumed by that call: the streams
still in OPEN state before finishing hw_params. When they are
suspended, user-space cannot perform resume or prepare because they
haven't been set up yet. The only possible recovery is to re-open the
device, which isn't nice at all. Similarly, when a stream is in
DISCONNECTED state, it makes no sense to change it to SUSPENDED
state. Ditto for in SETUP state; which you can re-prepare directly.

So, this patch addresses these issues by filtering the PCM streams to
be suspended by checking the PCM state. When a stream is in either
OPEN, SETUP or DISCONNECTED as well as already SUSPENDED, the suspend
action is skipped.

To be noted, this problem was originally reported for the PCM runtime
PM on HD-audio. And, the runtime PM problem itself was already
addressed (although not intended) by the code refactoring commits
3d21ef0b49f8 ("ALSA: pcm: Suspend streams globally via device type PM
ops") and 17bc4815de58 ("ALSA: pci: Remove superfluous
snd_pcm_suspend*() calls"). These commits eliminated the
snd_pcm_suspend*() calls from the runtime PM suspend callback code
path, hence the racy OPEN state won't appear while runtime PM.
(FWIW, the race window is between snd_pcm_open_substream() and the
first power up in azx_pcm_open().)

Although the runtime PM issue was already "fixed", the same problem is
still present for the system PM, hence this patch is still needed.
And for stable trees, this patch alone should suffice for fixing the
runtime PM problem, too.

Reported-and-tested-by: Jon Hunter <jonathanh@...>
Cc: <stable@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/core/pcm_native.c


[linux:lloyd-aviation] By Kailang Yang <kailang@...>:
522f06c9c00d: ALSA: hda/realtek - Add support headset mode for DELL WYSE AIO

commit 136824efaab2c095fc911048f7c7ddeda258c965 upstream.

This patch will enable WYSE AIO for Headset mode.

Signed-off-by: Kailang Yang <kailang@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_realtek.c


[linux:lloyd-aviation] By Kailang Yang <kailang@...>:
89ec6d400b5d: ALSA: hda/realtek - Add support headset mode for New DELL WYSE NB

commit da484d00f020af3dd7cfcc6c4b69a7f856832883 upstream.

Enable headset mode support for new WYSE NB platform.

Signed-off-by: Kailang Yang <kailang@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_realtek.c


[linux:lloyd-aviation] By Jian-Hong Pan <jian-hong@...>:
5ec67684be9e: ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286

commit 667a8f73753908c4d0171e52b71774f9be5d6713 upstream.

Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
record sound from headset MIC. This patch adds the
ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.

Fixes: 9f8aefed9623 ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G")
Fixes: b72f936f6b32 ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G")
Signed-off-by: Jian-Hong Pan <jian-hong@...>
Reviewed-by: Kailang Yang <kailang@...>
Cc: <stable@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_realtek.c


[linux:lloyd-aviation] By Jian-Hong Pan <jian-hong@...>:
5fa5a8679b92: ALSA: hda/realtek: Enable headset MIC of Acer Aspire Z24-890 with ALC286

commit 2733ccebf4a937a0858e7d05a4a003b89715033f upstream.

The Acer Aspire Z24-890 cannot detect the headset MIC until
ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk applied.

Signed-off-by: Jian-Hong Pan <jian-hong@...>
Signed-off-by: Daniel Drake <drake@...>
Cc: <stable@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_realtek.c


[linux:lloyd-aviation] By Chris Chiu <chiu@...>:
48e8e6a736b6: ALSA: hda/realtek - Add support for Acer Aspire E5-523G/ES1-432 headset mic

commit c7531e31c8a440b5fe6bd62664def5bcb6262f96 upstream.

The Acer laptop Aspire E5-523G and ES1-432 with ALC255 can't detect
the headset microphone until ALC255_FIXUP_ACER_MIC_NO_PRESENCE quirk
applied.

Signed-off-by: Chris Chiu <chiu@...>
Signed-off-by: Daniel Drake <drake@...>
Signed-off-by: Jian-Hong Pan <jian-hong@...>
Cc: <stable@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_realtek.c


[linux:lloyd-aviation] By Jian-Hong Pan <jian-hong@...>:
fd4000c77a5a: ALSA: hda/realtek: Enable ASUS X441MB and X705FD headset MIC with ALC256

commit e1037354a0a75acdea2b27043c0a371ed85cf262 upstream.

The ASUS laptop X441MB and X705FD with ALC256 cannot detect the headset
MIC until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.

Signed-off-by: Chris Chiu <chiu@...>
Signed-off-by: Daniel Drake <drake@...>
Signed-off-by: Jian-Hong Pan <jian-hong@...>
Cc: <stable@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_realtek.c


[linux:lloyd-aviation] By Chris Chiu <chiu@...>:
633d5db40280: ALSA: hda/realtek: Enable headset mic of ASUS P5440FF with ALC256

commit a806ef1cf3bbc0baadc6cdeb11f12b5dd27e91c2 upstream.

The ASUS laptop P5440FF with ALC256 can't detect the headset microphone
until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.

Signed-off-by: Chris Chiu <chiu@...>
Signed-off-by: Daniel Drake <drake@...>
Signed-off-by: Jian-Hong Pan <jian-hong@...>
Cc: <stable@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_realtek.c


[linux:lloyd-aviation] By Jian-Hong Pan <jian-hong@...>:
6f3dbb71085c: ALSA: hda/realtek: Enable headset MIC of ASUS X430UN and X512DK with ALC256

commit 6ac371aa1a74240fb910c98aa3484d5ece8473d3 upstream.

The ASUS X430UN and X512DK with ALC256 cannot detect the headset MIC
until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.

Signed-off-by: Jian-Hong Pan <jian-hong@...>
Signed-off-by: Daniel Drake <drake@...>
Cc: <stable@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_realtek.c


[linux:lloyd-aviation] By Bernhard Rosenkraenzer <bero@...>:
4dfae837ceaf: ALSA: hda/realtek - Fix speakers on Acer Predator Helios 500 Ryzen laptops

commit e2a829b3da01b9b32c4d0291d042b8a6e2a98ca3 upstream.

On an Acer Predator Helios 500 (Ryzen version), the laptop's speakers
don't work out of the box.

The problem can be worked around with hdajackretask, remapping the
"Black Headphone, Right side" pin (0x21) to the Internal speaker.

This patch adds a quirk to change this mapping by default.

[ corrected ALC299_FIXUP_PREDATOR_SPK definition and adapted for the
latest tree by tiwai ]

Signed-off-by: Bernhard Rosenkraenzer <bero@...>
Signed-off-by: Takashi Iwai <tiwai@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: sound/pci/hda/patch_realtek.c


[linux:lloyd-aviation] By Fredrik Noring <noring@...>:
aa7f29f87027: kbuild: modversions: Fix relative CRC byte order interpretation

commit 54a7151b1496cddbb7a83546b7998103e98edc88 upstream.

Fix commit 56067812d5b0 ("kbuild: modversions: add infrastructure for
emitting relative CRCs") where CRCs are interpreted in host byte order
rather than proper kernel byte order. The bug is conditional on
CONFIG_MODULE_REL_CRCS.

For example, when loading a BE module into a BE kernel compiled with a LE
system, the error "disagrees about version of symbol module_layout" is
produced. A message such as "Found checksum D7FA6856 vs module 5668FAD7"
will be given with debug enabled, which indicates an obvious endian
problem within __kcrctab within the kernel image.

The general solution is to use the macro TO_NATIVE, as is done in
similar cases throughout modpost.c. With this correction it has been
verified that a BE kernel compiled with a LE system accepts BE modules.

This change has also been verified with a LE kernel compiled with a LE
system, in which case TO_NATIVE returns its value unmodified since the
byte orders match. This is by far the common case.

Fixes: 56067812d5b0 ("kbuild: modversions: add infrastructure for emitting relative CRCs")
Signed-off-by: Fredrik Noring <noring@...>
Cc: stable@...
Signed-off-by: Masahiro Yamada <yamada.masahiro@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: scripts/mod/modpost.c


[linux:lloyd-aviation] By Tetsuo Handa <penguin-kernel@...>:
72b790c417b9: fs/open.c: allow opening only regular files during execve()

commit 73601ea5b7b18eb234219ae2adf77530f389da79 upstream.

syzbot is hitting lockdep warning [1] due to trying to open a fifo
during an execve() operation. But we don't need to open non regular
files during an execve() operation, for all files which we will need are
the executable file itself and the interpreter programs like /bin/sh and
ld-linux.so.2 .

Since the manpage for execve(2) says that execve() returns EACCES when
the file or a script interpreter is not a regular file, and the manpage
for uselib(2) says that uselib() can return EACCES, and we use
FMODE_EXEC when opening for execve()/uselib(), we can bail out if a non
regular file is requested with FMODE_EXEC set.

Since this deadlock followed by khungtaskd warnings is trivially
reproducible by a local unprivileged user, and syzbot's frequent crash
due to this deadlock defers finding other bugs, let's workaround this
deadlock until we get a chance to find a better solution.

[1] https://syzkaller.appspot.com/bug?id=b5095bfec44ec84213bac54742a82483aad578ce

Link: http://lkml.kernel.org/r/1552044017-7890-1-git-send-email-penguin-kernel@...
Reported-by: syzbot <syzbot+e93a80c1bb7c5c56e522461c149f8bf55eab1b2b@...>
Fixes: 8924feff66f35fe2 ("splice: lift pipe_lock out of splice_to_pipe()")
Signed-off-by: Tetsuo Handa <penguin-kernel@...>
Acked-by: Kees Cook <keescook@...>
Cc: Al Viro <viro@...>
Cc: Eric Biggers <ebiggers3@...>
Cc: Dmitry Vyukov <dvyukov@...>
Cc: <stable@...> [4.9+]
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/open.c


[linux:lloyd-aviation] By Darrick J. Wong <darrick.wong@...>:
3b3fcc3d4ffd: ocfs2: fix inode bh swapping mixup in ocfs2_reflink_inodes_lock

commit e6a9467ea14bae8691b0f72c500510c42ea8edb8 upstream.

ocfs2_reflink_inodes_lock() can swap the inode1/inode2 variables so that
we always grab cluster locks in order of increasing inode number.

Unfortunately, we forget to swap the inode record buffer head pointers
when we've done this, which leads to incorrect bookkeepping when we're
trying to make the two inodes have the same refcount tree.

This has the effect of causing filesystem shutdowns if you're trying to
reflink data from inode 100 into inode 97, where inode 100 already has a
refcount tree attached and inode 97 doesn't. The reflink code decides
to copy the refcount tree pointer from 100 to 97, but uses inode 97's
inode record to open the tree root (which it doesn't have) and blows up.
This issue causes filesystem shutdowns and metadata corruption!

Link: http://lkml.kernel.org/r/20190312214910.GK20533@magnolia
Fixes: 29ac8e856cb369 ("ocfs2: implement the VFS clone_range, copy_range, and dedupe_range features")
Signed-off-by: Darrick J. Wong <darrick.wong@...>
Reviewed-by: Joseph Qi <jiangqi903@...>
Cc: Mark Fasheh <mfasheh@...>
Cc: Joel Becker <jlbec@...>
Cc: Junxiao Bi <junxiao.bi@...>
Cc: Joseph Qi <joseph.qi@...>
Cc: <stable@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ocfs2/refcounttree.c


[linux:lloyd-aviation] By Bart Van Assche <bvanassche@...>:
d72658775c4b: scsi: sd: Fix a race between closing an sd device and sd I/O

commit c14a57264399efd39514a2329c591a4b954246d8 upstream.

The scsi_end_request() function calls scsi_cmd_to_driver() indirectly and
hence needs the disk->private_data pointer. Avoid that that pointer is
cleared before all affected I/O requests have finished. This patch avoids
that the following crash occurs:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Call trace:
scsi_mq_uninit_cmd+0x1c/0x30
scsi_end_request+0x7c/0x1b8
scsi_io_completion+0x464/0x668
scsi_finish_command+0xbc/0x160
scsi_eh_flush_done_q+0x10c/0x170
sas_scsi_recover_host+0x84c/0xa98 [libsas]
scsi_error_handler+0x140/0x5b0
kthread+0x100/0x12c
ret_from_fork+0x10/0x18

Cc: Christoph Hellwig <hch@...>
Cc: Ming Lei <ming.lei@...>
Cc: Hannes Reinecke <hare@...>
Cc: Johannes Thumshirn <jthumshirn@...>
Cc: Jason Yan <yanaijie@...>
Cc: <stable@...>
Signed-off-by: Bart Van Assche <bvanassche@...>
Reported-by: Jason Yan <yanaijie@...>
Reviewed-by: Christoph Hellwig <hch@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/scsi/sd.c


[linux:lloyd-aviation] By Martin K. Petersen <martin.petersen@...>:
a52eb223a6ee: scsi: sd: Quiesce warning if device does not report optimal I/O size

commit 1d5de5bd311be7cd54f02f7cd164f0349a75c876 upstream.

Commit a83da8a4509d ("scsi: sd: Optimal I/O size should be a multiple
of physical block size") split one conditional into several separate
statements in an effort to provide more accurate warning messages when
a device reports a nonsensical value. However, this reorganization
accidentally dropped the precondition of the reported value being
larger than zero. This lead to a warning getting emitted on devices
that do not report an optimal I/O size at all.

Remain silent if a device does not report an optimal I/O size.

Fixes: a83da8a4509d ("scsi: sd: Optimal I/O size should be a multiple of physical block size")
Cc: Randy Dunlap <rdunlap@...>
Cc: <stable@...>
Reported-by: Hussam Al-Tayeb <ht990332@...>
Tested-by: Hussam Al-Tayeb <ht990332@...>
Reviewed-by: Bart Van Assche <bvanassche@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/scsi/sd.c


[linux:lloyd-aviation] By Steffen Maier <maier@...>:
983a543de13a: scsi: zfcp: fix rport unblock if deleted SCSI devices on Scsi_Host

commit fe67888fc007a76b81e37da23ce5bd8fb95890b0 upstream.

An already deleted SCSI device can exist on the Scsi_Host and remain there
because something still holds a reference. A new SCSI device with the same
H:C:T:L and FCP device, target port WWPN, and FCP LUN can be created. When
we try to unblock an rport, we still find the deleted SCSI device and
return early because the zfcp_scsi_dev of that SCSI device is not
ZFCP_STATUS_COMMON_UNBLOCKED. Hence we miss to unblock the rport, even if
the new proper SCSI device would be in good state.

Therefore, skip deleted SCSI devices when iterating the sdevs of the shost.
[cf. __scsi_device_lookup{_by_target}() or scsi_device_get()]

The following abbreviated trace sequence can indicate such problem:

Area : REC
Tag : ersfs_3
LUN : 0x4045400300000000
WWPN : 0x50050763031bd327
LUN status : 0x40000000 not ZFCP_STATUS_COMMON_UNBLOCKED
Ready count : n not incremented yet
Running count : 0x00000000
ERP want : 0x01
ERP need : 0xc1 ZFCP_ERP_ACTION_NONE

Area : REC
Tag : ersfs_3
LUN : 0x4045400300000000
WWPN : 0x50050763031bd327
LUN status : 0x41000000
Ready count : n+1
Running count : 0x00000000
ERP want : 0x01
ERP need : 0x01

...

Area : REC
Level : 4 only with increased trace level
Tag : ertru_l
LUN : 0x4045400300000000
WWPN : 0x50050763031bd327
LUN status : 0x40000000
Request ID : 0x0000000000000000
ERP status : 0x01800000
ERP step : 0x1000
ERP action : 0x01
ERP count : 0x00

NOT followed by a trace record with tag "scpaddy"
for WWPN 0x50050763031bd327.

Signed-off-by: Steffen Maier <maier@...>
Fixes: 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
Cc: <stable@...> #2.6.32+
Reviewed-by: Jens Remus <jremus@...>
Reviewed-by: Benjamin Block <bblock@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/s390/scsi/zfcp_erp.c


[linux:lloyd-aviation] By Steffen Maier <maier@...>:
a93cd9137fea: scsi: zfcp: fix scsi_eh host reset with port_forced ERP for non-NPIV FCP devices

commit 242ec1455151267fe35a0834aa9038e4c4670884 upstream.

Suppose more than one non-NPIV FCP device is active on the same channel.
Send I/O to storage and have some of the pending I/O run into a SCSI
command timeout, e.g. due to bit errors on the fibre. Now the error
situation stops. However, we saw FCP requests continue to timeout in the
channel. The abort will be successful, but the subsequent TUR fails.
Scsi_eh starts. The LUN reset fails. The target reset fails. The host
reset only did an FCP device recovery. However, for non-NPIV FCP devices,
this does not close and reopen ports on the SAN-side if other non-NPIV FCP
device(s) share the same open ports.

In order to resolve the continuing FCP request timeouts, we need to
explicitly close and reopen ports on the SAN-side.

This was missing since the beginning of zfcp in v2.6.0 history commit
ea127f975424 ("[PATCH] s390 (7/7): zfcp host adapter.").

Note: The FSF requests for forced port reopen could run into FSF request
timeouts due to other reasons. This would trigger an internal FCP device
recovery. Pending forced port reopen recoveries would get dismissed. So
some ports might not get fully reopened during this host reset handler.
However, subsequent I/O would trigger the above described escalation and
eventually all ports would be forced reopen to resolve any continuing FCP
request timeouts due to earlier bit errors.

Signed-off-by: Steffen Maier <maier@...>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: <stable@...> #3.0+
Reviewed-by: Jens Remus <jremus@...>
Reviewed-by: Benjamin Block <bblock@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/s390/scsi/zfcp_erp.c
Modified: drivers/s390/scsi/zfcp_ext.h
Modified: drivers/s390/scsi/zfcp_scsi.c


[linux:lloyd-aviation] By Jonas Karlman <jonas@...>:
7fb7414da97e: drm/rockchip: vop: reset scale mode when win is disabled

commit e9abc611a941d4051cde1d94b2ab7473fdb50102 upstream.

NV12 framebuffers produced by the VPU shows distorted on RK3288
after win has been disabled when scaling is active.

This issue can be reproduced using a 1080p modeset by:
- Scale a 1280x720 NV12 framebuffer to 1920x1080 on win0
- Disable win0
- Display a 1920x1080 NV12 framebuffer without scaling on win0
- Output will now show the framebuffer distorted

And by:
- Scale a 1280x720 NV12 framebuffer to 1920x1080
- Change to a 720p modeset (win gets disabled and scaling reset to none)
- Output will now show the framebuffer distorted

Fix this by setting scale mode to none when win is disabled.

Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale")
Cc: stable@...
Signed-off-by: Jonas Karlman <jonas@...>
Signed-off-by: Heiko Stuebner <heiko@...>
Link: https://patchwork.freedesktop.org/patch/msgid/AM3PR03MB0966DE3E19BACE07328CD637AC7D0@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/rockchip/rockchip_drm_vop.c


[linux:lloyd-aviation] By Kangjie Lu <kjlu@...>:
124e42064c0d: tty: mxs-auart: fix a potential NULL pointer dereference

commit 6734330654dac550f12e932996b868c6d0dcb421 upstream.

In case ioremap fails, the fix returns -ENOMEM to avoid NULL
pointer dereferences.
Multiple places use port.membase.

Signed-off-by: Kangjie Lu <kjlu@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/mxs-auart.c


[linux:lloyd-aviation] By Kangjie Lu <kjlu@...>:
b9bbd1edddf7: tty: atmel_serial: fix a potential NULL pointer dereference

commit c85be041065c0be8bc48eda4c45e0319caf1d0e5 upstream.

In case dmaengine_prep_dma_cyclic fails, the fix returns a proper
error code to avoid NULL pointer dereference.

Signed-off-by: Kangjie Lu <kjlu@...>
Fixes: 34df42f59a60 ("serial: at91: add rx dma support")
Acked-by: Richard Genoud <richard.genoud@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/atmel_serial.c


[linux:lloyd-aviation] By Nathan Chancellor <natechancellor@...>:
668ba38d8950: tty: serial: qcom_geni_serial: Initialize baud in qcom_geni_console_setup

commit c5cbc78acf693f5605d4a85b1327fa7933daf092 upstream.

When building with -Wsometimes-uninitialized, Clang warns:

drivers/tty/serial/qcom_geni_serial.c:1079:6: warning: variable 'baud'
is used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]

It's not wrong; when options is NULL, baud has no default value. Use
9600 as that is a sane default.

Link: https://github.com/ClangBuiltLinux/linux/issues/395
Suggested-by: Greg Kroah-Hartman <gregkh@...>
Signed-off-by: Nathan Chancellor <natechancellor@...>
Reviewed-by: Nick Desaulniers <ndesaulniers@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/qcom_geni_serial.c


[linux:lloyd-aviation] By Ian Abbott <abbotti@...>:
d0360bf48143: staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest

commit bafd9c64056cd034a1174dcadb65cd3b294ff8f6 upstream.

`ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO
subdevice (subdevice 2) of supported National Instruments M-series
cards. It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST`
ioctls for this subdevice. There are two causes for a possible
divide-by-zero error when validating that the `stop_arg` member of the
passed-in command is not too large.

The first cause for the divide-by-zero is that calls to
`comedi_bytes_per_scan()` are only valid once the command has been
copied to `s->async->cmd`, but that copy is only done for the
`COMEDI_CMD` ioctl. For the `COMEDI_CMDTEST` ioctl, it will use
whatever was left there by the previous `COMEDI_CMD` ioctl, if any.
(This is very likely, as it is usual for the application to use
`COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous,
valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()`
will return 0, so the subsequent division in `ni_cdio_cmdtest()` of
`s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a
divide-by-zero error. To fix this error, call a new function
`comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing
`comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for
its calculations. (Also refactor `comedi_bytes_per_scan()` to call the
new function.)

Once the first cause for the divide-by-zero has been fixed, the second
cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if
the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0.
Fix it by only performing the division (and validating that `stop_arg`
is no more than the maximum value) if `comedi_bytes_per_scan_cmd()`
returns a non-zero value.

The problem was reported on the COMEDI mailing list here:
https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKM

Reported-by: Ivan Vasilyev <grabesstimme@...>
Tested-by: Ivan Vasilyev <grabesstimme@...>
Fixes: f164cbf98fa8 ("staging: comedi: ni_mio_common: add finite regeneration to dio output")
Cc: <stable@...> # 4.6+
Cc: Spencer E. Olson <olsonse@...>
Signed-off-by: Ian Abbott <abbotti@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/comedi/comedidev.h
Modified: drivers/staging/comedi/drivers.c
Modified: drivers/staging/comedi/drivers/ni_mio_common.c


[linux:lloyd-aviation] By Samuel Thibault <samuel.thibault@...>:
86092f2d5ccb: staging: speakup_soft: Fix alternate speech with other synths

commit 45ac7b31bc6c4af885cc5b5d6c534c15bcbe7643 upstream.

When switching from speakup_soft to another synth, speakup_soft would
keep calling synth_buffer_getc() from softsynthx_read.

Let's thus make synth.c export the knowledge of the current synth, so
that speakup_soft can determine whether it should be running.

speakup_soft also needs to set itself alive, otherwise the switch would
let it remain silent.

Signed-off-by: Samuel Thibault <samuel.thibault@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/speakup/speakup_soft.c
Modified: drivers/staging/speakup/spk_priv.h
Modified: drivers/staging/speakup/synth.c


[linux:lloyd-aviation] By Malcolm Priestley <tvboxspy@...>:
b9ddff2a41cd: staging: vt6655: Remove vif check from vnt_interrupt

commit cc26358f89c3e493b54766b1ca56cfc6b14db78a upstream.

A check for vif is made in vnt_interrupt_work.

There is a small chance of leaving interrupt disabled while vif
is NULL and the work hasn't been scheduled.

Signed-off-by: Malcolm Priestley <tvboxspy@...>
CC: stable@... # v4.2+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/vt6655/device_main.c


[linux:lloyd-aviation] By Malcolm Priestley <tvboxspy@...>:
3b6b76644ba5: staging: vt6655: Fix interrupt race condition on device start up.

commit 3b9c2f2e0e99bb67c96abcb659b3465efe3bee1f upstream.

It appears on some slower systems that the driver can find its way
out of the workqueue while the interrupt is disabled by continuous polling
by it.

Move MACvIntEnable to vnt_interrupt_work so that it is always enabled
on all routes out of vnt_interrupt_process.

Move MACvIntDisable so that the device doesn't keep polling the system
while the workqueue is being processed.

Signed-off-by: Malcolm Priestley <tvboxspy@...>
CC: stable@... # v4.2+
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/vt6655/device_main.c


[linux:lloyd-aviation] By Chao Yu <yuchao0@...>:
a090ed15420a: staging: erofs: fix to handle error path of erofs_vmap()

commit 8bce6dcede65139a087ff240127e3f3c01363eed upstream.

erofs_vmap() wrapped vmap() and vm_map_ram() to return virtual
continuous memory, but both of them can failed due to a lot of
reason, previously, erofs_vmap()'s callers didn't handle them,
which can potentially cause NULL pointer access, fix it.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Fixes: 0d40d6e399c1 ("staging: erofs: add a generic z_erofs VLE decompressor")
Cc: <stable@...> # 4.19+
Signed-off-by: Gao Xiang <gaoxiang25@...>
Signed-off-by: Chao Yu <yuchao0@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/erofs/unzip_vle.c
Modified: drivers/staging/erofs/unzip_vle_lz4.c


[linux:lloyd-aviation] By Aditya Pakki <pakki001@...>:
f34ec64b3f6c: serial: max310x: Fix to avoid potential NULL pointer dereference

commit 3a10e3dd52e80b9a97a3346020024d17b2c272d6 upstream.

of_match_device can return a NULL pointer when matching device is not
found. This patch avoids a scenario causing NULL pointer derefernce.

Signed-off-by: Aditya Pakki <pakki001@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/max310x.c


[linux:lloyd-aviation] By Aditya Pakki <pakki001@...>:
b1e660c6f802: serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference

commit 32f47179833b63de72427131169809065db6745e upstream.

of_match_device on failure to find a matching device can return a NULL
pointer. The patch checks for such a scenrio and passes the error upstream.

Signed-off-by: Aditya Pakki <pakki001@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/mvebu-uart.c


[linux:lloyd-aviation] By Hoan Nguyen An <na-hoan@...>:
59203f078cc6: serial: sh-sci: Fix setting SCSCR_TIE while transferring data

commit 93bcefd4c6bad4c69dbc4edcd3fbf774b24d930d upstream.

We disable transmission interrupt (clear SCSCR_TIE) after all data has been transmitted
(if uart_circ_empty(xmit)). While transmitting, if the data is still in the tty buffer,
re-enable the SCSCR_TIE bit, which was done at sci_start_tx().
This is unnecessary processing, wasting CPU operation if the data transmission length is large.
And further, transmit end, FIFO empty bits disabling have also been performed in the step above.

Signed-off-by: Hoan Nguyen An <na-hoan@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/sh-sci.c


[linux:lloyd-aviation] By Greg Kroah-Hartman <gregkh@...>:
2a63003545d0: USB: serial: cp210x: add new device id

commit a595ecdd5f60b2d93863cebb07eec7f935839b54 upstream.

Lorenz Messtechnik has a device that is controlled by the cp210x driver,
so add the device id to the driver. The device id was provided by
Silicon-Labs for the devices from this vendor.

Reported-by: Uli <t9cpu@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
Cc: stable <stable@...>
Signed-off-by: Johan Hovold <johan@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/serial/cp210x.c


[linux:lloyd-aviation] By George McCollister <george.mccollister@...>:
1f46db3cc133: USB: serial: ftdi_sio: add additional NovaTech products

commit 422c2537ba9d42320f8ab6573940269f87095320 upstream.

Add PIDs for the NovaTech OrionLX+ and Orion I/O so they can be
automatically detected.

Signed-off-by: George McCollister <george.mccollister@...>
Cc: stable <stable@...>
Signed-off-by: Johan Hovold <johan@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/serial/ftdi_sio.c
Modified: drivers/usb/serial/ftdi_sio_ids.h


[linux:lloyd-aviation] By Lin Yi <teroincn@...>:
d7dfccfd3c4b: USB: serial: mos7720: fix mos_parport refcount imbalance on error path

commit 2908b076f5198d231de62713cb2b633a3a4b95ac upstream.

The write_parport_reg_nonblock() helper takes a reference to the struct
mos_parport, but failed to release it in a couple of error paths after
allocation failures, leading to a memory leak.

Johan said that move the kref_get() and mos_parport assignment to the
end of urbtrack initialisation is a better way, so move it. and
mos_parport do not used until urbtrack initialisation.

Signed-off-by: Lin Yi <teroincn@...>
Fixes: b69578df7e98 ("USB: usbserial: mos7720: add support for parallel port on moschip 7715")
Cc: stable <stable@...> # 2.6.35
Signed-off-by: Johan Hovold <johan@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/serial/mos7720.c


[linux:lloyd-aviation] By Mans Rullgard <mans@...>:
002795b0d9b3: USB: serial: option: set driver_info for SIM5218 and compatibles

commit f8df5c2c3e2df5ffaf9fb5503da93d477a8c7db4 upstream.

The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4
of which are serial ports. The fifth is a network interface supported
by the qmi-wwan driver. Furthermore, the serial ports do not support
modem control signals. Add driver_info flags to reflect this.

Signed-off-by: Mans Rullgard <mans@...>
Fixes: ec0cd94d881c ("usb: option: add SIMCom SIM5218")
Cc: stable <stable@...> # 3.2
Signed-off-by: Johan Hovold <johan@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/serial/option.c


[linux:lloyd-aviation] By Kristian Evensen <kristian.evensen@...>:
19151c645d0c: USB: serial: option: add support for Quectel EM12

commit d1252f0237238b912c3e7a51bf237acf34c97983 upstream.

The Quectel EM12 is a Cat. 12 LTE modem. It behaves in the exactly the
same way as the EP06 (including the dynamic configuration behavior), so
the same checks on reserved interfaces, etc. are needed.

Signed-off-by: Kristian Evensen <kristian.evensen@...>
Cc: stable <stable@...>
Signed-off-by: Johan Hovold <johan@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/serial/option.c


[linux:lloyd-aviation] By Bjørn Mork <bjorn@...>:
1c992ea006ce: USB: serial: option: add Olicard 600

commit 84f3b43f7378b98b7e3096d5499de75183d4347c upstream.

This is a Qualcomm based device with a QMI function on interface 4.
It is mode switched from 2020:2030 using a standard eject message.

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=2020 ProdID=2031 Rev= 2.32
S: Manufacturer=Mobile Connect
S: Product=Mobile Connect
S: SerialNumber=0123456789ABCDEF
C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

Cc: stable@...
Signed-off-by: Bjørn Mork <bjorn@...>
[ johan: use tabs to align comments in adjacent lines ]
Signed-off-by: Johan Hovold <johan@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/serial/option.c


[linux:lloyd-aviation] By Wentao Wang <witallwang@...>:
c956914f1efa: Disable kgdboc failed by echo space to /sys/module/kgdboc/parameters/kgdboc

commit 3ec8002951ea173e24b466df1ea98c56b7920e63 upstream.

Echo "" to /sys/module/kgdboc/parameters/kgdboc will fail with "No such
device” error.

This is caused by function "configure_kgdboc" who init err to ENODEV
when the config is empty (legal input) the code go out with ENODEV
returned.

Fixes: 2dd453168643 ("kgdboc: Fix restrict error")
Signed-off-by: Wentao Wang <witallwang@...>
Cc: stable <stable@...>
Acked-by: Daniel Thompson <daniel.thompson@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/kgdboc.c


[linux:lloyd-aviation] By YueHaibing <yuehaibing@...>:
07d0d2bd957a: fs/proc/proc_sysctl.c: fix NULL pointer dereference in put_links

commit 23da9588037ecdd4901db76a5b79a42b529c4ec3 upstream.

Syzkaller reports:

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN PTI
CPU: 1 PID: 5373 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
RIP: 0010:put_links+0x101/0x440 fs/proc/proc_sysctl.c:1599
Code: 00 0f 85 3a 03 00 00 48 8b 43 38 48 89 44 24 20 48 83 c0 38 48 89 c2 48 89 44 24 28 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 fe 02 00 00 48 8b 74 24 20 48 c7 c7 60 2a 9d 91
RSP: 0018:ffff8881d828f238 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8881e01b1140 RCX: ffffffff8ee98267
RDX: 0000000000000007 RSI: ffffc90001479000 RDI: ffff8881e01b1178
RBP: dffffc0000000000 R08: ffffed103ee27259 R09: ffffed103ee27259
R10: 0000000000000001 R11: ffffed103ee27258 R12: fffffffffffffff4
R13: 0000000000000006 R14: ffff8881f59838c0 R15: dffffc0000000000
FS: 00007f072254f700(0000) GS:ffff8881f7100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff8b286668 CR3: 00000001f0542002 CR4: 00000000007606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
drop_sysctl_table+0x152/0x9f0 fs/proc/proc_sysctl.c:1629
get_subdir fs/proc/proc_sysctl.c:1022 [inline]
__register_sysctl_table+0xd65/0x1090 fs/proc/proc_sysctl.c:1335
br_netfilter_init+0xbc/0x1000 [br_netfilter]
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f072254ec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003
RBP: 00007f072254ec70 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f072254f6bc
R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
Modules linked in: br_netfilter(+) dvb_usb_dibusb_mc_common dib3000mc dibx000_common dvb_usb_dibusb_common dvb_usb_dw2102 dvb_usb classmate_laptop palmas_regulator cn videobuf2_v4l2 v4l2_common snd_soc_bd28623 mptbase snd_usb_usx2y snd_usbmidi_lib snd_rawmidi wmi libnvdimm lockd sunrpc grace rc_kworld_pc150u rc_core rtc_da9063 sha1_ssse3 i2c_cros_ec_tunnel adxl34x_spi adxl34x nfnetlink lib80211 i5500_temp dvb_as102 dvb_core videobuf2_common videodev media videobuf2_vmalloc videobuf2_memops udc_core lnbp22 leds_lp3952 hid_roccat_ryos s1d13xxxfb mtd vport_geneve openvswitch nf_conncount nf_nat_ipv6 nsh geneve udp_tunnel ip6_udp_tunnel snd_soc_mt6351 sis_agp phylink snd_soc_adau1761_spi snd_soc_adau1761 snd_soc_adau17x1 snd_soc_core snd_pcm_dmaengine ac97_bus snd_compress snd_soc_adau_utils snd_soc_sigmadsp_regmap snd_soc_sigmadsp raid_class hid_roccat_konepure hid_roccat_common hid_roccat c2port_duramar2150 core mdio_bcm_unimac iptable_security iptable_raw iptable_mangle
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim devlink vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel joydev mousedev ide_pci_generic piix aesni_intel aes_x86_64 ide_core crypto_simd atkbd cryptd glue_helper serio_raw ata_generic pata_acpi i2c_piix4 floppy sch_fq_codel ip_tables x_tables ipv6 [last unloaded: lm73]
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 770020de38961fd0 ]---

A new dir entry can be created in get_subdir and its 'header->parent' is
set to NULL. Only after insert_header success, it will be set to 'dir',
otherwise 'header->parent' is set to NULL and drop_sysctl_table is called.
However in err handling path of get_subdir, drop_sysctl_table also be
called on 'new->header' regardless its value of parent pointer. Then
put_links is called, which triggers NULL-ptr deref when access member of
header->parent.

In fact we have multiple error paths which call drop_sysctl_table() there,
upon failure on insert_links() we also call drop_sysctl_table().And even
in the successful case on __register_sysctl_table() we still always call
drop_sysctl_table().This patch fix it.

Link: http://lkml.kernel.org/r/20190314085527.13244-1-yuehaibing@...
Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between sysctl_table_sets")
Signed-off-by: YueHaibing <yuehaibing@...>
Reported-by: Hulk Robot <hulkci@...>
Acked-by: Luis Chamberlain <mcgrof@...>
Cc: Kees Cook <keescook@...>
Cc: Alexey Dobriyan <adobriyan@...>
Cc: Alexei Starovoitov <ast@...>
Cc: Daniel Borkmann <daniel@...>
Cc: Al Viro <viro@...>
Cc: Eric W. Biederman <ebiederm@...>
Cc: <stable@...> [3.4+]
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/proc/proc_sysctl.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
eb1e552524b4: drm/vgem: fix use-after-free when drm_gem_handle_create() fails

commit 21d2b122732318b48c10b7262e15595ce54511d3 upstream.

If drm_gem_handle_create() fails in vgem_gem_create(), then the
drm_vgem_gem_object is freed twice: once when the reference is dropped
by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().

This was hit by syzkaller using fault injection.

Fix it by skipping the second free.

Reported-by: syzbot+e73f2fb5ed5a5df36d33@...
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Reviewed-by: Chris Wilson <chris@...>
Cc: Laura Abbott <labbott@...>
Cc: Daniel Vetter <daniel.vetter@...>
Cc: stable@...
Signed-off-by: Eric Biggers <ebiggers@...>
Acked-by: Laura Abbott <labbott@...>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@...>
Link: https://patchwork.freedesktop.org/patch/msgid/20190226214451.195123-1-ebiggers@...
Signed-off-by: Maxime Ripard <maxime.ripard@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/vgem/vgem_drv.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
75f9e994b9fd: drm/vkms: fix use-after-free when drm_gem_handle_create() fails

commit 36b6c9ed45afe89045973e8dee1b004dd5372d40 upstream.

If drm_gem_handle_create() fails in vkms_gem_create(), then the
vkms_gem_object is freed twice: once when the reference is dropped by
drm_gem_object_put_unlocked(), and again by the extra calls to
drm_gem_object_release() and kfree().

Fix it by skipping the second release and free.

This bug was originally found in the vgem driver by syzkaller using
fault injection, but I noticed it's also present in the vkms driver.

Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@...>
Cc: Haneen Mohammed <hamohammed.sa@...>
Cc: Daniel Vetter <daniel.vetter@...>
Cc: Chris Wilson <chris@...>
Cc: stable@...
Signed-off-by: Eric Biggers <ebiggers@...>
Reviewed-by: Chris Wilson <chris@...>
Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@...>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@...>
Link: https://patchwork.freedesktop.org/patch/msgid/20190226220858.214438-1-ebiggers@...
Signed-off-by: Maxime Ripard <maxime.ripard@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/vkms/vkms_gem.c


[linux:lloyd-aviation] By Zhenyu Wang <zhenyuw@...>:
df74e70ffec6: drm/i915/gvt: Fix MI_FLUSH_DW parsing with correct index check

commit 13bcb80b7ee79431fce361e060611134cb19e209 upstream.

When MI_FLUSH_DW post write hw status page in index mode, the index
value is in dword step and turned into address offset in cmd dword1.
As status page size is 4K, so can't exceed that.

This fixed upper bound check in cmd parser code which incorrectly
stopped VM for reason of invalid MI_FLUSH_DW write index.

v2:
- Fix upper bound as 4K page size because index value is address offset.

Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner")
Cc: stable@... # v4.10+
Cc: "Zhao, Yan Y" <yan.y.zhao@...>
Reviewed-by: Yan Zhao <yan.y.zhao@...>
Signed-off-by: Zhenyu Wang <zhenyuw@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpu/drm/i915/gvt/cmd_parser.c


[linux:lloyd-aviation] By Kangjie Lu <kjlu@...>:
b26f7e86d3cc: gpio: exar: add a check for the return value of ida_simple_get fails

commit 7ecced0934e574b528a1ba6c237731e682216a74 upstream.

ida_simple_get may fail and return a negative error number.
The fix checks its return value; if it fails, go to err_destroy.

Cc: <stable@...>
Signed-off-by: Kangjie Lu <kjlu@...>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpio/gpio-exar.c


[linux:lloyd-aviation] By Axel Lin <axel.lin@...>:
6ebe03734361: gpio: adnp: Fix testing wrong value in adnp_gpio_direction_input

commit c5bc6e526d3f217ed2cc3681d256dc4a2af4cc2b upstream.

Current code test wrong value so it does not verify if the written
data is correctly read back. Fix it.
Also make it return -EPERM if read value does not match written bit,
just like it done for adnp_gpio_direction_output().

Fixes: 5e969a401a01 ("gpio: Add Avionic Design N-bit GPIO expander support")
Cc: <stable@...>
Signed-off-by: Axel Lin <axel.lin@...>
Reviewed-by: Thierry Reding <thierry.reding@...>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/gpio/gpio-adnp.c


[linux:lloyd-aviation] By Chen-Yu Tsai <wens@...>:
66e44981de0e: phy: sun4i-usb: Support set_mode to USB_HOST for non-OTG PHYs

commit 1396929e8a903db80425343cacca766a18ad6409 upstream.

While only the first PHY supports mode switching, the remaining PHYs
work in USB host mode. They should support set_mode with mode=USB_HOST
instead of failing. This is especially needed now that the USB core does
set_mode for all USB ports, which was added in commit b97a31348379 ("usb:
core: comply to PHY framework").

Make set_mode with mode=USB_HOST a no-op instead of failing for the
non-OTG USB PHYs.

Fixes: 6ba43c291961 ("phy-sun4i-usb: Add support for phy_set_mode")
Signed-off-by: Chen-Yu Tsai <wens@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/phy/allwinner/phy-sun4i-usb.c


[linux:lloyd-aviation] By Arnd Bergmann <arnd@...>:
614ac345bfec: usb: mtu3: fix EXTCON dependency

commit 3d54d10c6afed34fd45b852bf76f55e8da31d8ef upstream.

When EXTCON is a loadable module, mtu3 fails to link as built-in:

drivers/usb/mtu3/mtu3_plat.o: In function `mtu3_probe':
mtu3_plat.c:(.text+0x690): undefined reference to `extcon_get_edev_by_phandle'

Add a Kconfig dependency to force mtu3 also to be a loadable module
if extconn is, but still allow it to be built without extcon.

Fixes: d0ed062a8b75 ("usb: mtu3: dual-role mode support")
Signed-off-by: Arnd Bergmann <arnd@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/mtu3/Kconfig


[linux:lloyd-aviation] By Radoslav Gerganov <rgerganov@...>:
ef4df134e77e: USB: gadget: f_hid: fix deadlock in f_hidg_write()

commit 072684e8c58d17e853f8e8b9f6d9ce2e58d2b036 upstream.

In f_hidg_write() the write_spinlock is acquired before calling
usb_ep_queue() which causes a deadlock when dummy_hcd is being used.
This is because dummy_queue() callbacks into f_hidg_req_complete() which
tries to acquire the same spinlock. This is (part of) the backtrace when
the deadlock occurs:

0xffffffffc06b1410 in f_hidg_req_complete
0xffffffffc06a590a in usb_gadget_giveback_request
0xffffffffc06cfff2 in dummy_queue
0xffffffffc06a4b96 in usb_ep_queue
0xffffffffc06b1eb6 in f_hidg_write
0xffffffff8127730b in __vfs_write
0xffffffff812774d1 in vfs_write
0xffffffff81277725 in SYSC_write

Fix this by releasing the write_spinlock before calling usb_ep_queue()

Reviewed-by: James Bottomley <James.Bottomley@...>
Tested-by: James Bottomley <James.Bottomley@...>
Cc: stable@... # 4.11+
Fixes: 749494b6bdbb ("usb: gadget: f_hid: fix: Move IN request allocation to set_alt()")
Signed-off-by: Radoslav Gerganov <rgerganov@...>
Signed-off-by: Felipe Balbi <felipe.balbi@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/gadget/function/f_hid.c


[linux:lloyd-aviation] By Fabrizio Castro <fabrizio.castro@...>:
015e5c17617a: usb: common: Consider only available nodes for dr_mode

commit 238e0268c82789e4c107a37045d529a6dbce51a9 upstream.

There are cases where multiple device tree nodes point to the
same phy node by means of the "phys" property, but we should
only consider those nodes that are marked as available rather
than just any node.

Fixes: 98bfb3946695 ("usb: of: add an api to get dr_mode by the phy node")
Cc: stable@... # v4.4+
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/common/common.c


[linux:lloyd-aviation] By Yasushi Asano <yasano@...>:
093ccda1a041: usb: host: xhci-rcar: Add XHCI_TRUST_TX_LENGTH quirk

commit 40fc165304f0faaae78b761f8ee30b5d216b1850 upstream.

When plugging BUFFALO LUA4-U3-AGT USB3.0 to Gigabit Ethernet LAN
Adapter, warning messages filled up dmesg.

[ 101.098287] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
[ 101.117463] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
[ 101.136513] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?

Adding the XHCI_TRUST_TX_LENGTH quirk resolves the issue.

Signed-off-by: Yasushi Asano <yasano@...>
Signed-off-by: Spyridon Papageorgiou <spapageorgiou@...>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/host/xhci-rcar.c


[linux:lloyd-aviation] By Mathias Nyman <mathias.nyman@...>:
c81b872281a1: xhci: Fix port resume done detection for SS ports with LPM enabled

commit 6cbcf596934c8e16d6288c7cc62dfb7ad8eadf15 upstream.

A suspended SS port in U3 link state will go to U0 when resumed, but
can almost immediately after that enter U1 or U2 link power save
states before host controller driver reads the port status.

Host controller driver only checks for U0 state, and might miss
the finished resume, leaving flags unclear and skip notifying usb
code of the wake.

Add U1 and U2 to the possible link states when checking for finished
port resume.

Cc: stable <stable@...>
Signed-off-by: Mathias Nyman <mathias.nyman@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/host/xhci-ring.c


[linux:lloyd-aviation] By Mathias Nyman <mathias.nyman@...>:
20a09a2e8703: usb: xhci: dbc: Don't free all memory with spinlock held

commit 8867ea262196a6945c24a0fb739575af646ec0e9 upstream.

The xhci debug capability (DbC) feature did its memory cleanup with
spinlock held. dma_free_coherent() warns if called with interrupts
disabled

move the memory cleanup outside the spinlock

Cc: stable <stable@...>
Signed-off-by: Mathias Nyman <mathias.nyman@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/host/xhci-dbgcap.c


[linux:lloyd-aviation] By Mathias Nyman <mathias.nyman@...>:
82a5090aad84: xhci: Don't let USB3 ports stuck in polling state prevent suspend

commit d92f2c59cc2cbca6bfb2cc54882b58ba76b15fd4 upstream.

Commit 2f31a67f01a8 ("usb: xhci: Prevent bus suspend if a port connect
change or polling state is detected") was intended to prevent ports that
were still link training from being forced to U3 suspend state mid
enumeration.
This solved enumeration issues for devices with slow link training.

Turns out some devices are stuck in the link training/polling state,
and thus that patch will prevent suspend completely for these devices.
This is seen with USB3 card readers in some MacBooks.

Instead of preventing suspend, give some time to complete the link
training. On successful training the port will end up as connected
and enabled.
If port instead is stuck in link training the bus suspend will continue
suspending after 360ms (10 * 36ms) timeout (tPollingLFPSTimeout).

Original patch was sent to stable, this one should go there as well

Fixes: 2f31a67f01a8 ("usb: xhci: Prevent bus suspend if a port connect change or polling state is detected")
Cc: stable@...
Signed-off-by: Mathias Nyman <mathias.nyman@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/host/xhci-hub.c
Modified: drivers/usb/host/xhci.h


[linux:lloyd-aviation] By Romain Izard <romain.izard.pro@...>:
2392ffab085a: usb: cdc-acm: fix race during wakeup blocking TX traffic

commit 93e1c8a638308980309e009cc40b5a57ef87caf1 upstream.

When the kernel is compiled with preemption enabled, the URB completion
handler can run in parallel with the work responsible for waking up the
tty layer. If the URB handler sets the EVENT_TTY_WAKEUP bit during the
call to tty_port_tty_wakeup() to signal that there is room for additional
input, it will be cleared at the end of this call. As a result, TX traffic
on the upper layer will be blocked.

This can be seen with a kernel configured with CONFIG_PREEMPT, and a fast
modem connected with PPP running over a USB CDC-ACM port.

Use test_and_clear_bit() instead, which ensures that each wakeup requested
by the URB completion code will trigger a call to tty_port_tty_wakeup().

Fixes: 1aba579f3cf5 cdc-acm: handle read pipe errors
Signed-off-by: Romain Izard <romain.izard.pro@...>
Cc: stable <stable@...>
Acked-by: Oliver Neukum <oneukum@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/class/cdc-acm.c


[linux:lloyd-aviation] By Nicolas Boichat <drinkcat@...>:
62d342d67060: mm: add support for kmem caches in DMA32 zone

commit 6d6ea1e967a246f12cfe2f5fb743b70b2e608d4a upstream.

Patch series "iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables",
v6.

This is a followup to the discussion in [1], [2].

IOMMUs using ARMv7 short-descriptor format require page tables (level 1
and 2) to be allocated within the first 4GB of RAM, even on 64-bit
systems.

For L1 tables that are bigger than a page, we can just use
__get_free_pages with GFP_DMA32 (on arm64 systems only, arm would still
use GFP_DMA).

For L2 tables that only take 1KB, it would be a waste to allocate a full
page, so we considered 3 approaches:
1. This series, adding support for GFP_DMA32 slab caches.
2. genalloc, which requires pre-allocating the maximum number of L2 page
tables (4096, so 4MB of memory).
3. page_frag, which is not very memory-efficient as it is unable to reuse
freed fragments until the whole page is freed. [3]

This series is the most memory-efficient approach.

stable@ note:
We confirmed that this is a regression, and IOMMU errors happen on 4.19
and linux-next/master on MT8173 (elm, Acer Chromebook R13). The issue
most likely starts from commit ad67f5a6545f ("arm64: replace ZONE_DMA
with ZONE_DMA32"), i.e. 4.15, and presumably breaks a number of Mediatek
platforms (and maybe others?).

[1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html
[2] https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031696.html
[3] https://patchwork.codeaurora.org/patch/671639/

This patch (of 3):

IOMMUs using ARMv7 short-descriptor format require page tables to be
allocated within the first 4GB of RAM, even on 64-bit systems. On arm64,
this is done by passing GFP_DMA32 flag to memory allocation functions.

For IOMMU L2 tables that only take 1KB, it would be a waste to allocate
a full page using get_free_pages, so we considered 3 approaches:
1. This patch, adding support for GFP_DMA32 slab caches.
2. genalloc, which requires pre-allocating the maximum number of L2
page tables (4096, so 4MB of memory).
3. page_frag, which is not very memory-efficient as it is unable
to reuse freed fragments until the whole page is freed.

This change makes it possible to create a custom cache in DMA32 zone using
kmem_cache_create, then allocate memory using kmem_cache_alloc.

We do not create a DMA32 kmalloc cache array, as there are currently no
users of kmalloc(..., GFP_DMA32). These calls will continue to trigger a
warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.

This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
unnecessary).

Link: http://lkml.kernel.org/r/20181210011504.122604-2-drinkcat@...
Signed-off-by: Nicolas Boichat <drinkcat@...>
Acked-by: Vlastimil Babka <vbabka@...>
Acked-by: Will Deacon <will.deacon@...>
Cc: Robin Murphy <robin.murphy@...>
Cc: Joerg Roedel <joro@...>
Cc: Christoph Lameter <cl@...>
Cc: Pekka Enberg <penberg@...>
Cc: David Rientjes <rientjes@...>
Cc: Joonsoo Kim <iamjoonsoo.kim@...>
Cc: Michal Hocko <mhocko@...>
Cc: Mel Gorman <mgorman@...>
Cc: Sasha Levin <Alexander.Levin@...>
Cc: Huaisheng Ye <yehs1@...>
Cc: Mike Rapoport <rppt@...>
Cc: Yong Wu <yong.wu@...>
Cc: Matthias Brugger <matthias.bgg@...>
Cc: Tomasz Figa <tfiga@...>
Cc: Yingjoe Chen <yingjoe.chen@...>
Cc: Christoph Hellwig <hch@...>
Cc: Matthew Wilcox <willy@...>
Cc: Hsin-Yi Wang <hsinyi@...>
Cc: <stable@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: include/linux/slab.h
Modified: mm/slab.c
Modified: mm/slab.h
Modified: mm/slab_common.c
Modified: mm/slub.c


[linux:lloyd-aviation] By Nicolas Boichat <drinkcat@...>:
c9874d397807: iommu/io-pgtable-arm-v7s: request DMA32 memory, and improve debugging

commit 0a352554da69b02f75ca3389c885c741f1f63235 upstream.

IOMMUs using ARMv7 short-descriptor format require page tables (level 1
and 2) to be allocated within the first 4GB of RAM, even on 64-bit
systems.

For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32 is
defined (e.g. on arm64 platforms).

For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32. Note that
we do not explicitly pass GFP_DMA[32] to kmem_cache_zalloc, as this is
not strictly necessary, and would cause a warning in mm/sl*b.c, as we
did not update GFP_SLAB_BUG_MASK.

Also, print an error when the physical address does not fit in
32-bit, to make debugging easier in the future.

Link: http://lkml.kernel.org/r/20181210011504.122604-3-drinkcat@...
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat <drinkcat@...>
Acked-by: Will Deacon <will.deacon@...>
Cc: Christoph Hellwig <hch@...>
Cc: Christoph Lameter <cl@...>
Cc: David Rientjes <rientjes@...>
Cc: Hsin-Yi Wang <hsinyi@...>
Cc: Huaisheng Ye <yehs1@...>
Cc: Joerg Roedel <joro@...>
Cc: Joonsoo Kim <iamjoonsoo.kim@...>
Cc: Matthew Wilcox <willy@...>
Cc: Matthias Brugger <matthias.bgg@...>
Cc: Mel Gorman <mgorman@...>
Cc: Michal Hocko <mhocko@...>
Cc: Mike Rapoport <rppt@...>
Cc: Pekka Enberg <penberg@...>
Cc: Robin Murphy <robin.murphy@...>
Cc: Sasha Levin <Alexander.Levin@...>
Cc: Tomasz Figa <tfiga@...>
Cc: Vlastimil Babka <vbabka@...>
Cc: Yingjoe Chen <yingjoe.chen@...>
Cc: Yong Wu <yong.wu@...>
Cc: <stable@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/iommu/io-pgtable-arm-v7s.c


[linux:lloyd-aviation] By Yang Shi <yang.shi@...>:
5966777dd807: mm: mempolicy: make mbind() return -EIO when MPOL_MF_STRICT is specified

commit a7f40cfe3b7ada57af9b62fd28430eeb4a7cfcb7 upstream.

When MPOL_MF_STRICT was specified and an existing page was already on a
node that does not follow the policy, mbind() should return -EIO. But
commit 6f4576e3687b ("mempolicy: apply page table walker on
queue_pages_range()") broke the rule.

And commit c8633798497c ("mm: mempolicy: mbind and migrate_pages support
thp migration") didn't return the correct value for THP mbind() too.

If MPOL_MF_STRICT is set, ignore vma_migratable() to make sure it
reaches queue_pages_to_pte_range() or queue_pages_pmd() to check if an
existing page was already on a node that does not follow the policy.
And, non-migratable vma may be used, return -EIO too if MPOL_MF_MOVE or
MPOL_MF_MOVE_ALL was specified.

Tested with https://github.com/metan-ucw/ltp/blob/master/testcases/kernel/syscalls/mbind/mbind02.c

[akpm@...: tweak code comment]
Link: http://lkml.kernel.org/r/1553020556-38583-1-git-send-email-yang.shi@...
Fixes: 6f4576e3687b ("mempolicy: apply page table walker on queue_pages_range()")
Signed-off-by: Yang Shi <yang.shi@...>
Signed-off-by: Oscar Salvador <osalvador@...>
Reported-by: Cyril Hrubis <chrubis@...>
Suggested-by: Kirill A. Shutemov <kirill@...>
Acked-by: Rafael Aquini <aquini@...>
Reviewed-by: Oscar Salvador <osalvador@...>
Acked-by: David Rientjes <rientjes@...>
Cc: Vlastimil Babka <vbabka@...>
Cc: <stable@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: mm/mempolicy.c


[linux:lloyd-aviation] By Lars Persson <lars.persson@...>:
f70ddae24bdf: mm/migrate.c: add missing flush_dcache_page for non-mapped page migrate

commit d2b2c6dd227ba5b8a802858748ec9a780cb75b47 upstream.

Our MIPS 1004Kc SoCs were seeing random userspace crashes with SIGILL
and SIGSEGV that could not be traced back to a userspace code bug. They
had all the magic signs of an I/D cache coherency issue.

Now recently we noticed that the /proc/sys/vm/compact_memory interface
was quite efficient at provoking this class of userspace crashes.

Studying the code in mm/migrate.c there is a distinction made between
migrating a page that is mapped at the instant of migration and one that
is not mapped. Our problem turned out to be the non-mapped pages.

For the non-mapped page the code performs a copy of the page content and
all relevant meta-data of the page without doing the required D-cache
maintenance. This leaves dirty data in the D-cache of the CPU and on
the 1004K cores this data is not visible to the I-cache. A subsequent
page-fault that triggers a mapping of the page will happily serve the
process with potentially stale code.

What about ARM then, this bug should have seen greater exposure? Well
ARM became immune to this flaw back in 2010, see commit c01778001a4f
("ARM: 6379/1: Assume new page cache pages have dirty D-cache").

My proposed fix moves the D-cache maintenance inside move_to_new_page to
make it common for both cases.

Link: http://lkml.kernel.org/r/20190315083502.11849-1-larper@...
Fixes: 97ee0524614 ("flush cache before installing new page at migraton")
Signed-off-by: Lars Persson <larper@...>
Reviewed-by: Paul Burton <paul.burton@...>
Acked-by: Mel Gorman <mgorman@...>
Cc: Ralf Baechle <ralf@...>
Cc: <stable@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: mm/migrate.c


[linux:lloyd-aviation] By Kan Liang <kan.liang@...>:
5f9366330950: perf pmu: Fix parser error for uncore event alias

commit e94d6b7f615e6dfbaf9fba7db6011db561461d0c upstream.

Perf fails to parse uncore event alias, for example:

# perf stat -e unc_m_clockticks -a --no-merge sleep 1
event syntax error: 'unc_m_clockticks'
\___ parser error

Current code assumes that the event alias is from one specific PMU.

To find the PMU, perf strcmps the PMU name of event alias with the real
PMU name on the system.

However, the uncore event alias may be from multiple PMUs with common
prefix. The PMU name of uncore event alias is the common prefix.

For example, UNC_M_CLOCKTICKS is clock event for iMC, which include 6
PMUs with the same prefix "uncore_imc" on a skylake server.

The real PMU names on the system for iMC are uncore_imc_0 ...
uncore_imc_5.

The strncmp is used to only check the common prefix for uncore event
alias.

With the patch:

# perf stat -e unc_m_clockticks -a --no-merge sleep 1
Performance counter stats for 'system wide':

723,594,722 unc_m_clockticks [uncore_imc_5]
724,001,954 unc_m_clockticks [uncore_imc_3]
724,042,655 unc_m_clockticks [uncore_imc_1]
724,161,001 unc_m_clockticks [uncore_imc_4]
724,293,713 unc_m_clockticks [uncore_imc_2]
724,340,901 unc_m_clockticks [uncore_imc_0]

1.002090060 seconds time elapsed

Signed-off-by: Kan Liang <kan.liang@...>
Acked-by: Jiri Olsa <jolsa@...>
Cc: Andi Kleen <ak@...>
Cc: Thomas Richter <tmricht@...>
Cc: stable@...
Fixes: ea1fa48c055f ("perf stat: Handle different PMU names with common prefix")
Link: http://lkml.kernel.org/r/1552672814-156173-1-git-send-email-kan.liang@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: tools/perf/util/pmu.c


[linux:lloyd-aviation] By Adrian Hunter <adrian.hunter@...>:
a436cf6479c0: perf intel-pt: Fix TSC slip

commit f3b4e06b3bda759afd042d3d5fa86bea8f1fe278 upstream.

A TSC packet can slip past MTC packets so that the timestamp appears to
go backwards. One estimate is that can be up to about 40 CPU cycles,
which is certainly less than 0x1000 TSC ticks, but accept slippage an
order of magnitude more to be on the safe side.

Signed-off-by: Adrian Hunter <adrian.hunter@...>
Cc: Jiri Olsa <jolsa@...>
Cc: stable@...
Fixes: 79b58424b821c ("perf tools: Add Intel PT support for decoding MTC packets")
Link: http://lkml.kernel.org/r/20190325135135.18348-1-adrian.hunter@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: tools/perf/util/intel-pt-decoder/intel-pt-decoder.c


[linux:lloyd-aviation] By Rolf Eike Beer <eb@...>:
0603e3a9281d: objtool: Query pkg-config for libelf location

commit 056d28d135bca0b1d0908990338e00e9dadaf057 upstream.

If it is not in the default location, compilation fails at several points.

Signed-off-by: Rolf Eike Beer <eb@...>
Signed-off-by: Josh Poimboeuf <jpoimboe@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Cc: stable@...
Link: https://lkml.kernel.org/r/91a25e992566a7968fedc89ec80e7f4c83ad0548.1553622500.git.jpoimboe@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: Makefile
Modified: tools/objtool/Makefile


[linux:lloyd-aviation] By Gautham R. Shenoy <ego@...>:
d7c00bbbfac4: powerpc/pseries/energy: Use OF accessor functions to read ibm,drc-indexes

commit ce9afe08e71e3f7d64f337a6e932e50849230fc2 upstream.

In cpu_to_drc_index() in the case when FW_FEATURE_DRC_INFO is absent,
we currently use of_read_property() to obtain the pointer to the array
corresponding to the property "ibm,drc-indexes". The elements of this
array are of type __be32, but are accessed without any conversion to
the OS-endianness, which is buggy on a Little Endian OS.

Fix this by using of_property_read_u32_index() accessor function to
safely read the elements of the array.

Fixes: e83636ac3334 ("pseries/drc-info: Search DRC properties for CPU indexes")
Cc: stable@... # v4.16+
Reported-by: Pavithra R. Prakash <pavrampu@...>
Signed-off-by: Gautham R. Shenoy <ego@...>
Reviewed-by: Vaidyanathan Srinivasan <svaidy@...>
[mpe: Make the WARN_ON a WARN_ON_ONCE so it's not retriggerable]
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/platforms/pseries/pseries_energy.c


[linux:lloyd-aviation] By Michael Ellerman <mpe@...>:
c91d07ad34d7: powerpc/64: Fix memcmp reading past the end of src/dest

commit d9470757398a700d9450a43508000bcfd010c7a4 upstream.

Chandan reported that fstests' generic/026 test hit a crash:

BUG: Unable to handle kernel data access at 0xc00000062ac40000
Faulting instruction address: 0xc000000000092240
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries
CPU: 0 PID: 27828 Comm: chacl Not tainted 5.0.0-rc2-next-20190115-00001-g6de6dba64dda #1
NIP: c000000000092240 LR: c00000000066a55c CTR: 0000000000000000
REGS: c00000062c0c3430 TRAP: 0300 Not tainted (5.0.0-rc2-next-20190115-00001-g6de6dba64dda)
MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 44000842 XER: 20000000
CFAR: 00007fff7f3108ac DAR: c00000062ac40000 DSISR: 40000000 IRQMASK: 0
GPR00: 0000000000000000 c00000062c0c36c0 c0000000017f4c00 c00000000121a660
GPR04: c00000062ac3fff9 0000000000000004 0000000000000020 00000000275b19c4
GPR08: 000000000000000c 46494c4500000000 5347495f41434c5f c0000000026073a0
GPR12: 0000000000000000 c0000000027a0000 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: c00000062ea70020 c00000062c0c38d0 0000000000000002 0000000000000002
GPR24: c00000062ac3ffe8 00000000275b19c4 0000000000000001 c00000062ac30000
GPR28: c00000062c0c38d0 c00000062ac30050 c00000062ac30058 0000000000000000
NIP memcmp+0x120/0x690
LR xfs_attr3_leaf_lookup_int+0x53c/0x5b0
Call Trace:
xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable)
xfs_da3_node_lookup_int+0x32c/0x5a0
xfs_attr_node_addname+0x170/0x6b0
xfs_attr_set+0x2ac/0x340
__xfs_set_acl+0xf0/0x230
xfs_set_acl+0xd0/0x160
set_posix_acl+0xc0/0x130
posix_acl_xattr_set+0x68/0x110
__vfs_setxattr+0xa4/0x110
__vfs_setxattr_noperm+0xac/0x240
vfs_setxattr+0x128/0x130
setxattr+0x248/0x600
path_setxattr+0x108/0x120
sys_setxattr+0x28/0x40
system_call+0x5c/0x70
Instruction dump:
7d201c28 7d402428 7c295040 38630008 38840008 408201f0 4200ffe8 2c050000
4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 7d4a3436 7c295040

The instruction dump decodes as:
subfic r6,r5,8
rlwinm r6,r6,3,0,28
ldbrx r9,0,r3
ldbrx r10,0,r4 <-

Which shows us doing an 8 byte load from c00000062ac3fff9, which
crosses the page boundary at c00000062ac40000 and faults.

It's not OK for memcmp to read past the end of the source or
destination buffers if that would cross a page boundary, because we
don't know that the next page is mapped.

As pointed out by Segher, we can read past the end of the source or
destination as long as we don't cross a 4K boundary, because that's
our minimum page size on all platforms.

The bug is in the code at the .Lcmp_rest_lt8bytes label. When we get
there we know that s1 is 8-byte aligned and we have at least 1 byte to
read, so a single 8-byte load won't read past the end of s1 and cross
a page boundary.

But we have to be more careful with s2. So check if it's within 8
bytes of a 4K boundary and if so go to the byte-by-byte loop.

Fixes: 2d9ee327adce ("powerpc/64: Align bytes before fall back to .Lshort in powerpc64 memcmp()")
Cc: stable@... # v4.19+
Reported-by: Chandan Rajendra <chandan@...>
Signed-off-by: Michael Ellerman <mpe@...>
Reviewed-by: Segher Boessenkool <segher@...>
Tested-by: Chandan Rajendra <chandan@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/powerpc/lib/memcmp_64.S


[linux:lloyd-aviation] By Thomas Gleixner <tglx@...>:
336f6b23b5b8: watchdog: Respect watchdog cpumask on CPU hotplug

commit 7dd47617114921fdd8c095509e5e7b4373cc44a1 upstream.

The rework of the watchdog core to use cpu_stop_work broke the watchdog
cpumask on CPU hotplug.

The watchdog_enable/disable() functions are now called unconditionally from
the hotplug callback, i.e. even on CPUs which are not in the watchdog
cpumask. As a consequence the watchdog can become unstoppable.

Only invoke them when the plugged CPU is in the watchdog cpumask.

Fixes: 9cf57731b63e ("watchdog/softlockup: Replace "watchdog/%u" threads with cpu_stop_work")
Reported-by: Maxime Coquelin <maxime.coquelin@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Tested-by: Maxime Coquelin <maxime.coquelin@...>
Cc: Peter Zijlstra <peterz@...>
Cc: Oleg Nesterov <oleg@...>
Cc: Michael Ellerman <mpe@...>
Cc: Nicholas Piggin <npiggin@...>
Cc: Don Zickus <dzickus@...>
Cc: Ricardo Neri <ricardo.neri-calderon@...>
Cc: stable@...
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1903262245490.1789@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/watchdog.c


[linux:lloyd-aviation] By Thomas Gleixner <tglx@...>:
a56aa02e6f15: cpu/hotplug: Prevent crash when CPU bringup fails on CONFIG_HOTPLUG_CPU=n

commit 206b92353c839c0b27a0b9bec24195f93fd6cf7a upstream.

Tianyu reported a crash in a CPU hotplug teardown callback when booting a
kernel which has CONFIG_HOTPLUG_CPU disabled with the 'nosmt' boot
parameter.

It turns out that the SMP=y CONFIG_HOTPLUG_CPU=n case has been broken
forever in case that a bringup callback fails. Unfortunately this issue was
not recognized when the CPU hotplug code was reworked, so the shortcoming
just stayed in place.

When a bringup callback fails, the CPU hotplug code rolls back the
operation and takes the CPU offline.

The 'nosmt' command line argument uses a bringup failure to abort the
bringup of SMT sibling CPUs. This partial bringup is required due to the
MCE misdesign on Intel CPUs.

With CONFIG_HOTPLUG_CPU=y the rollback works perfectly fine, but
CONFIG_HOTPLUG_CPU=n lacks essential mechanisms to exercise the low level
teardown of a CPU including the synchronizations in various facilities like
RCU, NOHZ and others.

As a consequence the teardown callbacks which must be executed on the
outgoing CPU within stop machine with interrupts disabled are executed on
the control CPU in interrupt enabled and preemptible context causing the
kernel to crash and burn. The pre state machine code has a different
failure mode which is more subtle and resulting in a less obvious use after
free crash because the control side frees resources which are still in use
by the undead CPU.

But this is not a x86 only problem. Any architecture which supports the
SMP=y HOTPLUG_CPU=n combination suffers from the same issue. It's just less
likely to be triggered because in 99.99999% of the cases all bringup
callbacks succeed.

The easy solution of making HOTPLUG_CPU mandatory for SMP is not working on
all architectures as the following architectures have either no hotplug
support at all or not all subarchitectures support it:

alpha, arc, hexagon, openrisc, riscv, sparc (32bit), mips (partial).

Crashing the kernel in such a situation is not an acceptable state
either.

Implement a minimal rollback variant by limiting the teardown to the point
where all regular teardown callbacks have been invoked and leave the CPU in
the 'dead' idle state. This has the following consequences:

- the CPU is brought down to the point where the stop_machine takedown
would happen.

- the CPU stays there forever and is idle

- The CPU is cleared in the CPU active mask, but not in the CPU online
mask which is a legit state.

- Interrupts are not forced away from the CPU

- All facilities which only look at online mask would still see it, but
that is the case during normal hotplug/unplug operations as well. It's
just a (way) longer time frame.

This will expose issues, which haven't been exposed before or only seldom,
because now the normally transient state of being non active but online is
a permanent state. In testing this exposed already an issue vs. work queues
where the vmstat code schedules work on the almost dead CPU which ends up
in an unbound workqueue and triggers 'preemtible context' warnings. This is
not a problem of this change, it merily exposes an already existing issue.
Still this is better than crashing fully without a chance to debug it.

This is mainly thought as workaround for those architectures which do not
support HOTPLUG_CPU. All others should enforce HOTPLUG_CPU for SMP.

Fixes: 2e1a3483ce74 ("cpu/hotplug: Split out the state walk into functions")
Reported-by: Tianyu Lan <Tianyu.Lan@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Tested-by: Tianyu Lan <Tianyu.Lan@...>
Acked-by: Greg Kroah-Hartman <gregkh@...>
Cc: Konrad Wilk <konrad.wilk@...>
Cc: Josh Poimboeuf <jpoimboe@...>
Cc: Mukesh Ojha <mojha@...>
Cc: Peter Zijlstra <peterz@...>
Cc: Jiri Kosina <jkosina@...>
Cc: Rik van Riel <riel@...>
Cc: Andy Lutomirski <luto@...>
Cc: Micheal Kelley <michael.h.kelley@...>
Cc: "K. Y. Srinivasan" <kys@...>
Cc: Linus Torvalds <torvalds@...>
Cc: Borislav Petkov <bp@...>
Cc: K. Y. Srinivasan <kys@...>
Cc: stable@...
Link: https://lkml.kernel.org/r/20190326163811.503390616@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/cpu.c


[linux:lloyd-aviation] By Thomas Gleixner <tglx@...>:
a0713e8103d1: x86/smp: Enforce CONFIG_HOTPLUG_CPU when SMP=y

commit bebd024e4815b1a170fcd21ead9c2222b23ce9e6 upstream.

The SMT disable 'nosmt' command line argument is not working properly when
CONFIG_HOTPLUG_CPU is disabled. The teardown of the sibling CPUs which are
required to be brought up due to the MCE issues, cannot work. The CPUs are
then kept in a half dead state.

As the 'nosmt' functionality has become popular due to the speculative
hardware vulnerabilities, the half torn down state is not a proper solution
to the problem.

Enforce CONFIG_HOTPLUG_CPU=y when SMP is enabled so the full operation is
possible.

Reported-by: Tianyu Lan <Tianyu.Lan@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Acked-by: Greg Kroah-Hartman <gregkh@...>
Cc: Konrad Wilk <konrad.wilk@...>
Cc: Josh Poimboeuf <jpoimboe@...>
Cc: Mukesh Ojha <mojha@...>
Cc: Peter Zijlstra <peterz@...>
Cc: Jiri Kosina <jkosina@...>
Cc: Rik van Riel <riel@...>
Cc: Andy Lutomirski <luto@...>
Cc: Micheal Kelley <michael.h.kelley@...>
Cc: "K. Y. Srinivasan" <kys@...>
Cc: Linus Torvalds <torvalds@...>
Cc: Borislav Petkov <bp@...>
Cc: K. Y. Srinivasan <kys@...>
Cc: stable@...
Link: https://lkml.kernel.org/r/20190326163811.598166056@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/Kconfig


[linux:lloyd-aviation] By Sean Christopherson <sean.j.christopherson@...>:
7ceedcefc2d2: KVM: Reject device ioctls from processes other than the VM's creator

commit ddba91801aeb5c160b660caed1800eb3aef403f8 upstream.

KVM's API requires thats ioctls must be issued from the same process
that created the VM. In other words, userspace can play games with a
VM's file descriptors, e.g. fork(), SCM_RIGHTS, etc..., but only the
creator can do anything useful. Explicitly reject device ioctls that
are issued by a process other than the VM's creator, and update KVM's
API documentation to extend its requirements to device ioctls.

Fixes: 852b6d57dc7f ("kvm: add device control API")
Cc: <stable@...>
Signed-off-by: Sean Christopherson <sean.j.christopherson@...>
Signed-off-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: Documentation/virtual/kvm/api.txt
Modified: virt/kvm/kvm_main.c


[linux:lloyd-aviation] By Sean Christopherson <sean.j.christopherson@...>:
b9733a74350d: KVM: x86: update %rip after emulating IO

commit 45def77ebf79e2e8942b89ed79294d97ce914fa0 upstream.

Most (all?) x86 platforms provide a port IO based reset mechanism, e.g.
OUT 92h or CF9h. Userspace may emulate said mechanism, i.e. reset a
vCPU in response to KVM_EXIT_IO, without explicitly announcing to KVM
that it is doing a reset, e.g. Qemu jams vCPU state and resumes running.

To avoid corruping %rip after such a reset, commit 0967b7bf1c22 ("KVM:
Skip pio instruction when it is emulated, not executed") changed the
behavior of PIO handlers, i.e. today's "fast" PIO handling to skip the
instruction prior to exiting to userspace. Full emulation doesn't need
such tricks becase re-emulating the instruction will naturally handle
%rip being changed to point at the reset vector.

Updating %rip prior to executing to userspace has several drawbacks:

- Userspace sees the wrong %rip on the exit, e.g. if PIO emulation
fails it will likely yell about the wrong address.
- Single step exits to userspace for are effectively dropped as
KVM_EXIT_DEBUG is overwritten with KVM_EXIT_IO.
- Behavior of PIO emulation is different depending on whether it
goes down the fast path or the slow path.

Rather than skip the PIO instruction before exiting to userspace,
snapshot the linear %rip and cancel PIO completion if the current
value does not match the snapshot. For a 64-bit vCPU, i.e. the most
common scenario, the snapshot and comparison has negligible overhead
as VMCS.GUEST_RIP will be cached regardless, i.e. there is no extra
VMREAD in this case.

All other alternatives to snapshotting the linear %rip that don't
rely on an explicit reset announcenment suffer from one corner case
or another. For example, canceling PIO completion on any write to
%rip fails if userspace does a save/restore of %rip, and attempting to
avoid that issue by canceling PIO only if %rip changed then fails if PIO
collides with the reset %rip. Attempting to zero in on the exact reset
vector won't work for APs, which means adding more hooks such as the
vCPU's MP_STATE, and so on and so forth.

Checking for a linear %rip match technically suffers from corner cases,
e.g. userspace could theoretically rewrite the underlying code page and
expect a different instruction to execute, or the guest hardcodes a PIO
reset at 0xfffffff0, but those are far, far outside of what can be
considered normal operation.

Fixes: 432baf60eee3 ("KVM: VMX: use kvm_fast_pio_in for handling IN I/O")
Cc: <stable@...>
Reported-by: Jim Mattson <jmattson@...>
Signed-off-by: Sean Christopherson <sean.j.christopherson@...>
Signed-off-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/include/asm/kvm_host.h
Modified: arch/x86/kvm/x86.c


[linux:lloyd-aviation] By Sean Christopherson <sean.j.christopherson@...>:
3a18eabaa712: KVM: x86: Emulate MSR_IA32_ARCH_CAPABILITIES on AMD hosts

commit 0cf9135b773bf32fba9dd8e6699c1b331ee4b749 upstream.

The CPUID flag ARCH_CAPABILITIES is unconditioinally exposed to host
userspace for all x86 hosts, i.e. KVM advertises ARCH_CAPABILITIES
regardless of hardware support under the pretense that KVM fully
emulates MSR_IA32_ARCH_CAPABILITIES. Unfortunately, only VMX hosts
handle accesses to MSR_IA32_ARCH_CAPABILITIES (despite KVM_GET_MSRS
also reporting MSR_IA32_ARCH_CAPABILITIES for all hosts).

Move the MSR_IA32_ARCH_CAPABILITIES handling to common x86 code so
that it's emulated on AMD hosts.

Fixes: 1eaafe91a0df4 ("kvm: x86: IA32_ARCH_CAPABILITIES is always supported")
Cc: stable@...
Reported-by: Xiaoyao Li <xiaoyao.li@...>
Cc: Jim Mattson <jmattson@...>
Signed-off-by: Sean Christopherson <sean.j.christopherson@...>
Signed-off-by: Paolo Bonzini <pbonzini@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/x86/include/asm/kvm_host.h
Modified: arch/x86/kvm/vmx.c
Modified: arch/x86/kvm/x86.c


[linux:lloyd-aviation] By Gao Xiang <gaoxiang25@...>:
83bbd66b3753: staging: erofs: fix error handling when failed to read compresssed data

commit b6391ac73400eff38377a4a7364bd3df5efb5178 upstream.

Complete read error handling paths for all three kinds of
compressed pages:

1) For cache-managed pages, PG_uptodate will be checked since
read_endio will unlock and SetPageUptodate for these pages;

2) For inplaced pages, read_endio cannot SetPageUptodate directly
since it should be used to mark the final decompressed data,
PG_error will be set with page locked for IO error instead;

3) For staging pages, PG_error is used, which is similar to
what we do for inplaced pages.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc: <stable@...> # 4.19+
Reviewed-by: Chao Yu <yuchao0@...>
Signed-off-by: Gao Xiang <gaoxiang25@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/erofs/unzip_vle.c


[linux:lloyd-aviation] By Gao Xiang <gaoxiang25@...>:
738dda85d181: staging: erofs: keep corrupted fs from crashing kernel in erofs_readdir()

commit 33bac912840fe64dbc15556302537dc6a17cac63 upstream.

After commit 419d6efc50e9, kernel cannot be crashed in the namei
path. However, corrupted nameoff can do harm in the process of
readdir for scenerios without dm-verity as well. Fix it now.

Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations")
Cc: <stable@...> # 4.19+
Signed-off-by: Gao Xiang <gaoxiang25@...>
Reviewed-by: Chao Yu <yuchao0@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/staging/erofs/dir.c


[linux:lloyd-aviation] By Xu Yu <xuyu@...>:
f5959dec081a: bpf: do not restore dst_reg when cur_state is freed

commit 0803278b0b4d8eeb2b461fb698785df65a725d9e upstream.

Syzkaller hit 'KASAN: use-after-free Write in sanitize_ptr_alu' bug.

Call trace:

dump_stack+0xbf/0x12e
print_address_description+0x6a/0x280
kasan_report+0x237/0x360
sanitize_ptr_alu+0x85a/0x8d0
adjust_ptr_min_max_vals+0x8f2/0x1ca0
adjust_reg_min_max_vals+0x8ed/0x22e0
do_check+0x1ca6/0x5d00
bpf_check+0x9ca/0x2570
bpf_prog_load+0xc91/0x1030
__se_sys_bpf+0x61e/0x1f00
do_syscall_64+0xc8/0x550
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fault injection trace:

 kfree+0xea/0x290
 free_func_state+0x4a/0x60
 free_verifier_state+0x61/0xe0
 push_stack+0x216/0x2f0 <- inject failslab
 sanitize_ptr_alu+0x2b1/0x8d0
 adjust_ptr_min_max_vals+0x8f2/0x1ca0
 adjust_reg_min_max_vals+0x8ed/0x22e0
 do_check+0x1ca6/0x5d00
 bpf_check+0x9ca/0x2570
 bpf_prog_load+0xc91/0x1030
 __se_sys_bpf+0x61e/0x1f00
 do_syscall_64+0xc8/0x550
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

When kzalloc() fails in push_stack(), free_verifier_state() will free
current verifier state. As push_stack() returns, dst_reg was restored
if ptr_is_dst_reg is false. However, as member of the cur_state,
dst_reg is also freed, and error occurs when dereferencing dst_reg.
Simply fix it by testing ret of push_stack() before restoring dst_reg.

Fixes: 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic")
Signed-off-by: Xu Yu <xuyu@...>
Signed-off-by: Daniel Borkmann <daniel@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: kernel/bpf/verifier.c


[linux:lloyd-aviation] By Heikki Krogerus <heikki.krogerus@...>:
e99d90ce7750: drivers: base: Helpers for adding device connection descriptions

commit cd7753d371388e712e3ee52b693459f9b71aaac2 upstream.

Introducing helpers for adding and removing multiple device
connection descriptions at once.

Acked-by: Hans de Goede <hdegoede@...>
Tested-by: Hans de Goede <hdegoede@...>
Signed-off-by: Heikki Krogerus <heikki.krogerus@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: include/linux/device.h


[linux:lloyd-aviation] By Heikki Krogerus <heikki.krogerus@...>:
3bb446a3fe87: platform: x86: intel_cht_int33fe: Register all connections at once

commit 140a4ec4adddda615b4e8e8055ca37a30c7fe5e8 upstream.

We can register all device connection descriptors with a
single call to device_connections_add().

Acked-by: Andy Shevchenko <andy.shevchenko@...>
Acked-by: Hans de Goede <hdegoede@...>
Tested-by: Hans de Goede <hdegoede@...>
Signed-off-by: Heikki Krogerus <heikki.krogerus@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/platform/x86/intel_cht_int33fe.c


[linux:lloyd-aviation] By Heikki Krogerus <heikki.krogerus@...>:
681a9fc184b3: platform: x86: intel_cht_int33fe: Add connection for the DP alt mode

commit 78d2b54b134ea6059e2b1554ad53fab2300a4cc6 upstream.

Adding a connection for the DisplayPort alternate mode.
PI3USB30532 is used for muxing the port to DisplayPort on
CHT platforms. The connection allows the alternate mode
device to get handle to the mux, and therefore make it
possible to use the USB Type-C connector as DisplayPort.

Acked-by: Andy Shevchenko <andy.shevchenko@...>
Acked-by: Hans de Goede <hdegoede@...>
Tested-by: Hans de Goede <hdegoede@...>
Signed-off-by: Heikki Krogerus <heikki.krogerus@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/platform/x86/intel_cht_int33fe.c


[linux:lloyd-aviation] By Heikki Krogerus <heikki.krogerus@...>:
6875404a12f8: platform: x86: intel_cht_int33fe: Add connections for the USB Type-C port

commit 495965a1002a0b301bf4fbfd1aed3233f3e7db1b upstream.

Assigning the mux to the USB Type-C port on top of fusb302.
That will prepare this driver for the change in the USB
Type-C class code, where the class driver will assume the
muxes to be always assigned to the ports and not the
controllers.

Once the USB Type-C class driver has been updated, the
connections between the mux and fusb302 can be dropped.

Acked-by: Andy Shevchenko <andy.shevchenko@...>
Acked-by: Hans de Goede <hdegoede@...>
Tested-by: Hans de Goede <hdegoede@...>
Signed-off-by: Heikki Krogerus <heikki.krogerus@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/platform/x86/intel_cht_int33fe.c


[linux:lloyd-aviation] By Heikki Krogerus <heikki.krogerus@...>:
056cda45cfed: usb: typec: class: Don't use port parent for getting mux handles

commit 23481121c81d984193edf1532f5e123637e50903 upstream.

It is not possible to use the parent of the port device when
requesting mux handles as the parent may be a multiport USB
Type-C or PD controller. The muxes must be assigned to the
ports, not the controllers.

This will also move the requesting of the muxes after the
port device is initialized.

Acked-by: Hans de Goede <hdegoede@...>
Tested-by: Hans de Goede <hdegoede@...>
Signed-off-by: Heikki Krogerus <heikki.krogerus@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/usb/typec/class.c


[linux:lloyd-aviation] By Heikki Krogerus <heikki.krogerus@...>:
11008a9b0fc7: platform: x86: intel_cht_int33fe: Remove the old connections for the muxes

commit 148b0aa78e4e1077e38f928124bbc9c2d2d24006 upstream.

USB Type-C class driver now expects the muxes to be always
assigned to the ports and not controllers, so the
connections for the mux and fusb302 can be removed.

Acked-by: Andy Shevchenko <andy.shevchenko@...>
Acked-by: Hans de Goede <hdegoede@...>
Tested-by: Hans de Goede <hdegoede@...>
Signed-off-by: Heikki Krogerus <heikki.krogerus@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/platform/x86/intel_cht_int33fe.c


[linux:lloyd-aviation] By Greg Kroah-Hartman <gregkh@...>:
4b3a3ab00fa7: Linux 4.19.33

Modified: Makefile


[linux:lloyd-aviation] By Will Deacon <will.deacon@...>:
bd62f1fe736e: arm64: debug: Don't propagate UNKNOWN FAR into si_code for debug signals

commit b9a4b9d084d978f80eb9210727c81804588b42ff upstream.

FAR_EL1 is UNKNOWN for all debug exceptions other than those caused by
taking a hardware watchpoint. Unfortunately, if a debug handler returns
a non-zero value, then we will propagate the UNKNOWN FAR value to
userspace via the si_addr field of the SIGTRAP siginfo_t.

Instead, let's set si_addr to take on the PC of the faulting instruction,
which we have available in the current pt_regs.

Cc: <stable@...>
Reviewed-by: Mark Rutland <mark.rutland@...>
Signed-off-by: Will Deacon <will.deacon@...>
Signed-off-by: Catalin Marinas <catalin.marinas@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: arch/arm64/mm/fault.c


[linux:lloyd-aviation] By zhangyi (F) <yi.zhang@...>:
2dbc7c66d6da: ext4: cleanup bh release code in ext4_ind_remove_space()

commit 5e86bdda41534e17621d5a071b294943cae4376e upstream.

Currently, we are releasing the indirect buffer where we are done with
it in ext4_ind_remove_space(), so we can see the brelse() and
BUFFER_TRACE() everywhere. It seems fragile and hard to read, and we
may probably forget to release the buffer some day. This patch cleans
up the code by putting of the code which releases the buffers to the
end of the function.

Signed-off-by: zhangyi (F) <yi.zhang@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Reviewed-by: Jan Kara <jack@...>
Cc: Jari Ruusu <jari.ruusu@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: fs/ext4/indirect.c


[linux:lloyd-aviation] By Razvan Stefanescu <razvan.stefanescu@...>:
b6b4bcb40be0: tty/serial: atmel: Add is_half_duplex helper

commit f3040983132bf3477acd45d2452a906e67c2fec9 upstream.

Use a helper function to check that a port needs to use half duplex
communication, replacing several occurrences of multi-line bit checking.

Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done")
Cc: stable <stable@...>
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@...>
Acked-by: Richard Genoud <richard.genoud@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/atmel_serial.c


[linux:lloyd-aviation] By Razvan Stefanescu <razvan.stefanescu@...>:
442d5d171cd8: tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped

commit 69646d7a3689fbe1a65ae90397d22ac3f1b8d40f upstream.

In half-duplex operation, RX should be started after TX completes.

If DMA is used, there is a case when the DMA transfer completes but the
TX FIFO is not emptied, so the RX cannot be restarted just yet.

Use a boolean variable to store this state and rearm TX interrupt mask
to be signaled again that the transfer finished. In interrupt transmit
handler this variable is used to start RX. A warning message is generated
if RX is activated before TX fifo is cleared.

Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable
RX after TX is done")
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@...>
Acked-by: Richard Genoud <richard.genoud@...>
Cc: stable <stable@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>

Modified: drivers/tty/serial/atmel_serial.c


[linux:lloyd-aviation] By Aurelien Aptel <aaptel@...>:
2938651d36ca: CIFS: fix POSIX lock leak and invalid ptr deref

[ Upstream commit bc31d0cdcfbadb6258b45db97e93b1c83822ba33 ]

We have a customer reporting crashes in lock_get_status() with many
"Leaked POSIX lock" messages preceeding the crash.

Leaked POSIX lock on dev=0x0:0x56 ...
Leaked POSIX lock on dev=0x0:0x56 ...
Leaked POSIX lock on dev=0x0:0x56 ...
Leaked POSIX lock on dev=0x0:0x53 ...
Leaked POSIX lock on dev=0x0:0x53 ...
Leaked POSIX lock on dev=0x0:0x53 ...
Leaked POSIX lock on dev=0x0:0x53 ...
POSIX: fl_owner=ffff8900e7b79380 fl_flags=0x1 fl_type=0x1 fl_pid=20709
Leaked POSIX lock on dev=0x0:0x4b ino...
Leaked locks on dev=0x0:0x4b ino=0xf911400000029:
POSIX: fl_owner=ffff89f41c870e00 fl_flags=0x1 fl_type=0x1 fl_pid=19592
stack segment: 0000 [#1] SMP
Modules linked in: binfmt_misc msr tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag rpcsec_gss_krb5 arc4 ecb auth_rpcgss nfsv4 md4 nfs nls_utf8 lockd grace cifs sunrpc ccm dns_resolver fscache af_packet iscsi_ibft iscsi_boot_sysfs vmw_vsock_vmci_transport vsock xfs libcrc32c sb_edac edac_core crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg ansi_cprng vmw_balloon aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev pcspkr vmxnet3 i2c_piix4 vmw_vmci shpchp fjes processor button ac btrfs xor raid6_pq sr_mod cdrom ata_generic sd_mod ata_piix vmwgfx crc32c_intel drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm serio_raw ahci libahci drm libata vmw_pvscsi sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4

Supported: Yes
CPU: 6 PID: 28250 Comm: lsof Not tainted 4.4.156-94.64-default #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
task: ffff88a345f28740 ti: ffff88c74005c000 task.ti: ffff88c74005c000
RIP: 0010:[<ffffffff8125dcab>] [<ffffffff8125dcab>] lock_get_status+0x9b/0x3b0
RSP: 0018:ffff88c74005fd90 EFLAGS: 00010202
RAX: ffff89bde83e20ae RBX: ffff89e870003d18 RCX: 0000000049534f50
RDX: ffffffff81a3541f RSI: ffffffff81a3544e RDI: ffff89bde83e20ae
RBP: 0026252423222120 R08: 0000000020584953 R09: 000000000000ffff
R10: 0000000000000000 R11: ffff88c74005fc70 R12: ffff89e5ca7b1340
R13: 00000000000050e5 R14: ffff89e870003d30 R15: ffff89e5ca7b1340
FS: 00007fafd64be800(0000) GS:ffff89f41fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001c80018 CR3: 000000a522048000 CR4: 0000000000360670
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
0000000000000208 ffffffff81a3d6b6 ffff89e870003d30 ffff89e870003d18
ffff89e5ca7b1340 ffff89f41738d7c0 ffff89e870003d30 ffff89e5ca7b1340
ffffffff8125e08f 0000000000000000 ffff89bc22b67d00 ffff88c74005ff28
Call Trace:
[<ffffffff8125e08f>] locks_show+0x2f/0x70
[<ffffffff81230ad1>] seq_read+0x251/0x3a0
[<ffffffff81275bbc>] proc_reg_read+0x3c/0x70
[<ffffffff8120e456>] __vfs_read+0x26/0x140
[<ffffffff8120e9da>] vfs_read+0x7a/0x120
[<ffffffff8120faf2>] SyS_read+0x42/0xa0
[<ffffffff8161cbc3>] entry_SYSCALL_64_fastpath+0x1e/0xb7

When Linux closes a FD (close(), close-on-exec, dup2(), ...) it calls
filp_close() which also removes all posix locks.

The lock struct is initialized like so in filp_close() and passed
down to cifs

...
lock.fl_type = F_UNLCK;
lock.fl_flags = FL_POSIX | FL_CLOSE;
lock.fl_start = 0;
lock.fl_end = OFFSET_MAX;
...

Note the FL_CLOSE flag, which hints the VFS code that this unlocking
is done for closing the fd.

filp_close()
locks_remove_posix(filp, id);
vfs_lock_file(filp, F_SETLK, &lock, NULL);
return filp->f_op->lock(filp, cmd, fl) => cifs_lock()
rc = cifs_setlk(file, flock, type, wait_flag, posix_lck, lock, unlock, xid);
rc = server->ops->mand_unlock_range(cfile, flock, xid);
if (flock->fl_flags & FL_POSIX && !rc)
rc = locks_lock_file_wait(file, flock)

Notice how we don't call locks_lock_file_wait() which does the
generic VFS lock/unlock/wait work on the inode if rc != 0.

If we are closing the handle, the SMB server is supposed to remove any
locks associated with it. Similarly, cifs.ko frees and wakes up any
lock and lock waiter when closing the file:

cifs_close()
cifsFileInfo_put(file->private_data)
/*
* Delete any outstanding lock records. We'll lose them when the file
* is closed anyway.
*/
down_write(&cifsi->lock_sem);
list_for_each_entry_safe(li, tmp, &cifs_file->llist->locks, llist) {
list_del(&li->llist);
cifs_del_lock_waiters(li);
kfree(li);
}
list_del(&cifs_file->llist->llist);
kfree(cifs_file->llist);
up_write(&cifsi->lock_sem);

So we can safely ignore unlocking failures in cifs_lock() if they
happen with the FL_CLOSE flag hint set as both the server and the
client take care of it during the actual closing.

This is not a proper fix for the unlocking failure but it's safe and
it seems to prevent the lock leakages and crashes the customer
experiences.

Signed-off-by: Aurelien Aptel <aaptel@...>
Signed-off-by: NeilBrown <neil@...>
Signed-off-by: Steve French <stfrench@...>
Acked-by: Pavel Shilovsky <pshilov@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/cifs/file.c


[linux:lloyd-aviation] By Masahiro Yamada <yamada.masahiro@...>:
56bb66c50296: h8300: use cc-cross-prefix instead of hardcoding h8300-unknown-linux-

[ Upstream commit fc2b47b55f17fd996f7a01975ce1c33c2f2513f6 ]

It believe it is a bad idea to hardcode a specific compiler prefix
that may or may not be installed on a user's system. It is annoying
when testing features that should not require compilers at all.

For example, mrproper, headers_install, etc. should work without
any compiler.

They look like follows on my machine.

$ make ARCH=h8300 mrproper
./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
make: h8300-unknown-linux-gcc: Command not found
make: h8300-unknown-linux-gcc: Command not found
[ a bunch of the same error messages continue ]

$ make ARCH=h8300 headers_install
./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
make: h8300-unknown-linux-gcc: Command not found
HOSTCC scripts/basic/fixdep
make: h8300-unknown-linux-gcc: Command not found
WRAP arch/h8300/include/generated/uapi/asm/kvm_para.h
[ snip ]

The solution is to delete this line, or to use cc-cross-prefix like
some architectures do. I chose the latter as a moderate fixup.

I added an alternative 'h8300-linux-' because it is available at:

https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/

Signed-off-by: Masahiro Yamada <yamada.masahiro@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/h8300/Makefile


[linux:lloyd-aviation] By Chao Yu <yuchao0@...>:
198c99857b30: f2fs: fix to adapt small inline xattr space in __find_inline_xattr()

[ Upstream commit 2c28aba8b2e2a51749fa66e01b68e1cd5b53e022 ]

With below testcase, we will fail to find existed xattr entry:

1. mkfs.f2fs -O extra_attr -O flexible_inline_xattr /dev/zram0
2. mount -t f2fs -o inline_xattr_size=1 /dev/zram0 /mnt/f2fs/
3. touch /mnt/f2fs/file
4. setfattr -n "user.name" -v 0 /mnt/f2fs/file
5. getfattr -n "user.name" /mnt/f2fs/file

/mnt/f2fs/file: user.name: No such attribute

The reason is for inode which has very small inline xattr size,
__find_inline_xattr() will fail to traverse any entry due to first
entry may not be loaded from xattr node yet, later, we may skip to
check entire xattr datas in __find_xattr(), result in such wrong
condition.

This patch adds condition to check such case to avoid this issue.

Signed-off-by: Chao Yu <yuchao0@...>
Signed-off-by: Jaegeuk Kim <jaegeuk@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/f2fs/xattr.c


[linux:lloyd-aviation] By Chao Yu <yuchao0@...>:
d7391962d723: f2fs: fix to avoid deadlock in f2fs_read_inline_dir()

[ Upstream commit aadcef64b22f668c1a107b86d3521d9cac915c24 ]

As Jiqun Li reported in bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=202883

sometimes, dead lock when make system call SYS_getdents64 with fsync() is
called by another process.

monkey running on android9.0

1. task 9785 held sbi->cp_rwsem and waiting lock_page()
2. task 10349 held mm_sem and waiting sbi->cp_rwsem
3. task 9709 held lock_page() and waiting mm_sem

so this is a dead lock scenario.

task stack is show by crash tools as following

crash_arm64> bt ffffffc03c354080
PID: 9785 TASK: ffffffc03c354080 CPU: 1 COMMAND: "RxIoScheduler-3"

#7 [ffffffc01b50fac0] __lock_page at ffffff80081b11e8
crash-arm64> bt 10349
PID: 10349 TASK: ffffffc018b83080 CPU: 1 COMMAND: "BUGLY_ASYNC_UPL"
#3 [ffffffc01f8cfa40] rwsem_down_read_failed at ffffff8008a93afc
PC: 00000033 LR: 00000000 SP: 00000000 PSTATE: ffffffffffffffff

crash-arm64> bt 9709
PID: 9709 TASK: ffffffc03e7f3080 CPU: 1 COMMAND: "IntentService[A"
#3 [ffffffc001e67850] rwsem_down_read_failed at ffffff8008a93afc
#8 [ffffffc001e67b80] el1_ia at ffffff8008084fc4
PC: ffffff8008274114 [compat_filldir64+120]
LR: ffffff80083584d4 [f2fs_fill_dentries+448]
SP: ffffffc001e67b80 PSTATE: 80400145
X29: ffffffc001e67b80 X28: 0000000000000000 X27: 000000000000001a
X26: 00000000000093d7 X25: ffffffc070d52480 X24: 0000000000000008
X23: 0000000000000028 X22: 00000000d43dfd60 X21: ffffffc001e67e90
X20: 0000000000000011 X19: ffffff80093a4000 X18: 0000000000000000
X17: 0000000000000000 X16: 0000000000000000 X15: 0000000000000000
X14: ffffffffffffffff X13: 0000000000000008 X12: 0101010101010101
X11: 7f7f7f7f7f7f7f7f X10: 6a6a6a6a6a6a6a6a X9: 7f7f7f7f7f7f7f7f
X8: 0000000080808000 X7: ffffff800827409c X6: 0000000080808000
X5: 0000000000000008 X4: 00000000000093d7 X3: 000000000000001a
X2: 0000000000000011 X1: ffffffc070d52480 X0: 0000000000800238
#9 [ffffffc001e67be0] f2fs_fill_dentries at ffffff80083584d0
PC: 0000003c LR: 00000000 SP: 00000000 PSTATE: 000000d9
X12: f48a02ff X11: d4678960 X10: d43dfc00 X9: d4678ae4
X8: 00000058 X7: d4678994 X6: d43de800 X5: 000000d9
X4: d43dfc0c X3: d43dfc10 X2: d46799c8 X1: 00000000
X0: 00001068

Below potential deadlock will happen between three threads:
Thread A Thread B Thread C
- f2fs_do_sync_file
- f2fs_write_checkpoint
- down_write(&sbi->node_change) -- 1)
- do_page_fault
- down_write(&mm->mmap_sem) -- 2)
- do_wp_page
- f2fs_vm_page_mkwrite
- getdents64
- f2fs_read_inline_dir
- lock_page -- 3)
- f2fs_sync_node_pages
- lock_page -- 3)
- __do_map_lock
- down_read(&sbi->node_change) -- 1)
- f2fs_fill_dentries
- dir_emit
- compat_filldir64
- do_page_fault
- down_read(&mm->mmap_sem) -- 2)

Since f2fs_readdir is protected by inode.i_rwsem, there should not be
any updates in inode page, we're safe to lookup dents in inode page
without its lock held, so taking off the lock to improve concurrency
of readdir and avoid potential deadlock.

Reported-by: Jiqun Li <jiqun.li@...>
Signed-off-by: Chao Yu <yuchao0@...>
Signed-off-by: Jaegeuk Kim <jaegeuk@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/f2fs/inline.c


[linux:lloyd-aviation] By Douglas Anderson <dianders@...>:
b73c7d020452: tracing: kdb: Fix ftdump to not sleep

[ Upstream commit 31b265b3baaf55f209229888b7ffea523ddab366 ]

As reported back in 2016-11 [1], the "ftdump" kdb command triggers a
BUG for "sleeping function called from invalid context".

kdb's "ftdump" command wants to call ring_buffer_read_prepare() in
atomic context. A very simple solution for this is to add allocation
flags to ring_buffer_read_prepare() so kdb can call it without
triggering the allocation error. This patch does that.

Note that in the original email thread about this, it was suggested
that perhaps the solution for kdb was to either preallocate the buffer
ahead of time or create our own iterator. I'm hoping that this
alternative of adding allocation flags to ring_buffer_read_prepare()
can be considered since it means I don't need to duplicate more of the
core trace code into "trace_kdb.c" (for either creating my own
iterator or re-preparing a ring allocator whose memory was already
allocated).

NOTE: another option for kdb is to actually figure out how to make it
reuse the existing ftrace_dump() function and totally eliminate the
duplication. This sounds very appealing and actually works (the "sr
z" command can be seen to properly dump the ftrace buffer). The
downside here is that ftrace_dump() fully consumes the trace buffer.
Unless that is changed I'd rather not use it because it means "ftdump
| grep xyz" won't be very useful to search the ftrace buffer since it
will throw away the whole trace on the first grep. A future patch to
dump only the last few lines of the buffer will also be hard to
implement.

[1] https://lkml.kernel.org/r/20161117191605.GA21459@...

Link: http://lkml.kernel.org/r/20190308193205.213659-1-dianders@...

Reported-by: Brian Norris <briannorris@...>
Signed-off-by: Douglas Anderson <dianders@...>
Signed-off-by: Steven Rostedt (VMware) <rostedt@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: include/linux/ring_buffer.h
Modified: kernel/trace/ring_buffer.c
Modified: kernel/trace/trace.c
Modified: kernel/trace/trace_kdb.c


[linux:lloyd-aviation] By Tonghao Zhang <xiangxia.m.yue@...>:
3bddc6149f02: net/mlx5: Avoid panic when setting vport rate

[ Upstream commit 24319258660a84dd77f4be026a55b10a12524919 ]

If we try to set VFs rate on a VF (not PF) net device, the kernel
will be crash. The commands are show as below:

$ echo 2 > /sys/class/net/$MLX_PF0/device/sriov_numvfs
$ ip link set $MLX_VF0 vf 0 max_tx_rate 2 min_tx_rate 1

If not applied the first patch ("net/mlx5: Avoid panic when setting
vport mac, getting vport config"), the command:

$ ip link set $MLX_VF0 vf 0 rate 100

can also crash the kernel.

[ 1650.006388] RIP: 0010:mlx5_eswitch_set_vport_rate+0x1f/0x260 [mlx5_core]
[ 1650.007092] do_setlink+0x982/0xd20
[ 1650.007129] __rtnl_newlink+0x528/0x7d0
[ 1650.007374] rtnl_newlink+0x43/0x60
[ 1650.007407] rtnetlink_rcv_msg+0x2a2/0x320
[ 1650.007484] netlink_rcv_skb+0xcb/0x100
[ 1650.007519] netlink_unicast+0x17f/0x230
[ 1650.007554] netlink_sendmsg+0x2d2/0x3d0
[ 1650.007592] sock_sendmsg+0x36/0x50
[ 1650.007625] ___sys_sendmsg+0x280/0x2a0
[ 1650.007963] __sys_sendmsg+0x58/0xa0
[ 1650.007998] do_syscall_64+0x5b/0x180
[ 1650.009438] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: c9497c98901c ("net/mlx5: Add support for setting VF min rate")
Cc: Mohamad Haj Yahia <mohamad@...>
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@...>
Reviewed-by: Roi Dayan <roid@...>
Acked-by: Saeed Mahameed <saeedm@...>
Signed-off-by: Saeed Mahameed <saeedm@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/mellanox/mlx5/core/eswitch.c


[linux:lloyd-aviation] By Tonghao Zhang <xiangxia.m.yue@...>:
8c50ab86e288: net/mlx5: Avoid panic when setting vport mac, getting vport config

[ Upstream commit 6e77c413e8e73d0f36b5358b601389d75ec4451c ]

If we try to set VFs mac address on a VF (not PF) net device,
the kernel will be crash. The commands are show as below:

$ echo 2 > /sys/class/net/$MLX_PF0/device/sriov_numvfs
$ ip link set $MLX_VF0 vf 0 mac 00:11:22:33:44:00

[exception RIP: mlx5_eswitch_set_vport_mac+41]
[ffffb8b7079e3688] do_setlink at ffffffff8f67f85b
[ffffb8b7079e37a8] __rtnl_newlink at ffffffff8f683778
[ffffb8b7079e3b68] rtnl_newlink at ffffffff8f683a63
[ffffb8b7079e3b90] rtnetlink_rcv_msg at ffffffff8f67d812
[ffffb8b7079e3c10] netlink_rcv_skb at ffffffff8f6b88ab
[ffffb8b7079e3c60] netlink_unicast at ffffffff8f6b808f
[ffffb8b7079e3ca0] netlink_sendmsg at ffffffff8f6b8412
[ffffb8b7079e3d18] sock_sendmsg at ffffffff8f6452f6
[ffffb8b7079e3d30] ___sys_sendmsg at ffffffff8f645860
[ffffb8b7079e3eb0] __sys_sendmsg at ffffffff8f647a38
[ffffb8b7079e3f38] do_syscall_64 at ffffffff8f00401b
[ffffb8b7079e3f50] entry_SYSCALL_64_after_hwframe at ffffffff8f80008c

and

[exception RIP: mlx5_eswitch_get_vport_config+12]
[ffffa70607e57678] mlx5e_get_vf_config at ffffffffc03c7f8f [mlx5_core]
[ffffa70607e57688] do_setlink at ffffffffbc67fa59
[ffffa70607e577a8] __rtnl_newlink at ffffffffbc683778
[ffffa70607e57b68] rtnl_newlink at ffffffffbc683a63
[ffffa70607e57b90] rtnetlink_rcv_msg at ffffffffbc67d812
[ffffa70607e57c10] netlink_rcv_skb at ffffffffbc6b88ab
[ffffa70607e57c60] netlink_unicast at ffffffffbc6b808f
[ffffa70607e57ca0] netlink_sendmsg at ffffffffbc6b8412
[ffffa70607e57d18] sock_sendmsg at ffffffffbc6452f6
[ffffa70607e57d30] ___sys_sendmsg at ffffffffbc645860
[ffffa70607e57eb0] __sys_sendmsg at ffffffffbc647a38
[ffffa70607e57f38] do_syscall_64 at ffffffffbc00401b
[ffffa70607e57f50] entry_SYSCALL_64_after_hwframe at ffffffffbc80008c

Fixes: a8d70a054a718 ("net/mlx5: E-Switch, Disallow vlan/spoofcheck setup if not being esw manager")
Cc: Eli Cohen <eli@...>
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@...>
Reviewed-by: Roi Dayan <roid@...>
Acked-by: Saeed Mahameed <saeedm@...>
Signed-off-by: Saeed Mahameed <saeedm@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/mellanox/mlx5/core/eswitch.c


[linux:lloyd-aviation] By Russell King <rmk+kernel@...>:
4c96500e3658: gpio: gpio-omap: fix level interrupt idling

[ Upstream commit d01849f7deba81f4959fd9e51bf20dbf46987d1c ]

Tony notes that the GPIO module does not idle when level interrupts are
in use, as the wakeup appears to get stuck.

After extensive investigation, it appears that the wakeup will only be
cleared if the interrupt status register is cleared while the interrupt
is enabled. However, we are currently clearing it with the interrupt
disabled for level-based interrupts.

It is acknowledged that this observed behaviour conflicts with a
statement in the TRM:

CAUTION
After servicing the interrupt, the status bit in the interrupt status
register (GPIOi.GPIO_IRQSTATUS_0 or GPIOi.GPIO_IRQSTATUS_1) must be
reset and the interrupt line released (by setting the corresponding
bit of the interrupt status register to 1) before enabling an
interrupt for the GPIO channel in the interrupt-enable register
(GPIOi.GPIO_IRQSTATUS_SET_0 or GPIOi.GPIO_IRQSTATUS_SET_1) to prevent
the occurrence of unexpected interrupts when enabling an interrupt
for the GPIO channel.

However, this does not appear to be a practical problem.

Further, as reported by Grygorii Strashko <grygorii.strashko@...>,
the TI Android kernel tree has an earlier similar patch as "GPIO: OMAP:
Fix the sequence to clear the IRQ status" saying:

if the status is cleared after disabling the IRQ then sWAKEUP will not
be cleared and gates the module transition

When we unmask the level interrupt after the interrupt has been handled,
enable the interrupt and only then clear the interrupt. If the interrupt
is still pending, the hardware will re-assert the interrupt status.

Should the caution note in the TRM prove to be a problem, we could
use a clear-enable-clear sequence instead.

Cc: Aaro Koskinen <aaro.koskinen@...>
Cc: Keerthy <j-keerthy@...>
Cc: Peter Ujfalusi <peter.ujfalusi@...>
Signed-off-by: Russell King <rmk+kernel@...>
[tony@...: updated comments based on an earlier TI patch]
Signed-off-by: Tony Lindgren <tony@...>
Acked-by: Grygorii Strashko <grygorii.strashko@...>
Signed-off-by: Linus Walleij <linus.walleij@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/gpio/gpio-omap.c


[linux:lloyd-aviation] By Luc Van Oostenryck <luc.vanoostenryck@...>:
d6ad08aa3467: include/linux/relay.h: fix percpu annotation in struct rchan

[ Upstream commit 62461ac2e5b6520b6d65fc6d7d7b4b8df4b848d8 ]

The percpu member of this structure is declared as:
struct ... ** __percpu member;
So its type is:
__percpu pointer to pointer to struct ...

But looking at how it's used, its type should be:
pointer to __percpu pointer to struct ...
and it should thus be declared as:
struct ... * __percpu *member;

So fix the placement of '__percpu' in the definition of this
structures.

This silents a few Sparse's warnings like:
warning: incorrect type in initializer (different address spaces)
expected void const [noderef] <asn:3> *__vpp_verify
got struct sched_domain **

Link: http://lkml.kernel.org/r/20190118144902.79065-1-luc.vanoostenryck@...
Fixes: 017c59c042d01 ("relay: Use per CPU constructs for the relay channel buffer pointers")
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@...>
Cc: Jens Axboe <axboe@...>
Cc: Thomas Gleixner <tglx@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: include/linux/relay.h


[linux:lloyd-aviation] By Christian Brauner <christian@...>:
b227f1571269: sysctl: handle overflow for file-max

[ Upstream commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5 ]

Currently, when writing

echo 18446744073709551616 > /proc/sys/fs/file-max

/proc/sys/fs/file-max will overflow and be set to 0. That quickly
crashes the system.

This commit sets the max and min value for file-max. The max value is
set to long int. Any higher value cannot currently be used as the
percpu counters are long ints and not unsigned integers.

Note that the file-max value is ultimately parsed via
__do_proc_doulongvec_minmax(). This function does not report error when
min or max are exceeded. Which means if a value largen that long int is
written userspace will not receive an error instead the old value will be
kept. There is an argument to be made that this should be changed and
__do_proc_doulongvec_minmax() should return an error when a dedicated min
or max value are exceeded. However this has the potential to break
userspace so let's defer this to an RFC patch.

Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@...
Signed-off-by: Christian Brauner <christian@...>
Acked-by: Kees Cook <keescook@...>
Cc: Alexey Dobriyan <adobriyan@...>
Cc: Al Viro <viro@...>
Cc: Dominik Brodowski <linux@...>
Cc: "Eric W. Biederman" <ebiederm@...>
Cc: Joe Lawrence <joe.lawrence@...>
Cc: Luis Chamberlain <mcgrof@...>
Cc: Waiman Long <longman@...>
[christian@...: v4]
Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@...
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: kernel/sysctl.c


[linux:lloyd-aviation] By Nathan Chancellor <natechancellor@...>:
9ec4860de95a: net: stmmac: Avoid sometimes uninitialized Clang warnings

[ Upstream commit df103170854e87124ee7bdd2bca64b178e653f97 ]

When building with -Wsometimes-uninitialized, Clang warns:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]

Clang is concerned with the use of stmmac_do_void_callback (which
stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
as it may fail to initialize these values if the if condition was ever
false (meaning the callbacks don't exist). It's not wrong because the
callbacks (get_timestamp and config_sub_second_increment respectively)
are the ones that initialize the variables. While it's unlikely that the
callbacks are ever going to disappear and make that condition false, we
can easily avoid this warning by zero initialize the variables.

Link: https://github.com/ClangBuiltLinux/linux/issues/384
Suggested-by: Nick Desaulniers <ndesaulniers@...>
Reviewed-by: Nick Desaulniers <ndesaulniers@...>
Signed-off-by: Nathan Chancellor <natechancellor@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c


[linux:lloyd-aviation] By Arnd Bergmann <arnd@...>:
6048330675cc: enic: fix build warning without CONFIG_CPUMASK_OFFSTACK

[ Upstream commit 43d281662fdb46750d49417559b71069f435298d ]

The enic driver relies on the CONFIG_CPUMASK_OFFSTACK feature to
dynamically allocate a struct member, but this is normally intended for
local variables.

Building with clang, I get a warning for a few locations that check the
address of the cpumask_var_t:

drivers/net/ethernet/cisco/enic/enic_main.c:122:22: error: address of array 'enic->msix[i].affinity_mask' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]

As far as I can tell, the code is still correct, as the truth value of
the pointer is what we need in this configuration. To get rid of
the warning, use cpumask_available() instead of checking the
pointer directly.

Fixes: 322cf7e3a4e8 ("enic: assign affinity hint to interrupts")
Signed-off-by: Arnd Bergmann <arnd@...>
Reviewed-by: Nathan Chancellor <natechancellor@...>
Signed-off-by: David S. Miller <davem@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/ethernet/cisco/enic/enic_main.c


[linux:lloyd-aviation] By Stanislav Fomichev <sdf@...>:
e21f655c60fa: libbpf: force fixdep compilation at the start of the build

[ Upstream commit 8e2688876c7f7073d925e1f150e86b8ed3338f52 ]

libbpf targets don't explicitly depend on fixdep target, so when
we do 'make -j$(nproc)', there is a high probability, that some
objects will be built before fixdep binary is available.

Fix this by running sub-make; this makes sure that fixdep dependency
is properly accounted for.

For the same issue in perf, see commit abb26210a395 ("perf tools: Force
fixdep compilation at the start of the build").

Before:

$ rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld -C tools/lib/bpf/

Auto-detecting system features:
... libelf: [ on ]
... bpf: [ on ]

HOSTCC /tmp/bld/fixdep.o
CC /tmp/bld/libbpf.o
CC /tmp/bld/bpf.o
CC /tmp/bld/btf.o
CC /tmp/bld/nlattr.o
CC /tmp/bld/libbpf_errno.o
CC /tmp/bld/str_error.o
CC /tmp/bld/netlink.o
CC /tmp/bld/bpf_prog_linfo.o
CC /tmp/bld/libbpf_probes.o
CC /tmp/bld/xsk.o
HOSTLD /tmp/bld/fixdep-in.o
LINK /tmp/bld/fixdep
LD /tmp/bld/libbpf-in.o
LINK /tmp/bld/libbpf.a
LINK /tmp/bld/libbpf.so
LINK /tmp/bld/test_libbpf

$ head /tmp/bld/.libbpf.o.cmd
# cannot find fixdep (/usr/local/google/home/sdf/src/linux/xxx//fixdep)
# using basic dep data

/tmp/bld/libbpf.o: libbpf.c /usr/include/stdc-predef.h \
/usr/include/stdlib.h /usr/include/features.h \
/usr/include/x86_64-linux-gnu/sys/cdefs.h \
/usr/include/x86_64-linux-gnu/bits/wordsize.h \
/usr/include/x86_64-linux-gnu/gnu/stubs.h \
/usr/include/x86_64-linux-gnu/gnu/stubs-64.h \
/usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h \

After:

$ rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld -C tools/lib/bpf/

Auto-detecting system features:
... libelf: [ on ]
... bpf: [ on ]

HOSTCC /tmp/bld/fixdep.o
HOSTLD /tmp/bld/fixdep-in.o
LINK /tmp/bld/fixdep
CC /tmp/bld/libbpf.o
CC /tmp/bld/bpf.o
CC /tmp/bld/nlattr.o
CC /tmp/bld/btf.o
CC /tmp/bld/libbpf_errno.o
CC /tmp/bld/str_error.o
CC /tmp/bld/netlink.o
CC /tmp/bld/bpf_prog_linfo.o
CC /tmp/bld/libbpf_probes.o
CC /tmp/bld/xsk.o
LD /tmp/bld/libbpf-in.o
LINK /tmp/bld/libbpf.a
LINK /tmp/bld/libbpf.so
LINK /tmp/bld/test_libbpf

$ head /tmp/bld/.libbpf.o.cmd
cmd_/tmp/bld/libbpf.o := gcc -Wp,-MD,/tmp/bld/.libbpf.o.d -Wp,-MT,/tmp/bld/libbpf.o -g -Wall -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Werror -Wall -fPIC -I. -I/usr/local/google/home/sdf/src/linux/tools/include -I/usr/local/google/home/sdf/src/linux/tools/arch/x86/include/uapi -I/usr/local/google/home/sdf/src/linux/tools/include/uapi -fvisibility=hidden -D"BUILD_STR(s)=$(pound)s" -c -o /tmp/bld/libbpf.o libbpf.c

source_/tmp/bld/libbpf.o := libbpf.c

deps_/tmp/bld/libbpf.o := \
/usr/include/stdc-predef.h \
/usr/include/stdlib.h \
/usr/include/features.h \
/usr/include/x86_64-linux-gnu/sys/cdefs.h \
/usr/include/x86_64-linux-gnu/bits/wordsize.h \

Fixes: 7c422f557266 ("tools build: Build fixdep helper from perf and basic libs")
Reported-by: Eric Dumazet <edumazet@...>
Signed-off-by: Stanislav Fomichev <sdf@...>
Acked-by: Yonghong Song <yhs@...>
Signed-off-by: Daniel Borkmann <daniel@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: tools/lib/bpf/Makefile


[linux:lloyd-aviation] By John Garry <john.garry@...>:
fce6aeaf913e: scsi: hisi_sas: Set PHY linkrate when disconnected

[ Upstream commit efdcad62e7b8a02fcccc5ccca57806dce1482ac8 ]

When the PHY comes down, we currently do not set the negotiated linkrate:

root@(none)$ pwd
/sys/class/sas_phy/phy-0:0
root@(none)$ more enable
1
root@(none)$ more negotiated_linkrate
12.0 Gbit
root@(none)$ echo 0 > enable
root@(none)$ more negotiated_linkrate
12.0 Gbit
root@(none)$

This patch fixes the driver code to set it properly when the PHY comes
down.

If the PHY had been enabled, then set unknown; otherwise, flag as disabled.

The logical place to set the negotiated linkrate for this scenario is PHY
down routine, which is called from the PHY down ISR.

However, it is not possible to know if the PHY comes down due to PHY
disable or loss of link, as sas_phy.enabled member is not set until after
the transport disable routine is complete, which races with the PHY down
ISR.

As an imperfect solution, use sas_phy_data.enable as the flag to know if
the PHY is down due to disable. It's imperfect, as sas_phy_data is internal
to libsas.

I can't see another way without adding a new field to hisi_sas_phy and
managing it, or changing SCSI SAS transport.

Signed-off-by: John Garry <john.garry@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/scsi/hisi_sas/hisi_sas_main.c


[linux:lloyd-aviation] By Xiang Chen <chenxiang66@...>:
e27cced35a4b: scsi: hisi_sas: Fix a timeout race of driver internal and SMP IO

[ Upstream commit 4790595723d4b833b18c994973d39f9efb842887 ]

For internal IO and SMP IO, there is a time-out timer for them. In the
timer handler, it checks whether IO is done according to the flag
task->task_state_lock.

There is an issue which may cause system suspended: internal IO or SMP IO
is sent, but at that time because of hardware exception (such as inject
2Bit ECC error), so IO is not completed and also not timeout. But, at that
time, the SAS controller reset occurs to recover system. It will release
the resource and set the status of IO to be SAS_TASK_STATE_DONE, so when IO
timeout, it will never complete the completion of IO and wait for ever.

[ 729.123632] Call trace:
[ 729.126791] [<ffff00000808655c>] __switch_to+0x94/0xa8
[ 729.133106] [<ffff000008d96e98>] __schedule+0x1e8/0x7fc
[ 729.138975] [<ffff000008d974e0>] schedule+0x34/0x8c
[ 729.144401] [<ffff000008d9b000>] schedule_timeout+0x1d8/0x3cc
[ 729.150690] [<ffff000008d98218>] wait_for_common+0xdc/0x1a0
[ 729.157101] [<ffff000008d98304>] wait_for_completion+0x28/0x34
[ 729.165973] [<ffff000000dcefb4>] hisi_sas_internal_task_abort+0x2a0/0x424 [hisi_sas_test_main]
[ 729.176447] [<ffff000000dd18f4>] hisi_sas_abort_task+0x244/0x2d8 [hisi_sas_test_main]
[ 729.185258] [<ffff000008971714>] sas_eh_handle_sas_errors+0x1c8/0x7b8
[ 729.192391] [<ffff000008972774>] sas_scsi_recover_host+0x130/0x398
[ 729.199237] [<ffff00000894d8a8>] scsi_error_handler+0x148/0x5c0
[ 729.206009] [<ffff0000080f4118>] kthread+0x10c/0x138
[ 729.211563] [<ffff0000080855dc>] ret_from_fork+0x10/0x18

To solve the issue, callback function task_done of those IOs need to be
called when on SAS controller reset.

Signed-off-by: Xiang Chen <chenxiang66@...>
Signed-off-by: John Garry <john.garry@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/scsi/hisi_sas/hisi_sas_main.c


[linux:lloyd-aviation] By Linus Torvalds <torvalds@...>:
3e8d62218aa4: iio: adc: fix warning in Qualcomm PM8xxx HK/XOADC driver

[ Upstream commit e0f0ae838a25464179d37f355d763f9ec139fc15 ]

The pm8xxx_get_channel() implementation is unclear, and causes gcc to
suddenly generate odd warnings. The trigger for the warning (at least
for me) was the entirely unrelated commit 79a4e91d1bb2 ("device.h: Add
__cold to dev_<level> logging functions"), which apparently changes gcc
code generation in the caller function enough to cause this:

drivers/iio/adc/qcom-pm8xxx-xoadc.c: In function ‘pm8xxx_xoadc_probe’:
drivers/iio/adc/qcom-pm8xxx-xoadc.c:633:8: warning: ‘ch’ may be used uninitialized in this function [-Wmaybe-uninitialized]
ret = pm8xxx_read_channel_rsv(adc, ch, AMUX_RSV4,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
&read_nomux_rsv4, true);
~~~~~~~~~~~~~~~~~~~~~~~
drivers/iio/adc/qcom-pm8xxx-xoadc.c:426:27: note: ‘ch’ was declared here
struct pm8xxx_chan_info *ch;
^~

because gcc for some reason then isn't able to see that the termination
condition for the "for( )" loop in that function is also the condition
for returning NULL.

So it's not _actually_ uninitialized, but the function is admittedly
just unnecessarily oddly written.

Simplify and clarify the function, making gcc also see that it always
returns a valid initialized value.

Cc: Joe Perches <joe@...>
Cc: Greg Kroah-Hartman <gregkh@...>
Cc: Andy Gross <andy.gross@...>
Cc: David Brown <david.brown@...>
Cc: Jonathan Cameron <jic23@...>
Cc: Hartmut Knaack <knaack.h@...>
Cc: Lars-Peter Clausen <lars@...>
Cc: Peter Meerwald-Stadler <pmeerw@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/iio/adc/qcom-pm8xxx-xoadc.c


[linux:lloyd-aviation] By Kairui Song <kasong@...>:
c3f28d59c1a5: x86/hyperv: Fix kernel panic when kexec on HyperV

[ Upstream commit 179fb36abb097976997f50733d5b122a29158cba ]

After commit 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments"),
kexec fails with a kernel panic:

kexec_core: Starting new kernel
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v3.0 03/02/2018
RIP: 0010:0xffffc9000001d000

Call Trace:
? __send_ipi_mask+0x1c6/0x2d0
? hv_send_ipi_mask_allbutself+0x6d/0xb0
? mp_save_irq+0x70/0x70
? __ioapic_read_entry+0x32/0x50
? ioapic_read_entry+0x39/0x50
? clear_IO_APIC_pin+0xb8/0x110
? native_stop_other_cpus+0x6e/0x170
? native_machine_shutdown+0x22/0x40
? kernel_kexec+0x136/0x156

That happens if hypercall based IPIs are used because the hypercall page is
reset very early upon kexec reboot, but kexec sends IPIs to stop CPUs,
which invokes the hypercall and dereferences the unusable page.

To fix his, reset hv_hypercall_pg to NULL before the page is reset to avoid
any misuse, IPI sending will fall back to the non hypercall based
method. This only happens on kexec / kdump so just setting the pointer to
NULL is good enough.

Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
Signed-off-by: Kairui Song <kasong@...>
Signed-off-by: Thomas Gleixner <tglx@...>
Cc: "K. Y. Srinivasan" <kys@...>
Cc: Haiyang Zhang <haiyangz@...>
Cc: Stephen Hemminger <sthemmin@...>
Cc: Sasha Levin <sashal@...>
Cc: Borislav Petkov <bp@...>
Cc: "H. Peter Anvin" <hpa@...>
Cc: Vitaly Kuznetsov <vkuznets@...>
Cc: Dave Young <dyoung@...>
Cc: devel@...
Link: https://lkml.kernel.org/r/20190306111827.14131-1-kasong@...
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/x86/hyperv/hv_init.c


[linux:lloyd-aviation] By Jiri Olsa <jolsa@...>:
aea8c971b9c5: perf c2c: Fix c2c report for empty numa node

[ Upstream commit e34c940245437f36d2c492edd1f8237eff391064 ]

Ravi Bangoria reported that we fail with an empty NUMA node with the
following message:

$ lscpu
NUMA node0 CPU(s):
NUMA node1 CPU(s): 0-4

$ sudo ./perf c2c report
node/cpu topology bugFailed setup nodes

Fix this by detecting the empty node and keeping its CPU set empty.

Reported-by: Nageswara R Sastry <nasastry@...>
Signed-off-by: Jiri Olsa <jolsa@...>
Tested-by: Ravi Bangoria <ravi.bangoria@...>
Cc: Alexander Shishkin <alexander.shishkin@...>
Cc: Andi Kleen <ak@...>
Cc: Jonas Rabenstein <jonas.rabenstein@...>
Cc: Namhyung Kim <namhyung@...>
Cc: Peter Zijlstra <peterz@...>
Link: http://lkml.kernel.org/r/20190305152536.21035-2-jolsa@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: tools/perf/builtin-c2c.c


[linux:lloyd-aviation] By Qian Cai <cai@...>:
7b287c47e452: mm/sparse: fix a bad comparison

[ Upstream commit d778015ac95bc036af73342c878ab19250e01fe1 ]

next_present_section_nr() could only return an unsigned number -1, so
just check it specifically where compilers will convert -1 to unsigned
if needed.

mm/sparse.c: In function 'sparse_init_nid':
mm/sparse.c:200:20: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
((section_nr >= 0) && \
^~
mm/sparse.c:478:2: note: in expansion of macro
'for_each_present_section_nr'
for_each_present_section_nr(pnum_begin, pnum) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/sparse.c:200:20: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
((section_nr >= 0) && \
^~
mm/sparse.c:497:2: note: in expansion of macro
'for_each_present_section_nr'
for_each_present_section_nr(pnum_begin, pnum) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/sparse.c: In function 'sparse_init':
mm/sparse.c:200:20: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
((section_nr >= 0) && \
^~
mm/sparse.c:520:2: note: in expansion of macro
'for_each_present_section_nr'
for_each_present_section_nr(pnum_begin + 1, pnum_end) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~

Link: http://lkml.kernel.org/r/20190228181839.86504-1-cai@...
Fixes: c4e1be9ec113 ("mm, sparsemem: break out of loops early")
Signed-off-by: Qian Cai <cai@...>
Reviewed-by: Andrew Morton <akpm@...>
Cc: Dave Hansen <dave.hansen@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/sparse.c


[linux:lloyd-aviation] By Peng Fan <peng.fan@...>:
f555b008c576: mm/cma.c: cma_declare_contiguous: correct err handling

[ Upstream commit 0d3bd18a5efd66097ef58622b898d3139790aa9d ]

In case cma_init_reserved_mem failed, need to free the memblock
allocated by memblock_reserve or memblock_alloc_range.

Quote Catalin's comments:
https://lkml.org/lkml/2019/2/26/482

Kmemleak is supposed to work with the memblock_{alloc,free} pair and it
ignores the memblock_reserve() as a memblock_alloc() implementation
detail. It is, however, tolerant to memblock_free() being called on
a sub-range or just a different range from a previous memblock_alloc().
So the original patch looks fine to me. FWIW:

Link: http://lkml.kernel.org/r/20190227144631.16708-1-peng.fan@...
Signed-off-by: Peng Fan <peng.fan@...>
Reviewed-by: Catalin Marinas <catalin.marinas@...>
Reviewed-by: Mike Rapoport <rppt@...>
Cc: Laura Abbott <labbott@...>
Cc: Joonsoo Kim <iamjoonsoo.kim@...>
Cc: Michal Hocko <mhocko@...>
Cc: Vlastimil Babka <vbabka@...>
Cc: Marek Szyprowski <m.szyprowski@...>
Cc: Andrey Konovalov <andreyknvl@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/cma.c


[linux:lloyd-aviation] By Qian Cai <cai@...>:
4c6d7dc741cb: mm/page_ext.c: fix an imbalance with kmemleak

[ Upstream commit 0c81585499601acd1d0e1cbf424cabfaee60628c ]

After offlining a memory block, kmemleak scan will trigger a crash, as
it encounters a page ext address that has already been freed during
memory offlining. At the beginning in alloc_page_ext(), it calls
kmemleak_alloc(), but it does not call kmemleak_free() in
free_page_ext().

BUG: unable to handle kernel paging request at ffff888453d00000
PGD 128a01067 P4D 128a01067 PUD 128a04067 PMD 47e09e067 PTE 800ffffbac2ff060
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
CPU: 1 PID: 1594 Comm: bash Not tainted 5.0.0-rc8+ #15
Hardware name: HP ProLiant DL180 Gen9/ProLiant DL180 Gen9, BIOS U20 10/25/2017
RIP: 0010:scan_block+0xb5/0x290
Code: 85 6e 01 00 00 48 b8 00 00 30 f5 81 88 ff ff 48 39 c3 0f 84 5b 01 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 0f 85 87 01 00 00 <4c> 8b 3b e8 f3 0c fa ff 4c 39 3d 0c 6b 4c 01 0f 87 08 01 00 00 4c
RSP: 0018:ffff8881ec57f8e0 EFLAGS: 00010082
RAX: 0000000000000000 RBX: ffff888453d00000 RCX: ffffffffa61e5a54
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff888453d00000
RBP: ffff8881ec57f920 R08: fffffbfff4ed588d R09: fffffbfff4ed588c
R10: fffffbfff4ed588c R11: ffffffffa76ac463 R12: dffffc0000000000
R13: ffff888453d00ff9 R14: ffff8881f80cef48 R15: ffff8881f80cef48
FS: 00007f6c0e3f8740(0000) GS:ffff8881f7680000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff888453d00000 CR3: 00000001c4244003 CR4: 00000000001606a0
Call Trace:
scan_gray_list+0x269/0x430
kmemleak_scan+0x5a8/0x10f0
kmemleak_write+0x541/0x6ca
full_proxy_write+0xf8/0x190
__vfs_write+0xeb/0x980
vfs_write+0x15a/0x4f0
ksys_write+0xd2/0x1b0
__x64_sys_write+0x73/0xb0
do_syscall_64+0xeb/0xaaa
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f6c0dad73b8
Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 63 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
RSP: 002b:00007ffd5b863cb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f6c0dad73b8
RDX: 0000000000000005 RSI: 000055a9216e1710 RDI: 0000000000000001
RBP: 000055a9216e1710 R08: 000000000000000a R09: 00007ffd5b863840
R10: 000000000000000a R11: 0000000000000246 R12: 00007f6c0dda9780
R13: 0000000000000005 R14: 00007f6c0dda4740 R15: 0000000000000005
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm irqbypass efivars ip_tables x_tables xfs sd_mod ahci libahci igb i2c_algo_bit libata i2c_core dm_mirror dm_region_hash dm_log dm_mod efivarfs
CR2: ffff888453d00000
---[ end trace ccf646c7456717c5 ]---
Kernel panic - not syncing: Fatal exception
Shutting down cpus with NMI
Kernel Offset: 0x24c00000 from 0xffffffff81000000 (relocation range:
0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---

Link: http://lkml.kernel.org/r/20190227173147.75650-1-cai@...
Signed-off-by: Qian Cai <cai@...>
Reviewed-by: Catalin Marinas <catalin.marinas@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/page_ext.c


[linux:lloyd-aviation] By Daniel Jordan <daniel.m.jordan@...>:
ed3345a6607b: mm, swap: bounds check swap_info array accesses to avoid NULL derefs

[ Upstream commit c10d38cc8d3e43f946b6c2bf4602c86791587f30 ]

Dan Carpenter reports a potential NULL dereference in
get_swap_page_of_type:

Smatch complains that the NULL checks on "si" aren't consistent. This
seems like a real bug because we have not ensured that the type is
valid and so "si" can be NULL.

Add the missing check for NULL, taking care to use a read barrier to
ensure CPU1 observes CPU0's updates in the correct order:

CPU0 CPU1
alloc_swap_info() if (type >= nr_swapfiles)
swap_info[type] = p /* handle invalid entry */
smp_wmb() smp_rmb()
++nr_swapfiles p = swap_info[type]

Without smp_rmb, CPU1 might observe CPU0's write to nr_swapfiles before
CPU0's write to swap_info[type] and read NULL from swap_info[type].

Ying Huang noticed other places in swapfile.c don't order these reads
properly. Introduce swap_type_to_swap_info to encourage correct usage.

Use READ_ONCE and WRITE_ONCE to follow the Linux Kernel Memory Model
(see tools/memory-model/Documentation/explanation.txt).

This ordering need not be enforced in places where swap_lock is held
(e.g. si_swapinfo) because swap_lock serializes updates to nr_swapfiles
and the swap_info array.

Link: http://lkml.kernel.org/r/20190131024410.29859-1-daniel.m.jordan@...
Fixes: ec8acf20afb8 ("swap: add per-partition lock for swapfile")
Signed-off-by: Daniel Jordan <daniel.m.jordan@...>
Reported-by: Dan Carpenter <dan.carpenter@...>
Suggested-by: "Huang, Ying" <ying.huang@...>
Reviewed-by: Andrea Parri <andrea.parri@...>
Acked-by: Peter Zijlstra (Intel) <peterz@...>
Cc: Alan Stern <stern@...>
Cc: Andi Kleen <ak@...>
Cc: Dave Hansen <dave.hansen@...>
Cc: Omar Sandoval <osandov@...>
Cc: Paul McKenney <paulmck@...>
Cc: Shaohua Li <shli@...>
Cc: Stephen Rothwell <sfr@...>
Cc: Tejun Heo <tj@...>
Cc: Will Deacon <will.deacon@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/swapfile.c


[linux:lloyd-aviation] By Tetsuo Handa <penguin-kernel@...>:
eed3ca0a66cf: mm,oom: don't kill global init via memory.oom.group

[ Upstream commit d342a0b38674867ea67fde47b0e1e60ffe9f17a2 ]

Since setting global init process to some memory cgroup is technically
possible, oom_kill_memcg_member() must check it.

Tasks in /test1 are going to be killed due to memory.oom.group set
Memory cgroup out of memory: Killed process 1 (systemd) total-vm:43400kB, anon-rss:1228kB, file-rss:3992kB, shmem-rss:0kB
oom_reaper: reaped process 1 (systemd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000008b

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main(int argc, char *argv[])
{
static char buffer[10485760];
static int pipe_fd[2] = { EOF, EOF };
unsigned int i;
int fd;
char buf[64] = { };
if (pipe(pipe_fd))
return 1;
if (chdir("/sys/fs/cgroup/"))
return 1;
fd = open("cgroup.subtree_control", O_WRONLY);
write(fd, "+memory", 7);
close(fd);
mkdir("test1", 0755);
fd = open("test1/memory.oom.group", O_WRONLY);
write(fd, "1", 1);
close(fd);
fd = open("test1/cgroup.procs", O_WRONLY);
write(fd, "1", 1);
snprintf(buf, sizeof(buf) - 1, "%d", getpid());
write(fd, buf, strlen(buf));
close(fd);
snprintf(buf, sizeof(buf) - 1, "%lu", sizeof(buffer) * 5);
fd = open("test1/memory.max", O_WRONLY);
write(fd, buf, strlen(buf));
close(fd);
for (i = 0; i < 10; i++)
if (fork() == 0) {
char c;
close(pipe_fd[1]);
read(pipe_fd[0], &c, 1);
memset(buffer, 0, sizeof(buffer));
sleep(3);
_exit(0);
}
close(pipe_fd[0]);
close(pipe_fd[1]);
sleep(3);
return 0;
}

[ 37.052923][ T9185] a.out invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
[ 37.056169][ T9185] CPU: 4 PID: 9185 Comm: a.out Kdump: loaded Not tainted 5.0.0-rc4-next-20190131 #280
[ 37.059205][ T9185] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018
[ 37.062954][ T9185] Call Trace:
[ 37.063976][ T9185] dump_stack+0x67/0x95
[ 37.065263][ T9185] dump_header+0x51/0x570
[ 37.066619][ T9185] ? trace_hardirqs_on+0x3f/0x110
[ 37.068171][ T9185] ? _raw_spin_unlock_irqrestore+0x3d/0x70
[ 37.069967][ T9185] oom_kill_process+0x18d/0x210
[ 37.071515][ T9185] out_of_memory+0x11b/0x380
[ 37.072936][ T9185] mem_cgroup_out_of_memory+0xb6/0xd0
[ 37.074601][ T9185] try_charge+0x790/0x820
[ 37.076021][ T9185] mem_cgroup_try_charge+0x42/0x1d0
[ 37.077629][ T9185] mem_cgroup_try_charge_delay+0x11/0x30
[ 37.079370][ T9185] do_anonymous_page+0x105/0x5e0
[ 37.080939][ T9185] __handle_mm_fault+0x9cb/0x1070
[ 37.082485][ T9185] handle_mm_fault+0x1b2/0x3a0
[ 37.083819][ T9185] ? handle_mm_fault+0x47/0x3a0
[ 37.085181][ T9185] __do_page_fault+0x255/0x4c0
[ 37.086529][ T9185] do_page_fault+0x28/0x260
[ 37.087788][ T9185] ? page_fault+0x8/0x30
[ 37.088978][ T9185] page_fault+0x1e/0x30
[ 37.090142][ T9185] RIP: 0033:0x7f8b183aefe0
[ 37.091433][ T9185] Code: 20 f3 44 0f 7f 44 17 d0 f3 44 0f 7f 47 30 f3 44 0f 7f 44 17 c0 48 01 fa 48 83 e2 c0 48 39 d1 74 a3 66 0f 1f 84 00 00 00 00 00 <66> 44 0f 7f 01 66 44 0f 7f 41 10 66 44 0f 7f 41 20 66 44 0f 7f 41
[ 37.096917][ T9185] RSP: 002b:00007fffc5d329e8 EFLAGS: 00010206
[ 37.098615][ T9185] RAX: 00000000006010e0 RBX: 0000000000000008 RCX: 0000000000c30000
[ 37.100905][ T9185] RDX: 00000000010010c0 RSI: 0000000000000000 RDI: 00000000006010e0
[ 37.103349][ T9185] RBP: 0000000000000000 R08: 00007f8b188f4740 R09: 0000000000000000
[ 37.105797][ T9185] R10: 00007fffc5d32420 R11: 00007f8b183aef40 R12: 0000000000000005
[ 37.108228][ T9185] R13: 0000000000000000 R14: ffffffffffffffff R15: 0000000000000000
[ 37.110840][ T9185] memory: usage 51200kB, limit 51200kB, failcnt 125
[ 37.113045][ T9185] memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0
[ 37.115808][ T9185] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
[ 37.117660][ T9185] Memory cgroup stats for /test1: cache:0KB rss:49484KB rss_huge:30720KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:49700KB inactive_file:0KB active_file:0KB unevictable:0KB
[ 37.123371][ T9185] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,oom_memcg=/test1,task_memcg=/test1,task=a.out,pid=9188,uid=0
[ 37.128158][ T9185] Memory cgroup out of memory: Killed process 9188 (a.out) total-vm:14456kB, anon-rss:10324kB, file-rss:504kB, shmem-rss:0kB
[ 37.132710][ T9185] Tasks in /test1 are going to be killed due to memory.oom.group set
[ 37.132833][ T54] oom_reaper: reaped process 9188 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[ 37.135498][ T9185] Memory cgroup out of memory: Killed process 1 (systemd) total-vm:43400kB, anon-rss:1228kB, file-rss:3992kB, shmem-rss:0kB
[ 37.143434][ T9185] Memory cgroup out of memory: Killed process 9182 (a.out) total-vm:14456kB, anon-rss:76kB, file-rss:588kB, shmem-rss:0kB
[ 37.144328][ T54] oom_reaper: reaped process 1 (systemd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[ 37.147585][ T9185] Memory cgroup out of memory: Killed process 9183 (a.out) total-vm:14456kB, anon-rss:6228kB, file-rss:512kB, shmem-rss:0kB
[ 37.157222][ T9185] Memory cgroup out of memory: Killed process 9184 (a.out) total-vm:14456kB, anon-rss:6228kB, file-rss:508kB, shmem-rss:0kB
[ 37.157259][ T9185] Memory cgroup out of memory: Killed process 9185 (a.out) total-vm:14456kB, anon-rss:6228kB, file-rss:512kB, shmem-rss:0kB
[ 37.157291][ T9185] Memory cgroup out of memory: Killed process 9186 (a.out) total-vm:14456kB, anon-rss:4180kB, file-rss:508kB, shmem-rss:0kB
[ 37.157306][ T54] oom_reaper: reaped process 9183 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[ 37.157328][ T9185] Memory cgroup out of memory: Killed process 9187 (a.out) total-vm:14456kB, anon-rss:4180kB, file-rss:512kB, shmem-rss:0kB
[ 37.157452][ T9185] Memory cgroup out of memory: Killed process 9189 (a.out) total-vm:14456kB, anon-rss:6228kB, file-rss:512kB, shmem-rss:0kB
[ 37.158733][ T9185] Memory cgroup out of memory: Killed process 9190 (a.out) total-vm:14456kB, anon-rss:552kB, file-rss:512kB, shmem-rss:0kB
[ 37.160083][ T54] oom_reaper: reaped process 9186 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[ 37.160187][ T54] oom_reaper: reaped process 9189 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[ 37.206941][ T54] oom_reaper: reaped process 9185 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[ 37.212300][ T9185] Memory cgroup out of memory: Killed process 9191 (a.out) total-vm:14456kB, anon-rss:4180kB, file-rss:512kB, shmem-rss:0kB
[ 37.212317][ T54] oom_reaper: reaped process 9190 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[ 37.218860][ T9185] Memory cgroup out of memory: Killed process 9192 (a.out) total-vm:14456kB, anon-rss:1080kB, file-rss:512kB, shmem-rss:0kB
[ 37.227667][ T54] oom_reaper: reaped process 9192 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[ 37.292323][ T9193] abrt-hook-ccpp (9193) used greatest stack depth: 10480 bytes left
[ 37.351843][ T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000008b
[ 37.354833][ T1] CPU: 7 PID: 1 Comm: systemd Kdump: loaded Not tainted 5.0.0-rc4-next-20190131 #280
[ 37.357876][ T1] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018
[ 37.361685][ T1] Call Trace:
[ 37.363239][ T1] dump_stack+0x67/0x95
[ 37.365010][ T1] panic+0xfc/0x2b0
[ 37.366853][ T1] do_exit+0xd55/0xd60
[ 37.368595][ T1] do_group_exit+0x47/0xc0
[ 37.370415][ T1] get_signal+0x32a/0x920
[ 37.372449][ T1] ? _raw_spin_unlock_irqrestore+0x3d/0x70
[ 37.374596][ T1] do_signal+0x32/0x6e0
[ 37.376430][ T1] ? exit_to_usermode_loop+0x26/0x9b
[ 37.378418][ T1] ? prepare_exit_to_usermode+0xa8/0xd0
[ 37.380571][ T1] exit_to_usermode_loop+0x3e/0x9b
[ 37.382588][ T1] prepare_exit_to_usermode+0xa8/0xd0
[ 37.384594][ T1] ? page_fault+0x8/0x30
[ 37.386453][ T1] retint_user+0x8/0x18
[ 37.388160][ T1] RIP: 0033:0x7f42c06974a8
[ 37.389922][ T1] Code: Bad RIP value.
[ 37.391788][ T1] RSP: 002b:00007ffc3effd388 EFLAGS: 00010213
[ 37.394075][ T1] RAX: 000000000000000e RBX: 00007ffc3effd390 RCX: 0000000000000000
[ 37.396963][ T1] RDX: 000000000000002a RSI: 00007ffc3effd390 RDI: 0000000000000004
[ 37.399550][ T1] RBP: 00007ffc3effd680 R08: 0000000000000000 R09: 0000000000000000
[ 37.402334][ T1] R10: 00000000ffffffff R11: 0000000000000246 R12: 0000000000000001
[ 37.404890][ T1] R13: ffffffffffffffff R14: 0000000000000884 R15: 000056460b1ac3b0

Link: http://lkml.kernel.org/r/201902010336.x113a4EO027170@...
Fixes: 3d8b38eb81cac813 ("mm, oom: introduce memory.oom.group")
Signed-off-by: Tetsuo Handa <penguin-kernel@...>
Acked-by: Michal Hocko <mhocko@...>
Cc: Roman Gushchin <guro@...>
Cc: Johannes Weiner <hannes@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/oom_kill.c


[linux:lloyd-aviation] By Tetsuo Handa <penguin-kernel@...>:
9d785b92cf0d: memcg: killed threads should not invoke memcg OOM killer

[ Upstream commit 7775face207922ea62a4e96b9cd45abfdc7b9840 ]

If a memory cgroup contains a single process with many threads
(including different process group sharing the mm) then it is possible
to trigger a race when the oom killer complains that there are no oom
elible tasks and complain into the log which is both annoying and
confusing because there is no actual problem. The race looks as
follows:

P1 oom_reaper P2
try_charge try_charge
mem_cgroup_out_of_memory
mutex_lock(oom_lock)
out_of_memory
oom_kill_process(P1,P2)
wake_oom_reaper
mutex_unlock(oom_lock)
oom_reap_task
mutex_lock(oom_lock)
select_bad_process # no victim

The problem is more visible with many threads.

Fix this by checking for fatal_signal_pending from
mem_cgroup_out_of_memory when the oom_lock is already held.

The oom bypass is safe because we do the same early in the try_charge
path already. The situation migh have changed in the mean time. It
should be safe to check for fatal_signal_pending and tsk_is_oom_victim
but for a better code readability abstract the current charge bypass
condition into should_force_charge and reuse it from that path. "

Link: http://lkml.kernel.org/r/01370f70-e1f6-ebe4-b95e-0df21a0bc15e@...
Signed-off-by: Tetsuo Handa <penguin-kernel@...>
Acked-by: Michal Hocko <mhocko@...>
Acked-by: Johannes Weiner <hannes@...>
Cc: David Rientjes <rientjes@...>
Cc: Kirill Tkhai <ktkhai@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/memcontrol.c


[linux:lloyd-aviation] By Vlastimil Babka <vbabka@...>:
67abbb9c5422: mm, mempolicy: fix uninit memory access

[ Upstream commit 2e25644e8da4ed3a27e7b8315aaae74660be72dc ]

Syzbot with KMSAN reports (excerpt):

==================================================================
BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline]
BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384
CPU: 1 PID: 17420 Comm: syz-executor4 Not tainted 4.20.0-rc7+ #15
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x173/0x1d0 lib/dump_stack.c:113
kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
__msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:295
mpol_rebind_policy mm/mempolicy.c:353 [inline]
mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384
update_tasks_nodemask+0x608/0xca0 kernel/cgroup/cpuset.c:1120
update_nodemasks_hier kernel/cgroup/cpuset.c:1185 [inline]
update_nodemask kernel/cgroup/cpuset.c:1253 [inline]
cpuset_write_resmask+0x2a98/0x34b0 kernel/cgroup/cpuset.c:1728

...

Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158
kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176
kmem_cache_alloc+0x572/0xb90 mm/slub.c:2777
mpol_new mm/mempolicy.c:276 [inline]
do_mbind mm/mempolicy.c:1180 [inline]
kernel_mbind+0x8a7/0x31a0 mm/mempolicy.c:1347
__do_sys_mbind mm/mempolicy.c:1354 [inline]

As it's difficult to report where exactly the uninit value resides in
the mempolicy object, we have to guess a bit. mm/mempolicy.c:353
contains this part of mpol_rebind_policy():

if (!mpol_store_user_nodemask(pol) &&
nodes_equal(pol->w.cpuset_mems_allowed, *newmask))

"mpol_store_user_nodemask(pol)" is testing pol->flags, which I couldn't
ever see being uninitialized after leaving mpol_new(). So I'll guess
it's actually about accessing pol->w.cpuset_mems_allowed on line 354,
but still part of statement starting on line 353.

For w.cpuset_mems_allowed to be not initialized, and the nodes_equal()
reachable for a mempolicy where mpol_set_nodemask() is called in
do_mbind(), it seems the only possibility is a MPOL_PREFERRED policy
with empty set of nodes, i.e. MPOL_LOCAL equivalent, with MPOL_F_LOCAL
flag. Let's exclude such policies from the nodes_equal() check. Note
the uninit access should be benign anyway, as rebinding this kind of
policy is always a no-op. Therefore no actual need for stable
inclusion.

Link: http://lkml.kernel.org/r/a71997c3-e8ae-a787-d5ce-3db05768b27c@...
Link: http://lkml.kernel.org/r/73da3e9c-cc84-509e-17d9-0c434bb9967d@...
Signed-off-by: Vlastimil Babka <vbabka@...>
Reported-by: syzbot+b19c2dc2c990ea657a71@...
Cc: Alexander Potapenko <glider@...>
Cc: Dmitry Vyukov <dvyukov@...>
Cc: Andrea Arcangeli <aarcange@...>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...>
Cc: Michal Hocko <mhocko@...>
Cc: David Rientjes <rientjes@...>
Cc: Yisheng Xie <xieyisheng1@...>
Cc: zhong jiang <zhongjiang@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/mempolicy.c


[linux:lloyd-aviation] By Uladzislau Rezki (Sony) <urezki@...>:
8a0fc62e331e: mm/vmalloc.c: fix kernel BUG at mm/vmalloc.c:512!

[ Upstream commit afd07389d3f4933c7f7817a92fb5e053d59a3182 ]

One of the vmalloc stress test case triggers the kernel BUG():

<snip>
[60.562151] ------------[ cut here ]------------
[60.562154] kernel BUG at mm/vmalloc.c:512!
[60.562206] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[60.562247] CPU: 0 PID: 430 Comm: vmalloc_test/0 Not tainted 4.20.0+ #161
[60.562293] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[60.562351] RIP: 0010:alloc_vmap_area+0x36f/0x390
<snip>

it can happen due to big align request resulting in overflowing of
calculated address, i.e. it becomes 0 after ALIGN()'s fixup.

Fix it by checking if calculated address is within vstart/vend range.

Link: http://lkml.kernel.org/r/20190124115648.9433-2-urezki@...
Signed-off-by: Uladzislau Rezki (Sony) <urezki@...>
Reviewed-by: Andrew Morton <akpm@...>
Cc: Ingo Molnar <mingo@...>
Cc: Joel Fernandes <joelaf@...>
Cc: Matthew Wilcox <willy@...>
Cc: Michal Hocko <mhocko@...>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@...>
Cc: Steven Rostedt <rostedt@...>
Cc: Tejun Heo <tj@...>
Cc: Thomas Garnier <thgarnie@...>
Cc: Thomas Gleixner <tglx@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/vmalloc.c


[linux:lloyd-aviation] By Qian Cai <cai@...>:
f09c424cea9f: mm/slab.c: kmemleak no scan alien caches

[ Upstream commit 92d1d07daad65c300c7d0b68bbef8867e9895d54 ]

Kmemleak throws endless warnings during boot due to in
__alloc_alien_cache(),

alc = kmalloc_node(memsize, gfp, node);
init_arraycache(&alc->ac, entries, batch);
kmemleak_no_scan(ac);

Kmemleak does not track the array cache (alc->ac) but the alien cache
(alc) instead, so let it track the latter by lifting kmemleak_no_scan()
out of init_arraycache().

There is another place that calls init_arraycache(), but
alloc_kmem_cache_cpus() uses the percpu allocation where will never be
considered as a leak.

kmemleak: Found object by alias at 0xffff8007b9aa7e38
CPU: 190 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2+ #2
Call trace:
dump_backtrace+0x0/0x168
show_stack+0x24/0x30
dump_stack+0x88/0xb0
lookup_object+0x84/0xac
find_and_get_object+0x84/0xe4
kmemleak_no_scan+0x74/0xf4
setup_kmem_cache_node+0x2b4/0x35c
__do_tune_cpucache+0x250/0x2d4
do_tune_cpucache+0x4c/0xe4
enable_cpucache+0xc8/0x110
setup_cpu_cache+0x40/0x1b8
__kmem_cache_create+0x240/0x358
create_cache+0xc0/0x198
kmem_cache_create_usercopy+0x158/0x20c
kmem_cache_create+0x50/0x64
fsnotify_init+0x58/0x6c
do_one_initcall+0x194/0x388
kernel_init_freeable+0x668/0x688
kernel_init+0x18/0x124
ret_from_fork+0x10/0x18
kmemleak: Object 0xffff8007b9aa7e00 (size 256):
kmemleak: comm "swapper/0", pid 1, jiffies 4294697137
kmemleak: min_count = 1
kmemleak: count = 0
kmemleak: flags = 0x1
kmemleak: checksum = 0
kmemleak: backtrace:
kmemleak_alloc+0x84/0xb8
kmem_cache_alloc_node_trace+0x31c/0x3a0
__kmalloc_node+0x58/0x78
setup_kmem_cache_node+0x26c/0x35c
__do_tune_cpucache+0x250/0x2d4
do_tune_cpucache+0x4c/0xe4
enable_cpucache+0xc8/0x110
setup_cpu_cache+0x40/0x1b8
__kmem_cache_create+0x240/0x358
create_cache+0xc0/0x198
kmem_cache_create_usercopy+0x158/0x20c
kmem_cache_create+0x50/0x64
fsnotify_init+0x58/0x6c
do_one_initcall+0x194/0x388
kernel_init_freeable+0x668/0x688
kernel_init+0x18/0x124
kmemleak: Not scanning unknown object at 0xffff8007b9aa7e38
CPU: 190 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2+ #2
Call trace:
dump_backtrace+0x0/0x168
show_stack+0x24/0x30
dump_stack+0x88/0xb0
kmemleak_no_scan+0x90/0xf4
setup_kmem_cache_node+0x2b4/0x35c
__do_tune_cpucache+0x250/0x2d4
do_tune_cpucache+0x4c/0xe4
enable_cpucache+0xc8/0x110
setup_cpu_cache+0x40/0x1b8
__kmem_cache_create+0x240/0x358
create_cache+0xc0/0x198
kmem_cache_create_usercopy+0x158/0x20c
kmem_cache_create+0x50/0x64
fsnotify_init+0x58/0x6c
do_one_initcall+0x194/0x388
kernel_init_freeable+0x668/0x688
kernel_init+0x18/0x124
ret_from_fork+0x10/0x18

Link: http://lkml.kernel.org/r/20190129184518.39808-1-cai@...
Fixes: 1fe00d50a9e8 ("slab: factor out initialization of array cache")
Signed-off-by: Qian Cai <cai@...>
Reviewed-by: Andrew Morton <akpm@...>
Cc: Christoph Lameter <cl@...>
Cc: Pekka Enberg <penberg@...>
Cc: David Rientjes <rientjes@...>
Cc: Joonsoo Kim <iamjoonsoo.kim@...>
Cc: Catalin Marinas <catalin.marinas@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/slab.c


[linux:lloyd-aviation] By Jia Guo <guojia12@...>:
20141feb9bde: ocfs2: fix a panic problem caused by o2cb_ctl

[ Upstream commit cc725ef3cb202ef2019a3c67c8913efa05c3cce6 ]

In the process of creating a node, it will cause NULL pointer
dereference in kernel if o2cb_ctl failed in the interval (mkdir,
o2cb_set_node_attribute(node_num)] in function o2cb_add_node.

The node num is initialized to 0 in function o2nm_node_group_make_item,
o2nm_node_group_drop_item will mistake the node number 0 for a valid
node number when we delete the node before the node number is set
correctly. If the local node number of the current host happens to be
0, cluster->cl_local_node will be set to O2NM_INVALID_NODE_NUM while
o2hb_thread still running. The panic stack is generated as follows:

o2hb_thread
\-o2hb_do_disk_heartbeat
\-o2hb_check_own_slot
|-slot = &reg->hr_slots[o2nm_this_node()];
//o2nm_this_node() return O2NM_INVALID_NODE_NUM

We need to check whether the node number is set when we delete the node.

Link: http://lkml.kernel.org/r/133d8045-72cc-863e-8eae-5013f9f6bc51@...
Signed-off-by: Jia Guo <guojia12@...>
Reviewed-by: Joseph Qi <jiangqi903@...>
Acked-by: Jun Piao <piaojun@...>
Cc: Mark Fasheh <mark@...>
Cc: Joel Becker <jlbec@...>
Cc: Junxiao Bi <junxiao.bi@...>
Cc: Changwei Ge <ge.changwei@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/ocfs2/cluster/nodemanager.c


[linux:lloyd-aviation] By Sahitya Tummala <stummala@...>:
9b4f27667402: f2fs: do not use mutex lock in atomic context

[ Upstream commit 9083977dabf3833298ddcd40dee28687f1e6b483 ]

Fix below warning coming because of using mutex lock in atomic context.

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:98
in_atomic(): 1, irqs_disabled(): 0, pid: 585, name: sh
Preemption disabled at: __radix_tree_preload+0x28/0x130
Call trace:
dump_backtrace+0x0/0x2b4
show_stack+0x20/0x28
dump_stack+0xa8/0xe0
___might_sleep+0x144/0x194
__might_sleep+0x58/0x8c
mutex_lock+0x2c/0x48
f2fs_trace_pid+0x88/0x14c
f2fs_set_node_page_dirty+0xd0/0x184

Do not use f2fs_radix_tree_insert() to avoid doing cond_resched() with
spin_lock() acquired.

Signed-off-by: Sahitya Tummala <stummala@...>
Reviewed-by: Chao Yu <yuchao0@...>
Signed-off-by: Jaegeuk Kim <jaegeuk@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/f2fs/trace.c


[linux:lloyd-aviation] By Shuriyc Chu <sureeju@...>:
d609ecd887f8: fs/file.c: initialize init_files.resize_wait

[ Upstream commit 5704a06810682683355624923547b41540e2801a ]

(Taken from https://bugzilla.kernel.org/show_bug.cgi?id=200647)

'get_unused_fd_flags' in kthread cause kernel crash. It works fine on
4.1, but causes crash after get 64 fds. It also cause crash on
ubuntu1404/1604/1804, centos7.5, and the crash messages are almost the
same.

The crash message on centos7.5 shows below:

start fd 61
start fd 62
start fd 63
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: __wake_up_common+0x2e/0x90
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: test(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter devlink sunrpc kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd sg ppdev pcspkr virtio_balloon parport_pc parport i2c_piix4 joydev ip_tables xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi virtio_scsi virtio_console virtio_net cirrus drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crct10dif_pclmul crct10dif_common crc32c_intel drm ata_piix serio_raw libata virtio_pci virtio_ring i2c_core
virtio floppy dm_mirror dm_region_hash dm_log dm_mod
CPU: 2 PID: 1820 Comm: test_fd Kdump: loaded Tainted: G OE ------------ 3.10.0-862.3.3.el7.x86_64 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
task: ffff8e92b9431fa0 ti: ffff8e94247a0000 task.ti: ffff8e94247a0000
RIP: 0010:__wake_up_common+0x2e/0x90
RSP: 0018:ffff8e94247a2d18 EFLAGS: 00010086
RAX: 0000000000000000 RBX: ffffffff9d09daa0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffff9d09daa0
RBP: ffff8e94247a2d50 R08: 0000000000000000 R09: ffff8e92b95dfda8
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9d09daa8
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8e9434e80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000017c686000 CR4: 00000000000207e0
Call Trace:
__wake_up+0x39/0x50
expand_files+0x131/0x250
__alloc_fd+0x47/0x170
get_unused_fd_flags+0x30/0x40
test_fd+0x12a/0x1c0 [test]
kthread+0xd1/0xe0
ret_from_fork_nospec_begin+0x21/0x21
Code: 66 90 55 48 89 e5 41 57 41 89 f7 41 56 41 89 ce 41 55 41 54 49 89 fc 49 83 c4 08 53 48 83 ec 10 48 8b 47 08 89 55 cc 4c 89 45 d0 <48> 8b 08 49 39 c4 48 8d 78 e8 4c 8d 69 e8 75 08 eb 3b 4c 89 ef
RIP __wake_up_common+0x2e/0x90
RSP <ffff8e94247a2d18>
CR2: 0000000000000000

This issue exists since CentOS 7.5 3.10.0-862 and CentOS 7.4
(3.10.0-693.21.1 ) is ok. Root cause: the item 'resize_wait' is not
initialized before being used.

Reported-by: Richard Zhang <zhang.zijian@...>
Reviewed-by: Andrew Morton <akpm@...>
Cc: Al Viro <viro@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/file.c


[linux:lloyd-aviation] By Qian Cai <cai@...>:
a6c56bf63e87: page_poison: play nicely with KASAN

[ Upstream commit 4117992df66a26fa33908b4969e04801534baab1 ]

KASAN does not play well with the page poisoning (CONFIG_PAGE_POISONING).
It triggers false positives in the allocation path:

BUG: KASAN: use-after-free in memchr_inv+0x2ea/0x330
Read of size 8 at addr ffff88881f800000 by task swapper/0
CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1+ #54
Call Trace:
dump_stack+0xe0/0x19a
print_address_description.cold.2+0x9/0x28b
kasan_report.cold.3+0x7a/0xb5
__asan_report_load8_noabort+0x19/0x20
memchr_inv+0x2ea/0x330
kernel_poison_pages+0x103/0x3d5
get_page_from_freelist+0x15e7/0x4d90

because KASAN has not yet unpoisoned the shadow page for allocation
before it checks memchr_inv() but only found a stale poison pattern.

Also, false positives in free path,

BUG: KASAN: slab-out-of-bounds in kernel_poison_pages+0x29e/0x3d5
Write of size 4096 at addr ffff8888112cc000 by task swapper/0/1
CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc1+ #55
Call Trace:
dump_stack+0xe0/0x19a
print_address_description.cold.2+0x9/0x28b
kasan_report.cold.3+0x7a/0xb5
check_memory_region+0x22d/0x250
memset+0x28/0x40
kernel_poison_pages+0x29e/0x3d5
__free_pages_ok+0x75f/0x13e0

due to KASAN adds poisoned redzones around slab objects, but the page
poisoning needs to poison the whole page.

Link: http://lkml.kernel.org/r/20190114233405.67843-1-cai@...
Signed-off-by: Qian Cai <cai@...>
Acked-by: Andrey Ryabinin <aryabinin@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: mm/page_alloc.c
Modified: mm/page_poison.c


[linux:lloyd-aviation] By Louis Taylor <louis@...>:
626d98bbdb30: cifs: use correct format characters

[ Upstream commit 259594bea574e515a148171b5cd84ce5cbdc028a ]

When compiling with -Wformat, clang emits the following warnings:

fs/cifs/smb1ops.c:312:20: warning: format specifies type 'unsigned
short' but the argument has type 'unsigned int' [-Wformat]
tgt_total_cnt, total_in_tgt);
^~~~~~~~~~~~

fs/cifs/cifs_dfs_ref.c:289:4: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
ref->flags, ref->server_type);
^~~~~~~~~~

fs/cifs/cifs_dfs_ref.c:289:16: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
ref->flags, ref->server_type);
^~~~~~~~~~~~~~~~

fs/cifs/cifs_dfs_ref.c:291:4: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
ref->ref_flag, ref->path_consumed);
^~~~~~~~~~~~~

fs/cifs/cifs_dfs_ref.c:291:19: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
ref->ref_flag, ref->path_consumed);
^~~~~~~~~~~~~~~~~~
The types of these arguments are unconditionally defined, so this patch
updates the format character to the correct ones for ints and unsigned
ints.

Link: https://github.com/ClangBuiltLinux/linux/issues/378

Signed-off-by: Louis Taylor <louis@...>
Signed-off-by: Steve French <stfrench@...>
Reviewed-by: Nick Desaulniers <ndesaulniers@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/cifs/cifs_dfs_ref.c
Modified: fs/cifs/smb1ops.c


[linux:lloyd-aviation] By Jason Cai (Xiang Feng) <jason.cai.kern@...>:
8c81fcd3d5c1: dm thin: add sanity checks to thin-pool and external snapshot creation

[ Upstream commit 70de2cbda8a5d788284469e755f8b097d339c240 ]

Invoking dm_get_device() twice on the same device path with different
modes is dangerous. Because in that case, upgrade_mode() will alloc a
new 'dm_dev' and free the old one, which may be referenced by a previous
caller. Dereferencing the dangling pointer will trigger kernel NULL
pointer dereference.

The following two cases can reproduce this issue. Actually, they are
invalid setups that must be disallowed, e.g.:

1. Creating a thin-pool with read_only mode, and the same device as
both metadata and data.

dmsetup create thinp --table \
"0 41943040 thin-pool /dev/vdb /dev/vdb 128 0 1 read_only"

BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
...
Call Trace:
new_read+0xfb/0x110 [dm_bufio]
dm_bm_read_lock+0x43/0x190 [dm_persistent_data]
? kmem_cache_alloc_trace+0x15c/0x1e0
__create_persistent_data_objects+0x65/0x3e0 [dm_thin_pool]
dm_pool_metadata_open+0x8c/0xf0 [dm_thin_pool]
pool_ctr.cold.79+0x213/0x913 [dm_thin_pool]
? realloc_argv+0x50/0x70 [dm_mod]
dm_table_add_target+0x14e/0x330 [dm_mod]
table_load+0x122/0x2e0 [dm_mod]
? dev_status+0x40/0x40 [dm_mod]
ctl_ioctl+0x1aa/0x3e0 [dm_mod]
dm_ctl_ioctl+0xa/0x10 [dm_mod]
do_vfs_ioctl+0xa2/0x600
? handle_mm_fault+0xda/0x200
? __do_page_fault+0x26c/0x4f0
ksys_ioctl+0x60/0x90
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x55/0x150
entry_SYSCALL_64_after_hwframe+0x44/0xa9

2. Creating a external snapshot using the same thin-pool device.

dmsetup create thinp --table \
"0 41943040 thin-pool /dev/vdc /dev/vdb 128 0 2 ignore_discard"
dmsetup message /dev/mapper/thinp 0 "create_thin 0"
dmsetup create snap --table \
"0 204800 thin /dev/mapper/thinp 0 /dev/mapper/thinp"

BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
...
Call Trace:
? __alloc_pages_nodemask+0x13c/0x2e0
retrieve_status+0xa5/0x1f0 [dm_mod]
? dm_get_live_or_inactive_table.isra.7+0x20/0x20 [dm_mod]
table_status+0x61/0xa0 [dm_mod]
ctl_ioctl+0x1aa/0x3e0 [dm_mod]
dm_ctl_ioctl+0xa/0x10 [dm_mod]
do_vfs_ioctl+0xa2/0x600
ksys_ioctl+0x60/0x90
? ksys_write+0x4f/0xb0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x55/0x150
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Jason Cai (Xiang Feng) <jason.cai@...>
Signed-off-by: Mike Snitzer <snitzer@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/md/dm-thin.c


[linux:lloyd-aviation] By Chao Yu <yuchao0@...>:
4ab78f4d75c6: f2fs: fix to check inline_xattr_size boundary correctly

[ Upstream commit 500e0b28ecd3c5aade98f3c3a339d18dcb166bb6 ]

We use below condition to check inline_xattr_size boundary:

if (!F2FS_OPTION(sbi).inline_xattr_size ||
F2FS_OPTION(sbi).inline_xattr_size >=
DEF_ADDRS_PER_INODE -
F2FS_TOTAL_EXTRA_ATTR_SIZE -
DEF_INLINE_RESERVED_SIZE -
DEF_MIN_INLINE_SIZE)

There is there problems in that check:
- we should allow inline_xattr_size equaling to min size of inline
{data,dentry} area.
- F2FS_TOTAL_EXTRA_ATTR_SIZE and inline_xattr_size are based on
different size unit, previous one is 4 bytes, latter one is 1 bytes.
- DEF_MIN_INLINE_SIZE only indicate min size of inline data area,
however, we need to consider min size of inline dentry area as well,
minimal inline dentry should at least contain two entries: '.' and
'..', so that min inline_dentry size is 40 bytes.

.bitmap 1 * 1 = 1
.reserved 1 * 1 = 1
.dentry 11 * 2 = 22
.filename 8 * 2 = 16
total 40

Signed-off-by: Chao Yu <yuchao0@...>
Signed-off-by: Jaegeuk Kim <jaegeuk@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/f2fs/f2fs.h
Modified: fs/f2fs/super.c
Modified: include/linux/f2fs_fs.h


[linux:lloyd-aviation] By Namjae Jeon <linkinjeon@...>:
d579b4eae836: cifs: Accept validate negotiate if server return NT_STATUS_NOT_SUPPORTED

[ Upstream commit 969ae8e8d4ee54c99134d3895f2adf96047f5bee ]

Old windows version or Netapp SMB server will return
NT_STATUS_NOT_SUPPORTED since they do not allow or implement
FSCTL_VALIDATE_NEGOTIATE_INFO. The client should accept the response
provided it's properly signed.

See
https://blogs.msdn.microsoft.com/openspecification/2012/06/28/smb3-secure-dialect-negotiation/

and

MS-SMB2 validate negotiate response processing:
https://msdn.microsoft.com/en-us/library/hh880630.aspx

Samba client had already handled it.
https://bugzilla.samba.org/attachment.cgi?id=13285&action=edit

Signed-off-by: Namjae Jeon <linkinjeon@...>
Signed-off-by: Steve French <stfrench@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/cifs/smb2pdu.c


[linux:lloyd-aviation] By Yao Liu <yotta.liu@...>:
36a3219e617a: cifs: Fix NULL pointer dereference of devname

[ Upstream commit 68e2672f8fbd1e04982b8d2798dd318bf2515dd2 ]

There is a NULL pointer dereference of devname in strspn()

The oops looks something like:

CIFS: Attempting to mount (null)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
...
RIP: 0010:strspn+0x0/0x50
...
Call Trace:
? cifs_parse_mount_options+0x222/0x1710 [cifs]
? cifs_get_volume_info+0x2f/0x80 [cifs]
cifs_setup_volume_info+0x20/0x190 [cifs]
cifs_get_volume_info+0x50/0x80 [cifs]
cifs_smb3_do_mount+0x59/0x630 [cifs]
? ida_alloc_range+0x34b/0x3d0
cifs_do_mount+0x11/0x20 [cifs]
mount_fs+0x52/0x170
vfs_kern_mount+0x6b/0x170
do_mount+0x216/0xdc0
ksys_mount+0x83/0xd0
__x64_sys_mount+0x25/0x30
do_syscall_64+0x65/0x220
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fix this by adding a NULL check on devname in cifs_parse_devname()

Signed-off-by: Yao Liu <yotta.liu@...>
Signed-off-by: Steve French <stfrench@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/cifs/connect.c


[linux:lloyd-aviation] By Li RongQing <lirongqing@...>:
709aaa09b200: netfilter: nf_tables: check the result of dereferencing base_chain->stats

[ Upstream commit a9f5e78c403d2d62ade4f4c85040efc85f4049b8 ]

Check the result of dereferencing base_chain->stats, instead of result
of this_cpu_ptr with NULL.

base_chain->stats maybe be changed to NULL when a chain is updated and a
new NULL counter can be attached.

And we do not need to check returning of this_cpu_ptr since
base_chain->stats is from percpu allocator if it is non-NULL,
this_cpu_ptr returns a valid value.

And fix two sparse error by replacing rcu_access_pointer and
rcu_dereference with READ_ONCE under rcu_read_lock.

Thanks for Eric's help to finish this patch.

Fixes: 009240940e84c1 ("netfilter: nf_tables: don't assume chain stats are set when jumplabel is set")
Signed-off-by: Eric Dumazet <eric.dumazet@...>
Signed-off-by: Zhang Yu <zhangyu31@...>
Signed-off-by: Li RongQing <lirongqing@...>
Signed-off-by: Pablo Neira Ayuso <pablo@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/netfilter/nf_tables_core.c


[linux:lloyd-aviation] By Florian Westphal <fw@...>:
ca66f667189c: netfilter: conntrack: tcp: only close if RST matches exact sequence

[ Upstream commit be0502a3f2e94211a8809a09ecbc3a017189b8fb ]

TCP resets cause instant transition from established to closed state
provided the reset is in-window. Endpoints that implement RFC 5961
require resets to match the next expected sequence number.
RST segments that are in-window (but that do not match RCV.NXT) are
ignored, and a "challenge ACK" is sent back.

Main problem for conntrack is that its a middlebox, i.e. whereas an end
host might have ACK'd SEQ (and would thus accept an RST with this
sequence number), conntrack might not have seen this ACK (yet).

Therefore we can't simply flag RSTs with non-exact match as invalid.

This updates RST processing as follows:

1. If the connection is in a state other than ESTABLISHED, nothing is
changed, RST is subject to normal in-window check.

2. If the RSTs sequence number either matches exactly RCV.NXT,
connection state moves to CLOSE.

3. The same applies if the RST sequence number aligns with a previous
packet in the same direction.

In all other cases, the connection remains in ESTABLISHED state.
If the normal-in-window check passes, the timeout will be lowered
to that of CLOSE.

If the peer sends a challenge ack, connection timeout will be reset.

If the challenge ACK triggers another RST (RST was valid after all),
this 2nd RST will match expected sequence and conntrack state changes to
CLOSE.

If no challenge ACK is received, the connection will time out after
CLOSE seconds (10 seconds by default), just like without this patch.

Packetdrill test case:

0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0

0.100 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7>
0.100 > S. 0:0(0) ack 1 win 64240 <mss 1460,nop,nop,sackOK,nop,wscale 7>
0.200 < . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4

// Receive a segment.
0.210 < P. 1:1001(1000) ack 1 win 46
0.210 > . 1:1(0) ack 1001

// Application writes 1000 bytes.
0.250 write(4, ..., 1000) = 1000
0.250 > P. 1:1001(1000) ack 1001

// First reset, old sequence. Conntrack (correctly) considers this
// invalid due to failed window validation (regardless of this patch).
0.260 < R 2:2(0) ack 1001 win 260

// 2nd reset, but too far ahead sequence. Same: correctly handled
// as invalid.
0.270 < R 99990001:99990001(0) ack 1001 win 260

// in-window, but not exact sequence.
// Current Linux kernels might reply with a challenge ack, and do not
// remove connection.
// Without this patch, conntrack state moves to CLOSE.
// With patch, timeout is lowered like CLOSE, but connection stays
// in ESTABLISHED state.
0.280 < R 1010:1010(0) ack 1001 win 260

// Expect challenge ACK
0.281 > . 1001:1001(0) ack 1001 win 501

// With or without this patch, RST will cause connection
// to move to CLOSE (sequence number matches)
// 0.282 < R 1001:1001(0) ack 1001 win 260

// ACK
0.300 < . 1001:1001(0) ack 1001 win 257

// more data could be exchanged here, connection
// is still established

// Client closes the connection.
0.610 < F. 1001:1001(0) ack 1001 win 260
0.650 > . 1001:1001(0) ack 1002

// Close the connection without reading outstanding data
0.700 close(4) = 0

// so one more reset. Will be deemed acceptable with patch as well:
// connection is already closing.
0.701 > R. 1001:1001(0) ack 1002 win 501
// End packetdrill test case.

With patch, this generates following conntrack events:
[NEW] 120 SYN_SENT src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [UNREPLIED]
[UPDATE] 60 SYN_RECV src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80
[UPDATE] 432000 ESTABLISHED src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [ASSURED]
[UPDATE] 120 FIN_WAIT src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [ASSURED]
[UPDATE] 60 CLOSE_WAIT src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [ASSURED]
[UPDATE] 10 CLOSE src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [ASSURED]

Without patch, first RST moves connection to close, whereas socket state
does not change until FIN is received.
[NEW] 120 SYN_SENT src=10.0.2.1 dst=10.0.0.1 sport=5141 dport=80 [UNREPLIED]
[UPDATE] 60 SYN_RECV src=10.0.2.1 dst=10.0.0.1 sport=5141 dport=80
[UPDATE] 432000 ESTABLISHED src=10.0.2.1 dst=10.0.0.1 sport=5141 dport=80 [ASSURED]
[UPDATE] 10 CLOSE src=10.0.2.1 dst=10.0.0.1 sport=5141 dport=80 [ASSURED]

Cc: Jozsef Kadlecsik <kadlec@...>
Signed-off-by: Florian Westphal <fw@...>
Signed-off-by: Pablo Neira Ayuso <pablo@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: net/netfilter/nf_conntrack_proto_tcp.c


[linux:lloyd-aviation] By luojiajun <luojiajun3@...>:
6a817a7aed1c: jbd2: fix invalid descriptor block checksum

[ Upstream commit 6e876c3dd205d30b0db6850e97a03d75457df007 ]

In jbd2_journal_commit_transaction(), if we are in abort mode,
we may flush the buffer without setting descriptor block checksum
by goto start_journal_io. Then fs is mounted,
jbd2_descriptor_block_csum_verify() failed.

[ 271.379811] EXT4-fs (vdd): shut down requested (2)
[ 271.381827] Aborting journal on device vdd-8.
[ 271.597136] JBD2: Invalid checksum recovering block 22199 in log
[ 271.598023] JBD2: recovery failed
[ 271.598484] EXT4-fs (vdd): error loading journal

Fix this problem by keep setting descriptor block checksum if the
descriptor buffer is not NULL.

This checksum problem can be reproduced by xfstests generic/388.

Signed-off-by: luojiajun <luojiajun3@...>
Signed-off-by: Theodore Ts'o <tytso@...>
Reviewed-by: Jan Kara <jack@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/jbd2/commit.c


[linux:lloyd-aviation] By Carlos Maiolino <cmaiolino@...>:
83c395332fdf: fs: fix guard_bio_eod to check for real EOD errors

[ Upstream commit dce30ca9e3b676fb288c33c1f4725a0621361185 ]

guard_bio_eod() can truncate a segment in bio to allow it to do IO on
odd last sectors of a device.

It already checks if the IO starts past EOD, but it does not consider
the possibility of an IO request starting within device boundaries can
contain more than one segment past EOD.

In such cases, truncated_bytes can be bigger than PAGE_SIZE, and will
underflow bvec->bv_len.

Fix this by checking if truncated_bytes is lower than PAGE_SIZE.

This situation has been found on filesystems such as isofs and vfat,
which doesn't check the device size before mount, if the device is
smaller than the filesystem itself, a readahead on such filesystem,
which spans EOD, can trigger this situation, leading a call to
zero_user() with a wrong size possibly corrupting memory.

I didn't see any crash, or didn't let the system run long enough to
check if memory corruption will be hit somewhere, but adding
instrumentation to guard_bio_end() to check truncated_bytes size, was
enough to see the error.

The following script can trigger the error.

MNT=/mnt
IMG=./DISK.img
DEV=/dev/loop0

mkfs.vfat $IMG
mount $IMG $MNT
cp -R /etc $MNT &> /dev/null
umount $MNT

losetup -D

losetup --find --show --sizelimit 16247280 $IMG
mount $DEV $MNT

find $MNT -type f -exec cat {} + >/dev/null

Kudos to Eric Sandeen for coming up with the reproducer above

Reviewed-by: Ming Lei <ming.lei@...>
Signed-off-by: Carlos Maiolino <cmaiolino@...>
Signed-off-by: Jens Axboe <axboe@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: fs/buffer.c


[linux:lloyd-aviation] By Tony Jones <tonyj@...>:
224c996e48be: tools lib traceevent: Fix buffer overflow in arg_eval

[ Upstream commit 7c5b019e3a638a5a290b0ec020f6ca83d2ec2aaa ]

Fix buffer overflow observed when running perf test.

The overflow is when trying to evaluate "1ULL << (64 - 1)" which is
resulting in -9223372036854775808 which overflows the 20 character
buffer.

If is possible this bug has been reported before but I still don't see
any fix checked in:

See: https://www.spinics.net/lists/linux-perf-users/msg07714.html

Reported-by: Michael Sartain <mikesart@...>
Reported-by: Mathias Krause <minipli@...>
Signed-off-by: Tony Jones <tonyj@...>
Acked-by: Steven Rostedt (VMware) <rostedt@...>
Cc: Frederic Weisbecker <fweisbec@...>
Fixes: f7d82350e597 ("tools/events: Add files to create libtraceevent.a")
Link: http://lkml.kernel.org/r/20190228015532.8941-1-tonyj@...
Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: tools/lib/traceevent/event-parse.c


[linux:lloyd-aviation] By Rafael J. Wysocki <rafael.j.wysocki@...>:
9546c3662dc5: PCI/PME: Fix hotplug/sysfs remove deadlock in pcie_pme_remove()

[ Upstream commit 95c80bc6952b6a5badc7b702d23e5bf14d251e7c ]

Dongdong reported a deadlock triggered by a hotplug event during a sysfs
"remove" operation:

pciehp 0000:00:0c.0:pcie004: Slot(0-1): Link Up
# echo 1 > 0000:00:0c.0/remove

PME and hotplug share an MSI/MSI-X vector. The sysfs "remove" side is:

remove_store
pci_stop_and_remove_bus_device_locked
pci_lock_rescan_remove
pci_stop_and_remove_bus_device
...
pcie_pme_remove
pcie_pme_suspend
synchronize_irq # wait for hotplug IRQ handler
pci_unlock_rescan_remove

The hotplug side is:

pciehp_ist
pciehp_handle_presence_or_link_change
pciehp_configure_device
pci_lock_rescan_remove # wait for pci_unlock_rescan_remove()

INFO: task bash:10913 blocked for more than 120 seconds.

# ps -ax |grep D
PID TTY STAT TIME COMMAND
10913 ttyAMA0 Ds+ 0:00 -bash
14022 ? D 0:00 [irq/745-pciehp]

# cat /proc/14022/stack
__switch_to+0x94/0xd8
pci_lock_rescan_remove+0x20/0x28
pciehp_configure_device+0x30/0x140
pciehp_handle_presence_or_link_change+0x324/0x458
pciehp_ist+0x1dc/0x1e0

# cat /proc/10913/stack
__switch_to+0x94/0xd8
synchronize_irq+0x8c/0xc0
pcie_pme_suspend+0xa4/0x118
pcie_pme_remove+0x20/0x40
pcie_port_remove_service+0x3c/0x58
...
pcie_port_device_remove+0x2c/0x48
pcie_portdrv_remove+0x68/0x78
pci_device_remove+0x48/0x120
...
pci_stop_bus_device+0x84/0xc0
pci_stop_and_remove_bus_device_locked+0x24/0x40
remove_store+0xa4/0xb8
dev_attr_store+0x44/0x60
sysfs_kf_write+0x58/0x80

It is incorrect to call pcie_pme_suspend() from pcie_pme_remove() for two
reasons.

First, pcie_pme_suspend() calls synchronize_irq(), which will wait for the
native hotplug interrupt handler as well as for the PME one, because they
share one IRQ (as per the spec). That may deadlock if hotplug is signaled
while pcie_pme_remove() is running and the latter calls
pci_lock_rescan_remove() before the former.

Second, if pcie_pme_suspend() figures out that wakeup needs to be enabled
for the port, it will return without disabling the interrupt as expected by
pcie_pme_remove() which was overlooked by commit c7b5a4e6e8fb ("PCI / PM:
Fix native PME handling during system suspend/resume").

To fix that, rework pcie_pme_remove() to disable the PME interrupt, clear
its status and prevent the PME worker function from re-enabling it before
calling free_irq() on it, which should be sufficient.

Fixes: c7b5a4e6e8fb ("PCI / PM: Fix native PME handling during system suspend/resume")
Link: https://lore.kernel.org/linux-pci/c7697e7c-e1af-13e4-8491-0a3996e6ab5d@...
Reported-by: Dongdong Liu <liudongdong3@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
[bhelgaas: add URL and deadlock details from Dongdong]
Signed-off-by: Bjorn Helgaas <bhelgaas@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/pci/pcie/pme.c


[linux:lloyd-aviation] By Alexei Avshalom Lazar <ailizaro@...>:
6115055b4efe: wil6210: check null pointer in _wil_cfg80211_merge_extra_ies

[ Upstream commit de77a53c2d1e8fb3621e63e8e1f0f0c9a1a99ff7 ]

ies1 or ies2 might be null when code inside
_wil_cfg80211_merge_extra_ies access them.
Add explicit check for null and make sure ies1/ies2 are not
accessed in such a case.

spos might be null and be accessed inside
_wil_cfg80211_merge_extra_ies.
Add explicit check for null in the while condition statement
and make sure spos is not accessed in such a case.

Signed-off-by: Alexei Avshalom Lazar <ailizaro@...>
Signed-off-by: Maya Erez <merez@...>
Signed-off-by: Kalle Valo <kvalo@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/wireless/ath/wil6210/cfg80211.c


[linux:lloyd-aviation] By Wen Yang <wen.yang99@...>:
241ebd2ea44b: mt76: fix a leaked reference by adding a missing of_node_put

[ Upstream commit 34e022d8b780a03902d82fb3997ba7c7b1f40c81 ]

The call to of_find_node_by_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
./drivers/net/wireless/mediatek/mt76/eeprom.c:58:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:61:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:67:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:70:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:72:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.

Signed-off-by: Wen Yang <wen.yang99@...>
Cc: Felix Fietkau <nbd@...>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@...>
Cc: Kalle Valo <kvalo@...>
Cc: "David S. Miller" <davem@...>
Cc: Matthias Brugger <matthias.bgg@...>
Cc: linux-wireless@...
Cc: netdev@...
Cc: linux-arm-kernel@...
Cc: linux-mediatek@...
Cc: linux-kernel@...
Signed-off-by: Kalle Valo <kvalo@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/net/wireless/mediatek/mt76/eeprom.c


[linux:lloyd-aviation] By Julia Lawall <Julia.Lawall@...>:
d401d121113e: crypto: crypto4xx - add missing of_node_put after of_device_is_available

[ Upstream commit 8c2b43d2d85b48a97d2f8279278a4aac5b45f925 ]

Add an of_node_put when a tested device node is not available.

The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):

// <smpl>
@@
identifier f;
local idexpression e;
expression x;
@@

e = f(...);
... when != of_node_put(e)
when != x = e
when != e = x
when any
if (<+...of_device_is_available(e)...+>) {
... when != of_node_put(e)
(
return e;
|
+ of_node_put(e);
return ...;
)
}
// </smpl>

Fixes: 5343e674f32fb ("crypto4xx: integrate ppc4xx-rng into crypto4xx")
Signed-off-by: Julia Lawall <Julia.Lawall@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/crypto/amcc/crypto4xx_trng.c


[linux:lloyd-aviation] By Eric Biggers <ebiggers@...>:
b142c7973338: crypto: cavium/zip - fix collision with generic cra_driver_name

[ Upstream commit 41798036430015ad45137db2d4c213cd77fd0251 ]

The cavium/zip implementation of the deflate compression algorithm is
incorrectly being registered under the generic driver name, which
prevents the generic implementation from being registered with the
crypto API when CONFIG_CRYPTO_DEV_CAVIUM_ZIP=y. Similarly the lzs
algorithm (which does not currently have a generic implementation...)
is incorrectly being registered as lzs-generic.

Fix the naming collision by adding a suffix "-cavium" to the
cra_driver_name of the cavium/zip algorithms.

Fixes: 640035a2dc55 ("crypto: zip - Add ThunderX ZIP driver core")
Cc: Mahipal Challa <mahipalreddy2006@...>
Cc: Jan Glauber <jglauber@...>
Signed-off-by: Eric Biggers <ebiggers@...>
Signed-off-by: Herbert Xu <herbert@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/crypto/cavium/zip/zip_main.c


[linux:lloyd-aviation] By Paul Kocialkowski <paul.kocialkowski@...>:
6030bcc04735: usb: chipidea: Grab the (legacy) USB PHY by phandle first

[ Upstream commit 68ef236274793066b9ba3154b16c0acc1c891e5c ]

According to the chipidea driver bindings, the USB PHY is specified via
the "phys" phandle node. However, this only takes effect for USB PHYs
that use the common PHY framework. For legacy USB PHYs, a simple lookup
based on the USB PHY type is done instead.

This does not play out well when more than one USB PHY is registered,
since the first registered PHY matching the type will always be
returned regardless of what the driver was bound to.

Fix this by looking up the PHY based on the "phys" phandle node.
Although generic PHYs are rather matched by their "phys-name" and not
the "phys" phandle directly, there is no helper for similar lookup on
legacy PHYs and it's probably not worth the effort to add it.

When no legacy USB PHY is found by phandle, fallback to grabbing any
registered USB2 PHY. This ensures backward compatibility if some users
were actually relying on this mechanism.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@...>
Signed-off-by: Peter Chen <peter.chen@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/usb/chipidea/core.c


[linux:lloyd-aviation] By Alexey Kardashevskiy <aik@...>:
4acf797458ce: powerpc/powernv/ioda: Fix locked_vm counting for memory used by IOMMU tables

[ Upstream commit 11f5acce2fa43b015a8120fa7620fa4efd0a2952 ]

We store 2 multilevel tables in iommu_table - one for the hardware and
one with the corresponding userspace addresses. Before allocating
the tables, the iommu_table_group_ops::get_table_size() hook returns
the combined size of the two and VFIO SPAPR TCE IOMMU driver adjusts
the locked_vm counter correctly. When the table is actually allocated,
the amount of allocated memory is stored in iommu_table::it_allocated_size
and used to decrement the locked_vm counter when we release the memory
used by the table; .get_table_size() and .create_table() calculate it
independently but the result is expected to be the same.

However the allocator does not add the userspace table size to
.it_allocated_size so when we destroy the table because of VFIO PCI
unplug (i.e. VFIO container is gone but the userspace keeps running),
we decrement locked_vm by just a half of size of memory we are
releasing.

To make things worse, since we enabled on-demand allocation of
indirect levels, it_allocated_size contains only the amount of memory
actually allocated at the table creation time which can just be a
fraction. It is not a problem with incrementing locked_vm (as
get_table_size() value is used) but it is with decrementing.

As the result, we leak locked_vm and may not be able to allocate more
IOMMU tables after few iterations of hotplug/unplug.

This sets it_allocated_size in the pnv_pci_ioda2_ops::create_table()
hook to what pnv_pci_ioda2_get_table_size() returns so from now on we
have a single place which calculates the maximum memory a table can
occupy. The original meaning of it_allocated_size is somewhat lost now
though.

We do not ditch it_allocated_size whatsoever here and we do not call
get_table_size() from vfio_iommu_spapr_tce.c when decrementing
locked_vm as we may have multiple IOMMU groups per container and even
though they all are supposed to have the same get_table_size()
implementation, there is a small chance for failure or confusion.

Fixes: 090bad39b237 ("powerpc/powernv: Add indirect levels to it_userspace")
Signed-off-by: Alexey Kardashevskiy <aik@...>
Reviewed-by: David Gibson <david@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/powerpc/platforms/powernv/pci-ioda-tce.c
Modified: arch/powerpc/platforms/powernv/pci-ioda.c


[linux:lloyd-aviation] By Benjamin Block <bblock@...>:
5db107484403: scsi: core: replace GFP_ATOMIC with GFP_KERNEL in scsi_scan.c

[ Upstream commit 1749ef00f7312679f76d5e9104c5d1e22a829038 ]

We had a test-report where, under memory pressure, adding LUNs to the
systems would fail (the tests add LUNs strictly in sequence):

[ 5525.853432] scsi 0:0:1:1088045124: Direct-Access IBM 2107900 .148 PQ: 0 ANSI: 5
[ 5525.853826] scsi 0:0:1:1088045124: alua: supports implicit TPGS
[ 5525.853830] scsi 0:0:1:1088045124: alua: device naa.6005076303ffd32700000000000044da port group 0 rel port 43
[ 5525.853931] sd 0:0:1:1088045124: Attached scsi generic sg10 type 0
[ 5525.854075] sd 0:0:1:1088045124: [sdk] Disabling DIF Type 1 protection
[ 5525.855495] sd 0:0:1:1088045124: [sdk] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB)
[ 5525.855606] sd 0:0:1:1088045124: [sdk] Write Protect is off
[ 5525.855609] sd 0:0:1:1088045124: [sdk] Mode Sense: ed 00 00 08
[ 5525.855795] sd 0:0:1:1088045124: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 5525.857838] sdk: sdk1
[ 5525.859468] sd 0:0:1:1088045124: [sdk] Attached SCSI disk
[ 5525.865073] sd 0:0:1:1088045124: alua: transition timeout set to 60 seconds
[ 5525.865078] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA
[ 5526.015070] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA
[ 5526.015213] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA
[ 5526.587439] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
[ 5526.588562] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured

Looking at the code of scsi_alloc_sdev(), and all the calling contexts,
there seems to be no reason to use GFP_ATMOIC here. All the different
call-contexts use a mutex at some point, and nothing in between that
requires no sleeping, as far as I could see. Additionally, the code that
later allocates the block queue for the device (scsi_mq_alloc_queue())
already uses GFP_KERNEL.

There are similar allocations in two other functions:
scsi_probe_and_add_lun(), and scsi_add_lun(),; that can also be done with
GFP_KERNEL.

Here is the contexts for the three functions so far:

scsi_alloc_sdev()
scsi_probe_and_add_lun()
scsi_sequential_lun_scan()
__scsi_scan_target()
scsi_scan_target()
mutex_lock()
scsi_scan_channel()
scsi_scan_host_selected()
mutex_lock()
scsi_report_lun_scan()
__scsi_scan_target()
...
__scsi_add_device()
mutex_lock()
__scsi_scan_target()
...
scsi_report_lun_scan()
...
scsi_get_host_dev()
mutex_lock()

scsi_probe_and_add_lun()
...

scsi_add_lun()
scsi_probe_and_add_lun()
...

So replace all these, and give them a bit of a better chance to succeed,
with more chances of reclaim.

Signed-off-by: Benjamin Block <bblock@...>
Reviewed-by: Bart Van Assche <bvanassche@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/scsi/scsi_scan.c


[linux:lloyd-aviation] By Masahiro Yamada <yamada.masahiro@...>:
638ecaf58369: kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing

[ Upstream commit 9390dff66a52d1a60c6e517d8fa6cdbdffc83cb1 ]

If include/config/auto.conf.cmd is lost for some reasons, it is not
self-healing, so the top Makefile misses to run syncconfig.
Move include/config/auto.conf.cmd to the target side.

I used a pattern rule instead of a normal rule here although it is
a bit gross.

If the rule were written with a normal rule like this,

include/config/auto.conf \
include/config/auto.conf.cmd \
include/config/tristate.conf: $(KCONFIG_CONFIG)
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig

... syncconfig would be executed per target.

Using a pattern rule makes sure that syncconfig is executed just once
because Make assumes the recipe will create all of the targets.

Here is a quote from the GNU Make manual [1]:

"Pattern rules may have more than one target. Unlike normal rules,
this does not act as many different rules with the same prerequisites
and recipe. If a pattern rule has multiple targets, make knows that
the rule's recipe is responsible for making all of the targets. The
recipe is executed only once to make all the targets. When searching
for a pattern rule to match a target, the target patterns of a rule
other than the one that matches the target in need of a rule are
incidental: make worries only about giving a recipe and prerequisites
to the file presently in question. However, when this file's recipe is
run, the other targets are marked as having been updated themselves."

[1]: https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html

Signed-off-by: Masahiro Yamada <yamada.masahiro@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: Makefile


[linux:lloyd-aviation] By Nathan Chancellor <natechancellor@...>:
c70214d519ed: powerpc/xmon: Fix opcode being uninitialized in print_insn_powerpc

[ Upstream commit e7140639b1de65bba435a6bd772d134901141f86 ]

When building with -Wsometimes-uninitialized, Clang warns:

arch/powerpc/xmon/ppc-dis.c:157:7: warning: variable 'opcode' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
if (cpu_has_feature(CPU_FTRS_POWER9))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/xmon/ppc-dis.c:167:7: note: uninitialized use occurs here
if (opcode == NULL)
^~~~~~
arch/powerpc/xmon/ppc-dis.c:157:3: note: remove the 'if' if its
condition is always true
if (cpu_has_feature(CPU_FTRS_POWER9))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/xmon/ppc-dis.c:132:38: note: initialize the variable
'opcode' to silence this warning
const struct powerpc_opcode *opcode;
^
= NULL
1 warning generated.

This warning seems to make no sense on the surface because opcode is set
to NULL right below this statement. However, there is a comma instead of
semicolon to end the dialect assignment, meaning that the opcode
assignment only happens in the if statement. Properly terminate that
line so that Clang no longer warns.

Fixes: 5b102782c7f4 ("powerpc/xmon: Enable disassembly files (compilation changes)")
Signed-off-by: Nathan Chancellor <natechancellor@...>
Reviewed-by: Nick Desaulniers <ndesaulniers@...>
Signed-off-by: Michael Ellerman <mpe@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: arch/powerpc/xmon/ppc-dis.c


[linux:lloyd-aviation] By Sai Prakash Ranjan <saiprakash.ranjan@...>:
2636ccec991e: coresight: etm4x: Add support to enable ETMv4.2

[ Upstream commit 5666dfd1d8a45a167f0d8b4ef47ea7f780b1f24a ]

SDM845 has ETMv4.2 and can use the existing etm4x driver.
But the current etm driver checks only for ETMv4.0 and
errors out for other etm4x versions. This patch adds this
missing support to enable SoC's with ETMv4x to use same
driver by checking only the ETM architecture major version
number.

Without this change, we get below error during etm probe:

/ # dmesg | grep etm
[ 6.660093] coresight-etm4x: probe of 7040000.etm failed with error -22
[ 6.666902] coresight-etm4x: probe of 7140000.etm failed with error -22
[ 6.673708] coresight-etm4x: probe of 7240000.etm failed with error -22
[ 6.680511] coresight-etm4x: probe of 7340000.etm failed with error -22
[ 6.687313] coresight-etm4x: probe of 7440000.etm failed with error -22
[ 6.694113] coresight-etm4x: probe of 7540000.etm failed with error -22
[ 6.700914] coresight-etm4x: probe of 7640000.etm failed with error -22
[ 6.707717] coresight-etm4x: probe of 7740000.etm failed with error -22

With this change, etm probe is successful:

/ # dmesg | grep etm
[ 6.659198] coresight-etm4x 7040000.etm: CPU0: ETM v4.2 initialized
[ 6.665848] coresight-etm4x 7140000.etm: CPU1: ETM v4.2 initialized
[ 6.672493] coresight-etm4x 7240000.etm: CPU2: ETM v4.2 initialized
[ 6.679129] coresight-etm4x 7340000.etm: CPU3: ETM v4.2 initialized
[ 6.685770] coresight-etm4x 7440000.etm: CPU4: ETM v4.2 initialized
[ 6.692403] coresight-etm4x 7540000.etm: CPU5: ETM v4.2 initialized
[ 6.699024] coresight-etm4x 7640000.etm: CPU6: ETM v4.2 initialized
[ 6.705646] coresight-etm4x 7740000.etm: CPU7: ETM v4.2 initialized

Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@...>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@...>
Signed-off-by: Mathieu Poirier <mathieu.poirier@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/hwtracing/coresight/coresight-etm4x.c


[linux:lloyd-aviation] By Lubomir Rintel <lkundrak@...>:
951307172652: serial: 8250_pxa: honor the port number from devicetree

[ Upstream commit fe9ed6d2483fda55465f32924fb15bce0fac3fac ]

Like the other OF-enabled drivers, use the port number from the firmware if
the devicetree specifies an alias:

aliases {
...
serial2 = &uart2; /* Should be ttyS2 */
}

This is how the deprecated pxa.c driver behaved, switching to 8250_pxa
messes up the numbering.

Signed-off-by: Lubomir Rintel <lkundrak@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
Signed-off-by: Sasha Levin <sashal@...>

Modified: drivers/tty/serial/8250/8250_pxa.c


[linux:lloyd-aviation] By Sebastian Andrzej Siewior <bigeasy@...>:
d81bdb3c17f1: ARM: 8840/1: use a raw_spinlock_t in unwind

[ Upstream comm