From: Greg Kroah-Hartman Date: Tue, 28 Mar 2017 12:12:48 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v4.4.58~4 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c0e5c706b0b470527dc81a6bb29238456cd88ac4;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch block-allow-write_same-commands-with-the-sg_io-ioctl.patch crypto-algif_hash-avoid-zero-sized-array.patch fbcon-fix-vc-attr-at-deinit.patch igb-add-i211-to-i210-phy-workaround.patch igb-workaround-for-igb-i210-firmware-issue.patch pci-add-comments-about-rom-bar-updating.patch pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch pci-do-any-vf-bar-updates-before-enabling-the-bars.patch pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch pci-ignore-bar-updates-on-virtual-functions.patch pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch pci-separate-vf-bar-updates-from-standard-bar-updates.patch pci-update-bars-using-property-bits-appropriate-for-type.patch s390-zcrypt-introduce-cex6-toleration.patch serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch xfs-clear-_xbf_pages-from-buffers-when-readahead-page.patch --- diff --git a/queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch b/queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch new file mode 100644 index 00000000000..311428566e8 --- /dev/null +++ b/queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch @@ -0,0 +1,57 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:17 +0530 +Subject: ACPI / blacklist: add _REV quirks for Dell Precision 5520 and 3520 +To: stable@vger.kernel.org +Cc: Alex Hung , "Rafael J . Wysocki" , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-18-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Alex Hung + +[ Upstream commit 9523b9bf6dceef6b0215e90b2348cd646597f796 ] + +Precision 5520 and 3520 either hang at login and during suspend or reboot. + +It turns out that that adding them to acpi_rev_dmi_table[] helps to work +around those issues. + +Signed-off-by: Alex Hung +[ rjw: Changelog ] +Signed-off-by: Rafael J. Wysocki + +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/blacklist.c | 16 ++++++++++++++++ + 1 file changed, 16 insertions(+) + +--- a/drivers/acpi/blacklist.c ++++ b/drivers/acpi/blacklist.c +@@ -346,6 +346,22 @@ static struct dmi_system_id acpi_osi_dmi + DMI_MATCH(DMI_PRODUCT_NAME, "XPS 13 9343"), + }, + }, ++ { ++ .callback = dmi_enable_rev_override, ++ .ident = "DELL Precision 5520", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Precision 5520"), ++ }, ++ }, ++ { ++ .callback = dmi_enable_rev_override, ++ .ident = "DELL Precision 3520", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Precision 3520"), ++ }, ++ }, + #endif + {} + }; diff --git a/queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch b/queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch new file mode 100644 index 00000000000..21e82ac65ea --- /dev/null +++ b/queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch @@ -0,0 +1,53 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:18 +0530 +Subject: ACPI / blacklist: Make Dell Latitude 3350 ethernet work +To: stable@vger.kernel.org +Cc: Michael Pobega , "Rafael J . Wysocki" , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-19-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Michael Pobega + +[ Upstream commit 708f5dcc21ae9b35f395865fc154b0105baf4de4 ] + +The Dell Latitude 3350's ethernet card attempts to use a reserved +IRQ (18), resulting in ACPI being unable to enable the ethernet. + +Adding it to acpi_rev_dmi_table[] helps to work around this problem. + +Signed-off-by: Michael Pobega +[ rjw: Changelog ] +Signed-off-by: Rafael J. Wysocki + +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/blacklist.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/drivers/acpi/blacklist.c ++++ b/drivers/acpi/blacklist.c +@@ -362,6 +362,18 @@ static struct dmi_system_id acpi_osi_dmi + DMI_MATCH(DMI_PRODUCT_NAME, "Precision 3520"), + }, + }, ++ /* ++ * Resolves a quirk with the Dell Latitude 3350 that ++ * causes the ethernet adapter to not function. ++ */ ++ { ++ .callback = dmi_enable_rev_override, ++ .ident = "DELL Latitude 3350", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Latitude 3350"), ++ }, ++ }, + #endif + {} + }; diff --git a/queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch b/queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch new file mode 100644 index 00000000000..270fab17f02 --- /dev/null +++ b/queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch @@ -0,0 +1,87 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:14 +0530 +Subject: block: allow WRITE_SAME commands with the SG_IO ioctl +To: stable@vger.kernel.org +Cc: Mauricio Faria de Oliveira , Brahadambal Srinivasan , Jens Axboe , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-15-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Mauricio Faria de Oliveira + +[ Upstream commit 25cdb64510644f3e854d502d69c73f21c6df88a9 ] + +The WRITE_SAME commands are not present in the blk_default_cmd_filter +write_ok list, and thus are failed with -EPERM when the SG_IO ioctl() +is executed without CAP_SYS_RAWIO capability (e.g., unprivileged users). +[ sg_io() -> blk_fill_sghdr_rq() > blk_verify_command() -> -EPERM ] + +The problem can be reproduced with the sg_write_same command + + # sg_write_same --num 1 --xferlen 512 /dev/sda + # + + # capsh --drop=cap_sys_rawio -- -c \ + 'sg_write_same --num 1 --xferlen 512 /dev/sda' + Write same: pass through os error: Operation not permitted + # + +For comparison, the WRITE_VERIFY command does not observe this problem, +since it is in that list: + + # capsh --drop=cap_sys_rawio -- -c \ + 'sg_write_verify --num 1 --ilen 512 --lba 0 /dev/sda' + # + +So, this patch adds the WRITE_SAME commands to the list, in order +for the SG_IO ioctl to finish successfully: + + # capsh --drop=cap_sys_rawio -- -c \ + 'sg_write_same --num 1 --xferlen 512 /dev/sda' + # + +That case happens to be exercised by QEMU KVM guests with 'scsi-block' devices +(qemu "-device scsi-block" [1], libvirt "" [2]), +which employs the SG_IO ioctl() and runs as an unprivileged user (libvirt-qemu). + +In that scenario, when a filesystem (e.g., ext4) performs its zero-out calls, +which are translated to write-same calls in the guest kernel, and then into +SG_IO ioctls to the host kernel, SCSI I/O errors may be observed in the guest: + + [...] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE + [...] sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current] + [...] sd 0:0:0:0: [sda] tag#0 Add. Sense: I/O process terminated + [...] sd 0:0:0:0: [sda] tag#0 CDB: Write Same(10) 41 00 01 04 e0 78 00 00 08 00 + [...] blk_update_request: I/O error, dev sda, sector 17096824 + +Links: +[1] http://git.qemu.org/?p=qemu.git;a=commit;h=336a6915bc7089fb20fea4ba99972ad9a97c5f52 +[2] https://libvirt.org/formatdomain.html#elementsDisks (see 'disk' -> 'device') + +Signed-off-by: Mauricio Faria de Oliveira +Signed-off-by: Brahadambal Srinivasan +Reported-by: Manjunatha H R +Reviewed-by: Christoph Hellwig +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + block/scsi_ioctl.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/block/scsi_ioctl.c ++++ b/block/scsi_ioctl.c +@@ -182,6 +182,9 @@ static void blk_set_cmd_filter_defaults( + __set_bit(WRITE_16, filter->write_ok); + __set_bit(WRITE_LONG, filter->write_ok); + __set_bit(WRITE_LONG_2, filter->write_ok); ++ __set_bit(WRITE_SAME, filter->write_ok); ++ __set_bit(WRITE_SAME_16, filter->write_ok); ++ __set_bit(WRITE_SAME_32, filter->write_ok); + __set_bit(ERASE, filter->write_ok); + __set_bit(GPCMD_MODE_SELECT_10, filter->write_ok); + __set_bit(MODE_SELECT, filter->write_ok); diff --git a/queue-4.4/crypto-algif_hash-avoid-zero-sized-array.patch b/queue-4.4/crypto-algif_hash-avoid-zero-sized-array.patch new file mode 100644 index 00000000000..18f62a87148 --- /dev/null +++ b/queue-4.4/crypto-algif_hash-avoid-zero-sized-array.patch @@ -0,0 +1,71 @@ +From 6207119444595d287b1e9e83a2066c17209698f3 Mon Sep 17 00:00:00 2001 +From: Jiri Slaby +Date: Thu, 15 Dec 2016 14:31:01 +0100 +Subject: crypto: algif_hash - avoid zero-sized array + +From: Jiri Slaby + +commit 6207119444595d287b1e9e83a2066c17209698f3 upstream. + +With this reproducer: + struct sockaddr_alg alg = { + .salg_family = 0x26, + .salg_type = "hash", + .salg_feat = 0xf, + .salg_mask = 0x5, + .salg_name = "digest_null", + }; + int sock, sock2; + + sock = socket(AF_ALG, SOCK_SEQPACKET, 0); + bind(sock, (struct sockaddr *)&alg, sizeof(alg)); + sock2 = accept(sock, NULL, NULL); + setsockopt(sock, SOL_ALG, ALG_SET_KEY, "\x9b\xca", 2); + accept(sock2, NULL, NULL); + +==== 8< ======== 8< ======== 8< ======== 8< ==== + +one can immediatelly see an UBSAN warning: +UBSAN: Undefined behaviour in crypto/algif_hash.c:187:7 +variable length array bound value 0 <= 0 +CPU: 0 PID: 15949 Comm: syz-executor Tainted: G E 4.4.30-0-default #1 +... +Call Trace: +... + [] ? __ubsan_handle_vla_bound_not_positive+0x13d/0x188 + [] ? __ubsan_handle_out_of_bounds+0x1bc/0x1bc + [] ? hash_accept+0x5bd/0x7d0 [algif_hash] + [] ? hash_accept_nokey+0x3f/0x51 [algif_hash] + [] ? hash_accept_parent_nokey+0x4a0/0x4a0 [algif_hash] + [] ? SyS_accept+0x2b/0x40 + +It is a correct warning, as hash state is propagated to accept as zero, +but creating a zero-length variable array is not allowed in C. + +Fix this as proposed by Herbert -- do "?: 1" on that site. No sizeof or +similar happens in the code there, so we just allocate one byte even +though we do not use the array. + +Signed-off-by: Jiri Slaby +Cc: Herbert Xu +Cc: "David S. Miller" (maintainer:CRYPTO API) +Reported-by: Sasha Levin +Signed-off-by: Herbert Xu +Cc: Arnd Bergmann +Signed-off-by: Greg Kroah-Hartman + +--- + crypto/algif_hash.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/crypto/algif_hash.c ++++ b/crypto/algif_hash.c +@@ -184,7 +184,7 @@ static int hash_accept(struct socket *so + struct alg_sock *ask = alg_sk(sk); + struct hash_ctx *ctx = ask->private; + struct ahash_request *req = &ctx->req; +- char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))]; ++ char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req)) ? : 1]; + struct sock *sk2; + struct alg_sock *ask2; + struct hash_ctx *ctx2; diff --git a/queue-4.4/fbcon-fix-vc-attr-at-deinit.patch b/queue-4.4/fbcon-fix-vc-attr-at-deinit.patch new file mode 100644 index 00000000000..f42251f1649 --- /dev/null +++ b/queue-4.4/fbcon-fix-vc-attr-at-deinit.patch @@ -0,0 +1,148 @@ +From 8aac7f34369726d1a158788ae8aff3002d5eb528 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Wed, 11 Jan 2017 17:09:50 +0100 +Subject: fbcon: Fix vc attr at deinit + +From: Takashi Iwai + +commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream. + +fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust +the vc attrs dynamically when vc_hi_font_mask is changed at +fbcon_init(). When the vc_hi_font_mask is set, it remaps the attrs in +the existing console buffer with one bit shift up (for 9 bits), while +it remaps with one bit shift down (for 8 bits) when the value is +cleared. It works fine as long as the font gets updated after fbcon +was initialized. + +However, we hit a bizarre problem when the console is switched to +another fb driver (typically from vesafb or efifb to drmfb). At +switching to the new fb driver, we temporarily rebind the console to +the dummy console, then rebind to the new driver. During the +switching, we leave the modified attrs as is. Thus, the new fbcon +takes over the old buffer as if it were to contain 8 bits chars +(although the attrs are still shifted for 9 bits), and effectively +this results in the yellow color texts instead of the original white +color, as found in the bugzilla entry below. + +An easy fix for this is to re-adjust the attrs before leaving the +fbcon at con_deinit callback. Since the code to adjust the attrs is +already present in the current fbcon code, in this patch, we simply +factor out the relevant code, and call it from fbcon_deinit(). + +Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619 +Signed-off-by: Takashi Iwai +Signed-off-by: Bartlomiej Zolnierkiewicz +Cc: Arnd Bergmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/video/console/fbcon.c | 67 +++++++++++++++++++++++++----------------- + 1 file changed, 40 insertions(+), 27 deletions(-) + +--- a/drivers/video/console/fbcon.c ++++ b/drivers/video/console/fbcon.c +@@ -1168,6 +1168,8 @@ static void fbcon_free_font(struct displ + p->userfont = 0; + } + ++static void set_vc_hi_font(struct vc_data *vc, bool set); ++ + static void fbcon_deinit(struct vc_data *vc) + { + struct display *p = &fb_display[vc->vc_num]; +@@ -1203,6 +1205,9 @@ finished: + if (free_font) + vc->vc_font.data = NULL; + ++ if (vc->vc_hi_font_mask) ++ set_vc_hi_font(vc, false); ++ + if (!con_is_bound(&fb_con)) + fbcon_exit(); + +@@ -2439,32 +2444,10 @@ static int fbcon_get_font(struct vc_data + return 0; + } + +-static int fbcon_do_set_font(struct vc_data *vc, int w, int h, +- const u8 * data, int userfont) ++/* set/clear vc_hi_font_mask and update vc attrs accordingly */ ++static void set_vc_hi_font(struct vc_data *vc, bool set) + { +- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]]; +- struct fbcon_ops *ops = info->fbcon_par; +- struct display *p = &fb_display[vc->vc_num]; +- int resize; +- int cnt; +- char *old_data = NULL; +- +- if (CON_IS_VISIBLE(vc) && softback_lines) +- fbcon_set_origin(vc); +- +- resize = (w != vc->vc_font.width) || (h != vc->vc_font.height); +- if (p->userfont) +- old_data = vc->vc_font.data; +- if (userfont) +- cnt = FNTCHARCNT(data); +- else +- cnt = 256; +- vc->vc_font.data = (void *)(p->fontdata = data); +- if ((p->userfont = userfont)) +- REFCOUNT(data)++; +- vc->vc_font.width = w; +- vc->vc_font.height = h; +- if (vc->vc_hi_font_mask && cnt == 256) { ++ if (!set) { + vc->vc_hi_font_mask = 0; + if (vc->vc_can_do_color) { + vc->vc_complement_mask >>= 1; +@@ -2487,7 +2470,7 @@ static int fbcon_do_set_font(struct vc_d + ((c & 0xfe00) >> 1) | (c & 0xff); + vc->vc_attr >>= 1; + } +- } else if (!vc->vc_hi_font_mask && cnt == 512) { ++ } else { + vc->vc_hi_font_mask = 0x100; + if (vc->vc_can_do_color) { + vc->vc_complement_mask <<= 1; +@@ -2519,8 +2502,38 @@ static int fbcon_do_set_font(struct vc_d + } else + vc->vc_video_erase_char = c & ~0x100; + } +- + } ++} ++ ++static int fbcon_do_set_font(struct vc_data *vc, int w, int h, ++ const u8 * data, int userfont) ++{ ++ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]]; ++ struct fbcon_ops *ops = info->fbcon_par; ++ struct display *p = &fb_display[vc->vc_num]; ++ int resize; ++ int cnt; ++ char *old_data = NULL; ++ ++ if (CON_IS_VISIBLE(vc) && softback_lines) ++ fbcon_set_origin(vc); ++ ++ resize = (w != vc->vc_font.width) || (h != vc->vc_font.height); ++ if (p->userfont) ++ old_data = vc->vc_font.data; ++ if (userfont) ++ cnt = FNTCHARCNT(data); ++ else ++ cnt = 256; ++ vc->vc_font.data = (void *)(p->fontdata = data); ++ if ((p->userfont = userfont)) ++ REFCOUNT(data)++; ++ vc->vc_font.width = w; ++ vc->vc_font.height = h; ++ if (vc->vc_hi_font_mask && cnt == 256) ++ set_vc_hi_font(vc, false); ++ else if (!vc->vc_hi_font_mask && cnt == 512) ++ set_vc_hi_font(vc, true); + + if (resize) { + int cols, rows; diff --git a/queue-4.4/igb-add-i211-to-i210-phy-workaround.patch b/queue-4.4/igb-add-i211-to-i210-phy-workaround.patch new file mode 100644 index 00000000000..2ed63a5927b --- /dev/null +++ b/queue-4.4/igb-add-i211-to-i210-phy-workaround.patch @@ -0,0 +1,40 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:03 +0530 +Subject: igb: add i211 to i210 PHY workaround +To: stable@vger.kernel.org +Cc: Todd Fujinaka , Jeff Kirsher , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-4-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Todd Fujinaka + +[ Upstream commit 5bc8c230e2a993b49244f9457499f17283da9ec7 ] + +i210 and i211 share the same PHY but have different PCI IDs. Don't +forget i211 for any i210 workarounds. + +Signed-off-by: Todd Fujinaka +Tested-by: Aaron Brown +Signed-off-by: Jeff Kirsher +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/igb/e1000_phy.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/intel/igb/e1000_phy.c ++++ b/drivers/net/ethernet/intel/igb/e1000_phy.c +@@ -78,7 +78,7 @@ s32 igb_get_phy_id(struct e1000_hw *hw) + u16 phy_id; + + /* ensure PHY page selection to fix misconfigured i210 */ +- if (hw->mac.type == e1000_i210) ++ if ((hw->mac.type == e1000_i210) || (hw->mac.type == e1000_i211)) + phy->ops.write_reg(hw, I347AT4_PAGE_SELECT, 0); + + ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id); diff --git a/queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch b/queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch new file mode 100644 index 00000000000..830b6970ab3 --- /dev/null +++ b/queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch @@ -0,0 +1,45 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:02 +0530 +Subject: igb: Workaround for igb i210 firmware issue +To: stable@vger.kernel.org +Cc: Chris J Arges , Jeff Kirsher , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-3-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Chris J Arges + +[ Upstream commit 4e684f59d760a2c7c716bb60190783546e2d08a1 ] + +Sometimes firmware may not properly initialize I347AT4_PAGE_SELECT causing +the probe of an igb i210 NIC to fail. This patch adds an addition zeroing +of this register during igb_get_phy_id to workaround this issue. + +Thanks for Jochen Henneberg for the idea and original patch. + +Signed-off-by: Chris J Arges +Tested-by: Aaron Brown +Signed-off-by: Jeff Kirsher +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/igb/e1000_phy.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/net/ethernet/intel/igb/e1000_phy.c ++++ b/drivers/net/ethernet/intel/igb/e1000_phy.c +@@ -77,6 +77,10 @@ s32 igb_get_phy_id(struct e1000_hw *hw) + s32 ret_val = 0; + u16 phy_id; + ++ /* ensure PHY page selection to fix misconfigured i210 */ ++ if (hw->mac.type == e1000_i210) ++ phy->ops.write_reg(hw, I347AT4_PAGE_SELECT, 0); ++ + ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id); + if (ret_val) + goto out; diff --git a/queue-4.4/pci-add-comments-about-rom-bar-updating.patch b/queue-4.4/pci-add-comments-about-rom-bar-updating.patch new file mode 100644 index 00000000000..f12a6623ee3 --- /dev/null +++ b/queue-4.4/pci-add-comments-about-rom-bar-updating.patch @@ -0,0 +1,73 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:07 +0530 +Subject: PCI: Add comments about ROM BAR updating +To: stable@vger.kernel.org +Cc: Bjorn Helgaas , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-8-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Bjorn Helgaas + +[ Upstream commit 0b457dde3cf8b7c76a60f8e960f21bbd4abdc416 ] + +pci_update_resource() updates a hardware BAR so its address matches the +kernel's struct resource UNLESS it's a disabled ROM BAR. We only update +those when we enable the ROM. + +It's not obvious from the code why ROM BARs should be handled specially. +Apparently there are Matrox devices with defective ROM BARs that read as +zero when disabled. That means that if pci_enable_rom() reads the disabled +BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and +writes it back, it would enable the ROM at address zero. + +Add comments and references to explain why we can't make the code look more +rational. + +The code changes are from 755528c860b0 ("Ignore disabled ROM resources at +setup") and 8085ce084c0f ("[PATCH] Fix PCI ROM mapping"). + +Link: https://lkml.org/lkml/2005/8/30/138 +Signed-off-by: Bjorn Helgaas +Reviewed-by: Gavin Shan +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman + [sumits: minor fixup in rom.c for 4.4.y] +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/rom.c | 5 +++++ + drivers/pci/setup-res.c | 6 ++++++ + 2 files changed, 11 insertions(+) + +--- a/drivers/pci/rom.c ++++ b/drivers/pci/rom.c +@@ -31,6 +31,11 @@ int pci_enable_rom(struct pci_dev *pdev) + if (!res->flags) + return -1; + ++ /* ++ * Ideally pci_update_resource() would update the ROM BAR address, ++ * and we would only set the enable bit here. But apparently some ++ * devices have buggy ROM BARs that read as zero when disabled. ++ */ + pcibios_resource_to_bus(pdev->bus, ®ion, res); + pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_addr); + rom_addr &= ~PCI_ROM_ADDRESS_MASK; +--- a/drivers/pci/setup-res.c ++++ b/drivers/pci/setup-res.c +@@ -68,6 +68,12 @@ static void pci_std_update_resource(stru + if (resno < PCI_ROM_RESOURCE) { + reg = PCI_BASE_ADDRESS_0 + 4 * resno; + } else if (resno == PCI_ROM_RESOURCE) { ++ ++ /* ++ * Apparently some Matrox devices have ROM BARs that read ++ * as zero when disabled, so don't update ROM BARs unless ++ * they're enabled. See https://lkml.org/lkml/2005/8/30/138. ++ */ + if (!(res->flags & IORESOURCE_ROM_ENABLE)) + return; + diff --git a/queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch b/queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch new file mode 100644 index 00000000000..33dbdcec8d5 --- /dev/null +++ b/queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch @@ -0,0 +1,42 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:08 +0530 +Subject: PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLE +To: stable@vger.kernel.org +Cc: Bjorn Helgaas , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-9-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Bjorn Helgaas + +[ Upstream commit 7a6d312b50e63f598f5b5914c4fd21878ac2b595 ] + +Remove the assumption that IORESOURCE_ROM_ENABLE == PCI_ROM_ADDRESS_ENABLE. +PCI_ROM_ADDRESS_ENABLE is the ROM enable bit defined by the PCI spec, so if +we're reading or writing a BAR register value, that's what we should use. +IORESOURCE_ROM_ENABLE is a corresponding bit in struct resource flags. + +Signed-off-by: Bjorn Helgaas +Reviewed-by: Gavin Shan +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/probe.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/pci/probe.c ++++ b/drivers/pci/probe.c +@@ -226,7 +226,8 @@ int __pci_read_base(struct pci_dev *dev, + mask64 = (u32)PCI_BASE_ADDRESS_MEM_MASK; + } + } else { +- res->flags |= (l & IORESOURCE_ROM_ENABLE); ++ if (l & PCI_ROM_ADDRESS_ENABLE) ++ res->flags |= IORESOURCE_ROM_ENABLE; + l64 = l & PCI_ROM_ADDRESS_MASK; + sz64 = sz & PCI_ROM_ADDRESS_MASK; + mask64 = (u32)PCI_ROM_ADDRESS_MASK; diff --git a/queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch b/queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch new file mode 100644 index 00000000000..d93a1d90732 --- /dev/null +++ b/queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch @@ -0,0 +1,70 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:12 +0530 +Subject: PCI: Do any VF BAR updates before enabling the BARs +To: stable@vger.kernel.org +Cc: Gavin Shan , Bjorn Helgaas , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-13-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Gavin Shan + +[ Upstream commit f40ec3c748c6912f6266c56a7f7992de61b255ed ] + +Previously we enabled VFs and enable their memory space before calling +pcibios_sriov_enable(). But pcibios_sriov_enable() may update the VF BARs: +for example, on PPC PowerNV we may change them to manage the association of +VFs to PEs. + +Because 64-bit BARs cannot be updated atomically, it's unsafe to update +them while they're enabled. The half-updated state may conflict with other +devices in the system. + +Call pcibios_sriov_enable() before enabling the VFs so any BAR updates +happen while the VF BARs are disabled. + +[bhelgaas: changelog] +Tested-by: Carol Soto +Signed-off-by: Gavin Shan +Signed-off-by: Bjorn Helgaas + +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/iov.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/drivers/pci/iov.c ++++ b/drivers/pci/iov.c +@@ -303,13 +303,6 @@ static int sriov_enable(struct pci_dev * + return rc; + } + +- pci_iov_set_numvfs(dev, nr_virtfn); +- iov->ctrl |= PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE; +- pci_cfg_access_lock(dev); +- pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl); +- msleep(100); +- pci_cfg_access_unlock(dev); +- + iov->initial_VFs = initial; + if (nr_virtfn < initial) + initial = nr_virtfn; +@@ -320,6 +313,13 @@ static int sriov_enable(struct pci_dev * + goto err_pcibios; + } + ++ pci_iov_set_numvfs(dev, nr_virtfn); ++ iov->ctrl |= PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE; ++ pci_cfg_access_lock(dev); ++ pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl); ++ msleep(100); ++ pci_cfg_access_unlock(dev); ++ + for (i = 0; i < initial; i++) { + rc = virtfn_add(dev, i, 0); + if (rc) diff --git a/queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch b/queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch new file mode 100644 index 00000000000..862e8cf70ac --- /dev/null +++ b/queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch @@ -0,0 +1,62 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:09 +0530 +Subject: PCI: Don't update VF BARs while VF memory space is enabled +To: stable@vger.kernel.org +Cc: Bjorn Helgaas , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-10-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Bjorn Helgaas + +[ Upstream commit 546ba9f8f22f71b0202b6ba8967be5cc6dae4e21 ] + +If we update a VF BAR while it's enabled, there are two potential problems: + + 1) Any driver that's using the VF has a cached BAR value that is stale + after the update, and + + 2) We can't update 64-bit BARs atomically, so the intermediate state + (new lower dword with old upper dword) may conflict with another + device, and an access by a driver unrelated to the VF may cause a bus + error. + +Warn about attempts to update VF BARs while they are enabled. This is a +programming error, so use dev_WARN() to get a backtrace. + +Signed-off-by: Bjorn Helgaas +Reviewed-by: Gavin Shan +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/iov.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/pci/iov.c ++++ b/drivers/pci/iov.c +@@ -567,6 +567,7 @@ void pci_iov_update_resource(struct pci_ + struct resource *res = dev->resource + resno; + int vf_bar = resno - PCI_IOV_RESOURCES; + struct pci_bus_region region; ++ u16 cmd; + u32 new; + int reg; + +@@ -578,6 +579,13 @@ void pci_iov_update_resource(struct pci_ + if (!iov) + return; + ++ pci_read_config_word(dev, iov->pos + PCI_SRIOV_CTRL, &cmd); ++ if ((cmd & PCI_SRIOV_CTRL_VFE) && (cmd & PCI_SRIOV_CTRL_MSE)) { ++ dev_WARN(&dev->dev, "can't update enabled VF BAR%d %pR\n", ++ vf_bar, res); ++ return; ++ } ++ + /* + * Ignore unimplemented BARs, unused resource slots for 64-bit + * BARs, and non-movable resources, e.g., those described via diff --git a/queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch b/queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch new file mode 100644 index 00000000000..1f4a314513a --- /dev/null +++ b/queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch @@ -0,0 +1,61 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:11 +0530 +Subject: PCI: Ignore BAR updates on virtual functions +To: stable@vger.kernel.org +Cc: Bjorn Helgaas , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-12-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Bjorn Helgaas + +[ Upstream commit 63880b230a4af502c56dde3d4588634c70c66006 ] + +VF BARs are read-only zero, so updating VF BARs will not have any effect. +See the SR-IOV spec r1.1, sec 3.4.1.11. + +We already ignore these updates because of 70675e0b6a1a ("PCI: Don't try to +restore VF BARs"); this merely restructures it slightly to make it easier +to split updates for standard and SR-IOV BARs. + +Signed-off-by: Bjorn Helgaas +Reviewed-by: Gavin Shan +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pci.c | 4 ---- + drivers/pci/setup-res.c | 5 ++--- + 2 files changed, 2 insertions(+), 7 deletions(-) + +--- a/drivers/pci/pci.c ++++ b/drivers/pci/pci.c +@@ -519,10 +519,6 @@ static void pci_restore_bars(struct pci_ + { + int i; + +- /* Per SR-IOV spec 3.4.1.11, VF BARs are RO zero */ +- if (dev->is_virtfn) +- return; +- + for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) + pci_update_resource(dev, i); + } +--- a/drivers/pci/setup-res.c ++++ b/drivers/pci/setup-res.c +@@ -34,10 +34,9 @@ static void pci_std_update_resource(stru + int reg; + struct resource *res = dev->resource + resno; + +- if (dev->is_virtfn) { +- dev_warn(&dev->dev, "can't update VF BAR%d\n", resno); ++ /* Per SR-IOV spec 3.4.1.11, VF BARs are RO zero */ ++ if (dev->is_virtfn) + return; +- } + + /* + * Ignore resources for unimplemented BARs and unused resource slots diff --git a/queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch b/queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch new file mode 100644 index 00000000000..db98dfea4c9 --- /dev/null +++ b/queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch @@ -0,0 +1,161 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:06 +0530 +Subject: PCI: Remove pci_resource_bar() and pci_iov_resource_bar() +To: stable@vger.kernel.org +Cc: Bjorn Helgaas , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-7-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Bjorn Helgaas + +[ Upstream commit 286c2378aaccc7343ebf17ec6cd86567659caf70 ] + +pci_std_update_resource() only deals with standard BARs, so we don't have +to worry about the complications of VF BARs in an SR-IOV capability. + +Compute the BAR address inline and remove pci_resource_bar(). That makes +pci_iov_resource_bar() unused, so remove that as well. + +Signed-off-by: Bjorn Helgaas +Reviewed-by: Gavin Shan +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/iov.c | 18 ------------------ + drivers/pci/pci.c | 30 ------------------------------ + drivers/pci/pci.h | 6 ------ + drivers/pci/setup-res.c | 13 +++++++------ + 4 files changed, 7 insertions(+), 60 deletions(-) + +--- a/drivers/pci/iov.c ++++ b/drivers/pci/iov.c +@@ -555,24 +555,6 @@ void pci_iov_release(struct pci_dev *dev + } + + /** +- * pci_iov_resource_bar - get position of the SR-IOV BAR +- * @dev: the PCI device +- * @resno: the resource number +- * +- * Returns position of the BAR encapsulated in the SR-IOV capability. +- */ +-int pci_iov_resource_bar(struct pci_dev *dev, int resno) +-{ +- if (resno < PCI_IOV_RESOURCES || resno > PCI_IOV_RESOURCE_END) +- return 0; +- +- BUG_ON(!dev->is_physfn); +- +- return dev->sriov->pos + PCI_SRIOV_BAR + +- 4 * (resno - PCI_IOV_RESOURCES); +-} +- +-/** + * pci_iov_update_resource - update a VF BAR + * @dev: the PCI device + * @resno: the resource number +--- a/drivers/pci/pci.c ++++ b/drivers/pci/pci.c +@@ -4472,36 +4472,6 @@ int pci_select_bars(struct pci_dev *dev, + } + EXPORT_SYMBOL(pci_select_bars); + +-/** +- * pci_resource_bar - get position of the BAR associated with a resource +- * @dev: the PCI device +- * @resno: the resource number +- * @type: the BAR type to be filled in +- * +- * Returns BAR position in config space, or 0 if the BAR is invalid. +- */ +-int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type *type) +-{ +- int reg; +- +- if (resno < PCI_ROM_RESOURCE) { +- *type = pci_bar_unknown; +- return PCI_BASE_ADDRESS_0 + 4 * resno; +- } else if (resno == PCI_ROM_RESOURCE) { +- *type = pci_bar_mem32; +- return dev->rom_base_reg; +- } else if (resno < PCI_BRIDGE_RESOURCES) { +- /* device specific resource */ +- *type = pci_bar_unknown; +- reg = pci_iov_resource_bar(dev, resno); +- if (reg) +- return reg; +- } +- +- dev_err(&dev->dev, "BAR %d: invalid resource\n", resno); +- return 0; +-} +- + /* Some architectures require additional programming to enable VGA */ + static arch_set_vga_state_t arch_set_vga_state; + +--- a/drivers/pci/pci.h ++++ b/drivers/pci/pci.h +@@ -232,7 +232,6 @@ bool pci_bus_read_dev_vendor_id(struct p + int pci_setup_device(struct pci_dev *dev); + int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, + struct resource *res, unsigned int reg); +-int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type *type); + void pci_configure_ari(struct pci_dev *dev); + void __pci_bus_size_bridges(struct pci_bus *bus, + struct list_head *realloc_head); +@@ -276,7 +275,6 @@ static inline void pci_restore_ats_state + #ifdef CONFIG_PCI_IOV + int pci_iov_init(struct pci_dev *dev); + void pci_iov_release(struct pci_dev *dev); +-int pci_iov_resource_bar(struct pci_dev *dev, int resno); + void pci_iov_update_resource(struct pci_dev *dev, int resno); + resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev, int resno); + void pci_restore_iov_state(struct pci_dev *dev); +@@ -291,10 +289,6 @@ static inline void pci_iov_release(struc + + { + } +-static inline int pci_iov_resource_bar(struct pci_dev *dev, int resno) +-{ +- return 0; +-} + static inline void pci_restore_iov_state(struct pci_dev *dev) + { + } +--- a/drivers/pci/setup-res.c ++++ b/drivers/pci/setup-res.c +@@ -32,7 +32,6 @@ static void pci_std_update_resource(stru + u16 cmd; + u32 new, check, mask; + int reg; +- enum pci_bar_type type; + struct resource *res = dev->resource + resno; + + if (dev->is_virtfn) { +@@ -66,14 +65,16 @@ static void pci_std_update_resource(stru + else + mask = (u32)PCI_BASE_ADDRESS_MEM_MASK; + +- reg = pci_resource_bar(dev, resno, &type); +- if (!reg) +- return; +- if (type != pci_bar_unknown) { ++ if (resno < PCI_ROM_RESOURCE) { ++ reg = PCI_BASE_ADDRESS_0 + 4 * resno; ++ } else if (resno == PCI_ROM_RESOURCE) { + if (!(res->flags & IORESOURCE_ROM_ENABLE)) + return; ++ ++ reg = dev->rom_base_reg; + new |= PCI_ROM_ADDRESS_ENABLE; +- } ++ } else ++ return; + + /* + * We can't update a 64-bit BAR atomically, so when possible, diff --git a/queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch b/queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch new file mode 100644 index 00000000000..f1219b5010e --- /dev/null +++ b/queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch @@ -0,0 +1,140 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:05 +0530 +Subject: PCI: Separate VF BAR updates from standard BAR updates +To: stable@vger.kernel.org +Cc: Bjorn Helgaas , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-6-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Bjorn Helgaas + +[ Upstream commit 6ffa2489c51da77564a0881a73765ea2169f955d ] + +Previously pci_update_resource() used the same code path for updating +standard BARs and VF BARs in SR-IOV capabilities. + +Split the VF BAR update into a new pci_iov_update_resource() internal +interface, which makes it simpler to compute the BAR address (we can get +rid of pci_resource_bar() and pci_iov_resource_bar()). + +This patch: + + - Renames pci_update_resource() to pci_std_update_resource(), + - Adds pci_iov_update_resource(), + - Makes pci_update_resource() a wrapper that calls the appropriate one, + +No functional change intended. + +Signed-off-by: Bjorn Helgaas +Reviewed-by: Gavin Shan +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/iov.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++ + drivers/pci/pci.h | 1 + drivers/pci/setup-res.c | 13 ++++++++++-- + 3 files changed, 62 insertions(+), 2 deletions(-) + +--- a/drivers/pci/iov.c ++++ b/drivers/pci/iov.c +@@ -572,6 +572,56 @@ int pci_iov_resource_bar(struct pci_dev + 4 * (resno - PCI_IOV_RESOURCES); + } + ++/** ++ * pci_iov_update_resource - update a VF BAR ++ * @dev: the PCI device ++ * @resno: the resource number ++ * ++ * Update a VF BAR in the SR-IOV capability of a PF. ++ */ ++void pci_iov_update_resource(struct pci_dev *dev, int resno) ++{ ++ struct pci_sriov *iov = dev->is_physfn ? dev->sriov : NULL; ++ struct resource *res = dev->resource + resno; ++ int vf_bar = resno - PCI_IOV_RESOURCES; ++ struct pci_bus_region region; ++ u32 new; ++ int reg; ++ ++ /* ++ * The generic pci_restore_bars() path calls this for all devices, ++ * including VFs and non-SR-IOV devices. If this is not a PF, we ++ * have nothing to do. ++ */ ++ if (!iov) ++ return; ++ ++ /* ++ * Ignore unimplemented BARs, unused resource slots for 64-bit ++ * BARs, and non-movable resources, e.g., those described via ++ * Enhanced Allocation. ++ */ ++ if (!res->flags) ++ return; ++ ++ if (res->flags & IORESOURCE_UNSET) ++ return; ++ ++ if (res->flags & IORESOURCE_PCI_FIXED) ++ return; ++ ++ pcibios_resource_to_bus(dev->bus, ®ion, res); ++ new = region.start; ++ new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK; ++ ++ reg = iov->pos + PCI_SRIOV_BAR + 4 * vf_bar; ++ pci_write_config_dword(dev, reg, new); ++ if (res->flags & IORESOURCE_MEM_64) { ++ new = region.start >> 16 >> 16; ++ pci_write_config_dword(dev, reg + 4, new); ++ } ++} ++ + resource_size_t __weak pcibios_iov_resource_alignment(struct pci_dev *dev, + int resno) + { +--- a/drivers/pci/pci.h ++++ b/drivers/pci/pci.h +@@ -277,6 +277,7 @@ static inline void pci_restore_ats_state + int pci_iov_init(struct pci_dev *dev); + void pci_iov_release(struct pci_dev *dev); + int pci_iov_resource_bar(struct pci_dev *dev, int resno); ++void pci_iov_update_resource(struct pci_dev *dev, int resno); + resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev, int resno); + void pci_restore_iov_state(struct pci_dev *dev); + int pci_iov_bus_range(struct pci_bus *bus); +--- a/drivers/pci/setup-res.c ++++ b/drivers/pci/setup-res.c +@@ -25,8 +25,7 @@ + #include + #include "pci.h" + +- +-void pci_update_resource(struct pci_dev *dev, int resno) ++static void pci_std_update_resource(struct pci_dev *dev, int resno) + { + struct pci_bus_region region; + bool disable; +@@ -110,6 +109,16 @@ void pci_update_resource(struct pci_dev + pci_write_config_word(dev, PCI_COMMAND, cmd); + } + ++void pci_update_resource(struct pci_dev *dev, int resno) ++{ ++ if (resno <= PCI_ROM_RESOURCE) ++ pci_std_update_resource(dev, resno); ++#ifdef CONFIG_PCI_IOV ++ else if (resno >= PCI_IOV_RESOURCES && resno <= PCI_IOV_RESOURCE_END) ++ pci_iov_update_resource(dev, resno); ++#endif ++} ++ + int pci_claim_resource(struct pci_dev *dev, int resource) + { + struct resource *res = &dev->resource[resource]; diff --git a/queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch b/queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch new file mode 100644 index 00000000000..212f5f5ef82 --- /dev/null +++ b/queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch @@ -0,0 +1,59 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:10 +0530 +Subject: PCI: Update BARs using property bits appropriate for type +To: stable@vger.kernel.org +Cc: Bjorn Helgaas , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-11-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Bjorn Helgaas + +[ Upstream commit 45d004f4afefdd8d79916ee6d97a9ecd94bb1ffe ] + +The BAR property bits (0-3 for memory BARs, 0-1 for I/O BARs) are supposed +to be read-only, but we do save them in res->flags and include them when +updating the BAR. + +Mask the I/O property bits with ~PCI_BASE_ADDRESS_IO_MASK (0x3) instead of +PCI_REGION_FLAG_MASK (0xf) to make it obvious that we can't corrupt bits +2-3 of I/O addresses. + +Use PCI_ROM_ADDRESS_MASK for ROM BARs. This means we'll only check the top +21 bits (instead of the 28 bits we used to check) of a ROM BAR to see if +the update was successful. + +Signed-off-by: Bjorn Helgaas +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/setup-res.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + +--- a/drivers/pci/setup-res.c ++++ b/drivers/pci/setup-res.c +@@ -58,12 +58,17 @@ static void pci_std_update_resource(stru + return; + + pcibios_resource_to_bus(dev->bus, ®ion, res); ++ new = region.start; + +- new = region.start | (res->flags & PCI_REGION_FLAG_MASK); +- if (res->flags & IORESOURCE_IO) ++ if (res->flags & IORESOURCE_IO) { + mask = (u32)PCI_BASE_ADDRESS_IO_MASK; +- else ++ new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK; ++ } else if (resno == PCI_ROM_RESOURCE) { ++ mask = (u32)PCI_ROM_ADDRESS_MASK; ++ } else { + mask = (u32)PCI_BASE_ADDRESS_MEM_MASK; ++ new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK; ++ } + + if (resno < PCI_ROM_RESOURCE) { + reg = PCI_BASE_ADDRESS_0 + 4 * resno; diff --git a/queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch b/queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch new file mode 100644 index 00000000000..a130685148a --- /dev/null +++ b/queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch @@ -0,0 +1,48 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:15 +0530 +Subject: s390/zcrypt: Introduce CEX6 toleration +To: stable@vger.kernel.org +Cc: Harald Freudenberger , Martin Schwidefsky , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-16-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Harald Freudenberger + +[ Upstream commit b3e8652bcbfa04807e44708d4d0c8cdad39c9215 ] + +Signed-off-by: Harald Freudenberger +Signed-off-by: Martin Schwidefsky +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/s390/crypto/ap_bus.c | 3 +++ + drivers/s390/crypto/ap_bus.h | 1 + + 2 files changed, 4 insertions(+) + +--- a/drivers/s390/crypto/ap_bus.c ++++ b/drivers/s390/crypto/ap_bus.c +@@ -1651,6 +1651,9 @@ static void ap_scan_bus(struct work_stru + ap_dev->queue_depth = queue_depth; + ap_dev->raw_hwtype = device_type; + ap_dev->device_type = device_type; ++ /* CEX6 toleration: map to CEX5 */ ++ if (device_type == AP_DEVICE_TYPE_CEX6) ++ ap_dev->device_type = AP_DEVICE_TYPE_CEX5; + ap_dev->functions = device_functions; + spin_lock_init(&ap_dev->lock); + INIT_LIST_HEAD(&ap_dev->pendingq); +--- a/drivers/s390/crypto/ap_bus.h ++++ b/drivers/s390/crypto/ap_bus.h +@@ -105,6 +105,7 @@ static inline int ap_test_bit(unsigned i + #define AP_DEVICE_TYPE_CEX3C 9 + #define AP_DEVICE_TYPE_CEX4 10 + #define AP_DEVICE_TYPE_CEX5 11 ++#define AP_DEVICE_TYPE_CEX6 12 + + /* + * Known function facilities diff --git a/queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch b/queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch new file mode 100644 index 00000000000..49fb859e405 --- /dev/null +++ b/queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch @@ -0,0 +1,113 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:19 +0530 +Subject: serial: 8250_pci: Detach low-level driver during PCI error recovery +To: stable@vger.kernel.org +Cc: Gabriel Krisman Bertazi , Greg Kroah-Hartman , Sasha Levin , Sumit Semwal +Message-ID: <1490458699-24484-20-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Gabriel Krisman Bertazi + +[ Upstream commit f209fa03fc9d131b3108c2e4936181eabab87416 ] + +During a PCI error recovery, like the ones provoked by EEH in the ppc64 +platform, all IO to the device must be blocked while the recovery is +completed. Current 8250_pci implementation only suspends the port +instead of detaching it, which doesn't prevent incoming accesses like +TIOCMGET and TIOCMSET calls from reaching the device. Those end up +racing with the EEH recovery, crashing it. Similar races were also +observed when opening the device and when shutting it down during +recovery. + +This patch implements a more robust IO blockage for the 8250_pci +recovery by unregistering the port at the beginning of the procedure and +re-adding it afterwards. Since the port is detached from the uart +layer, we can be sure that no request will make through to the device +during recovery. This is similar to the solution used by the JSM serial +driver. + +I thank Peter Hurley for valuable input on +this one over one year ago. + +Signed-off-by: Gabriel Krisman Bertazi +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/8250/8250_pci.c | 23 +++++++++++++++++++---- + 1 file changed, 19 insertions(+), 4 deletions(-) + +--- a/drivers/tty/serial/8250/8250_pci.c ++++ b/drivers/tty/serial/8250/8250_pci.c +@@ -57,6 +57,7 @@ struct serial_private { + unsigned int nr; + void __iomem *remapped_bar[PCI_NUM_BAR_RESOURCES]; + struct pci_serial_quirk *quirk; ++ const struct pciserial_board *board; + int line[0]; + }; + +@@ -4058,6 +4059,7 @@ pciserial_init_ports(struct pci_dev *dev + } + } + priv->nr = i; ++ priv->board = board; + return priv; + + err_deinit: +@@ -4068,7 +4070,7 @@ err_out: + } + EXPORT_SYMBOL_GPL(pciserial_init_ports); + +-void pciserial_remove_ports(struct serial_private *priv) ++void pciserial_detach_ports(struct serial_private *priv) + { + struct pci_serial_quirk *quirk; + int i; +@@ -4088,7 +4090,11 @@ void pciserial_remove_ports(struct seria + quirk = find_quirk(priv->dev); + if (quirk->exit) + quirk->exit(priv->dev); ++} + ++void pciserial_remove_ports(struct serial_private *priv) ++{ ++ pciserial_detach_ports(priv); + kfree(priv); + } + EXPORT_SYMBOL_GPL(pciserial_remove_ports); +@@ -5819,7 +5825,7 @@ static pci_ers_result_t serial8250_io_er + return PCI_ERS_RESULT_DISCONNECT; + + if (priv) +- pciserial_suspend_ports(priv); ++ pciserial_detach_ports(priv); + + pci_disable_device(dev); + +@@ -5844,9 +5850,18 @@ static pci_ers_result_t serial8250_io_sl + static void serial8250_io_resume(struct pci_dev *dev) + { + struct serial_private *priv = pci_get_drvdata(dev); ++ const struct pciserial_board *board; + +- if (priv) +- pciserial_resume_ports(priv); ++ if (!priv) ++ return; ++ ++ board = priv->board; ++ kfree(priv); ++ priv = pciserial_init_ports(dev, board); ++ ++ if (!IS_ERR(priv)) { ++ pci_set_drvdata(dev, priv); ++ } + } + + static const struct pci_error_handlers serial8250_err_handler = { diff --git a/queue-4.4/series b/queue-4.4/series index f5a0fc329fb..c76a8b31f71 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -52,3 +52,25 @@ xfs-don-t-allow-di_size-with-high-bit-set.patch xfs-fix-up-xfs_swap_extent_forks-inline-extent-handling.patch nl80211-fix-dumpit-error-path-rtnl-deadlocks.patch usb-usbtmc-add-missing-endpoint-sanity-check.patch +xfs-clear-_xbf_pages-from-buffers-when-readahead-page.patch +xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch +igb-workaround-for-igb-i210-firmware-issue.patch +igb-add-i211-to-i210-phy-workaround.patch +x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch +pci-separate-vf-bar-updates-from-standard-bar-updates.patch +pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch +pci-add-comments-about-rom-bar-updating.patch +pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch +pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch +pci-update-bars-using-property-bits-appropriate-for-type.patch +pci-ignore-bar-updates-on-virtual-functions.patch +pci-do-any-vf-bar-updates-before-enabling-the-bars.patch +vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch +block-allow-write_same-commands-with-the-sg_io-ioctl.patch +s390-zcrypt-introduce-cex6-toleration.patch +uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch +acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch +acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch +serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch +fbcon-fix-vc-attr-at-deinit.patch +crypto-algif_hash-avoid-zero-sized-array.patch diff --git a/queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch b/queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch new file mode 100644 index 00000000000..9d95b2045c8 --- /dev/null +++ b/queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch @@ -0,0 +1,179 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:16 +0530 +Subject: uvcvideo: uvc_scan_fallback() for webcams with broken chain +To: stable@vger.kernel.org +Cc: Henrik Ingo , Laurent Pinchart , Mauro Carvalho Chehab , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-17-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Henrik Ingo + +[ Upstream commit e950267ab802c8558f1100eafd4087fd039ad634 ] + +Some devices have invalid baSourceID references, causing uvc_scan_chain() +to fail, but if we just take the entities we can find and put them +together in the most sensible chain we can think of, turns out they do +work anyway. Note: This heuristic assumes there is a single chain. + +At the time of writing, devices known to have such a broken chain are + - Acer Integrated Camera (5986:055a) + - Realtek rtl157a7 (0bda:57a7) + +Signed-off-by: Henrik Ingo +Signed-off-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/usb/uvc/uvc_driver.c | 118 +++++++++++++++++++++++++++++++++++-- + 1 file changed, 112 insertions(+), 6 deletions(-) + +--- a/drivers/media/usb/uvc/uvc_driver.c ++++ b/drivers/media/usb/uvc/uvc_driver.c +@@ -1595,6 +1595,114 @@ static const char *uvc_print_chain(struc + return buffer; + } + ++static struct uvc_video_chain *uvc_alloc_chain(struct uvc_device *dev) ++{ ++ struct uvc_video_chain *chain; ++ ++ chain = kzalloc(sizeof(*chain), GFP_KERNEL); ++ if (chain == NULL) ++ return NULL; ++ ++ INIT_LIST_HEAD(&chain->entities); ++ mutex_init(&chain->ctrl_mutex); ++ chain->dev = dev; ++ v4l2_prio_init(&chain->prio); ++ ++ return chain; ++} ++ ++/* ++ * Fallback heuristic for devices that don't connect units and terminals in a ++ * valid chain. ++ * ++ * Some devices have invalid baSourceID references, causing uvc_scan_chain() ++ * to fail, but if we just take the entities we can find and put them together ++ * in the most sensible chain we can think of, turns out they do work anyway. ++ * Note: This heuristic assumes there is a single chain. ++ * ++ * At the time of writing, devices known to have such a broken chain are ++ * - Acer Integrated Camera (5986:055a) ++ * - Realtek rtl157a7 (0bda:57a7) ++ */ ++static int uvc_scan_fallback(struct uvc_device *dev) ++{ ++ struct uvc_video_chain *chain; ++ struct uvc_entity *iterm = NULL; ++ struct uvc_entity *oterm = NULL; ++ struct uvc_entity *entity; ++ struct uvc_entity *prev; ++ ++ /* ++ * Start by locating the input and output terminals. We only support ++ * devices with exactly one of each for now. ++ */ ++ list_for_each_entry(entity, &dev->entities, list) { ++ if (UVC_ENTITY_IS_ITERM(entity)) { ++ if (iterm) ++ return -EINVAL; ++ iterm = entity; ++ } ++ ++ if (UVC_ENTITY_IS_OTERM(entity)) { ++ if (oterm) ++ return -EINVAL; ++ oterm = entity; ++ } ++ } ++ ++ if (iterm == NULL || oterm == NULL) ++ return -EINVAL; ++ ++ /* Allocate the chain and fill it. */ ++ chain = uvc_alloc_chain(dev); ++ if (chain == NULL) ++ return -ENOMEM; ++ ++ if (uvc_scan_chain_entity(chain, oterm) < 0) ++ goto error; ++ ++ prev = oterm; ++ ++ /* ++ * Add all Processing and Extension Units with two pads. The order ++ * doesn't matter much, use reverse list traversal to connect units in ++ * UVC descriptor order as we build the chain from output to input. This ++ * leads to units appearing in the order meant by the manufacturer for ++ * the cameras known to require this heuristic. ++ */ ++ list_for_each_entry_reverse(entity, &dev->entities, list) { ++ if (entity->type != UVC_VC_PROCESSING_UNIT && ++ entity->type != UVC_VC_EXTENSION_UNIT) ++ continue; ++ ++ if (entity->num_pads != 2) ++ continue; ++ ++ if (uvc_scan_chain_entity(chain, entity) < 0) ++ goto error; ++ ++ prev->baSourceID[0] = entity->id; ++ prev = entity; ++ } ++ ++ if (uvc_scan_chain_entity(chain, iterm) < 0) ++ goto error; ++ ++ prev->baSourceID[0] = iterm->id; ++ ++ list_add_tail(&chain->list, &dev->chains); ++ ++ uvc_trace(UVC_TRACE_PROBE, ++ "Found a video chain by fallback heuristic (%s).\n", ++ uvc_print_chain(chain)); ++ ++ return 0; ++ ++error: ++ kfree(chain); ++ return -EINVAL; ++} ++ + /* + * Scan the device for video chains and register video devices. + * +@@ -1617,15 +1725,10 @@ static int uvc_scan_device(struct uvc_de + if (term->chain.next || term->chain.prev) + continue; + +- chain = kzalloc(sizeof(*chain), GFP_KERNEL); ++ chain = uvc_alloc_chain(dev); + if (chain == NULL) + return -ENOMEM; + +- INIT_LIST_HEAD(&chain->entities); +- mutex_init(&chain->ctrl_mutex); +- chain->dev = dev; +- v4l2_prio_init(&chain->prio); +- + term->flags |= UVC_ENTITY_FLAG_DEFAULT; + + if (uvc_scan_chain(chain, term) < 0) { +@@ -1639,6 +1742,9 @@ static int uvc_scan_device(struct uvc_de + list_add_tail(&chain->list, &dev->chains); + } + ++ if (list_empty(&dev->chains)) ++ uvc_scan_fallback(dev); ++ + if (list_empty(&dev->chains)) { + uvc_printk(KERN_INFO, "No valid video chain found.\n"); + return -1; diff --git a/queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch b/queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch new file mode 100644 index 00000000000..2d9e4efda7e --- /dev/null +++ b/queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch @@ -0,0 +1,85 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:13 +0530 +Subject: vfio/spapr: Postpone allocation of userspace version of TCE table +To: stable@vger.kernel.org +Cc: Alexey Kardashevskiy , Michael Ellerman , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-14-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Alexey Kardashevskiy + +[ Upstream commit 39701e56f5f16ea0cf8fc9e8472e645f8de91d23 ] + +The iommu_table struct manages a hardware TCE table and a vmalloc'd +table with corresponding userspace addresses. Both are allocated when +the default DMA window is created and this happens when the very first +group is attached to a container. + +As we are going to allow the userspace to configure container in one +memory context and pas container fd to another, we have to postpones +such allocations till a container fd is passed to the destination +user process so we would account locked memory limit against the actual +container user constrainsts. + +This postpones the it_userspace array allocation till it is used first +time for mapping. The unmapping patch already checks if the array is +allocated. + +Signed-off-by: Alexey Kardashevskiy +Reviewed-by: David Gibson +Acked-by: Alex Williamson +Signed-off-by: Michael Ellerman +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/vfio/vfio_iommu_spapr_tce.c | 20 +++++++------------- + 1 file changed, 7 insertions(+), 13 deletions(-) + +--- a/drivers/vfio/vfio_iommu_spapr_tce.c ++++ b/drivers/vfio/vfio_iommu_spapr_tce.c +@@ -511,6 +511,12 @@ static long tce_iommu_build_v2(struct tc + unsigned long hpa; + enum dma_data_direction dirtmp; + ++ if (!tbl->it_userspace) { ++ ret = tce_iommu_userspace_view_alloc(tbl); ++ if (ret) ++ return ret; ++ } ++ + for (i = 0; i < pages; ++i) { + struct mm_iommu_table_group_mem_t *mem = NULL; + unsigned long *pua = IOMMU_TABLE_USERSPACE_ENTRY(tbl, +@@ -584,15 +590,6 @@ static long tce_iommu_create_table(struc + WARN_ON(!ret && !(*ptbl)->it_ops->free); + WARN_ON(!ret && ((*ptbl)->it_allocated_size != table_size)); + +- if (!ret && container->v2) { +- ret = tce_iommu_userspace_view_alloc(*ptbl); +- if (ret) +- (*ptbl)->it_ops->free(*ptbl); +- } +- +- if (ret) +- decrement_locked_vm(table_size >> PAGE_SHIFT); +- + return ret; + } + +@@ -1064,10 +1061,7 @@ static int tce_iommu_take_ownership(stru + if (!tbl || !tbl->it_map) + continue; + +- rc = tce_iommu_userspace_view_alloc(tbl); +- if (!rc) +- rc = iommu_take_ownership(tbl); +- ++ rc = iommu_take_ownership(tbl); + if (rc) { + for (j = 0; j < i; ++j) + iommu_release_ownership( diff --git a/queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch b/queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch new file mode 100644 index 00000000000..a943a255e61 --- /dev/null +++ b/queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch @@ -0,0 +1,129 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:04 +0530 +Subject: x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic +To: stable@vger.kernel.org +Cc: Vitaly Kuznetsov , devel@linuxdriverproject.org, Haiyang Zhang , Thomas Gleixner , Ingo Molnar , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-5-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Vitaly Kuznetsov + +[ Upstream commit 59107e2f48831daedc46973ce4988605ab066de3 ] + +There is a feature in Hyper-V ('Debug-VM --InjectNonMaskableInterrupt') +which injects NMI to the guest. We may want to crash the guest and do kdump +on this NMI by enabling unknown_nmi_panic. To make kdump succeed we need to +allow the kdump kernel to re-establish VMBus connection so it will see +VMBus devices (storage, network,..). + +To properly unload VMBus making it possible to start over during kdump we +need to do the following: + + - Send an 'unload' message to the hypervisor. This can be done on any CPU + so we do this the crashing CPU. + + - Receive the 'unload finished' reply message. WS2012R2 delivers this + message to the CPU which was used to establish VMBus connection during + module load and this CPU may differ from the CPU sending 'unload'. + +Receiving a VMBus message means the following: + + - There is a per-CPU slot in memory for one message. This slot can in + theory be accessed by any CPU. + + - We get an interrupt on the CPU when a message was placed into the slot. + + - When we read the message we need to clear the slot and signal the fact + to the hypervisor. In case there are more messages to this CPU pending + the hypervisor will deliver the next message. The signaling is done by + writing to an MSR so this can only be done on the appropriate CPU. + +To avoid doing cross-CPU work on crash we have vmbus_wait_for_unload() +function which checks message slots for all CPUs in a loop waiting for the +'unload finished' messages. However, there is an issue which arises when +these conditions are met: + + - We're crashing on a CPU which is different from the one which was used + to initially contact the hypervisor. + + - The CPU which was used for the initial contact is blocked with interrupts + disabled and there is a message pending in the message slot. + +In this case we won't be able to read the 'unload finished' message on the +crashing CPU. This is reproducible when we receive unknown NMIs on all CPUs +simultaneously: the first CPU entering panic() will proceed to crash and +all other CPUs will stop themselves with interrupts disabled. + +The suggested solution is to handle unknown NMIs for Hyper-V guests on the +first CPU which gets them only. This will allow us to rely on VMBus +interrupt handler being able to receive the 'unload finish' message in +case it is delivered to a different CPU. + +The issue is not reproducible on WS2016 as Debug-VM delivers NMI to the +boot CPU only, WS2012R2 and earlier Hyper-V versions are affected. + +Signed-off-by: Vitaly Kuznetsov +Acked-by: K. Y. Srinivasan +Cc: devel@linuxdriverproject.org +Cc: Haiyang Zhang +Link: http://lkml.kernel.org/r/20161202100720.28121-1-vkuznets@redhat.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/mshyperv.c | 24 ++++++++++++++++++++++++ + 1 file changed, 24 insertions(+) + +--- a/arch/x86/kernel/cpu/mshyperv.c ++++ b/arch/x86/kernel/cpu/mshyperv.c +@@ -30,6 +30,7 @@ + #include + #include + #include ++#include + + struct ms_hyperv_info ms_hyperv; + EXPORT_SYMBOL_GPL(ms_hyperv); +@@ -157,6 +158,26 @@ static unsigned char hv_get_nmi_reason(v + return 0; + } + ++#ifdef CONFIG_X86_LOCAL_APIC ++/* ++ * Prior to WS2016 Debug-VM sends NMIs to all CPUs which makes ++ * it dificult to process CHANNELMSG_UNLOAD in case of crash. Handle ++ * unknown NMI on the first CPU which gets it. ++ */ ++static int hv_nmi_unknown(unsigned int val, struct pt_regs *regs) ++{ ++ static atomic_t nmi_cpu = ATOMIC_INIT(-1); ++ ++ if (!unknown_nmi_panic) ++ return NMI_DONE; ++ ++ if (atomic_cmpxchg(&nmi_cpu, -1, raw_smp_processor_id()) != -1) ++ return NMI_HANDLED; ++ ++ return NMI_DONE; ++} ++#endif ++ + static void __init ms_hyperv_init_platform(void) + { + /* +@@ -182,6 +203,9 @@ static void __init ms_hyperv_init_platfo + printk(KERN_INFO "HyperV: LAPIC Timer Frequency: %#x\n", + lapic_timer_frequency); + } ++ ++ register_nmi_handler(NMI_UNKNOWN, hv_nmi_unknown, NMI_FLAG_FIRST, ++ "hv_nmi_unknown"); + #endif + + if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE) diff --git a/queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch b/queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch new file mode 100644 index 00000000000..fd767157db2 --- /dev/null +++ b/queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch @@ -0,0 +1,90 @@ +From foo@baz Tue Mar 28 13:59:27 CEST 2017 +From: Sumit Semwal +Date: Sat, 25 Mar 2017 21:48:01 +0530 +Subject: xen: do not re-use pirq number cached in pci device msi msg data +To: stable@vger.kernel.org +Cc: Dan Streetman , Dan Streetman , Boris Ostrovsky , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal +Message-ID: <1490458699-24484-2-git-send-email-sumit.semwal@linaro.org> + +From: Sumit Semwal + + +From: Dan Streetman + +[ Upstream commit c74fd80f2f41d05f350bb478151021f88551afe8 ] + +Revert the main part of commit: +af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests") + +That commit introduced reading the pci device's msi message data to see +if a pirq was previously configured for the device's msi/msix, and re-use +that pirq. At the time, that was the correct behavior. However, a +later change to Qemu caused it to call into the Xen hypervisor to unmap +all pirqs for a pci device, when the pci device disables its MSI/MSIX +vectors; specifically the Qemu commit: +c976437c7dba9c7444fb41df45468968aaa326ad +("qemu-xen: free all the pirqs for msi/msix when driver unload") + +Once Qemu added this pirq unmapping, it was no longer correct for the +kernel to re-use the pirq number cached in the pci device msi message +data. All Qemu releases since 2.1.0 contain the patch that unmaps the +pirqs when the pci device disables its MSI/MSIX vectors. + +This bug is causing failures to initialize multiple NVMe controllers +under Xen, because the NVMe driver sets up a single MSIX vector for +each controller (concurrently), and then after using that to talk to +the controller for some configuration data, it disables the single MSIX +vector and re-configures all the MSIX vectors it needs. So the MSIX +setup code tries to re-use the cached pirq from the first vector +for each controller, but the hypervisor has already given away that +pirq to another controller, and its initialization fails. + +This is discussed in more detail at: +https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html + +Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests") +Signed-off-by: Dan Streetman +Reviewed-by: Stefano Stabellini +Acked-by: Konrad Rzeszutek Wilk +Signed-off-by: Boris Ostrovsky +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sumit Semwal +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/pci/xen.c | 23 +++++++---------------- + 1 file changed, 7 insertions(+), 16 deletions(-) + +--- a/arch/x86/pci/xen.c ++++ b/arch/x86/pci/xen.c +@@ -231,23 +231,14 @@ static int xen_hvm_setup_msi_irqs(struct + return 1; + + for_each_pci_msi_entry(msidesc, dev) { +- __pci_read_msi_msg(msidesc, &msg); +- pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) | +- ((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff); +- if (msg.data != XEN_PIRQ_MSI_DATA || +- xen_irq_from_pirq(pirq) < 0) { +- pirq = xen_allocate_pirq_msi(dev, msidesc); +- if (pirq < 0) { +- irq = -ENODEV; +- goto error; +- } +- xen_msi_compose_msg(dev, pirq, &msg); +- __pci_write_msi_msg(msidesc, &msg); +- dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq); +- } else { +- dev_dbg(&dev->dev, +- "xen: msi already bound to pirq=%d\n", pirq); ++ pirq = xen_allocate_pirq_msi(dev, msidesc); ++ if (pirq < 0) { ++ irq = -ENODEV; ++ goto error; + } ++ xen_msi_compose_msg(dev, pirq, &msg); ++ __pci_write_msi_msg(msidesc, &msg); ++ dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq); + irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq, + (type == PCI_CAP_ID_MSI) ? nvec : 1, + (type == PCI_CAP_ID_MSIX) ? diff --git a/queue-4.4/xfs-clear-_xbf_pages-from-buffers-when-readahead-page.patch b/queue-4.4/xfs-clear-_xbf_pages-from-buffers-when-readahead-page.patch new file mode 100644 index 00000000000..b00cac8b8d6 --- /dev/null +++ b/queue-4.4/xfs-clear-_xbf_pages-from-buffers-when-readahead-page.patch @@ -0,0 +1,46 @@ +From 2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b Mon Sep 17 00:00:00 2001 +From: "Darrick J. Wong" +Date: Wed, 25 Jan 2017 20:24:57 -0800 +Subject: xfs: clear _XBF_PAGES from buffers when readahead page + +From: Darrick J. Wong + +commit 2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b upstream. + +If we try to allocate memory pages to back an xfs_buf that we're trying +to read, it's possible that we'll be so short on memory that the page +allocation fails. For a blocking read we'll just wait, but for +readahead we simply dump all the pages we've collected so far. + +Unfortunately, after dumping the pages we neglect to clear the +_XBF_PAGES state, which means that the subsequent call to xfs_buf_free +thinks that b_pages still points to pages we own. It then double-frees +the b_pages pages. + +This results in screaming about negative page refcounts from the memory +manager, which xfs oughtn't be triggering. To reproduce this case, +mount a filesystem where the size of the inodes far outweighs the +availalble memory (a ~500M inode filesystem on a VM with 300MB memory +did the trick here) and run bulkstat in parallel with other memory +eating processes to put a huge load on the system. The "check summary" +phase of xfs_scrub also works for this purpose. + +Signed-off-by: Darrick J. Wong +Reviewed-by: Eric Sandeen +Cc: Ivan Kozik +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/xfs_buf.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/xfs/xfs_buf.c ++++ b/fs/xfs/xfs_buf.c +@@ -375,6 +375,7 @@ retry: + out_free_pages: + for (i = 0; i < bp->b_page_count; i++) + __free_page(bp->b_pages[i]); ++ bp->b_flags &= ~_XBF_PAGES; + return error; + } +