This is a note to let you know that I've just added the patch titled
xfs: always free inline data before resetting inode fork during ifree
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: "Darrick J. Wong" <darrick.wong(a)oracle.com>
Date: Wed, 22 Nov 2017 12:21:07 -0800
Subject: xfs: always free inline data before resetting inode fork during ifree
From: "Darrick J. Wong" <darrick.wong(a)oracle.com>
[ Upstream commit 98c4f78dcdd8cec112d1cbc5e9a792ee6e5ab7a6 ]
In xfs_ifree, we reset the data/attr forks to extents format without
bothering to free any inline data buffer that might still be around
after all the blocks have been truncated off the file. Prior to commit
43518812d2 ("xfs: remove support for inlining data/extents into the
inode fork") nobody noticed because the leftover inline data after
truncation was small enough to fit inside the inline buffer inside the
fork itself.
However, now that we've removed the inline buffer, we /always/ have to
free the inline data buffer or else we leak them like crazy. This test
was found by turning on kmemleak for generic/001 or generic/388.
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_inode.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2422,6 +2422,24 @@ retry:
}
/*
+ * Free any local-format buffers sitting around before we reset to
+ * extents format.
+ */
+static inline void
+xfs_ifree_local_data(
+ struct xfs_inode *ip,
+ int whichfork)
+{
+ struct xfs_ifork *ifp;
+
+ if (XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_LOCAL)
+ return;
+
+ ifp = XFS_IFORK_PTR(ip, whichfork);
+ xfs_idata_realloc(ip, -ifp->if_bytes, whichfork);
+}
+
+/*
* This is called to return an inode to the inode free list.
* The inode should already be truncated to 0 length and have
* no pages associated with it. This routine also assumes that
@@ -2458,6 +2476,9 @@ xfs_ifree(
if (error)
return error;
+ xfs_ifree_local_data(ip, XFS_DATA_FORK);
+ xfs_ifree_local_data(ip, XFS_ATTR_FORK);
+
VFS_I(ip)->i_mode = 0; /* mark incore inode as free */
ip->i_d.di_flags = 0;
ip->i_d.di_dmevmask = 0;
Patches currently in stable-queue which might be from darrick.wong(a)oracle.com are
queue-4.14/xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch
queue-4.14/xfs-log-recovery-should-replay-deferred-ops-in-order.patch
queue-4.14/xfs-ubsan-fixes.patch
queue-4.14/xfs-fortify-xfs_alloc_buftarg-error-handling.patch
queue-4.14/xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch
This is a note to let you know that I've just added the patch titled
xen-netfront: remove warning when unloading module
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xen-netfront-remove-warning-when-unloading-module.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Eduardo Otubo <otubo(a)redhat.com>
Date: Thu, 23 Nov 2017 15:18:35 +0100
Subject: xen-netfront: remove warning when unloading module
From: Eduardo Otubo <otubo(a)redhat.com>
[ Upstream commit 5b5971df3bc2775107ddad164018a8a8db633b81 ]
v2:
* Replace busy wait with wait_event()/wake_up_all()
* Cannot garantee that at the time xennet_remove is called, the
xen_netback state will not be XenbusStateClosed, so added a
condition for that
* There's a small chance for the xen_netback state is
XenbusStateUnknown by the time the xen_netfront switches to Closed,
so added a condition for that.
When unloading module xen_netfront from guest, dmesg would output
warning messages like below:
[ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
[ 105.236839] deferring g.e. 0x903 (pfn 0x35805)
This problem relies on netfront and netback being out of sync. By the time
netfront revokes the g.e.'s netback didn't have enough time to free all of
them, hence displaying the warnings on dmesg.
The trick here is to make netfront to wait until netback frees all the g.e.'s
and only then continue to cleanup for the module removal, and this is done by
manipulating both device states.
Signed-off-by: Eduardo Otubo <otubo(a)redhat.com>
Acked-by: Juergen Gross <jgross(a)suse.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netfront.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -87,6 +87,8 @@ struct netfront_cb {
/* IRQ name is queue name with "-tx" or "-rx" appended */
#define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
+static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
+
struct netfront_stats {
u64 packets;
u64 bytes;
@@ -2021,10 +2023,12 @@ static void netback_changed(struct xenbu
break;
case XenbusStateClosed:
+ wake_up_all(&module_unload_q);
if (dev->state == XenbusStateClosed)
break;
/* Missed the backend's CLOSING state -- fallthrough */
case XenbusStateClosing:
+ wake_up_all(&module_unload_q);
xenbus_frontend_closed(dev);
break;
}
@@ -2130,6 +2134,20 @@ static int xennet_remove(struct xenbus_d
dev_dbg(&dev->dev, "%s\n", dev->nodename);
+ if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) {
+ xenbus_switch_state(dev, XenbusStateClosing);
+ wait_event(module_unload_q,
+ xenbus_read_driver_state(dev->otherend) ==
+ XenbusStateClosing);
+
+ xenbus_switch_state(dev, XenbusStateClosed);
+ wait_event(module_unload_q,
+ xenbus_read_driver_state(dev->otherend) ==
+ XenbusStateClosed ||
+ xenbus_read_driver_state(dev->otherend) ==
+ XenbusStateUnknown);
+ }
+
xennet_disconnect_backend(info);
unregister_netdev(info->netdev);
Patches currently in stable-queue which might be from otubo(a)redhat.com are
queue-4.14/xen-netfront-remove-warning-when-unloading-module.patch
This is a note to let you know that I've just added the patch titled
x86/xen: Support early interrupts in xen pv guests
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-xen-support-early-interrupts-in-xen-pv-guests.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Juergen Gross <jgross(a)suse.com>
Date: Fri, 24 Nov 2017 09:42:21 +0100
Subject: x86/xen: Support early interrupts in xen pv guests
From: Juergen Gross <jgross(a)suse.com>
[ Upstream commit 42b3a4cb5609de757f5445fcad18945ba9239a07 ]
Add early interrupt handlers activated by idt_setup_early_handler() to
the handlers supported by Xen pv guests. This will allow for early
WARN() calls not crashing the guest.
Suggested-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Juergen Gross <jgross(a)suse.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: xen-devel(a)lists.xenproject.org
Cc: boris.ostrovsky(a)oracle.com
Link: https://lkml.kernel.org/r/20171124084221.30172-1-jgross@suse.com
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/segment.h | 12 ++++++++++++
arch/x86/mm/extable.c | 4 +++-
arch/x86/xen/enlighten_pv.c | 37 ++++++++++++++++++++++++-------------
arch/x86/xen/xen-asm_64.S | 14 ++++++++++++++
4 files changed, 53 insertions(+), 14 deletions(-)
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -236,11 +236,23 @@
*/
#define EARLY_IDT_HANDLER_SIZE 9
+/*
+ * xen_early_idt_handler_array is for Xen pv guests: for each entry in
+ * early_idt_handler_array it contains a prequel in the form of
+ * pop %rcx; pop %r11; jmp early_idt_handler_array[i]; summing up to
+ * max 8 bytes.
+ */
+#define XEN_EARLY_IDT_HANDLER_SIZE 8
+
#ifndef __ASSEMBLY__
extern const char early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE];
extern void early_ignore_irq(void);
+#if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+extern const char xen_early_idt_handler_array[NUM_EXCEPTION_VECTORS][XEN_EARLY_IDT_HANDLER_SIZE];
+#endif
+
/*
* Load a segment. Fall back on loading the zero segment if something goes
* wrong. This variant assumes that loading zero fully clears the segment.
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -1,6 +1,7 @@
#include <linux/extable.h>
#include <linux/uaccess.h>
#include <linux/sched/debug.h>
+#include <xen/xen.h>
#include <asm/fpu/internal.h>
#include <asm/traps.h>
@@ -212,8 +213,9 @@ void __init early_fixup_exception(struct
* Old CPUs leave the high bits of CS on the stack
* undefined. I'm not sure which CPUs do this, but at least
* the 486 DX works this way.
+ * Xen pv domains are not using the default __KERNEL_CS.
*/
- if (regs->cs != __KERNEL_CS)
+ if (!xen_pv_domain() && regs->cs != __KERNEL_CS)
goto fail;
/*
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -622,7 +622,7 @@ static struct trap_array_entry trap_arra
{ simd_coprocessor_error, xen_simd_coprocessor_error, false },
};
-static bool get_trap_addr(void **addr, unsigned int ist)
+static bool __ref get_trap_addr(void **addr, unsigned int ist)
{
unsigned int nr;
bool ist_okay = false;
@@ -644,6 +644,14 @@ static bool get_trap_addr(void **addr, u
}
}
+ if (nr == ARRAY_SIZE(trap_array) &&
+ *addr >= (void *)early_idt_handler_array[0] &&
+ *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS]) {
+ nr = (*addr - (void *)early_idt_handler_array[0]) /
+ EARLY_IDT_HANDLER_SIZE;
+ *addr = (void *)xen_early_idt_handler_array[nr];
+ }
+
if (WARN_ON(ist != 0 && !ist_okay))
return false;
@@ -1261,6 +1269,21 @@ asmlinkage __visible void __init xen_sta
xen_setup_gdt(0);
xen_init_irq_ops();
+
+ /* Let's presume PV guests always boot on vCPU with id 0. */
+ per_cpu(xen_vcpu_id, 0) = 0;
+
+ /*
+ * Setup xen_vcpu early because idt_setup_early_handler needs it for
+ * local_irq_disable(), irqs_disabled().
+ *
+ * Don't do the full vcpu_info placement stuff until we have
+ * the cpu_possible_mask and a non-dummy shared_info.
+ */
+ xen_vcpu_info_reset(0);
+
+ idt_setup_early_handler();
+
xen_init_capabilities();
#ifdef CONFIG_X86_LOCAL_APIC
@@ -1294,18 +1317,6 @@ asmlinkage __visible void __init xen_sta
*/
acpi_numa = -1;
#endif
- /* Let's presume PV guests always boot on vCPU with id 0. */
- per_cpu(xen_vcpu_id, 0) = 0;
-
- /*
- * Setup xen_vcpu early because start_kernel needs it for
- * local_irq_disable(), irqs_disabled().
- *
- * Don't do the full vcpu_info placement stuff until we have
- * the cpu_possible_mask and a non-dummy shared_info.
- */
- xen_vcpu_info_reset(0);
-
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_pv, xen_cpu_dead_pv));
local_irq_disable();
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -15,6 +15,7 @@
#include <xen/interface/xen.h>
+#include <linux/init.h>
#include <linux/linkage.h>
.macro xen_pv_trap name
@@ -54,6 +55,19 @@ xen_pv_trap entry_INT80_compat
#endif
xen_pv_trap hypervisor_callback
+ __INIT
+ENTRY(xen_early_idt_handler_array)
+ i = 0
+ .rept NUM_EXCEPTION_VECTORS
+ pop %rcx
+ pop %r11
+ jmp early_idt_handler_array + i*EARLY_IDT_HANDLER_SIZE
+ i = i + 1
+ .fill xen_early_idt_handler_array + i*XEN_EARLY_IDT_HANDLER_SIZE - ., 1, 0xcc
+ .endr
+END(xen_early_idt_handler_array)
+ __FINIT
+
hypercall_iret = hypercall_page + __HYPERVISOR_iret * 32
/*
* Xen64 iret frame:
Patches currently in stable-queue which might be from jgross(a)suse.com are
queue-4.14/xen-netfront-remove-warning-when-unloading-module.patch
queue-4.14/x86-xen-support-early-interrupts-in-xen-pv-guests.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: don't dereference g until after it has been null checked
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Colin Ian King <colin.king(a)canonical.com>
Date: Tue, 14 Nov 2017 16:18:28 +0000
Subject: usb: gadget: don't dereference g until after it has been null checked
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit b2fc059fa549fe6881d4c1f8d698b0f50bcd16ec ]
Avoid dereferencing pointer g until after g has been sanity null checked;
move the assignment of cdev much later when it is required into a more
local scope.
Detected by CoverityScan, CID#1222135 ("Dereference before null check")
Fixes: b785ea7ce662 ("usb: gadget: composite: fix ep->maxburst initialization")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/composite.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -150,7 +150,6 @@ int config_ep_by_speed(struct usb_gadget
struct usb_function *f,
struct usb_ep *_ep)
{
- struct usb_composite_dev *cdev = get_gadget_data(g);
struct usb_endpoint_descriptor *chosen_desc = NULL;
struct usb_descriptor_header **speed_desc = NULL;
@@ -229,8 +228,12 @@ ep_found:
_ep->maxburst = comp_desc->bMaxBurst + 1;
break;
default:
- if (comp_desc->bMaxBurst != 0)
+ if (comp_desc->bMaxBurst != 0) {
+ struct usb_composite_dev *cdev;
+
+ cdev = get_gadget_data(g);
ERROR(cdev, "ep0 bMaxBurst must be 0\n");
+ }
_ep->maxburst = 1;
break;
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/i2c-i2c-boardinfo-fix-memory-leaks-on-devinfo.patch
queue-4.14/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch
This is a note to let you know that I've just added the patch titled
uapi: fix linux/kfd_ioctl.h userspace compilation errors
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
uapi-fix-linux-kfd_ioctl.h-userspace-compilation-errors.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: "Dmitry V. Levin" <ldv(a)altlinux.org>
Date: Mon, 13 Nov 2017 03:35:27 +0300
Subject: uapi: fix linux/kfd_ioctl.h userspace compilation errors
From: "Dmitry V. Levin" <ldv(a)altlinux.org>
[ Upstream commit b4d085201d86af69cbda2214c6dafc0be240ef9f ]
Consistently use types provided by <linux/types.h> via <drm/drm.h>
to fix the following linux/kfd_ioctl.h userspace compilation errors:
/usr/include/linux/kfd_ioctl.h:236:2: error: unknown type name 'uint64_t'
uint64_t va_addr; /* to KFD */
/usr/include/linux/kfd_ioctl.h:237:2: error: unknown type name 'uint32_t'
uint32_t gpu_id; /* to KFD */
/usr/include/linux/kfd_ioctl.h:238:2: error: unknown type name 'uint32_t'
uint32_t pad;
/usr/include/linux/kfd_ioctl.h:243:2: error: unknown type name 'uint64_t'
uint64_t tile_config_ptr;
/usr/include/linux/kfd_ioctl.h:245:2: error: unknown type name 'uint64_t'
uint64_t macro_tile_config_ptr;
/usr/include/linux/kfd_ioctl.h:249:2: error: unknown type name 'uint32_t'
uint32_t num_tile_configs;
/usr/include/linux/kfd_ioctl.h:253:2: error: unknown type name 'uint32_t'
uint32_t num_macro_tile_configs;
/usr/include/linux/kfd_ioctl.h:255:2: error: unknown type name 'uint32_t'
uint32_t gpu_id; /* to KFD */
/usr/include/linux/kfd_ioctl.h:256:2: error: unknown type name 'uint32_t'
uint32_t gb_addr_config; /* from KFD */
/usr/include/linux/kfd_ioctl.h:257:2: error: unknown type name 'uint32_t'
uint32_t num_banks; /* from KFD */
/usr/include/linux/kfd_ioctl.h:258:2: error: unknown type name 'uint32_t'
uint32_t num_ranks; /* from KFD */
Fixes: 6a1c9510694fe ("drm/amdkfd: Adding new IOCTL for scratch memory v2")
Fixes: 5d71dbc3a5886 ("drm/amdkfd: Implement image tiling mode support v2")
Signed-off-by: Dmitry V. Levin <ldv(a)altlinux.org>
Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/kfd_ioctl.h | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
--- a/include/uapi/linux/kfd_ioctl.h
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -233,29 +233,29 @@ struct kfd_ioctl_wait_events_args {
};
struct kfd_ioctl_set_scratch_backing_va_args {
- uint64_t va_addr; /* to KFD */
- uint32_t gpu_id; /* to KFD */
- uint32_t pad;
+ __u64 va_addr; /* to KFD */
+ __u32 gpu_id; /* to KFD */
+ __u32 pad;
};
struct kfd_ioctl_get_tile_config_args {
/* to KFD: pointer to tile array */
- uint64_t tile_config_ptr;
+ __u64 tile_config_ptr;
/* to KFD: pointer to macro tile array */
- uint64_t macro_tile_config_ptr;
+ __u64 macro_tile_config_ptr;
/* to KFD: array size allocated by user mode
* from KFD: array size filled by kernel
*/
- uint32_t num_tile_configs;
+ __u32 num_tile_configs;
/* to KFD: array size allocated by user mode
* from KFD: array size filled by kernel
*/
- uint32_t num_macro_tile_configs;
+ __u32 num_macro_tile_configs;
- uint32_t gpu_id; /* to KFD */
- uint32_t gb_addr_config; /* from KFD */
- uint32_t num_banks; /* from KFD */
- uint32_t num_ranks; /* from KFD */
+ __u32 gpu_id; /* to KFD */
+ __u32 gb_addr_config; /* from KFD */
+ __u32 num_banks; /* from KFD */
+ __u32 num_ranks; /* from KFD */
/* struct size can be extended later if needed
* without breaking ABI compatibility
*/
Patches currently in stable-queue which might be from ldv(a)altlinux.org are
queue-4.14/uapi-fix-linux-kfd_ioctl.h-userspace-compilation-errors.patch
This is a note to let you know that I've just added the patch titled
SUNRPC: Allow connect to return EHOSTUNREACH
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sunrpc-allow-connect-to-return-ehostunreach.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Fri, 24 Nov 2017 12:00:24 -0500
Subject: SUNRPC: Allow connect to return EHOSTUNREACH
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit 4ba161a793d5f43757c35feff258d9f20a082940 ]
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Tested-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sunrpc/xprtsock.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -2437,6 +2437,7 @@ static void xs_tcp_setup_socket(struct w
case -ECONNREFUSED:
case -ECONNRESET:
case -ENETUNREACH:
+ case -EHOSTUNREACH:
case -EADDRINUSE:
case -ENOBUFS:
/*
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.14/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch
queue-4.14/sunrpc-allow-connect-to-return-ehostunreach.patch
queue-4.14/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch
This is a note to let you know that I've just added the patch titled
staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Larry Finger <Larry.Finger(a)lwfinger.net>
Date: Sat, 25 Nov 2017 13:32:38 -0600
Subject: staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID
From: Larry Finger <Larry.Finger(a)lwfinger.net>
[ Upstream commit b77992d2df9e47144354d1b25328b180afa33442 ]
When not associated with an AP, wifi device drivers should respond to the
SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the
behavior expected by dhcpcd.
Currently, this driver returns an error code (-1) from the ioctl call,
which causes dhcpcd to assume that the device is not a wireless interface
and therefore it fails to work correctly with it thereafter.
This problem was reported and tested at
https://github.com/lwfinger/rtl8188eu/issues/234.
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -1395,19 +1395,13 @@ static int rtw_wx_get_essid(struct net_d
if ((check_fwstate(pmlmepriv, _FW_LINKED)) ||
(check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))) {
len = pcur_bss->Ssid.SsidLength;
-
- wrqu->essid.length = len;
-
memcpy(extra, pcur_bss->Ssid.Ssid, len);
-
- wrqu->essid.flags = 1;
} else {
- ret = -1;
- goto exit;
+ len = 0;
+ *extra = 0;
}
-
-exit:
-
+ wrqu->essid.length = len;
+ wrqu->essid.flags = 1;
return ret;
}
Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are
queue-4.14/staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch
This is a note to let you know that I've just added the patch titled
sctp: set sender next_tsn for the old result with ctsn_ack_point plus 1
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-set-sender-next_tsn-for-the-old-result-with-ctsn_ack_point-plus-1.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Sat, 25 Nov 2017 21:05:36 +0800
Subject: sctp: set sender next_tsn for the old result with ctsn_ack_point plus 1
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 52a395896a051a3d5c34fba67c324f69ec5e67c6 ]
When doing asoc reset, if the sender of the response has already sent some
chunk and increased asoc->next_tsn before the duplicate request comes, the
response will use the old result with an incorrect sender next_tsn.
Better than asoc->next_tsn, asoc->ctsn_ack_point can't be changed after
the sender of the response has performed the asoc reset and before the
peer has confirmed it, and it's value is still asoc->next_tsn original
value minus 1.
This patch sets sender next_tsn for the old result with ctsn_ack_point
plus 1 when processing the duplicate request, to make sure the sender
next_tsn value peer gets will be always right.
Fixes: 692787cef651 ("sctp: implement receiver-side procedures for the SSN/TSN Reset Request Parameter")
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/stream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -541,7 +541,7 @@ struct sctp_chunk *sctp_process_strreset
i = asoc->strreset_inseq - request_seq - 1;
result = asoc->strreset_result[i];
if (result == SCTP_STRRESET_PERFORMED) {
- next_tsn = asoc->next_tsn;
+ next_tsn = asoc->ctsn_ack_point + 1;
init_tsn =
sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map) + 1;
}
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/sctp-set-sender-next_tsn-for-the-old-result-with-ctsn_ack_point-plus-1.patch
queue-4.14/sctp-only-allow-the-asoc-reset-when-the-asoc-outq-is-empty.patch
queue-4.14/sctp-avoid-flushing-unsent-queue-when-doing-asoc-reset.patch
This is a note to let you know that I've just added the patch titled
sctp: only allow the asoc reset when the asoc outq is empty
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-only-allow-the-asoc-reset-when-the-asoc-outq-is-empty.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Sat, 25 Nov 2017 21:05:34 +0800
Subject: sctp: only allow the asoc reset when the asoc outq is empty
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 5c6144a0eb5366ae07fc5059301b139338f39bbd ]
As it says in rfc6525#section5.1.4, before sending the request,
C2: The sender has either no outstanding TSNs or considers all
outstanding TSNs abandoned.
Prior to this patch, it tried to consider all outstanding TSNs abandoned
by dropping all chunks in all outqs with sctp_outq_free (even including
sacked, retransmit and transmitted queues) when doing this reset, which
is too aggressive.
To make it work gently, this patch will only allow the asoc reset when
the sender has no outstanding TSNs by checking if unsent, transmitted
and retransmit are all empty with sctp_outq_is_empty before sending
and processing the request.
Fixes: 692787cef651 ("sctp: implement receiver-side procedures for the SSN/TSN Reset Request Parameter")
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/stream.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -224,6 +224,9 @@ int sctp_send_reset_assoc(struct sctp_as
if (asoc->strreset_outstanding)
return -EINPROGRESS;
+ if (!sctp_outq_is_empty(&asoc->outqueue))
+ return -EAGAIN;
+
chunk = sctp_make_strreset_tsnreq(asoc);
if (!chunk)
return -ENOMEM;
@@ -544,6 +547,12 @@ struct sctp_chunk *sctp_process_strreset
}
goto err;
}
+
+ if (!sctp_outq_is_empty(&asoc->outqueue)) {
+ result = SCTP_STRRESET_IN_PROGRESS;
+ goto err;
+ }
+
asoc->strreset_inseq++;
if (!(asoc->strreset_enable & SCTP_ENABLE_RESET_ASSOC_REQ))
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/sctp-set-sender-next_tsn-for-the-old-result-with-ctsn_ack_point-plus-1.patch
queue-4.14/sctp-only-allow-the-asoc-reset-when-the-asoc-outq-is-empty.patch
queue-4.14/sctp-avoid-flushing-unsent-queue-when-doing-asoc-reset.patch
This is a note to let you know that I've just added the patch titled
sctp: avoid flushing unsent queue when doing asoc reset
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-avoid-flushing-unsent-queue-when-doing-asoc-reset.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Sat, 25 Nov 2017 21:05:35 +0800
Subject: sctp: avoid flushing unsent queue when doing asoc reset
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 159f2a7456c6ae95c1e1a58e8b8ec65ef12d51cf ]
Now when doing asoc reset, it cleans up sacked and abandoned queues
by calling sctp_outq_free where it also cleans up unsent, retransmit
and transmitted queues.
It's safe for the sender of response, as these 3 queues are empty at
that time. But when the receiver of response is doing the reset, the
users may already enqueue some chunks into unsent during the time
waiting the response, and these chunks should not be flushed.
To void the chunks in it would be removed, it moves the queue into a
temp list, then gets it back after sctp_outq_free is done.
The patch also fixes some incorrect comments in
sctp_process_strreset_tsnreq.
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/stream.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -563,9 +563,10 @@ struct sctp_chunk *sctp_process_strreset
goto out;
}
- /* G3: The same processing as though a SACK chunk with no gap report
- * and a cumulative TSN ACK of the Sender's Next TSN minus 1 were
- * received MUST be performed.
+ /* G4: The same processing as though a FWD-TSN chunk (as defined in
+ * [RFC3758]) with all streams affected and a new cumulative TSN
+ * ACK of the Receiver's Next TSN minus 1 were received MUST be
+ * performed.
*/
max_tsn_seen = sctp_tsnmap_get_max_tsn_seen(&asoc->peer.tsn_map);
sctp_ulpq_reasm_flushtsn(&asoc->ulpq, max_tsn_seen);
@@ -580,10 +581,9 @@ struct sctp_chunk *sctp_process_strreset
sctp_tsnmap_init(&asoc->peer.tsn_map, SCTP_TSN_MAP_INITIAL,
init_tsn, GFP_ATOMIC);
- /* G4: The same processing as though a FWD-TSN chunk (as defined in
- * [RFC3758]) with all streams affected and a new cumulative TSN
- * ACK of the Receiver's Next TSN minus 1 were received MUST be
- * performed.
+ /* G3: The same processing as though a SACK chunk with no gap report
+ * and a cumulative TSN ACK of the Sender's Next TSN minus 1 were
+ * received MUST be performed.
*/
sctp_outq_free(&asoc->outqueue);
@@ -844,6 +844,7 @@ struct sctp_chunk *sctp_process_strreset
if (result == SCTP_STRRESET_PERFORMED) {
__u32 mtsn = sctp_tsnmap_get_max_tsn_seen(
&asoc->peer.tsn_map);
+ LIST_HEAD(temp);
sctp_ulpq_reasm_flushtsn(&asoc->ulpq, mtsn);
sctp_ulpq_abort_pd(&asoc->ulpq, GFP_ATOMIC);
@@ -852,7 +853,13 @@ struct sctp_chunk *sctp_process_strreset
SCTP_TSN_MAP_INITIAL,
stsn, GFP_ATOMIC);
+ /* Clean up sacked and abandoned queues only. As the
+ * out_chunk_list may not be empty, splice it to temp,
+ * then get it back after sctp_outq_free is done.
+ */
+ list_splice_init(&asoc->outqueue.out_chunk_list, &temp);
sctp_outq_free(&asoc->outqueue);
+ list_splice_init(&temp, &asoc->outqueue.out_chunk_list);
asoc->next_tsn = rtsn;
asoc->ctsn_ack_point = asoc->next_tsn - 1;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/sctp-set-sender-next_tsn-for-the-old-result-with-ctsn_ack_point-plus-1.patch
queue-4.14/sctp-only-allow-the-asoc-reset-when-the-asoc-outq-is-empty.patch
queue-4.14/sctp-avoid-flushing-unsent-queue-when-doing-asoc-reset.patch