lp:~kmously/ubuntu/+source/linux/+git/bionic

Author: William Breathitt Gray
Author Date: 2021-02-04 10:55:46 UTC

UBUNTU: Ubuntu-aws-4.15.0-1094.101

Signed-off-by: William Breathitt Gray <william.gray@canonical.com>

Author: Kelsey Steele
Author Date: 2021-02-04 03:20:00 UTC

UBUNTU: [Config] azure: Remove pci-hyperv from module list

BugLink: https://bugs.launchpad.net/bugs/1908571

CONFIG_PCI_HYPERV was set as a built-in to allow instances to boot
directly from NVME disks. Update module list to remove pci-hyperv,
otherwise build will fail.

Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>

Author: Khaled El Mously
Author Date: 2021-02-03 04:00:59 UTC

UBUNTU: [config] updateconfigs

Ignore: yes
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2020-12-09 04:27:03 UTC

Revert "md: add md_submit_discard_bio() for submitting discard bio"

BugLink: https://bugs.launchpad.net/bugs/1907262

This reverts commit edf4cd46cf86430f67499035ae461e2e9d23ffa6.

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2020-08-13 03:04:27 UTC

UBUNTU: [config] updateconfigs for EFI_CUSTOM_SSDT_OVERLAYS

BugLink: https://bugs.launchpad.net/bugs/1886995

The code that this config enables was previously enabled by
CONFIG_ACPI. As that config was already enabled, enabling this
one as well to preserve functionality.

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2019-03-26 06:07:12 UTC

UBUNTU: Ubuntu-4.15.0-48.51

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Marcelo Cerri
Author Date: 2019-02-28 16:15:11 UTC

UBUNTU: [Config] linux-gcp: Update annotations file

http://bugs.launchpad.net/bugs/1752072

Based on the git log of linux-gcp, add any missing configuration
change to the linux-gcp annotations file and update any necessary flag
as well.

The following commands were used to re-order the annotations file:

    fakeroot debian/rules clean
    kteam-tools/devel/devel-config-summary . test
    kteam-tools/devel/lib-config/devel-reorder-annotations . debian.gcp/config/annotations /tmp/annotations
    sed -i '/^# Menu/ { N; /^# Menu.*\n$/d }' /tmp/annotations
    git clear -dxf
    mv /tmp/annotations debian.gcp/config/annotations

Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Acked-by: Kleber Souza <kleber.souza@canonical.com>
Acked-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Thadeu Lima de Souza Cascardo
Author Date: 2019-02-21 16:35:18 UTC

UBUNTU: Packaging: Make update-from-*master call copy-files

BugLink: https://bugs.launchpad.net/bugs/1817734

Now that copy-files (and optionally local-mangle) are introduced,
update-from-*master may make use of them, instead of doing the copies and
mangles itself. That makes it easier to replace update-from-*master with a
single script version for all trees in the future.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2018-08-29 05:46:12 UTC

UBUNTU: SAUCE: Ignore removal of module dsa_loop_bdinfo

Commit "net: dsa: Fix functional dsa-loop dependency on FIXED_PHY"
has changed dsa_loop_bdinfo from =m to =y

Ignore: yes
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2018-08-16 04:56:44 UTC

UBUNTU: Ubuntu-aws-4.15.0-1020.20

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2018-08-16 04:56:44 UTC

UBUNTU: Ubuntu-aws-4.15.0-1020.20

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Gabriel Matni
Author Date: 2018-03-22 19:15:12 UTC

serial: mvebu-uart: fix tx lost characters

BugLink: http://bugs.launchpad.net/bugs/1783418

[ Upstream commit c685af1108d7c303f0b901413405d68eaeac4477 ]

Fixes missing characters on kernel console at low baud rates (i.e.9600).
The driver should poll TX_RDY or TX_FIFO_EMP instead of TX_EMP to ensure
that the transmitter holding register (THR) is ready to receive a new byte.

TX_EMP tells us when it is possible to send a break sequence via
SND_BRK_SEQ. While this also indicates that both the THR and the TSR are
empty, it does not guarantee that a new byte can be written just yet.

Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port")
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Gabriel Matni <gabriel.matni@exfo.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2018-07-10 23:55:04 UTC

