* Patch "usb: host: xhci-mem: allocate zeroed Scratchpad Buffer" has been added to the 3.18-stable tree
From: gregkh @ 2017-05-23 12:13 UTC (permalink / raw)
To: peter.chen, gregkh, mathias.nyman; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
usb: host: xhci-mem: allocate zeroed Scratchpad Buffer
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=summary
The filename of the patch is:
usb-host-xhci-mem-allocate-zeroed-scratchpad-buffer.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@vger.kernel.org> know about it.
>From 7480d912d549f414e0ce39331870899e89a5598c Mon Sep 17 00:00:00 2001
From: Peter Chen <peter.chen@nxp.com>
Date: Wed, 17 May 2017 18:32:01 +0300
Subject: usb: host: xhci-mem: allocate zeroed Scratchpad Buffer
From: Peter Chen <peter.chen@nxp.com>
commit 7480d912d549f414e0ce39331870899e89a5598c upstream.
According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad
Buffer needs to be zeroed.
...
The following operations take place to allocate
Scratchpad Buffers to the xHC:
...
b. Software clears the Scratchpad Buffer to '0'
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1676,7 +1676,7 @@ static int scratchpad_alloc(struct xhci_
xhci->dcbaa->dev_context_ptrs[0] = cpu_to_le64(xhci->scratchpad->sp_dma);
for (i = 0; i < num_sp; i++) {
dma_addr_t dma;
- void *buf = dma_alloc_coherent(dev, xhci->page_size, &dma,
+ void *buf = dma_zalloc_coherent(dev, xhci->page_size, &dma,
flags);
if (!buf)
goto fail_sp5;
Patches currently in stable-queue which might be from peter.chen@nxp.com are
queue-3.18/usb-host-xhci-mem-allocate-zeroed-scratchpad-buffer.patch
^ permalink raw reply
* Patch "libnvdimm: fix clear length of nvdimm_forget_poison()" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 10:39 UTC (permalink / raw)
To: toshi.kani, dan.j.williams, dave.jiang, gregkh, vishal.l.verma
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
libnvdimm: fix clear length of nvdimm_forget_poison()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
libnvdimm-fix-clear-length-of-nvdimm_forget_poison.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 8d13c0290655b883df9083a2a0af0d782bc38aef Mon Sep 17 00:00:00 2001
From: Toshi Kani <toshi.kani@hpe.com>
Date: Thu, 27 Apr 2017 16:57:05 -0600
Subject: libnvdimm: fix clear length of nvdimm_forget_poison()
From: Toshi Kani <toshi.kani@hpe.com>
commit 8d13c0290655b883df9083a2a0af0d782bc38aef upstream.
ND_CMD_CLEAR_ERROR command returns 'clear_err.cleared', the length
of error actually cleared, which may be smaller than its requested
'len'.
Change nvdimm_clear_poison() to call nvdimm_forget_poison() with
'clear_err.cleared' when this value is valid.
Fixes: e046114af5fc ("libnvdimm: clear the internal poison_list when clearing badblocks")
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvdimm/bus.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -218,7 +218,10 @@ long nvdimm_clear_poison(struct device *
if (cmd_rc < 0)
return cmd_rc;
- nvdimm_clear_from_poison_list(nvdimm_bus, phys, len);
+ if (clear_err.cleared > 0)
+ nvdimm_clear_from_poison_list(nvdimm_bus, phys,
+ clear_err.cleared);
+
return clear_err.cleared;
}
EXPORT_SYMBOL_GPL(nvdimm_clear_poison);
Patches currently in stable-queue which might be from toshi.kani@hpe.com are
queue-4.9/libnvdimm-fix-clear-length-of-nvdimm_forget_poison.patch
^ permalink raw reply
* Patch "sched/fair: Initialize throttle_count for new task-groups lazily" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 10:39 UTC (permalink / raw)
To: khlebnikov, benjamin.pineau, gregkh, mingo, peterz, tglx,
torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
sched/fair: Initialize throttle_count for new task-groups lazily
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=summary
The filename of the patch is:
sched-fair-initialize-throttle_count-for-new-task-groups-lazily.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@vger.kernel.org> know about it.
>From 094f469172e00d6ab0a3130b0e01c83b3cf3a98d Mon Sep 17 00:00:00 2001
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Thu, 16 Jun 2016 15:57:01 +0300
Subject: sched/fair: Initialize throttle_count for new task-groups lazily
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
commit 094f469172e00d6ab0a3130b0e01c83b3cf3a98d upstream.
Cgroup created inside throttled group must inherit current throttle_count.
Broken throttle_count allows to nominate throttled entries as a next buddy,
later this leads to null pointer dereference in pick_next_task_fair().
This patch initialize cfs_rq->throttle_count at first enqueue: laziness
allows to skip locking all rq at group creation. Lazy approach also allows
to skip full sub-tree scan at throttling hierarchy (not in this patch).
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Link: http://lkml.kernel.org/r/146608182119.21870.8439834428248129633.stgit@buzz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ben Pineau <benjamin.pineau@mirakl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/fair.c | 20 ++++++++++++++++++++
kernel/sched/sched.h | 2 +-
2 files changed, 21 insertions(+), 1 deletion(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3918,6 +3918,26 @@ static void check_enqueue_throttle(struc
if (!cfs_bandwidth_used())
return;
+ /* Synchronize hierarchical throttle counter: */
+ if (unlikely(!cfs_rq->throttle_uptodate)) {
+ struct rq *rq = rq_of(cfs_rq);
+ struct cfs_rq *pcfs_rq;
+ struct task_group *tg;
+
+ cfs_rq->throttle_uptodate = 1;
+
+ /* Get closest up-to-date node, because leaves go first: */
+ for (tg = cfs_rq->tg->parent; tg; tg = tg->parent) {
+ pcfs_rq = tg->cfs_rq[cpu_of(rq)];
+ if (pcfs_rq->throttle_uptodate)
+ break;
+ }
+ if (tg) {
+ cfs_rq->throttle_count = pcfs_rq->throttle_count;
+ cfs_rq->throttled_clock_task = rq_clock_task(rq);
+ }
+ }
+
/* an active group must be handled by the update_curr()->put() path */
if (!cfs_rq->runtime_enabled || cfs_rq->curr)
return;
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -417,7 +417,7 @@ struct cfs_rq {
u64 throttled_clock, throttled_clock_task;
u64 throttled_clock_task_time;
- int throttled, throttle_count;
+ int throttled, throttle_count, throttle_uptodate;
struct list_head throttled_list;
#endif /* CONFIG_CFS_BANDWIDTH */
#endif /* CONFIG_FAIR_GROUP_SCHED */
Patches currently in stable-queue which might be from khlebnikov@yandex-team.ru are
queue-4.4/sched-fair-do-not-announce-throttled-next-buddy-in-dequeue_task_fair.patch
queue-4.4/sched-fair-initialize-throttle_count-for-new-task-groups-lazily.patch
^ permalink raw reply
* Patch "sched/fair: Do not announce throttled next buddy in dequeue_task_fair()" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 10:39 UTC (permalink / raw)
To: khlebnikov, benjamin.pineau, bsegall, gregkh, mingo, peterz, tglx,
torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
sched/fair: Do not announce throttled next buddy in dequeue_task_fair()
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=summary
The filename of the patch is:
sched-fair-do-not-announce-throttled-next-buddy-in-dequeue_task_fair.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@vger.kernel.org> know about it.
>From 754bd598be9bbc953bc709a9e8ed7f3188bfb9d7 Mon Sep 17 00:00:00 2001
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Thu, 16 Jun 2016 15:57:15 +0300
Subject: sched/fair: Do not announce throttled next buddy in dequeue_task_fair()
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
commit 754bd598be9bbc953bc709a9e8ed7f3188bfb9d7 upstream.
Hierarchy could be already throttled at this point. Throttled next
buddy could trigger a NULL pointer dereference in pick_next_task_fair().
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/146608183552.21905.15924473394414832071.stgit@buzz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ben Pineau <benjamin.pineau@mirakl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/fair.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4233,15 +4233,14 @@ static void dequeue_task_fair(struct rq
/* Don't dequeue parent if it has other entities besides us */
if (cfs_rq->load.weight) {
+ /* Avoid re-evaluating load for this entity: */
+ se = parent_entity(se);
/*
* Bias pick_next to pick a task from this cfs_rq, as
* p is sleeping when it is within its sched_slice.
*/
- if (task_sleep && parent_entity(se))
- set_next_buddy(parent_entity(se));
-
- /* avoid re-evaluating load for this entity */
- se = parent_entity(se);
+ if (task_sleep && se && !throttled_hierarchy(cfs_rq))
+ set_next_buddy(se);
break;
}
flags |= DEQUEUE_SLEEP;
Patches currently in stable-queue which might be from khlebnikov@yandex-team.ru are
queue-4.4/sched-fair-do-not-announce-throttled-next-buddy-in-dequeue_task_fair.patch
queue-4.4/sched-fair-initialize-throttle_count-for-new-task-groups-lazily.patch
^ permalink raw reply
* Patch "EDAC, amd64: Fix reporting of Chip Select sizes on Fam17h" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 10:33 UTC (permalink / raw)
To: yazen.ghannam, benbennett, bp, gregkh, linux-edac; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
EDAC, amd64: Fix reporting of Chip Select sizes on Fam17h
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
edac-amd64-fix-reporting-of-chip-select-sizes-on-fam17h.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From eb77e6b80f3bed262c7773236f0fb84649fd3091 Mon Sep 17 00:00:00 2001
From: Yazen Ghannam <yazen.ghannam@amd.com>
Date: Thu, 27 Apr 2017 12:11:54 -0500
Subject: EDAC, amd64: Fix reporting of Chip Select sizes on Fam17h
From: Yazen Ghannam <yazen.ghannam@amd.com>
commit eb77e6b80f3bed262c7773236f0fb84649fd3091 upstream.
The wrong index into the csbases/csmasks arrays was being passed to
the function to compute the chip select sizes, which resulted in the
wrong size being computed. Address that so that the correct values are
computed and printed.
Also, redo how we calculate the number of pages in a CS row.
Reported-by: Benjamin Bennett <benbennett@gmail.com>
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/1493313114-11260-1-git-send-email-Yazen.Ghannam@amd.com
[ Remove unneeded integer math comment, minor cleanups. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/edac/amd64_edac.c | 40 +++++++++++++++++++---------------------
1 file changed, 19 insertions(+), 21 deletions(-)
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -782,24 +782,26 @@ static void debug_dump_dramcfg_low(struc
static void debug_display_dimm_sizes_df(struct amd64_pvt *pvt, u8 ctrl)
{
- u32 *dcsb = ctrl ? pvt->csels[1].csbases : pvt->csels[0].csbases;
- int dimm, size0, size1;
+ int dimm, size0, size1, cs0, cs1;
edac_printk(KERN_DEBUG, EDAC_MC, "UMC%d chip selects:\n", ctrl);
for (dimm = 0; dimm < 4; dimm++) {
size0 = 0;
+ cs0 = dimm * 2;
- if (dcsb[dimm*2] & DCSB_CS_ENABLE)
- size0 = pvt->ops->dbam_to_cs(pvt, ctrl, 0, dimm);
+ if (csrow_enabled(cs0, ctrl, pvt))
+ size0 = pvt->ops->dbam_to_cs(pvt, ctrl, 0, cs0);
size1 = 0;
- if (dcsb[dimm*2 + 1] & DCSB_CS_ENABLE)
- size1 = pvt->ops->dbam_to_cs(pvt, ctrl, 0, dimm);
+ cs1 = dimm * 2 + 1;
+
+ if (csrow_enabled(cs1, ctrl, pvt))
+ size1 = pvt->ops->dbam_to_cs(pvt, ctrl, 0, cs1);
amd64_info(EDAC_MC ": %d: %5dMB %d: %5dMB\n",
- dimm * 2, size0,
- dimm * 2 + 1, size1);
+ cs0, size0,
+ cs1, size1);
}
}
@@ -2756,26 +2758,22 @@ skip:
* encompasses
*
*/
-static u32 get_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
+static u32 get_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr_orig)
{
- u32 cs_mode, nr_pages;
u32 dbam = dct ? pvt->dbam1 : pvt->dbam0;
+ int csrow_nr = csrow_nr_orig;
+ u32 cs_mode, nr_pages;
+ if (!pvt->umc)
+ csrow_nr >>= 1;
- /*
- * The math on this doesn't look right on the surface because x/2*4 can
- * be simplified to x*2 but this expression makes use of the fact that
- * it is integral math where 1/2=0. This intermediate value becomes the
- * number of bits to shift the DBAM register to extract the proper CSROW
- * field.
- */
- cs_mode = DBAM_DIMM(csrow_nr / 2, dbam);
+ cs_mode = DBAM_DIMM(csrow_nr, dbam);
- nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode, (csrow_nr / 2))
- << (20 - PAGE_SHIFT);
+ nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode, csrow_nr);
+ nr_pages <<= 20 - PAGE_SHIFT;
edac_dbg(0, "csrow: %d, channel: %d, DBAM idx: %d\n",
- csrow_nr, dct, cs_mode);
+ csrow_nr_orig, dct, cs_mode);
edac_dbg(0, "nr_pages/channel: %u\n", nr_pages);
return nr_pages;
Patches currently in stable-queue which might be from yazen.ghannam@amd.com are
queue-4.11/edac-amd64-fix-reporting-of-chip-select-sizes-on-fam17h.patch
^ permalink raw reply
* Patch "libnvdimm: fix clear length of nvdimm_forget_poison()" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 10:33 UTC (permalink / raw)
To: toshi.kani, dan.j.williams, dave.jiang, gregkh, vishal.l.verma
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
libnvdimm: fix clear length of nvdimm_forget_poison()
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
libnvdimm-fix-clear-length-of-nvdimm_forget_poison.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 8d13c0290655b883df9083a2a0af0d782bc38aef Mon Sep 17 00:00:00 2001
From: Toshi Kani <toshi.kani@hpe.com>
Date: Thu, 27 Apr 2017 16:57:05 -0600
Subject: libnvdimm: fix clear length of nvdimm_forget_poison()
From: Toshi Kani <toshi.kani@hpe.com>
commit 8d13c0290655b883df9083a2a0af0d782bc38aef upstream.
ND_CMD_CLEAR_ERROR command returns 'clear_err.cleared', the length
of error actually cleared, which may be smaller than its requested
'len'.
Change nvdimm_clear_poison() to call nvdimm_forget_poison() with
'clear_err.cleared' when this value is valid.
Fixes: e046114af5fc ("libnvdimm: clear the internal poison_list when clearing badblocks")
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvdimm/bus.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -218,7 +218,10 @@ long nvdimm_clear_poison(struct device *
if (cmd_rc < 0)
return cmd_rc;
- nvdimm_clear_from_poison_list(nvdimm_bus, phys, len);
+ if (clear_err.cleared > 0)
+ nvdimm_clear_from_poison_list(nvdimm_bus, phys,
+ clear_err.cleared);
+
return clear_err.cleared;
}
EXPORT_SYMBOL_GPL(nvdimm_clear_poison);
Patches currently in stable-queue which might be from toshi.kani@hpe.com are
queue-4.11/libnvdimm-fix-clear-length-of-nvdimm_forget_poison.patch
^ permalink raw reply
* Patch "dax: fix data corruption when fault races with write" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 10:33 UTC (permalink / raw)
To: jack, akpm, dan.j.williams, gregkh, ross.zwisler, torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
dax: fix data corruption when fault races with write
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
dax-fix-data-corruption-when-fault-races-with-write.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 13e451fdc1af05568ea379d71c02a126295d2244 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Fri, 12 May 2017 15:46:57 -0700
Subject: dax: fix data corruption when fault races with write
From: Jan Kara <jack@suse.cz>
commit 13e451fdc1af05568ea379d71c02a126295d2244 upstream.
Currently DAX read fault can race with write(2) in the following way:
CPU1 - write(2) CPU2 - read fault
dax_iomap_pte_fault()
->iomap_begin() - sees hole
dax_iomap_rw()
iomap_apply()
->iomap_begin - allocates blocks
dax_iomap_actor()
invalidate_inode_pages2_range()
- there's nothing to invalidate
grab_mapping_entry()
- we add zero page in the radix tree
and map it to page tables
The result is that hole page is mapped into page tables (and thus zeros
are seen in mmap) while file has data written in that place.
Fix the problem by locking exception entry before mapping blocks for the
fault. That way we are sure invalidate_inode_pages2_range() call for
racing write will either block on entry lock waiting for the fault to
finish (and unmap stale page tables after that) or read fault will see
already allocated blocks by write(2).
Fixes: 9f141d6ef6258a3a37a045842d9ba7e68f368956
Link: http://lkml.kernel.org/r/20170510085419.27601-5-jack@suse.cz
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/dax.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1124,23 +1124,23 @@ static int dax_iomap_pte_fault(struct vm
if ((vmf->flags & FAULT_FLAG_WRITE) && !vmf->cow_page)
flags |= IOMAP_WRITE;
+ entry = grab_mapping_entry(mapping, vmf->pgoff, 0);
+ if (IS_ERR(entry))
+ return dax_fault_return(PTR_ERR(entry));
+
/*
* Note that we don't bother to use iomap_apply here: DAX required
* the file system block size to be equal the page size, which means
* that we never have to deal with more than a single extent here.
*/
error = ops->iomap_begin(inode, pos, PAGE_SIZE, flags, &iomap);
- if (error)
- return dax_fault_return(error);
- if (WARN_ON_ONCE(iomap.offset + iomap.length < pos + PAGE_SIZE)) {
- vmf_ret = dax_fault_return(-EIO); /* fs corruption? */
- goto finish_iomap;
+ if (error) {
+ vmf_ret = dax_fault_return(error);
+ goto unlock_entry;
}
-
- entry = grab_mapping_entry(mapping, vmf->pgoff, 0);
- if (IS_ERR(entry)) {
- vmf_ret = dax_fault_return(PTR_ERR(entry));
- goto finish_iomap;
+ if (WARN_ON_ONCE(iomap.offset + iomap.length < pos + PAGE_SIZE)) {
+ error = -EIO; /* fs corruption? */
+ goto error_finish_iomap;
}
sector = dax_iomap_sector(&iomap, pos);
@@ -1162,13 +1162,13 @@ static int dax_iomap_pte_fault(struct vm
}
if (error)
- goto error_unlock_entry;
+ goto error_finish_iomap;
__SetPageUptodate(vmf->cow_page);
vmf_ret = finish_fault(vmf);
if (!vmf_ret)
vmf_ret = VM_FAULT_DONE_COW;
- goto unlock_entry;
+ goto finish_iomap;
}
switch (iomap.type) {
@@ -1188,7 +1188,7 @@ static int dax_iomap_pte_fault(struct vm
case IOMAP_HOLE:
if (!(vmf->flags & FAULT_FLAG_WRITE)) {
vmf_ret = dax_load_hole(mapping, &entry, vmf);
- goto unlock_entry;
+ goto finish_iomap;
}
/*FALLTHRU*/
default:
@@ -1197,10 +1197,8 @@ static int dax_iomap_pte_fault(struct vm
break;
}
- error_unlock_entry:
+ error_finish_iomap:
vmf_ret = dax_fault_return(error) | major;
- unlock_entry:
- put_locked_mapping_entry(mapping, vmf->pgoff, entry);
finish_iomap:
if (ops->iomap_end) {
int copied = PAGE_SIZE;
@@ -1215,6 +1213,8 @@ static int dax_iomap_pte_fault(struct vm
*/
ops->iomap_end(inode, pos, PAGE_SIZE, copied, flags, &iomap);
}
+ unlock_entry:
+ put_locked_mapping_entry(mapping, vmf->pgoff, entry);
return vmf_ret;
}
Patches currently in stable-queue which might be from jack@suse.cz are
queue-4.11/dax-fix-data-corruption-when-fault-races-with-write.patch
queue-4.11/fanotify-don-t-expose-eopenstale-to-userspace.patch
^ permalink raw reply
* Re: Two sched patchs missing from 4.4-stable: inclusion possible?
From: Greg KH @ 2017-05-23 10:27 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ben Pineau, Ingo Molnar, stable, linux-kernel
In-Reply-To: <20170518105103.locuxtyazicdnf4y@hirez.programming.kicks-ass.net>
On Thu, May 18, 2017 at 12:51:03PM +0200, Peter Zijlstra wrote:
> On Thu, May 18, 2017 at 11:35:00AM +0200, Greg KH wrote:
> > On Thu, May 18, 2017 at 11:11:23AM +0200, Ben Pineau wrote:
> > > Hello,
> > >
> > > The following two patches series, merged in mainline 4.7, was Cc'ed to stable@,
> > > but somehow didn't made its way to the 4.4.x stable tree:
> > > 754bd598be9bbc953bc709a9e8ed7f3188bfb9d7
> > > 094f469172e00d6ab0a3130b0e01c83b3cf3a98d
>
> It would be so much easier if that were normal quotes like:
>
> 754bd598be9b ("sched/fair: Do not announce throttled next buddy in dequeue_task_fair()")
> 094f469172e0 ("sched/fair: Initialize throttle_count for new task-groups lazily")
>
> Then I'd not have had to look them up. And I'm most certainly not going
> to click through various interweb sites to provide answers.
>
> > Sure, I'll be glad to take them if I can get an ack from the patch
> > authors, and reviewers (added to: and cc:)...
> >
> > Ingo and Peter, any objections?
>
> No, those patches should be fine I think.
Thanks, now queued up.
greg k-h
^ permalink raw reply
* Re: FAILED: patch "[PATCH] dax: fix PMD data corruption when fault races with write" failed to apply to 4.10-stable tree
From: Greg KH @ 2017-05-23 10:25 UTC (permalink / raw)
To: Ross Zwisler; +Cc: akpm, dan.j.williams, jack, stable, torvalds
In-Reply-To: <20170519195412.GA14926@linux.intel.com>
On Fri, May 19, 2017 at 01:54:12PM -0600, Ross Zwisler wrote:
> On Thu, May 18, 2017 at 09:26:31AM +0200, gregkh@linuxfoundation.org wrote:
> >
> > The patch below does not apply to the 4.10-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> >
> > thanks,
> >
> > greg k-h
>
> The patch below is a backport of:
>
> commit 876f29460cbd ("dax: fix PMD data corruption when fault races with write")
>
> to v4.10.16. This was patch 5 in the series.
>
> This patch still needs a backport of the following ext4 commit (which was
> patch 3 in the series) from Jan to work correctly:
>
> commit fb26a1cbed8c ("ext4: return to starting transaction in ext4_dax_huge_fault()")
Thanks for this, but 4.10 is now end-of-life, so I'm not going to worry
about the ext4 patch :)
greg k-h
^ permalink raw reply
* Re: FAILED: patch "[PATCH] dax: fix data corruption when fault races with write" failed to apply to 4.11-stable tree
From: Greg KH @ 2017-05-23 10:25 UTC (permalink / raw)
To: Ross Zwisler; +Cc: jack, akpm, dan.j.williams, stable, torvalds
In-Reply-To: <20170518231440.GC28029@linux.intel.com>
On Thu, May 18, 2017 at 05:14:40PM -0600, Ross Zwisler wrote:
> On Thu, May 18, 2017 at 09:26:04AM +0200, gregkh@linuxfoundation.org wrote:
> >
> > The patch below does not apply to the 4.11-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> >
> > thanks,
> >
> > greg k-h
>
> The following patch from Jan was sent in v3 of his series before he had merged
> with my tracepoint changes, and applies cleanly to v4.11.1. This is for the
> following upstream commit:
>
> commit 13e451fdc1af ("dax: fix data corruption when fault races with write")
Thanks, now applied.
greg k-h
^ permalink raw reply
* Patch "fscrypt: avoid collisions when presenting long encrypted filenames" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 10:23 UTC (permalink / raw)
To: ebiggers, gregkh, gwendal, tytso; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
fscrypt: avoid collisions when presenting long encrypted filenames
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
fscrypt-avoid-collisions-when-presenting-long-encrypted-filenames.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 6b06cdee81d68a8a829ad8e8d0f31d6836744af9 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers@google.com>
Date: Mon, 24 Apr 2017 10:00:09 -0700
Subject: fscrypt: avoid collisions when presenting long encrypted filenames
From: Eric Biggers <ebiggers@google.com>
commit 6b06cdee81d68a8a829ad8e8d0f31d6836744af9 upstream.
When accessing an encrypted directory without the key, userspace must
operate on filenames derived from the ciphertext names, which contain
arbitrary bytes. Since we must support filenames as long as NAME_MAX,
we can't always just base64-encode the ciphertext, since that may make
it too long. Currently, this is solved by presenting long names in an
abbreviated form containing any needed filesystem-specific hashes (e.g.
to identify a directory block), then the last 16 bytes of ciphertext.
This needs to be sufficient to identify the actual name on lookup.
However, there is a bug. It seems to have been assumed that due to the
use of a CBC (ciphertext block chaining)-based encryption mode, the last
16 bytes (i.e. the AES block size) of ciphertext would depend on the
full plaintext, preventing collisions. However, we actually use CBC
with ciphertext stealing (CTS), which handles the last two blocks
specially, causing them to appear "flipped". Thus, it's actually the
second-to-last block which depends on the full plaintext.
This caused long filenames that differ only near the end of their
plaintexts to, when observed without the key, point to the wrong inode
and be undeletable. For example, with ext4:
# echo pass | e4crypt add_key -p 16 edir/
# seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
# find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
100000
# sync
# echo 3 > /proc/sys/vm/drop_caches
# keyctl new_session
# find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
2004
# rm -rf edir/
rm: cannot remove 'edir/_A7nNFi3rhkEQlJ6P,hdzluhODKOeWx5V': Structure needs cleaning
...
To fix this, when presenting long encrypted filenames, encode the
second-to-last block of ciphertext rather than the last 16 bytes.
Although it would be nice to solve this without depending on a specific
encryption mode, that would mean doing a cryptographic hash like SHA-256
which would be much less efficient. This way is sufficient for now, and
it's still compatible with encryption modes like HEH which are strong
pseudorandom permutations. Also, changing the presented names is still
allowed at any time because they are only provided to allow applications
to do things like delete encrypted directories. They're not designed to
be used to persistently identify files --- which would be hard to do
anyway, given that they're encrypted after all.
For ease of backports, this patch only makes the minimal fix to both
ext4 and f2fs. It leaves ubifs as-is, since ubifs doesn't compare the
ciphertext block yet. Follow-on patches will clean things up properly
and make the filesystems use a shared helper function.
Fixes: 5de0b4d0cd15 ("ext4 crypto: simplify and speed up filename encryption")
Reported-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/crypto/fname.c | 2 +-
fs/ext4/namei.c | 4 ++--
fs/f2fs/dir.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
--- a/fs/crypto/fname.c
+++ b/fs/crypto/fname.c
@@ -300,7 +300,7 @@ int fscrypt_fname_disk_to_usr(struct ino
} else {
memset(buf, 0, 8);
}
- memcpy(buf + 8, iname->name + iname->len - 16, 16);
+ memcpy(buf + 8, iname->name + ((iname->len - 17) & ~15), 16);
oname->name[0] = '_';
oname->len = 1 + digest_encode(buf, 24, oname->name + 1);
return 0;
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1255,9 +1255,9 @@ static inline int ext4_match(struct ext4
if (unlikely(!name)) {
if (fname->usr_fname->name[0] == '_') {
int ret;
- if (de->name_len < 16)
+ if (de->name_len <= 32)
return 0;
- ret = memcmp(de->name + de->name_len - 16,
+ ret = memcmp(de->name + ((de->name_len - 17) & ~15),
fname->crypto_buf.name + 8, 16);
return (ret == 0) ? 1 : 0;
}
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -139,8 +139,8 @@ struct f2fs_dir_entry *find_target_dentr
#ifdef CONFIG_F2FS_FS_ENCRYPTION
if (unlikely(!name->name)) {
if (fname->usr_fname->name[0] == '_') {
- if (de_name.len >= 16 &&
- !memcmp(de_name.name + de_name.len - 16,
+ if (de_name.len > 32 &&
+ !memcmp(de_name.name + ((de_name.len - 17) & ~15),
fname->crypto_buf.name + 8, 16))
goto found;
goto not_match;
Patches currently in stable-queue which might be from ebiggers@google.com are
queue-4.9/fscrypt-avoid-collisions-when-presenting-long-encrypted-filenames.patch
queue-4.9/f2fs-check-entire-encrypted-bigname-when-finding-a-dentry.patch
^ permalink raw reply
* Patch "f2fs: check entire encrypted bigname when finding a dentry" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 10:23 UTC (permalink / raw)
To: jaegeuk, ebiggers, gregkh, stable, tytso; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
f2fs: check entire encrypted bigname when finding a dentry
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
f2fs-check-entire-encrypted-bigname-when-finding-a-dentry.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 6332cd32c8290a80e929fc044dc5bdba77396e33 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk@kernel.org>
Date: Mon, 24 Apr 2017 10:00:08 -0700
Subject: f2fs: check entire encrypted bigname when finding a dentry
From: Jaegeuk Kim <jaegeuk@kernel.org>
commit 6332cd32c8290a80e929fc044dc5bdba77396e33 upstream.
If user has no key under an encrypted dir, fscrypt gives digested dentries.
Previously, when looking up a dentry, f2fs only checks its hash value with
first 4 bytes of the digested dentry, which didn't handle hash collisions fully.
This patch enhances to check entire dentry bytes likewise ext4.
Eric reported how to reproduce this issue by:
# seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
# find edir -type f | xargs stat -c %i | sort | uniq | wc -l
100000
# sync
# echo 3 > /proc/sys/vm/drop_caches
# keyctl new_session
# find edir -type f | xargs stat -c %i | sort | uniq | wc -l
99999
Cc: <stable@vger.kernel.org>
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(fixed f2fs_dentry_hash() to work even when the hash is 0)
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/f2fs/dir.c | 37 +++++++++++++++++++++----------------
fs/f2fs/f2fs.h | 3 ++-
fs/f2fs/hash.c | 7 ++++++-
fs/f2fs/inline.c | 4 ++--
4 files changed, 31 insertions(+), 20 deletions(-)
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -130,19 +130,29 @@ struct f2fs_dir_entry *find_target_dentr
continue;
}
- /* encrypted case */
+ if (de->hash_code != namehash)
+ goto not_match;
+
de_name.name = d->filename[bit_pos];
de_name.len = le16_to_cpu(de->name_len);
- /* show encrypted name */
- if (fname->hash) {
- if (de->hash_code == fname->hash)
- goto found;
- } else if (de_name.len == name->len &&
- de->hash_code == namehash &&
- !memcmp(de_name.name, name->name, name->len))
+#ifdef CONFIG_F2FS_FS_ENCRYPTION
+ if (unlikely(!name->name)) {
+ if (fname->usr_fname->name[0] == '_') {
+ if (de_name.len >= 16 &&
+ !memcmp(de_name.name + de_name.len - 16,
+ fname->crypto_buf.name + 8, 16))
+ goto found;
+ goto not_match;
+ }
+ name->name = fname->crypto_buf.name;
+ name->len = fname->crypto_buf.len;
+ }
+#endif
+ if (de_name.len == name->len &&
+ !memcmp(de_name.name, name->name, name->len))
goto found;
-
+not_match:
if (max_slots && max_len > *max_slots)
*max_slots = max_len;
max_len = 0;
@@ -170,12 +180,7 @@ static struct f2fs_dir_entry *find_in_le
struct f2fs_dir_entry *de = NULL;
bool room = false;
int max_slots;
- f2fs_hash_t namehash;
-
- if(fname->hash)
- namehash = cpu_to_le32(fname->hash);
- else
- namehash = f2fs_dentry_hash(&name);
+ f2fs_hash_t namehash = f2fs_dentry_hash(&name, fname);
nbucket = dir_buckets(level, F2FS_I(dir)->i_dir_level);
nblock = bucket_blocks(level);
@@ -539,7 +544,7 @@ int f2fs_add_regular_entry(struct inode
level = 0;
slots = GET_DENTRY_SLOTS(new_name->len);
- dentry_hash = f2fs_dentry_hash(new_name);
+ dentry_hash = f2fs_dentry_hash(new_name, NULL);
current_depth = F2FS_I(dir)->i_current_depth;
if (F2FS_I(dir)->chash == dentry_hash) {
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2016,7 +2016,8 @@ int sanity_check_ckpt(struct f2fs_sb_inf
/*
* hash.c
*/
-f2fs_hash_t f2fs_dentry_hash(const struct qstr *);
+f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
+ struct fscrypt_name *fname);
/*
* node.c
--- a/fs/f2fs/hash.c
+++ b/fs/f2fs/hash.c
@@ -70,7 +70,8 @@ static void str2hashbuf(const unsigned c
*buf++ = pad;
}
-f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info)
+f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
+ struct fscrypt_name *fname)
{
__u32 hash;
f2fs_hash_t f2fs_hash;
@@ -79,6 +80,10 @@ f2fs_hash_t f2fs_dentry_hash(const struc
const unsigned char *name = name_info->name;
size_t len = name_info->len;
+ /* encrypted bigname case */
+ if (fname && !fname->disk_name.name)
+ return cpu_to_le32(fname->hash);
+
if (is_dot_dotdot(name_info))
return 0;
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -294,7 +294,7 @@ struct f2fs_dir_entry *find_in_inline_di
return NULL;
}
- namehash = f2fs_dentry_hash(&name);
+ namehash = f2fs_dentry_hash(&name, fname);
inline_dentry = inline_data_addr(ipage);
@@ -531,7 +531,7 @@ int f2fs_add_inline_entry(struct inode *
f2fs_wait_on_page_writeback(ipage, NODE, true);
- name_hash = f2fs_dentry_hash(new_name);
+ name_hash = f2fs_dentry_hash(new_name, NULL);
make_dentry_ptr(NULL, &d, (void *)dentry_blk, 2);
f2fs_update_dentry(ino, mode, &d, new_name, name_hash, bit_pos);
Patches currently in stable-queue which might be from jaegeuk@kernel.org are
queue-4.9/f2fs-check-entire-encrypted-bigname-when-finding-a-dentry.patch
^ permalink raw reply
* Patch "net: qmi_wwan: Add SIMCom 7230E" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 10:22 UTC (permalink / raw)
To: kristian.evensen, bjorn, davem, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
net: qmi_wwan: Add SIMCom 7230E
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=summary
The filename of the patch is:
net-qmi_wwan-add-simcom-7230e.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@vger.kernel.org> know about it.
>From 18715b261541f35ccede9b8686ee3ebaac697d38 Mon Sep 17 00:00:00 2001
From: Kristian Evensen <kristian.evensen@gmail.com>
Date: Thu, 7 Jan 2016 16:41:33 +0100
Subject: net: qmi_wwan: Add SIMCom 7230E
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Kristian Evensen <kristian.evensen@gmail.com>
commit 18715b261541f35ccede9b8686ee3ebaac697d38 upstream.
SIMCom 7230E is a QMI LTE module with support for most "normal" bands.
Manual testing has showed that only interface five works.
Cc: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -754,6 +754,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x413c, 0x81b1, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)}, /* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)}, /* WeTelecom WPD-600N */
+ {QMI_FIXED_INTF(0x1e0e, 0x9001, 5)}, /* SIMCom 7230E */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
Patches currently in stable-queue which might be from kristian.evensen@gmail.com are
queue-4.4/net-qmi_wwan-add-simcom-7230e.patch
^ permalink raw reply
* Patch "fscrypt: fix context consistency check when key(s) unavailable" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 10:22 UTC (permalink / raw)
To: ebiggers, gregkh, tytso; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
fscrypt: fix context consistency check when key(s) unavailable
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=summary
The filename of the patch is:
fscrypt-fix-context-consistency-check-when-key-s-unavailable.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@vger.kernel.org> know about it.
>From 272f98f6846277378e1758a49a49d7bf39343c02 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers@google.com>
Date: Fri, 7 Apr 2017 10:58:37 -0700
Subject: fscrypt: fix context consistency check when key(s) unavailable
From: Eric Biggers <ebiggers@google.com>
commit 272f98f6846277378e1758a49a49d7bf39343c02 upstream.
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/crypto_policy.c | 66 ++++++++++++++++++++++++++++++++++--------------
fs/f2fs/crypto_policy.c | 65 ++++++++++++++++++++++++++++++++++-------------
2 files changed, 96 insertions(+), 35 deletions(-)
--- a/fs/ext4/crypto_policy.c
+++ b/fs/ext4/crypto_policy.c
@@ -148,26 +148,38 @@ int ext4_get_policy(struct inode *inode,
int ext4_is_child_context_consistent_with_parent(struct inode *parent,
struct inode *child)
{
- struct ext4_crypt_info *parent_ci, *child_ci;
+ const struct ext4_crypt_info *parent_ci, *child_ci;
+ struct ext4_encryption_context parent_ctx, child_ctx;
int res;
- if ((parent == NULL) || (child == NULL)) {
- pr_err("parent %p child %p\n", parent, child);
- WARN_ON(1); /* Should never happen */
- return 0;
- }
-
/* No restrictions on file types which are never encrypted */
if (!S_ISREG(child->i_mode) && !S_ISDIR(child->i_mode) &&
!S_ISLNK(child->i_mode))
return 1;
- /* no restrictions if the parent directory is not encrypted */
+ /* No restrictions if the parent directory is unencrypted */
if (!ext4_encrypted_inode(parent))
return 1;
- /* if the child directory is not encrypted, this is always a problem */
+
+ /* Encrypted directories must not contain unencrypted files */
if (!ext4_encrypted_inode(child))
return 0;
+
+ /*
+ * Both parent and child are encrypted, so verify they use the same
+ * encryption policy. Compare the fscrypt_info structs if the keys are
+ * available, otherwise retrieve and compare the fscrypt_contexts.
+ *
+ * Note that the fscrypt_context retrieval will be required frequently
+ * when accessing an encrypted directory tree without the key.
+ * Performance-wise this is not a big deal because we already don't
+ * really optimize for file access without the key (to the extent that
+ * such access is even possible), given that any attempted access
+ * already causes a fscrypt_context retrieval and keyring search.
+ *
+ * In any case, if an unexpected error occurs, fall back to "forbidden".
+ */
+
res = ext4_get_encryption_info(parent);
if (res)
return 0;
@@ -176,17 +188,35 @@ int ext4_is_child_context_consistent_wit
return 0;
parent_ci = EXT4_I(parent)->i_crypt_info;
child_ci = EXT4_I(child)->i_crypt_info;
- if (!parent_ci && !child_ci)
- return 1;
- if (!parent_ci || !child_ci)
+ if (parent_ci && child_ci) {
+ return memcmp(parent_ci->ci_master_key, child_ci->ci_master_key,
+ EXT4_KEY_DESCRIPTOR_SIZE) == 0 &&
+ (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
+ (parent_ci->ci_filename_mode ==
+ child_ci->ci_filename_mode) &&
+ (parent_ci->ci_flags == child_ci->ci_flags);
+ }
+
+ res = ext4_xattr_get(parent, EXT4_XATTR_INDEX_ENCRYPTION,
+ EXT4_XATTR_NAME_ENCRYPTION_CONTEXT,
+ &parent_ctx, sizeof(parent_ctx));
+ if (res != sizeof(parent_ctx))
+ return 0;
+
+ res = ext4_xattr_get(child, EXT4_XATTR_INDEX_ENCRYPTION,
+ EXT4_XATTR_NAME_ENCRYPTION_CONTEXT,
+ &child_ctx, sizeof(child_ctx));
+ if (res != sizeof(child_ctx))
return 0;
- return (memcmp(parent_ci->ci_master_key,
- child_ci->ci_master_key,
- EXT4_KEY_DESCRIPTOR_SIZE) == 0 &&
- (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
- (parent_ci->ci_filename_mode == child_ci->ci_filename_mode) &&
- (parent_ci->ci_flags == child_ci->ci_flags));
+ return memcmp(parent_ctx.master_key_descriptor,
+ child_ctx.master_key_descriptor,
+ EXT4_KEY_DESCRIPTOR_SIZE) == 0 &&
+ (parent_ctx.contents_encryption_mode ==
+ child_ctx.contents_encryption_mode) &&
+ (parent_ctx.filenames_encryption_mode ==
+ child_ctx.filenames_encryption_mode) &&
+ (parent_ctx.flags == child_ctx.flags);
}
/**
--- a/fs/f2fs/crypto_policy.c
+++ b/fs/f2fs/crypto_policy.c
@@ -141,25 +141,38 @@ int f2fs_get_policy(struct inode *inode,
int f2fs_is_child_context_consistent_with_parent(struct inode *parent,
struct inode *child)
{
- struct f2fs_crypt_info *parent_ci, *child_ci;
+ const struct f2fs_crypt_info *parent_ci, *child_ci;
+ struct f2fs_encryption_context parent_ctx, child_ctx;
int res;
- if ((parent == NULL) || (child == NULL)) {
- pr_err("parent %p child %p\n", parent, child);
- BUG_ON(1);
- }
-
/* No restrictions on file types which are never encrypted */
if (!S_ISREG(child->i_mode) && !S_ISDIR(child->i_mode) &&
!S_ISLNK(child->i_mode))
return 1;
- /* no restrictions if the parent directory is not encrypted */
+ /* No restrictions if the parent directory is unencrypted */
if (!f2fs_encrypted_inode(parent))
return 1;
- /* if the child directory is not encrypted, this is always a problem */
+
+ /* Encrypted directories must not contain unencrypted files */
if (!f2fs_encrypted_inode(child))
return 0;
+
+ /*
+ * Both parent and child are encrypted, so verify they use the same
+ * encryption policy. Compare the fscrypt_info structs if the keys are
+ * available, otherwise retrieve and compare the fscrypt_contexts.
+ *
+ * Note that the fscrypt_context retrieval will be required frequently
+ * when accessing an encrypted directory tree without the key.
+ * Performance-wise this is not a big deal because we already don't
+ * really optimize for file access without the key (to the extent that
+ * such access is even possible), given that any attempted access
+ * already causes a fscrypt_context retrieval and keyring search.
+ *
+ * In any case, if an unexpected error occurs, fall back to "forbidden".
+ */
+
res = f2fs_get_encryption_info(parent);
if (res)
return 0;
@@ -168,17 +181,35 @@ int f2fs_is_child_context_consistent_wit
return 0;
parent_ci = F2FS_I(parent)->i_crypt_info;
child_ci = F2FS_I(child)->i_crypt_info;
- if (!parent_ci && !child_ci)
- return 1;
- if (!parent_ci || !child_ci)
+ if (parent_ci && child_ci) {
+ return memcmp(parent_ci->ci_master_key, child_ci->ci_master_key,
+ F2FS_KEY_DESCRIPTOR_SIZE) == 0 &&
+ (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
+ (parent_ci->ci_filename_mode ==
+ child_ci->ci_filename_mode) &&
+ (parent_ci->ci_flags == child_ci->ci_flags);
+ }
+
+ res = f2fs_getxattr(parent, F2FS_XATTR_INDEX_ENCRYPTION,
+ F2FS_XATTR_NAME_ENCRYPTION_CONTEXT,
+ &parent_ctx, sizeof(parent_ctx), NULL);
+ if (res != sizeof(parent_ctx))
+ return 0;
+
+ res = f2fs_getxattr(child, F2FS_XATTR_INDEX_ENCRYPTION,
+ F2FS_XATTR_NAME_ENCRYPTION_CONTEXT,
+ &child_ctx, sizeof(child_ctx), NULL);
+ if (res != sizeof(child_ctx))
return 0;
- return (memcmp(parent_ci->ci_master_key,
- child_ci->ci_master_key,
- F2FS_KEY_DESCRIPTOR_SIZE) == 0 &&
- (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
- (parent_ci->ci_filename_mode == child_ci->ci_filename_mode) &&
- (parent_ci->ci_flags == child_ci->ci_flags));
+ return memcmp(parent_ctx.master_key_descriptor,
+ child_ctx.master_key_descriptor,
+ F2FS_KEY_DESCRIPTOR_SIZE) == 0 &&
+ (parent_ctx.contents_encryption_mode ==
+ child_ctx.contents_encryption_mode) &&
+ (parent_ctx.filenames_encryption_mode ==
+ child_ctx.filenames_encryption_mode) &&
+ (parent_ctx.flags == child_ctx.flags);
}
/**
Patches currently in stable-queue which might be from ebiggers@google.com are
queue-4.4/fscrypt-avoid-collisions-when-presenting-long-encrypted-filenames.patch
queue-4.4/fscrypt-fix-context-consistency-check-when-key-s-unavailable.patch
queue-4.4/ext4-crypto-fix-some-error-handling.patch
queue-4.4/ext4-crypto-don-t-let-data-integrity-writebacks-fail-with-enomem.patch
queue-4.4/f2fs-check-entire-encrypted-bigname-when-finding-a-dentry.patch
^ permalink raw reply
* Patch "fscrypt: avoid collisions when presenting long encrypted filenames" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 10:22 UTC (permalink / raw)
To: ebiggers, gregkh, gwendal, tytso; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
fscrypt: avoid collisions when presenting long encrypted filenames
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=summary
The filename of the patch is:
fscrypt-avoid-collisions-when-presenting-long-encrypted-filenames.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@vger.kernel.org> know about it.
>From 6b06cdee81d68a8a829ad8e8d0f31d6836744af9 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers@google.com>
Date: Mon, 24 Apr 2017 10:00:09 -0700
Subject: fscrypt: avoid collisions when presenting long encrypted filenames
From: Eric Biggers <ebiggers@google.com>
commit 6b06cdee81d68a8a829ad8e8d0f31d6836744af9 upstream.
When accessing an encrypted directory without the key, userspace must
operate on filenames derived from the ciphertext names, which contain
arbitrary bytes. Since we must support filenames as long as NAME_MAX,
we can't always just base64-encode the ciphertext, since that may make
it too long. Currently, this is solved by presenting long names in an
abbreviated form containing any needed filesystem-specific hashes (e.g.
to identify a directory block), then the last 16 bytes of ciphertext.
This needs to be sufficient to identify the actual name on lookup.
However, there is a bug. It seems to have been assumed that due to the
use of a CBC (ciphertext block chaining)-based encryption mode, the last
16 bytes (i.e. the AES block size) of ciphertext would depend on the
full plaintext, preventing collisions. However, we actually use CBC
with ciphertext stealing (CTS), which handles the last two blocks
specially, causing them to appear "flipped". Thus, it's actually the
second-to-last block which depends on the full plaintext.
This caused long filenames that differ only near the end of their
plaintexts to, when observed without the key, point to the wrong inode
and be undeletable. For example, with ext4:
# echo pass | e4crypt add_key -p 16 edir/
# seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
# find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
100000
# sync
# echo 3 > /proc/sys/vm/drop_caches
# keyctl new_session
# find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
2004
# rm -rf edir/
rm: cannot remove 'edir/_A7nNFi3rhkEQlJ6P,hdzluhODKOeWx5V': Structure needs cleaning
...
To fix this, when presenting long encrypted filenames, encode the
second-to-last block of ciphertext rather than the last 16 bytes.
Although it would be nice to solve this without depending on a specific
encryption mode, that would mean doing a cryptographic hash like SHA-256
which would be much less efficient. This way is sufficient for now, and
it's still compatible with encryption modes like HEH which are strong
pseudorandom permutations. Also, changing the presented names is still
allowed at any time because they are only provided to allow applications
to do things like delete encrypted directories. They're not designed to
be used to persistently identify files --- which would be hard to do
anyway, given that they're encrypted after all.
For ease of backports, this patch only makes the minimal fix to both
ext4 and f2fs. It leaves ubifs as-is, since ubifs doesn't compare the
ciphertext block yet. Follow-on patches will clean things up properly
and make the filesystems use a shared helper function.
Fixes: 5de0b4d0cd15 ("ext4 crypto: simplify and speed up filename encryption")
Reported-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/crypto_fname.c | 2 +-
fs/ext4/namei.c | 4 ++--
fs/f2fs/crypto_fname.c | 2 +-
fs/f2fs/dir.c | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
--- a/fs/ext4/crypto_fname.c
+++ b/fs/ext4/crypto_fname.c
@@ -343,7 +343,7 @@ int _ext4_fname_disk_to_usr(struct inode
memcpy(buf+4, &hinfo->minor_hash, 4);
} else
memset(buf, 0, 8);
- memcpy(buf + 8, iname->name + iname->len - 16, 16);
+ memcpy(buf + 8, iname->name + ((iname->len - 17) & ~15), 16);
oname->name[0] = '_';
ret = digest_encode(buf, 24, oname->name+1);
oname->len = ret + 1;
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1243,9 +1243,9 @@ static inline int ext4_match(struct ext4
if (unlikely(!name)) {
if (fname->usr_fname->name[0] == '_') {
int ret;
- if (de->name_len < 16)
+ if (de->name_len <= 32)
return 0;
- ret = memcmp(de->name + de->name_len - 16,
+ ret = memcmp(de->name + ((de->name_len - 17) & ~15),
fname->crypto_buf.name + 8, 16);
return (ret == 0) ? 1 : 0;
}
--- a/fs/f2fs/crypto_fname.c
+++ b/fs/f2fs/crypto_fname.c
@@ -333,7 +333,7 @@ int f2fs_fname_disk_to_usr(struct inode
memset(buf + 4, 0, 4);
} else
memset(buf, 0, 8);
- memcpy(buf + 8, iname->name + iname->len - 16, 16);
+ memcpy(buf + 8, iname->name + ((iname->len - 17) & ~15), 16);
oname->name[0] = '_';
ret = digest_encode(buf, 24, oname->name + 1);
oname->len = ret + 1;
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -133,8 +133,8 @@ struct f2fs_dir_entry *find_target_dentr
#ifdef CONFIG_F2FS_FS_ENCRYPTION
if (unlikely(!name->name)) {
if (fname->usr_fname->name[0] == '_') {
- if (de_name.len >= 16 &&
- !memcmp(de_name.name + de_name.len - 16,
+ if (de_name.len > 32 &&
+ !memcmp(de_name.name + ((de_name.len - 17) & ~15),
fname->crypto_buf.name + 8, 16))
goto found;
goto not_match;
Patches currently in stable-queue which might be from ebiggers@google.com are
queue-4.4/fscrypt-avoid-collisions-when-presenting-long-encrypted-filenames.patch
queue-4.4/fscrypt-fix-context-consistency-check-when-key-s-unavailable.patch
queue-4.4/ext4-crypto-fix-some-error-handling.patch
queue-4.4/ext4-crypto-don-t-let-data-integrity-writebacks-fail-with-enomem.patch
queue-4.4/f2fs-check-entire-encrypted-bigname-when-finding-a-dentry.patch
^ permalink raw reply
* Patch "f2fs: check entire encrypted bigname when finding a dentry" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 10:22 UTC (permalink / raw)
To: jaegeuk, ebiggers, gregkh, stable, tytso; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
f2fs: check entire encrypted bigname when finding a dentry
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=summary
The filename of the patch is:
f2fs-check-entire-encrypted-bigname-when-finding-a-dentry.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@vger.kernel.org> know about it.
>From 6332cd32c8290a80e929fc044dc5bdba77396e33 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk@kernel.org>
Date: Mon, 24 Apr 2017 10:00:08 -0700
Subject: f2fs: check entire encrypted bigname when finding a dentry
From: Jaegeuk Kim <jaegeuk@kernel.org>
commit 6332cd32c8290a80e929fc044dc5bdba77396e33 upstream.
If user has no key under an encrypted dir, fscrypt gives digested dentries.
Previously, when looking up a dentry, f2fs only checks its hash value with
first 4 bytes of the digested dentry, which didn't handle hash collisions fully.
This patch enhances to check entire dentry bytes likewise ext4.
Eric reported how to reproduce this issue by:
# seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
# find edir -type f | xargs stat -c %i | sort | uniq | wc -l
100000
# sync
# echo 3 > /proc/sys/vm/drop_caches
# keyctl new_session
# find edir -type f | xargs stat -c %i | sort | uniq | wc -l
99999
Cc: <stable@vger.kernel.org>
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(fixed f2fs_dentry_hash() to work even when the hash is 0)
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/f2fs/dir.c | 32 +++++++++++++++++++++-----------
fs/f2fs/f2fs.h | 3 ++-
fs/f2fs/hash.c | 7 ++++++-
fs/f2fs/inline.c | 4 ++--
4 files changed, 31 insertions(+), 15 deletions(-)
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -124,19 +124,29 @@ struct f2fs_dir_entry *find_target_dentr
de = &d->dentry[bit_pos];
- /* encrypted case */
+ if (de->hash_code != namehash)
+ goto not_match;
+
de_name.name = d->filename[bit_pos];
de_name.len = le16_to_cpu(de->name_len);
- /* show encrypted name */
- if (fname->hash) {
- if (de->hash_code == fname->hash)
- goto found;
- } else if (de_name.len == name->len &&
- de->hash_code == namehash &&
- !memcmp(de_name.name, name->name, name->len))
+#ifdef CONFIG_F2FS_FS_ENCRYPTION
+ if (unlikely(!name->name)) {
+ if (fname->usr_fname->name[0] == '_') {
+ if (de_name.len >= 16 &&
+ !memcmp(de_name.name + de_name.len - 16,
+ fname->crypto_buf.name + 8, 16))
+ goto found;
+ goto not_match;
+ }
+ name->name = fname->crypto_buf.name;
+ name->len = fname->crypto_buf.len;
+ }
+#endif
+ if (de_name.len == name->len &&
+ !memcmp(de_name.name, name->name, name->len))
goto found;
-
+not_match:
if (max_slots && max_len > *max_slots)
*max_slots = max_len;
max_len = 0;
@@ -170,7 +180,7 @@ static struct f2fs_dir_entry *find_in_le
int max_slots;
f2fs_hash_t namehash;
- namehash = f2fs_dentry_hash(&name);
+ namehash = f2fs_dentry_hash(&name, fname);
f2fs_bug_on(F2FS_I_SB(dir), level > MAX_DIR_HASH_DEPTH);
@@ -547,7 +557,7 @@ int __f2fs_add_link(struct inode *dir, c
level = 0;
slots = GET_DENTRY_SLOTS(new_name.len);
- dentry_hash = f2fs_dentry_hash(&new_name);
+ dentry_hash = f2fs_dentry_hash(&new_name, NULL);
current_depth = F2FS_I(dir)->i_current_depth;
if (F2FS_I(dir)->chash == dentry_hash) {
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1722,7 +1722,8 @@ void f2fs_msg(struct super_block *, cons
/*
* hash.c
*/
-f2fs_hash_t f2fs_dentry_hash(const struct qstr *);
+f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
+ struct f2fs_filename *fname);
/*
* node.c
--- a/fs/f2fs/hash.c
+++ b/fs/f2fs/hash.c
@@ -70,7 +70,8 @@ static void str2hashbuf(const unsigned c
*buf++ = pad;
}
-f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info)
+f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
+ struct f2fs_filename *fname)
{
__u32 hash;
f2fs_hash_t f2fs_hash;
@@ -79,6 +80,10 @@ f2fs_hash_t f2fs_dentry_hash(const struc
const unsigned char *name = name_info->name;
size_t len = name_info->len;
+ /* encrypted bigname case */
+ if (fname && !fname->disk_name.name)
+ return cpu_to_le32(fname->hash);
+
if (is_dot_dotdot(name_info))
return 0;
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -303,7 +303,7 @@ struct f2fs_dir_entry *find_in_inline_di
if (IS_ERR(ipage))
return NULL;
- namehash = f2fs_dentry_hash(&name);
+ namehash = f2fs_dentry_hash(&name, fname);
inline_dentry = inline_data_addr(ipage);
@@ -468,7 +468,7 @@ int f2fs_add_inline_entry(struct inode *
f2fs_wait_on_page_writeback(ipage, NODE);
- name_hash = f2fs_dentry_hash(name);
+ name_hash = f2fs_dentry_hash(name, NULL);
make_dentry_ptr(NULL, &d, (void *)dentry_blk, 2);
f2fs_update_dentry(ino, mode, &d, name, name_hash, bit_pos);
Patches currently in stable-queue which might be from jaegeuk@kernel.org are
queue-4.4/f2fs-check-entire-encrypted-bigname-when-finding-a-dentry.patch
^ permalink raw reply
* Patch "ext4 crypto: fix some error handling" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 10:22 UTC (permalink / raw)
To: dan.carpenter, ebiggers, gregkh, tytso; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ext4 crypto: fix some error 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=summary
The filename of the patch is:
ext4-crypto-fix-some-error-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@vger.kernel.org> know about it.
>From 4762cc3fbbd89e5fd316d6e4d3244a8984444f8d Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Sat, 2 Apr 2016 18:13:38 -0400
Subject: ext4 crypto: fix some error handling
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 4762cc3fbbd89e5fd316d6e4d3244a8984444f8d upstream.
We should be testing for -ENOMEM but the minus sign is missing.
Fixes: c9af28fdd449 ('ext4 crypto: don't let data integrity writebacks fail with ENOMEM')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/page-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -492,7 +492,7 @@ int ext4_bio_write_page(struct ext4_io_s
data_page = ext4_encrypt(inode, page, gfp_flags);
if (IS_ERR(data_page)) {
ret = PTR_ERR(data_page);
- if (ret == ENOMEM && wbc->sync_mode == WB_SYNC_ALL) {
+ if (ret == -ENOMEM && wbc->sync_mode == WB_SYNC_ALL) {
if (io->io_bio) {
ext4_io_submit(io);
congestion_wait(BLK_RW_ASYNC, HZ/50);
Patches currently in stable-queue which might be from dan.carpenter@oracle.com are
queue-4.4/ext4-crypto-fix-some-error-handling.patch
^ permalink raw reply
* Patch "ext4 crypto: don't let data integrity writebacks fail with ENOMEM" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 10:22 UTC (permalink / raw)
To: tytso, ebiggers, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ext4 crypto: don't let data integrity writebacks fail with ENOMEM
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=summary
The filename of the patch is:
ext4-crypto-don-t-let-data-integrity-writebacks-fail-with-enomem.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@vger.kernel.org> know about it.
>From c9af28fdd44922a6c10c9f8315718408af98e315 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Sat, 26 Mar 2016 16:14:34 -0400
Subject: ext4 crypto: don't let data integrity writebacks fail with ENOMEM
From: Theodore Ts'o <tytso@mit.edu>
commit c9af28fdd44922a6c10c9f8315718408af98e315 upstream.
We don't want the writeback triggered from the journal commit (in
data=writeback mode) to cause the journal to abort due to
generic_writepages() returning an ENOMEM error. In addition, if
fsync() fails with ENOMEM, most applications will probably not do the
right thing.
So if we are doing a data integrity sync, and ext4_encrypt() returns
ENOMEM, we will submit any queued I/O to date, and then retry the
allocation using GFP_NOFAIL.
Google-Bug-Id: 27641567
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/crypto.c | 37 +++++++++++++++++++++----------------
fs/ext4/ext4.h | 6 ++++--
fs/ext4/page-io.c | 14 +++++++++++++-
fs/ext4/readpage.c | 2 +-
4 files changed, 39 insertions(+), 20 deletions(-)
--- a/fs/ext4/crypto.c
+++ b/fs/ext4/crypto.c
@@ -94,7 +94,8 @@ void ext4_release_crypto_ctx(struct ext4
* Return: An allocated and initialized encryption context on success; error
* value or NULL otherwise.
*/
-struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode)
+struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode,
+ gfp_t gfp_flags)
{
struct ext4_crypto_ctx *ctx = NULL;
int res = 0;
@@ -121,7 +122,7 @@ struct ext4_crypto_ctx *ext4_get_crypto_
list_del(&ctx->free_list);
spin_unlock_irqrestore(&ext4_crypto_ctx_lock, flags);
if (!ctx) {
- ctx = kmem_cache_zalloc(ext4_crypto_ctx_cachep, GFP_NOFS);
+ ctx = kmem_cache_zalloc(ext4_crypto_ctx_cachep, gfp_flags);
if (!ctx) {
res = -ENOMEM;
goto out;
@@ -258,7 +259,8 @@ static int ext4_page_crypto(struct inode
ext4_direction_t rw,
pgoff_t index,
struct page *src_page,
- struct page *dest_page)
+ struct page *dest_page,
+ gfp_t gfp_flags)
{
u8 xts_tweak[EXT4_XTS_TWEAK_SIZE];
@@ -269,7 +271,7 @@ static int ext4_page_crypto(struct inode
struct crypto_ablkcipher *tfm = ci->ci_ctfm;
int res = 0;
- req = ablkcipher_request_alloc(tfm, GFP_NOFS);
+ req = ablkcipher_request_alloc(tfm, gfp_flags);
if (!req) {
printk_ratelimited(KERN_ERR
"%s: crypto_request_alloc() failed\n",
@@ -310,9 +312,10 @@ static int ext4_page_crypto(struct inode
return 0;
}
-static struct page *alloc_bounce_page(struct ext4_crypto_ctx *ctx)
+static struct page *alloc_bounce_page(struct ext4_crypto_ctx *ctx,
+ gfp_t gfp_flags)
{
- ctx->w.bounce_page = mempool_alloc(ext4_bounce_page_pool, GFP_NOWAIT);
+ ctx->w.bounce_page = mempool_alloc(ext4_bounce_page_pool, gfp_flags);
if (ctx->w.bounce_page == NULL)
return ERR_PTR(-ENOMEM);
ctx->flags |= EXT4_WRITE_PATH_FL;
@@ -335,7 +338,8 @@ static struct page *alloc_bounce_page(st
* error value or NULL.
*/
struct page *ext4_encrypt(struct inode *inode,
- struct page *plaintext_page)
+ struct page *plaintext_page,
+ gfp_t gfp_flags)
{
struct ext4_crypto_ctx *ctx;
struct page *ciphertext_page = NULL;
@@ -343,17 +347,17 @@ struct page *ext4_encrypt(struct inode *
BUG_ON(!PageLocked(plaintext_page));
- ctx = ext4_get_crypto_ctx(inode);
+ ctx = ext4_get_crypto_ctx(inode, gfp_flags);
if (IS_ERR(ctx))
return (struct page *) ctx;
/* The encryption operation will require a bounce page. */
- ciphertext_page = alloc_bounce_page(ctx);
+ ciphertext_page = alloc_bounce_page(ctx, gfp_flags);
if (IS_ERR(ciphertext_page))
goto errout;
ctx->w.control_page = plaintext_page;
err = ext4_page_crypto(inode, EXT4_ENCRYPT, plaintext_page->index,
- plaintext_page, ciphertext_page);
+ plaintext_page, ciphertext_page, gfp_flags);
if (err) {
ciphertext_page = ERR_PTR(err);
errout:
@@ -381,8 +385,8 @@ int ext4_decrypt(struct page *page)
{
BUG_ON(!PageLocked(page));
- return ext4_page_crypto(page->mapping->host,
- EXT4_DECRYPT, page->index, page, page);
+ return ext4_page_crypto(page->mapping->host, EXT4_DECRYPT,
+ page->index, page, page, GFP_NOFS);
}
int ext4_encrypted_zeroout(struct inode *inode, struct ext4_extent *ex)
@@ -403,11 +407,11 @@ int ext4_encrypted_zeroout(struct inode
BUG_ON(inode->i_sb->s_blocksize != PAGE_CACHE_SIZE);
- ctx = ext4_get_crypto_ctx(inode);
+ ctx = ext4_get_crypto_ctx(inode, GFP_NOFS);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ciphertext_page = alloc_bounce_page(ctx);
+ ciphertext_page = alloc_bounce_page(ctx, GFP_NOWAIT);
if (IS_ERR(ciphertext_page)) {
err = PTR_ERR(ciphertext_page);
goto errout;
@@ -415,11 +419,12 @@ int ext4_encrypted_zeroout(struct inode
while (len--) {
err = ext4_page_crypto(inode, EXT4_ENCRYPT, lblk,
- ZERO_PAGE(0), ciphertext_page);
+ ZERO_PAGE(0), ciphertext_page,
+ GFP_NOFS);
if (err)
goto errout;
- bio = bio_alloc(GFP_KERNEL, 1);
+ bio = bio_alloc(GFP_NOWAIT, 1);
if (!bio) {
err = -ENOMEM;
goto errout;
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2261,11 +2261,13 @@ extern struct kmem_cache *ext4_crypt_inf
bool ext4_valid_contents_enc_mode(uint32_t mode);
uint32_t ext4_validate_encryption_key_size(uint32_t mode, uint32_t size);
extern struct workqueue_struct *ext4_read_workqueue;
-struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode);
+struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode,
+ gfp_t gfp_flags);
void ext4_release_crypto_ctx(struct ext4_crypto_ctx *ctx);
void ext4_restore_control_page(struct page *data_page);
struct page *ext4_encrypt(struct inode *inode,
- struct page *plaintext_page);
+ struct page *plaintext_page,
+ gfp_t gfp_flags);
int ext4_decrypt(struct page *page);
int ext4_encrypted_zeroout(struct inode *inode, struct ext4_extent *ex);
extern const struct dentry_operations ext4_encrypted_d_ops;
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -23,6 +23,7 @@
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/mm.h>
+#include <linux/backing-dev.h>
#include "ext4_jbd2.h"
#include "xattr.h"
@@ -485,9 +486,20 @@ int ext4_bio_write_page(struct ext4_io_s
if (ext4_encrypted_inode(inode) && S_ISREG(inode->i_mode) &&
nr_to_submit) {
- data_page = ext4_encrypt(inode, page);
+ gfp_t gfp_flags = GFP_NOFS;
+
+ retry_encrypt:
+ data_page = ext4_encrypt(inode, page, gfp_flags);
if (IS_ERR(data_page)) {
ret = PTR_ERR(data_page);
+ if (ret == ENOMEM && wbc->sync_mode == WB_SYNC_ALL) {
+ if (io->io_bio) {
+ ext4_io_submit(io);
+ congestion_wait(BLK_RW_ASYNC, HZ/50);
+ }
+ gfp_flags |= __GFP_NOFAIL;
+ goto retry_encrypt;
+ }
data_page = NULL;
goto out;
}
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -279,7 +279,7 @@ int ext4_mpage_readpages(struct address_
if (ext4_encrypted_inode(inode) &&
S_ISREG(inode->i_mode)) {
- ctx = ext4_get_crypto_ctx(inode);
+ ctx = ext4_get_crypto_ctx(inode, GFP_NOFS);
if (IS_ERR(ctx))
goto set_error_page;
}
Patches currently in stable-queue which might be from tytso@mit.edu are
queue-4.4/fscrypt-avoid-collisions-when-presenting-long-encrypted-filenames.patch
queue-4.4/fscrypt-fix-context-consistency-check-when-key-s-unavailable.patch
queue-4.4/ext4-crypto-fix-some-error-handling.patch
queue-4.4/ext4-crypto-don-t-let-data-integrity-writebacks-fail-with-enomem.patch
queue-4.4/f2fs-check-entire-encrypted-bigname-when-finding-a-dentry.patch
^ permalink raw reply
* Re: [PATCH 1/2] f2fs: check entire encrypted bigname when finding a dentry
From: Greg Kroah-Hartman @ 2017-05-23 10:22 UTC (permalink / raw)
To: Eric Biggers; +Cc: stable, Jaegeuk Kim, Eric Biggers, Theodore Ts'o
In-Reply-To: <20170518180711.22969-1-ebiggers3@gmail.com>
On Thu, May 18, 2017 at 11:07:10AM -0700, Eric Biggers wrote:
> From: Jaegeuk Kim <jaegeuk@kernel.org>
>
> commit 6332cd32c8290a80e929fc044dc5bdba77396e33 upstream. Please apply
> to 4.9-stable.
Thanks for all of these backports, now queued up.
greg k-h
^ permalink raw reply
* Re: [PATCH] fscrypt: fix context consistency check when key(s) unavailable
From: Greg Kroah-Hartman @ 2017-05-23 10:17 UTC (permalink / raw)
To: Eric Biggers; +Cc: stable, Jaegeuk Kim, Eric Biggers, Theodore Ts'o
In-Reply-To: <20170518184204.84255-1-ebiggers3@gmail.com>
On Thu, May 18, 2017 at 11:42:04AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> commit a03ea7dc45df3134113f6fc589658fec90402954 upstream. Please apply
> to 4.4-stable.
You mean 272f98f6846277378e1758a49a49d7bf39343c02, right?
^ permalink raw reply
* Re: [PATCH 1/2] ext4 crypto: don't let data integrity writebacks fail with ENOMEM
From: Greg Kroah-Hartman @ 2017-05-23 10:13 UTC (permalink / raw)
To: Eric Biggers; +Cc: stable, Theodore Ts'o, Eric Biggers
In-Reply-To: <20170522233752.109220-1-ebiggers3@gmail.com>
On Mon, May 22, 2017 at 04:37:51PM -0700, Eric Biggers wrote:
> From: Theodore Ts'o <tytso@mit.edu>
>
> commit c9af28fdd44922a6c10c9f8315718408af98e315 upstream. [Please apply
> to 4.4-stable. This fixes a bug which has caused problems on both
> Android and Chrome OS, and this fix has already been included in a
> number of ext4 encryption backports.]
>
> We don't want the writeback triggered from the journal commit (in
> data=writeback mode) to cause the journal to abort due to
> generic_writepages() returning an ENOMEM error. In addition, if
> fsync() fails with ENOMEM, most applications will probably not do the
> right thing.
>
> So if we are doing a data integrity sync, and ext4_encrypt() returns
> ENOMEM, we will submit any queued I/O to date, and then retry the
> allocation using GFP_NOFAIL.
>
> Google-Bug-Id: 27641567
>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Thanks for both of these, now queued up.
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/2] dax: Fix race between colliding PMD & PTE entries
From: Jan Kara @ 2017-05-23 9:59 UTC (permalink / raw)
To: Ross Zwisler
Cc: Andrew Morton, linux-kernel, Darrick J. Wong, Alexander Viro,
Christoph Hellwig, Dan Williams, Dave Hansen, Jan Kara,
Matthew Wilcox, linux-fsdevel, linux-mm, linux-nvdimm,
Kirill A . Shutemov, Pawel Lebioda, Dave Jiang, Xiong Zhou,
Eryu Guan, stable
In-Reply-To: <20170522215749.23516-2-ross.zwisler@linux.intel.com>
On Mon 22-05-17 15:57:49, Ross Zwisler wrote:
> We currently have two related PMD vs PTE races in the DAX code. These can
> both be easily triggered by having two threads reading and writing
> simultaneously to the same private mapping, with the key being that private
> mapping reads can be handled with PMDs but private mapping writes are
> always handled with PTEs so that we can COW.
>
> Here is the first race:
>
> CPU 0 CPU 1
>
> (private mapping write)
> __handle_mm_fault()
> create_huge_pmd() - FALLBACK
> handle_pte_fault()
> passes check for pmd_devmap()
>
> (private mapping read)
> __handle_mm_fault()
> create_huge_pmd()
> dax_iomap_pmd_fault() inserts PMD
>
> dax_iomap_pte_fault() does a PTE fault, but we already have a DAX PMD
> installed in our page tables at this spot.
>
> Here's the second race:
>
> CPU 0 CPU 1
>
> (private mapping read)
> __handle_mm_fault()
> passes check for pmd_none()
> create_huge_pmd()
> dax_iomap_pmd_fault() inserts PMD
>
> (private mapping write)
> __handle_mm_fault()
> create_huge_pmd() - FALLBACK
> (private mapping read)
> __handle_mm_fault()
> passes check for pmd_none()
> create_huge_pmd()
>
> handle_pte_fault()
> dax_iomap_pte_fault() inserts PTE
> dax_iomap_pmd_fault() inserts PMD,
> but we already have a PTE at
> this spot.
>
> The core of the issue is that while there is isolation between faults to
> the same range in the DAX fault handlers via our DAX entry locking, there
> is no isolation between faults in the code in mm/memory.c. This means for
> instance that this code in __handle_mm_fault() can run:
>
> if (pmd_none(*vmf.pmd) && transparent_hugepage_enabled(vma)) {
> ret = create_huge_pmd(&vmf);
>
> But by the time we actually get to run the fault handler called by
> create_huge_pmd(), the PMD is no longer pmd_none() because a racing PTE
> fault has installed a normal PMD here as a parent. This is the cause of
> the 2nd race. The first race is similar - there is the following check in
> handle_pte_fault():
>
> } else {
> /* See comment in pte_alloc_one_map() */
> if (pmd_devmap(*vmf->pmd) || pmd_trans_unstable(vmf->pmd))
> return 0;
>
> So if a pmd_devmap() PMD (a DAX PMD) has been installed at vmf->pmd, we
> will bail and retry the fault. This is correct, but there is nothing
> preventing the PMD from being installed after this check but before we
> actually get to the DAX PTE fault handlers.
>
> In my testing these races result in the following types of errors:
>
> BUG: Bad rss-counter state mm:ffff8800a817d280 idx:1 val:1
> BUG: non-zero nr_ptes on freeing mm: 15
>
> Fix this issue by having the DAX fault handlers verify that it is safe to
> continue their fault after they have taken an entry lock to block other
> racing faults.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Reported-by: Pawel Lebioda <pawel.lebioda@intel.com>
> Cc: stable@vger.kernel.org
Looks good. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
>
> Changes from v1:
> - Handle the failure case in dax_iomap_pte_fault() by retrying the fault
> (Jan).
>
> This series has survived my new xfstest (generic/437) and full xfstest
> regression testing runs.
> ---
> fs/dax.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index c22eaf1..fc62f36 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1155,6 +1155,17 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
> }
>
> /*
> + * It is possible, particularly with mixed reads & writes to private
> + * mappings, that we have raced with a PMD fault that overlaps with
> + * the PTE we need to set up. If so just return and the fault will be
> + * retried.
> + */
> + if (pmd_devmap(*vmf->pmd)) {
> + vmf_ret = VM_FAULT_NOPAGE;
> + goto unlock_entry;
> + }
> +
> + /*
> * Note that we don't bother to use iomap_apply here: DAX required
> * the file system block size to be equal the page size, which means
> * that we never have to deal with more than a single extent here.
> @@ -1398,6 +1409,15 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
> goto fallback;
>
> /*
> + * It is possible, particularly with mixed reads & writes to private
> + * mappings, that we have raced with a PTE fault that overlaps with
> + * the PMD we need to set up. If so we just fall back to a PTE fault
> + * ourselves.
> + */
> + if (!pmd_none(*vmf->pmd))
> + goto unlock_entry;
> +
> + /*
> * Note that we don't use iomap_apply here. We aren't doing I/O, only
> * setting up a mapping, so really we're using iomap_begin() as a way
> * to look up our filesystem block.
> --
> 2.9.4
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Patch "drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one" has been added to the 4.9-stable tree
From: Greg Kroah-Hartman @ 2017-05-23 9:30 UTC (permalink / raw)
To: Ilia Mirkin; +Cc: Ben Skeggs, # 3.9+, stable-commits
In-Reply-To: <CAKb7UviMpJ+aHGTrLJ2g77VeVbxUffh0hC9amTy68JOX8jptqA@mail.gmail.com>
On Mon, May 22, 2017 at 07:49:50PM -0400, Ilia Mirkin wrote:
> On Mon, May 22, 2017 at 6:57 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> > Hi Greg,
> >
> > This patch appears to have misapplied. I'm not sure why cherry-pick
> > got it wrong, but this is meant to go in the nv4a_chipset definition,
> > not nv44_chipset.
> >
> > This comment also applies to the 4.4 and 4.11 cherry-picks you just did.
>
> Aha, I see what happened. f94773b9f5ecd1df7c88c2e921924dd41d2020cc
> made it into v4.11. However by then it appears to have also made it
> into drm-next as ac799acaa4d8db4f7dcd968b15c9596c80a4677f and thus the
> drm merge into v4.12. So now you have two versions of the same commit
> and are trying to cherry-pick both.
Why in the world would you include the same patch in two different trees
with two different git ids? I'm _really_ starting to hate the drm
trees...
> I'm guessing it's also the reason why your cherrypick of my other
> commit failed (ad01a91a820cd9f0d880c407bf556b67298dcc93).
That would make sense, but again, why is this happening?
> And I might note that
> "drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-one.patch" was
> already there before, so didn't make it into your "4.9-stable patches"
> commit on the stable-queue git tree.
Ok, so what should i do here? Drop all of the nouveau patches? Some of
them? Which ones were wrong?
totally confused and grumpy,
greg k-h
^ permalink raw reply
* Re: FAILED: patch "[PATCH] of: fdt: add missing allocation-failure check" failed to apply to 4.4-stable tree
From: Greg Kroah-Hartman @ 2017-05-23 9:16 UTC (permalink / raw)
To: Rob Herring; +Cc: Johan Hovold, stable
In-Reply-To: <CAL_Jsq+2cZ82QmdWcSW0n00LeqB+VNei35gjAuJ5CXyEpu=bsg@mail.gmail.com>
On Mon, May 22, 2017 at 03:46:29PM -0500, Rob Herring wrote:
> On Mon, May 22, 2017 at 2:17 PM, <gregkh@linuxfoundation.org> wrote:
> >
> > The patch below does not apply to the 4.4-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> >
> > thanks,
> >
> > greg k-h
> >
> > ------------------ original commit in Linus's tree ------------------
> >
> > From 49e67dd17649b60b4d54966e18ec9c80198227f0 Mon Sep 17 00:00:00 2001
> > From: Johan Hovold <johan@kernel.org>
> > Date: Wed, 17 May 2017 17:29:09 +0200
> > Subject: [PATCH] of: fdt: add missing allocation-failure check
> >
> > The memory allocator passed to __unflatten_device_tree() (e.g. a wrapped
> > kzalloc) can fail so add the missing sanity check to avoid dereferencing
> > a NULL pointer.
> >
> > Fixes: fe14042358fa ("of/flattree: Refactor unflatten_device_tree and add fdt_unflatten_tree")
> > Cc: stable <stable@vger.kernel.org> # 2.6.38
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> >
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index a0972219ccfc..0373ae49d24d 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -507,6 +507,9 @@ void *__unflatten_device_tree(const void *blob,
>
> The context looks the same, it's just the line number is 416 in v4.4.
>
> >
> > /* Allocate memory for the expanded device tree */
> > mem = dt_alloc(size + 4, __alignof__(struct device_node));
> > + if (!mem)
> > + return NULL;
> > +
No, in 4.4 this function's return type is "void", not "void *" so the
build fails (well, has a warning, which means it isn't correct.)
thanks,
greg k-h
^ permalink raw reply
* [PATCH rdma-next 1/2] IB/core: Namespace is a mandatory input parameter for address resolution
From: Leon Romanovsky @ 2017-05-23 7:48 UTC (permalink / raw)
To: Doug Ledford; +Cc: linux-rdma, Moni Shoua, stable
From: Moni Shoua <monis@mellanox.com>
In function addr_resolve() the namespace is a required input parameter
and not an output. It is passed later for searching the routing table
and device addresses. Also, it shouldn't be copied back to the caller.
Fixes: 565edd1d5555 ('IB/addr: Pass network namespace as a parameter')
Cc: <stable@vger.kernel.org> # v4.3+
Signed-off-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
---
drivers/infiniband/core/addr.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 02971e239a18..d2afcb3dd81a 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -518,6 +518,11 @@ static int addr_resolve(struct sockaddr *src_in,
struct dst_entry *dst;
int ret;
+ if (!addr->net) {
+ pr_warn_ratelimited("%s: missing namespace\n", __func__);
+ return -EINVAL;
+ }
+
if (src_in->sa_family == AF_INET) {
struct rtable *rt = NULL;
const struct sockaddr_in *dst_in4 =
@@ -555,7 +560,6 @@ static int addr_resolve(struct sockaddr *src_in,
}
addr->bound_dev_if = ndev->ifindex;
- addr->net = dev_net(ndev);
dev_put(ndev);
return ret;
--
2.12.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox