This is a note to let you know that I've just added the patch titled
tipc: fix link attribute propagation bug
to the 4.4-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:
tipc-fix-link-attribute-propagation-bug.patch
and it can be found in the queue-4.4 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 d01332f1acacc0cb43a61f4244dd2b846d4cd585 Mon Sep 17 00:00:00 2001
From: Richard Alpe <richard.alpe(a)ericsson.com>
Date: Mon, 1 Feb 2016 08:19:56 +0100
Subject: tipc: fix link attribute propagation bug
From: Richard Alpe <richard.alpe(a)ericsson.com>
commit d01332f1acacc0cb43a61f4244dd2b846d4cd585 upstream.
Changing certain link attributes (link tolerance and link priority)
from the TIPC management tool is supposed to automatically take
effect at both endpoints of the affected link.
Currently the media address is not instantiated for the link and is
used uninstantiated when crafting protocol messages designated for the
peer endpoint. This means that changing a link property currently
results in the property being changed on the local machine but the
protocol message designated for the peer gets lost. Resulting in
property discrepancy between the endpoints.
In this patch we resolve this by using the media address from the
link entry and using the bearer transmit function to send it. Hence,
we can now eliminate the redundant function tipc_link_prot_xmit() and
the redundant field tipc_link::media_addr.
Fixes: 2af5ae372a4b (tipc: clean up unused code and structures)
Reviewed-by: Jon Maloy <jon.maloy(a)ericsson.com>
Reported-by: Jason Hu <huzhijiang(a)gmail.com>
Signed-off-by: Richard Alpe <richard.alpe(a)ericsson.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
[backported to 4.4 by Tommi Rantala]
Signed-off-by: Tommi Rantala <tommi.t.rantala(a)nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/tipc/link.c | 28 ++++++----------------------
net/tipc/link.h | 1 -
2 files changed, 6 insertions(+), 23 deletions(-)
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1084,25 +1084,6 @@ drop:
return rc;
}
-/*
- * Send protocol message to the other endpoint.
- */
-void tipc_link_proto_xmit(struct tipc_link *l, u32 msg_typ, int probe_msg,
- u32 gap, u32 tolerance, u32 priority)
-{
- struct sk_buff *skb = NULL;
- struct sk_buff_head xmitq;
-
- __skb_queue_head_init(&xmitq);
- tipc_link_build_proto_msg(l, msg_typ, probe_msg, gap,
- tolerance, priority, &xmitq);
- skb = __skb_dequeue(&xmitq);
- if (!skb)
- return;
- tipc_bearer_xmit_skb(l->net, l->bearer_id, skb, l->media_addr);
- l->rcv_unacked = 0;
-}
-
static void tipc_link_build_proto_msg(struct tipc_link *l, int mtyp, bool probe,
u16 rcvgap, int tolerance, int priority,
struct sk_buff_head *xmitq)
@@ -1636,9 +1617,12 @@ int tipc_nl_link_set(struct sk_buff *skb
char *name;
struct tipc_link *link;
struct tipc_node *node;
+ struct sk_buff_head xmitq;
struct nlattr *attrs[TIPC_NLA_LINK_MAX + 1];
struct net *net = sock_net(skb->sk);
+ __skb_queue_head_init(&xmitq);
+
if (!info->attrs[TIPC_NLA_LINK])
return -EINVAL;
@@ -1683,14 +1667,14 @@ int tipc_nl_link_set(struct sk_buff *skb
tol = nla_get_u32(props[TIPC_NLA_PROP_TOL]);
link->tolerance = tol;
- tipc_link_proto_xmit(link, STATE_MSG, 0, 0, tol, 0);
+ tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, tol, 0, &xmitq);
}
if (props[TIPC_NLA_PROP_PRIO]) {
u32 prio;
prio = nla_get_u32(props[TIPC_NLA_PROP_PRIO]);
link->priority = prio;
- tipc_link_proto_xmit(link, STATE_MSG, 0, 0, 0, prio);
+ tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, 0, prio, &xmitq);
}
if (props[TIPC_NLA_PROP_WIN]) {
u32 win;
@@ -1702,7 +1686,7 @@ int tipc_nl_link_set(struct sk_buff *skb
out:
tipc_node_unlock(node);
-
+ tipc_bearer_xmit(net, bearer_id, &xmitq, &node->links[bearer_id].maddr);
return res;
}
--- a/net/tipc/link.h
+++ b/net/tipc/link.h
@@ -153,7 +153,6 @@ struct tipc_stats {
struct tipc_link {
u32 addr;
char name[TIPC_MAX_LINK_NAME];
- struct tipc_media_addr *media_addr;
struct net *net;
/* Management and link supervision data */
Patches currently in stable-queue which might be from richard.alpe(a)ericsson.com are
queue-4.4/tipc-fix-link-attribute-propagation-bug.patch
This is a note to let you know that I've just added the patch titled
target/iscsi: Fix iSCSI task reassignment handling
to the 4.4-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:
target-iscsi-fix-iscsi-task-reassignment-handling.patch
and it can be found in the queue-4.4 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 59b6986dbfcdab96a971f9663221849de79a7556 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)sandisk.com>
Date: Thu, 5 Jan 2017 12:39:57 +0100
Subject: target/iscsi: Fix iSCSI task reassignment handling
From: Bart Van Assche <bart.vanassche(a)sandisk.com>
commit 59b6986dbfcdab96a971f9663221849de79a7556 upstream.
Allocate a task management request structure for all task management
requests, including task reassignment. This change avoids that the
se_tmr->response assignment dereferences an uninitialized se_tmr
pointer.
Reported-by: Moshe David <mdavid(a)infinidat.com>
Signed-off-by: Bart Van Assche <bart.vanassche(a)sandisk.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Cc: Moshe David <mdavid(a)infinidat.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1759,7 +1759,7 @@ iscsit_handle_task_mgt_cmd(struct iscsi_
struct iscsi_tm *hdr;
int out_of_order_cmdsn = 0, ret;
bool sess_ref = false;
- u8 function;
+ u8 function, tcm_function = TMR_UNKNOWN;
hdr = (struct iscsi_tm *) buf;
hdr->flags &= ~ISCSI_FLAG_CMD_FINAL;
@@ -1805,10 +1805,6 @@ iscsit_handle_task_mgt_cmd(struct iscsi_
* LIO-Target $FABRIC_MOD
*/
if (function != ISCSI_TM_FUNC_TASK_REASSIGN) {
-
- u8 tcm_function;
- int ret;
-
transport_init_se_cmd(&cmd->se_cmd, &iscsi_ops,
conn->sess->se_sess, 0, DMA_NONE,
TCM_SIMPLE_TAG, cmd->sense_buffer + 2);
@@ -1844,15 +1840,14 @@ iscsit_handle_task_mgt_cmd(struct iscsi_
return iscsit_add_reject_cmd(cmd,
ISCSI_REASON_BOOKMARK_NO_RESOURCES, buf);
}
-
- ret = core_tmr_alloc_req(&cmd->se_cmd, cmd->tmr_req,
- tcm_function, GFP_KERNEL);
- if (ret < 0)
- return iscsit_add_reject_cmd(cmd,
+ }
+ ret = core_tmr_alloc_req(&cmd->se_cmd, cmd->tmr_req, tcm_function,
+ GFP_KERNEL);
+ if (ret < 0)
+ return iscsit_add_reject_cmd(cmd,
ISCSI_REASON_BOOKMARK_NO_RESOURCES, buf);
- cmd->tmr_req->se_tmr_req = cmd->se_cmd.se_tmr_req;
- }
+ cmd->tmr_req->se_tmr_req = cmd->se_cmd.se_tmr_req;
cmd->iscsi_opcode = ISCSI_OP_SCSI_TMFUNC;
cmd->i_state = ISTATE_SEND_TASKMGTRSP;
Patches currently in stable-queue which might be from bart.vanassche(a)sandisk.com are
queue-4.4/target-iscsi-fix-iscsi-task-reassignment-handling.patch
This is a note to let you know that I've just added the patch titled
brcmfmac: remove setting IBSS mode when stopping AP
to the 4.4-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:
brcmfmac-remove-setting-ibss-mode-when-stopping-ap.patch
and it can be found in the queue-4.4 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 9029679f66d976f8c720eb03c4898274803c9923 Mon Sep 17 00:00:00 2001
From: Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
Date: Thu, 18 May 2017 17:22:19 +0800
Subject: brcmfmac: remove setting IBSS mode when stopping AP
From: Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
commit 9029679f66d976f8c720eb03c4898274803c9923 upstream.
Upon stopping an AP interface the driver disable INFRA mode effectively
setting the interface in IBSS mode. However, this may affect other
interfaces running in INFRA mode. For instance, if user creates and stops
hostap daemon on virtual interface, then association cannot work on
primary interface because default BSS has been set to IBSS mode in
firmware side. The IBSS mode should be set when cfg80211 changes the
interface.
Reviewed-by: Wright Feng <wright.feng(a)cypress.com>
Signed-off-by: Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
[kvalo(a)codeaurora.org: rephased commit log based on discussion]
Signed-off-by: Wright Feng <wright.feng(a)cypress.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Cc: Philipp Rosenberger <p.rosenberger(a)linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 3 ---
1 file changed, 3 deletions(-)
--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -4295,9 +4295,6 @@ static int brcmf_cfg80211_stop_ap(struct
err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_AP, 0);
if (err < 0)
brcmf_err("setting AP mode failed %d\n", err);
- err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_INFRA, 0);
- if (err < 0)
- brcmf_err("setting INFRA mode failed %d\n", err);
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
brcmf_fil_iovar_int_set(ifp, "mbss", 0);
err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_REGULATORY,
Patches currently in stable-queue which might be from Chi-Hsien.Lin(a)cypress.com are
queue-4.4/brcmfmac-remove-setting-ibss-mode-when-stopping-ap.patch
This is a note to let you know that I've just added the patch titled
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
to the 4.4-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:
security-keys-add-config_keys_compat-to-kconfig.patch
and it can be found in the queue-4.4 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 47b2c3fff4932e6fc17ce13d51a43c6969714e20 Mon Sep 17 00:00:00 2001
From: Bilal Amarni <bilal.amarni(a)gmail.com>
Date: Thu, 8 Jun 2017 14:47:26 +0100
Subject: security/keys: add CONFIG_KEYS_COMPAT to Kconfig
From: Bilal Amarni <bilal.amarni(a)gmail.com>
commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 upstream.
CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for
several 64-bit architectures : mips, parisc, tile.
At the moment and for those architectures, calling in 32-bit userspace the
keyctl syscall would return an ENOSYS error.
This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to
make sure the compatibility wrapper is registered by default for any 64-bit
architecture as long as it is configured with CONFIG_COMPAT.
[DH: Modified to remove arm64 compat enablement also as requested by Eric
Biggers]
Signed-off-by: Bilal Amarni <bilal.amarni(a)gmail.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Cc: James Cowgill <james.cowgill(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/Kconfig | 5 -----
arch/s390/Kconfig | 3 ---
arch/sparc/Kconfig | 3 ---
arch/x86/Kconfig | 4 ----
security/keys/Kconfig | 4 ++++
5 files changed, 4 insertions(+), 15 deletions(-)
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1082,11 +1082,6 @@ source "arch/powerpc/Kconfig.debug"
source "security/Kconfig"
-config KEYS_COMPAT
- bool
- depends on COMPAT && KEYS
- default y
-
source "crypto/Kconfig"
config PPC_LIB_RHEAP
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -346,9 +346,6 @@ config COMPAT
config SYSVIPC_COMPAT
def_bool y if COMPAT && SYSVIPC
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
config SMP
def_bool y
prompt "Symmetric multi-processing support"
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -549,9 +549,6 @@ config SYSVIPC_COMPAT
depends on COMPAT && SYSVIPC
default y
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
endmenu
source "net/Kconfig"
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2641,10 +2641,6 @@ config COMPAT_FOR_U64_ALIGNMENT
config SYSVIPC_COMPAT
def_bool y
depends on SYSVIPC
-
-config KEYS_COMPAT
- def_bool y
- depends on KEYS
endif
endmenu
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -20,6 +20,10 @@ config KEYS
If you are unsure as to whether this is required, answer N.
+config KEYS_COMPAT
+ def_bool y
+ depends on COMPAT && KEYS
+
config PERSISTENT_KEYRINGS
bool "Enable register of persistent per-UID keyrings"
depends on KEYS
Patches currently in stable-queue which might be from bilal.amarni(a)gmail.com are
queue-4.4/security-keys-add-config_keys_compat-to-kconfig.patch
This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: warn user when dma test times out
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:
dmaengine-dmatest-warn-user-when-dma-test-times-out.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 a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 Mon Sep 17 00:00:00 2001
From: Adam Wallis <awallis(a)codeaurora.org>
Date: Thu, 2 Nov 2017 08:53:30 -0400
Subject: dmaengine: dmatest: warn user when dma test times out
From: Adam Wallis <awallis(a)codeaurora.org>
commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 upstream.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks). Ideally, this would be
cleaned up in the thread handler, but at the very least, the kernel
is left in a very precarious scenario that can lead to some long debug
sessions when the crash comes later.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Signed-off-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -702,6 +702,7 @@ static int dmatest_func(void *data)
* free it this time?" dancing. For now, just
* leave it dangling.
*/
+ WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
len, 0);
Patches currently in stable-queue which might be from awallis(a)codeaurora.org are
queue-4.14/dmaengine-dmatest-warn-user-when-dma-test-times-out.patch
This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: warn user when dma test times out
to the 4.13-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:
dmaengine-dmatest-warn-user-when-dma-test-times-out.patch
and it can be found in the queue-4.13 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 a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 Mon Sep 17 00:00:00 2001
From: Adam Wallis <awallis(a)codeaurora.org>
Date: Thu, 2 Nov 2017 08:53:30 -0400
Subject: dmaengine: dmatest: warn user when dma test times out
From: Adam Wallis <awallis(a)codeaurora.org>
commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 upstream.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks). Ideally, this would be
cleaned up in the thread handler, but at the very least, the kernel
is left in a very precarious scenario that can lead to some long debug
sessions when the crash comes later.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Signed-off-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -696,6 +696,7 @@ static int dmatest_func(void *data)
* free it this time?" dancing. For now, just
* leave it dangling.
*/
+ WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
len, 0);
Patches currently in stable-queue which might be from awallis(a)codeaurora.org are
queue-4.13/dmaengine-dmatest-warn-user-when-dma-test-times-out.patch
This is a note to let you know that I've just added the patch titled
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
to the 3.18-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:
security-keys-add-config_keys_compat-to-kconfig.patch
and it can be found in the queue-3.18 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 47b2c3fff4932e6fc17ce13d51a43c6969714e20 Mon Sep 17 00:00:00 2001
From: Bilal Amarni <bilal.amarni(a)gmail.com>
Date: Thu, 8 Jun 2017 14:47:26 +0100
Subject: security/keys: add CONFIG_KEYS_COMPAT to Kconfig
From: Bilal Amarni <bilal.amarni(a)gmail.com>
commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 upstream.
CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for
several 64-bit architectures : mips, parisc, tile.
At the moment and for those architectures, calling in 32-bit userspace the
keyctl syscall would return an ENOSYS error.
This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to
make sure the compatibility wrapper is registered by default for any 64-bit
architecture as long as it is configured with CONFIG_COMPAT.
[DH: Modified to remove arm64 compat enablement also as requested by Eric
Biggers]
Signed-off-by: Bilal Amarni <bilal.amarni(a)gmail.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Cc: James Cowgill <james.cowgill(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/Kconfig | 5 -----
arch/s390/Kconfig | 3 ---
arch/sparc/Kconfig | 3 ---
arch/x86/Kconfig | 4 ----
security/keys/Kconfig | 4 ++++
5 files changed, 4 insertions(+), 15 deletions(-)
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1070,11 +1070,6 @@ source "arch/powerpc/Kconfig.debug"
source "security/Kconfig"
-config KEYS_COMPAT
- bool
- depends on COMPAT && KEYS
- default y
-
source "crypto/Kconfig"
config PPC_LIB_RHEAP
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -332,9 +332,6 @@ config COMPAT
config SYSVIPC_COMPAT
def_bool y if COMPAT && SYSVIPC
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
config SMP
def_bool y
prompt "Symmetric multi-processing support"
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -542,9 +542,6 @@ config SYSVIPC_COMPAT
depends on COMPAT && SYSVIPC
default y
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
endmenu
source "net/Kconfig"
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2471,10 +2471,6 @@ config COMPAT_FOR_U64_ALIGNMENT
config SYSVIPC_COMPAT
def_bool y
depends on SYSVIPC
-
-config KEYS_COMPAT
- def_bool y
- depends on KEYS
endif
endmenu
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -20,6 +20,10 @@ config KEYS
If you are unsure as to whether this is required, answer N.
+config KEYS_COMPAT
+ def_bool y
+ depends on COMPAT && KEYS
+
config PERSISTENT_KEYRINGS
bool "Enable register of persistent per-UID keyrings"
depends on KEYS
Patches currently in stable-queue which might be from bilal.amarni(a)gmail.com are
queue-3.18/security-keys-add-config_keys_compat-to-kconfig.patch
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Greg-KH,
Here are two target patches for v4.4.y stable, the first of which
did not originally include a stable CC, and the latter did not apply
due to a minor context change.
The series has been cut against v4.4.98. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Nicholas Bellinger (1):
target: Fix node_acl demo-mode + uncached dynamic shutdown regression
drivers/target/iscsi/iscsi_target.c | 19 +++++++------------
drivers/target/target_core_tpg.c | 4 ++--
drivers/target/target_core_transport.c | 4 ++--
include/target/target_core_base.h | 1 +
4 files changed, 12 insertions(+), 16 deletions(-)
--
1.8.5.3