UBUNTU: Ubuntu-4.15.0-27.29

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Po-Hsu Lin
Author Date: 2018-06-12 10:53:15 UTC

UBUNTU: [Config]: enable CONFIG_FORTIFY_SOURCE

BugLink: https://bugs.launchpad.net/bugs/1766774

Enable the CONFIG_FORTIFY_SOURCE, which is required by the kernel security
testsuite.

Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Greg Kroah-Hartman
Author Date: 2018-04-26 15:28:00 UTC

Revert "pinctrl: intel: Initialize GPIO properly when used through irqchip"

BugLink: http://bugs.launchpad.net/bugs/1775483

This reverts commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257

Mike writes:
 It seems that commit f5a26acf0162 ("pinctrl: intel: Initialize GPIO
 properly when used through irqchip") can cause problems on some Skylake
 systems with Sunrisepoint PCH-H. Namely on certain systems it may turn
 the backlight PWM pin from native mode to GPIO which makes the screen
 blank during boot.

 There is more information here:

   https://bugzilla.redhat.com/show_bug.cgi?id=1543769

 The actual reason is that GPIO numbering used in BIOS is using "Windows"
 numbers meaning that they don't match the hardware 1:1 and because of
 this a wrong pin (backlight PWM) is picked and switched to GPIO mode.

 There is a proper fix for this but since it has quite many dependencies
 on commits that cannot be considered stable material, I suggest we
 revert commit f5a26acf0162 from stable trees 4.9, 4.14 and 4.15 to
 prevent the backlight issue.

Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Fixes: f5a26acf0162 ("pinctrl: intel: Initialize GPIO properly when used through irqchip")
Cc: Daniel Drake <drake@endlessm.com>
Cc: Chris Chiu <chiu@endlessm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Tetsuo Handa
Author Date: 2018-04-04 10:53:07 UTC

mm,vmscan: Allow preallocating memory for register_shrinker().

BugLink: http://bugs.launchpad.net/bugs/1774063

commit 8e04944f0ea8b838399049bdcda920ab36ae3b04 upstream.

syzbot is catching so many bugs triggered by commit 9ee332d99e4d5a97
("sget(): handle failures of register_shrinker()"). That commit expected
that calling kill_sb() from deactivate_locked_super() without successful
fill_super() is safe, but the reality was different; some callers assign
attributes which are needed for kill_sb() after sget() succeeds.

For example, [1] is a report where sb->s_mode (which seems to be either
FMODE_READ | FMODE_EXCL | FMODE_WRITE or FMODE_READ | FMODE_EXCL) is not
assigned unless sget() succeeds. But it does not worth complicate sget()
so that register_shrinker() failure path can safely call
kill_block_super() via kill_sb(). Making alloc_super() fail if memory
allocation for register_shrinker() failed is much simpler. Let's avoid
calling deactivate_locked_super() from sget_userns() by preallocating
memory for the shrinker and making register_shrinker() in sget_userns()
never fail.

[1] https://syzkaller.appspot.com/bug?id=588996a25a2587be2e3a54e8646728fb9cae44e7

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+5a170e19c963a2e0df79@syzkaller.appspotmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Jiri Kosina
Author Date: 2018-04-19 07:25:15 UTC

HID: i2c-hid: fix inverted return value from i2c_hid_command()

BugLink: http://bugs.launchpad.net/bugs/1773233

commit b658912cb023cd6f8e46963d29779903d3c10538 upstream.

i2c_hid_command() returns non-zero in error cases (the actual
errno). Error handling in for I2C_HID_QUIRK_RESEND_REPORT_DESCR
case in i2c_hid_resume() had the check inverted; fix that.

Fixes: 3e83eda467 ("HID: i2c-hid: Fix resume issue on Raydium touchscreen device")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khalid Elmously <khalid.elmously@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2018-05-24 15:34:20 UTC

UBUNTU: Ubuntu-gcp-4.15.0-1009.9

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2018-05-24 15:25:37 UTC

UBUNTU: Ubuntu-kvm-4.15.0-1011.11

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2018-05-24 05:26:31 UTC

UBUNTU: Ubuntu-oem-4.15.0-1007.10

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2018-05-24 04:06:30 UTC

UBUNTU: Ubuntu-aws-4.15.0-1010.10

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Khaled El Mously
Author Date: 2018-05-24 02:19:27 UTC

UBUNTU: Ubuntu-raspi-4.15.0-1012.13

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

Author: Lyude
Author Date: 2018-05-11 16:00:53 UTC

drm/nouveau: Fix deadlock in nv50_mstm_register_connector()

BugLink: http://bugs.launchpad.net/bugs/1763189

Currently; we're grabbing all of the modesetting locks before adding MST
connectors to fbdev. This isn't actually necessary, and causes a
deadlock as well:

======================================================
WARNING: possible circular locking dependency detected
4.17.0-rc3Lyude-Test+ #1 Tainted: G O
------------------------------------------------------
kworker/1:0/18 is trying to acquire lock:
00000000c832f62d (&helper->lock){+.+.}, at: drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]

but task is already holding lock:
00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #3 (crtc_ww_class_mutex){+.+.}:
       ww_mutex_lock+0x43/0x80
       drm_modeset_lock+0x71/0x130 [drm]
       drm_helper_probe_single_connector_modes+0x7d/0x6b0 [drm_kms_helper]
       drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper]
       __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper]
       nouveau_fbcon_init+0x138/0x1a0 [nouveau]
       nouveau_drm_load+0x173/0x7e0 [nouveau]
       drm_dev_register+0x134/0x1c0 [drm]
       drm_get_pci_dev+0x8e/0x160 [drm]
       nouveau_drm_probe+0x1a9/0x230 [nouveau]
       pci_device_probe+0xcd/0x150
       driver_probe_device+0x30b/0x480
       __driver_attach+0xbc/0xe0
       bus_for_each_dev+0x67/0x90
       bus_add_driver+0x164/0x260
       driver_register+0x57/0xc0
       do_one_initcall+0x4d/0x323
       do_init_module+0x5b/0x1f8
       load_module+0x20e5/0x2ac0
       __do_sys_finit_module+0xb7/0xd0
       do_syscall_64+0x60/0x1b0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #2 (crtc_ww_class_acquire){+.+.}:
       drm_helper_probe_single_connector_modes+0x58/0x6b0 [drm_kms_helper]
       drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper]
       __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper]
       nouveau_fbcon_init+0x138/0x1a0 [nouveau]
       nouveau_drm_load+0x173/0x7e0 [nouveau]
       drm_dev_register+0x134/0x1c0 [drm]
       drm_get_pci_dev+0x8e/0x160 [drm]
       nouveau_drm_probe+0x1a9/0x230 [nouveau]
       pci_device_probe+0xcd/0x150
       driver_probe_device+0x30b/0x480
       __driver_attach+0xbc/0xe0
       bus_for_each_dev+0x67/0x90
       bus_add_driver+0x164/0x260
       driver_register+0x57/0xc0
       do_one_initcall+0x4d/0x323
       do_init_module+0x5b/0x1f8
       load_module+0x20e5/0x2ac0
       __do_sys_finit_module+0xb7/0xd0
       do_syscall_64+0x60/0x1b0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #1 (&dev->mode_config.mutex){+.+.}:
       drm_setup_crtcs+0x10c/0xc90 [drm_kms_helper]
       __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper]
       nouveau_fbcon_init+0x138/0x1a0 [nouveau]
       nouveau_drm_load+0x173/0x7e0 [nouveau]
       drm_dev_register+0x134/0x1c0 [drm]
       drm_get_pci_dev+0x8e/0x160 [drm]
       nouveau_drm_probe+0x1a9/0x230 [nouveau]
       pci_device_probe+0xcd/0x150
       driver_probe_device+0x30b/0x480
       __driver_attach+0xbc/0xe0
       bus_for_each_dev+0x67/0x90
       bus_add_driver+0x164/0x260
       driver_register+0x57/0xc0
       do_one_initcall+0x4d/0x323
       do_init_module+0x5b/0x1f8
       load_module+0x20e5/0x2ac0
       __do_sys_finit_module+0xb7/0xd0
       do_syscall_64+0x60/0x1b0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #0 (&helper->lock){+.+.}:
       __mutex_lock+0x70/0x9d0
       drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
       nv50_mstm_register_connector+0x2c/0x50 [nouveau]
       drm_dp_add_port+0x2f5/0x420 [drm_kms_helper]
       drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
       drm_dp_add_port+0x33f/0x420 [drm_kms_helper]
       drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
       drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper]
       drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper]
       process_one_work+0x20d/0x650
       worker_thread+0x3a/0x390
       kthread+0x11e/0x140
       ret_from_fork+0x3a/0x50

other info that might help us debug this:
Chain exists of:
  &helper->lock --> crtc_ww_class_acquire --> crtc_ww_class_mutex
 Possible unsafe locking scenario:
       CPU0 CPU1
       ---- ----
  lock(crtc_ww_class_mutex);
                               lock(crtc_ww_class_acquire);
                               lock(crtc_ww_class_mutex);
  lock(&helper->lock);

 *** DEADLOCK ***
5 locks held by kworker/1:0/18:
 #0: 000000004a05cd50 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x187/0x650
 #1: 00000000601c11d1 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x187/0x650
 #2: 00000000586ca0df (&dev->mode_config.mutex){+.+.}, at: drm_modeset_lock_all+0x3a/0x1b0 [drm]
 #3: 00000000d3ca0ffa (crtc_ww_class_acquire){+.+.}, at: drm_modeset_lock_all+0x44/0x1b0 [drm]
 #4: 00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm]

stack backtrace:
CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G O 4.17.0-rc3Lyude-Test+ #1
Hardware name: Gateway FX6840/FX6840, BIOS P01-A3 05/17/2010
Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
Call Trace:
 dump_stack+0x85/0xcb
 print_circular_bug.isra.38+0x1ce/0x1db
 __lock_acquire+0x128f/0x1350
 ? lock_acquire+0x9f/0x200
 ? lock_acquire+0x9f/0x200
 ? __ww_mutex_lock.constprop.13+0x8f/0x1000
 lock_acquire+0x9f/0x200
 ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
 ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
 __mutex_lock+0x70/0x9d0
 ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
 ? ww_mutex_lock+0x43/0x80
 ? _cond_resched+0x15/0x30
 ? ww_mutex_lock+0x43/0x80
 ? drm_modeset_lock+0xb2/0x130 [drm]
 ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
 drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
 nv50_mstm_register_connector+0x2c/0x50 [nouveau]
 drm_dp_add_port+0x2f5/0x420 [drm_kms_helper]
 ? mark_held_locks+0x50/0x80
 ? kfree+0xcf/0x2a0
 ? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper]
 ? trace_hardirqs_on_caller+0xed/0x180
 ? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper]
 drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
 drm_dp_add_port+0x33f/0x420 [drm_kms_helper]
 ? nouveau_connector_aux_xfer+0x7c/0xb0 [nouveau]
 ? find_held_lock+0x2d/0x90
 ? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper]
 ? __mutex_unlock_slowpath+0x3b/0x280
 ? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper]
 drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
 drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper]
 drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper]
 process_one_work+0x20d/0x650
 worker_thread+0x3a/0x390
 ? process_one_work+0x650/0x650
 kthread+0x11e/0x140
 ? kthread_create_worker_on_cpu+0x50/0x50
 ret_from_fork+0x3a/0x50

Taking example from i915, the only time we need to hold any modesetting
locks is when changing the port on the mstc, and in that case we only
need to hold the connection mutex.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: stable@vger.kernel.org

Signed-off-by: Lyude Paul <lyude@redhat.com>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
(cherry-picked from 352672db857290ab5b0e2b6a99c414f92bee024c)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Khalid Elmously <khalid.elmously@canonical.com>
Acked-by: Kleber Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>