The Kernel Crypto API request output the next IV data to
IV buffer for CBC implementation. So the last block data of
ciphertext should be copid into assigned IV buffer.
Reported-by: Eric Biggers <ebiggers(a)google.com>
Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288")
Cc: <stable(a)vger.kernel.org> # v4.5+
Signed-off-by: Zhang Zhijie <zhangzj(a)rock-chips.com>
diff --git a/drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c b/drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
index 02dac6ae7e53..7564b4c41afc 100644
--- a/drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
+++ b/drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
@@ -250,9 +250,14 @@ static int rk_set_data_start(struct rk_crypto_info *dev)
u8 *src_last_blk = page_address(sg_page(dev->sg_src)) +
dev->sg_src->offset + dev->sg_src->length - ivsize;
- /* store the iv that need to be updated in chain mode */
- if (ctx->mode & RK_CRYPTO_DEC)
+ /* Store the iv that need to be updated in chain mode.
+ * And update the IV buffer to contain the next IV for decryption mode.
+ */
+ if (ctx->mode & RK_CRYPTO_DEC) {
memcpy(ctx->iv, src_last_blk, ivsize);
+ sg_pcopy_to_buffer(dev->first, dev->src_nents, req->info,
+ ivsize, dev->total - ivsize);
+ }
err = dev->load_data(dev, dev->sg_src, dev->sg_dst);
if (!err)
@@ -288,13 +293,19 @@ static void rk_iv_copyback(struct rk_crypto_info *dev)
struct ablkcipher_request *req =
ablkcipher_request_cast(dev->async_req);
struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
+ struct rk_cipher_ctx *ctx = crypto_ablkcipher_ctx(tfm);
u32 ivsize = crypto_ablkcipher_ivsize(tfm);
- if (ivsize == DES_BLOCK_SIZE)
- memcpy_fromio(req->info, dev->reg + RK_CRYPTO_TDES_IV_0,
- ivsize);
- else if (ivsize == AES_BLOCK_SIZE)
- memcpy_fromio(req->info, dev->reg + RK_CRYPTO_AES_IV_0, ivsize);
+ /* Update the IV buffer to contain the next IV for encryption mode. */
+ if (!(ctx->mode & RK_CRYPTO_DEC)) {
+ if (dev->aligned) {
+ memcpy(req->info, sg_virt(dev->sg_dst) +
+ dev->sg_dst->length - ivsize, ivsize);
+ } else {
+ memcpy(req->info, dev->addr_vir +
+ dev->count - ivsize, ivsize);
+ }
+ }
}
static void rk_update_iv(struct rk_crypto_info *dev)
--
2.17.1
Currently, we free the psp_master if the PLATFORM_INIT fails during the
SEV FW probe. If psp_master is freed then driver does not invoke the PSP
FW. As per SEV FW spec, there are several commands (PLATFORM_RESET,
PLATFORM_STATUS, GET_ID etc) which can be executed in the UNINIT state
We should not free the psp_master when PLATFORM_INIT fails.
Fixes: 200664d5237f ("crypto: ccp: Add SEV support")
Cc: Tom Lendacky <thomas.lendacky(a)amd.com>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Cc: Gary Hook <gary.hook(a)amd.com>
Cc: stable(a)vger.kernel.org # 4.19.y
Signed-off-by: Brijesh Singh <brijesh.singh(a)amd.com>
---
drivers/crypto/ccp/psp-dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 80a59be9c80d..656838433f2f 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -1064,7 +1064,7 @@ void psp_pci_init(void)
rc = sev_platform_init(&error);
if (rc) {
dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error);
- goto err;
+ return;
}
dev_info(sp->dev, "SEV API:%d.%d build:%d\n", psp_master->api_major,
--
2.17.1
From: Ofir Drang <ofir.drang(a)arm.com>
During power management suspend the driver need to prepare the device
for the power down operation and as a last indication write to the
HOST_POWER_DOWN_EN register which signals to the hardware that
The ccree is ready for power down.
Signed-off-by: Ofir Drang <ofir.drang(a)arm.com>
Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com>
Cc: stable(a)vger.kernel.org # v4.19+
---
drivers/crypto/ccree/cc_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ccree/cc_pm.c b/drivers/crypto/ccree/cc_pm.c
index 9a5abe406996..77025da2dcb6 100644
--- a/drivers/crypto/ccree/cc_pm.c
+++ b/drivers/crypto/ccree/cc_pm.c
@@ -25,13 +25,13 @@ int cc_pm_suspend(struct device *dev)
int rc;
dev_dbg(dev, "set HOST_POWER_DOWN_EN\n");
- cc_iowrite(drvdata, CC_REG(HOST_POWER_DOWN_EN), POWER_DOWN_ENABLE);
rc = cc_suspend_req_queue(drvdata);
if (rc) {
dev_err(dev, "cc_suspend_req_queue (%x)\n", rc);
return rc;
}
fini_cc_regs(drvdata);
+ cc_iowrite(drvdata, CC_REG(HOST_POWER_DOWN_EN), POWER_DOWN_ENABLE);
cc_clk_off(drvdata);
return 0;
}
--
2.21.0
commit 662d66466637862ef955f7f6e78a286d8cf0ebef upstream.
When a QP is put into error state, all pending requests in the send
work queue should be drained. The following sequence of events could
lead to a failure, causing a request to hang:
(1) The QP builds a packet and tries to send through SDMA engine.
However, PIO engine is still busy. Consequently, this packet is put
on the QP's tx list and the QP is put on the PIO waiting list. The
field qp->s_flags is set with HFI1_S_WAIT_PIO_DRAIN;
(2) The QP is put into error state by the user application and
notify_error_qp() is called, which removes the QP from the PIO waiting
list and the packet from the QP's tx list. In addition, qp->s_flags
is cleared of RVT_S_ANY_WAIT_IO bits, which does not include
HFI1_S_WAIT_PIO_DRAIN bit;
(3) The hfi1_schdule_send() function is called to drain the QP's send
queue. Subsequently, hfi1_do_send() is called. Since the flag bit
HFI1_S_WAIT_PIO_DRAIN is set in qp->s_flags, hfi1_send_ok() fails.
As a result, hfi1_do_send() bails out without draining any request
from the send queue;
(4) The PIO engine completes the sending and tries to wake up any QP
on its waiting list. But the QP has been removed from the PIO waiting
list and therefore is kept in sleep forever.
The fix is to clear qp->s_flags of HFI1_S_ANY_WAIT_IO bits in step (2).
HFI1_S_ANY_WAIT_IO includes RVT_S_ANY_WAIT_IO and HFI1_S_WAIT_PIO_DRAIN.
Fixes: 2e2ba09e48b7 ("IB/rdmavt, IB/hfi1: Create device dependent s_flags")
Cc: <stable(a)vger.kernel.org> # 4.19.x+
Reviewed-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com>
Reviewed-by: Alex Estrin <alex.estrin(a)intel.com>
Signed-off-by: Kaike Wan <kaike.wan(a)intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
---
drivers/infiniband/hw/hfi1/qp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/qp.c b/drivers/infiniband/hw/hfi1/qp.c
index 9b1e84a..63c5ba6 100644
--- a/drivers/infiniband/hw/hfi1/qp.c
+++ b/drivers/infiniband/hw/hfi1/qp.c
@@ -784,7 +784,7 @@ void notify_error_qp(struct rvt_qp *qp)
write_seqlock(lock);
if (!list_empty(&priv->s_iowait.list) &&
!(qp->s_flags & RVT_S_BUSY)) {
- qp->s_flags &= ~RVT_S_ANY_WAIT_IO;
+ qp->s_flags &= ~HFI1_S_ANY_WAIT_IO;
list_del_init(&priv->s_iowait.list);
priv->s_iowait.lock = NULL;
rvt_put_qp(qp);
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
debugfs can now report an error code if something went wrong instead of
just NULL. So if the return value is to be used as a "real" dentry, it
needs to be checked if it is an error before dereferencing it.
This is now happening because of ff9fb72bc077 ("debugfs: return error
values, not NULL"). If multiple iwlwifi devices are in the system, this
can cause problems when the driver attempts to create the main debugfs
directory again. Later on in the code we fail horribly by trying to
dereference a pointer that is an error value.
Reported-by: Laura Abbott <labbott(a)redhat.com>
Reported-by: Gabriel Ramirez <gabriello.ramirez(a)gmail.com>
Cc: Johannes Berg <johannes.berg(a)intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
Cc: Luca Coelho <luciano.coelho(a)intel.com>
Cc: Intel Linux Wireless <linuxwifi(a)intel.com>
Cc: Kalle Valo <kvalo(a)codeaurora.org>
Cc: stable <stable(a)vger.kernel.org> # 5.0
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
index 2453ceabf00d..738eddb2e7ac 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
@@ -774,6 +774,11 @@ void iwl_mvm_vif_dbgfs_register(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
return;
mvmvif->dbgfs_dir = debugfs_create_dir("iwlmvm", dbgfs_dir);
+ if (IS_ERR_OR_NULL(mvmvif->dbgfs_dir)) {
+ IWL_ERR(mvm, "Failed to create debugfs directory under %pd\n",
+ dbgfs_dir);
+ return;
+ }
if (!mvmvif->dbgfs_dir) {
IWL_ERR(mvm, "Failed to create debugfs directory under %pd\n",
--
2.20.1
Because bio_kmalloc uses inline iovecs, the limit on the number of entries
is not BIO_MAX_PAGES but rather UIO_MAXIOV, which indeed is already checked
in bio_kmalloc. This could cause SG_IO requests to be truncated and the HBA
to report a DMA overrun.
Note that if the argument to iov_iter_npages were changed to UIO_MAXIOV,
we would still truncate SG_IO requests beyond UIO_MAXIOV pages. Changing
it to UIO_MAXIOV + 1 instead ensures that bio_kmalloc notices that the
request is too big and blocks it.
Cc: stable(a)vger.kernel.org
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Fixes: b282cc766958 ("bio_map_user_iov(): get rid of the iov_for_each()", 2017-10-11)
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
v1->v2: now with "git commit"
---
block/bio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/bio.c b/block/bio.c
index 4db1008309ed..0914ae4adae9 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1299,7 +1299,7 @@ struct bio *bio_map_user_iov(struct request_queue *q,
if (!iov_iter_count(iter))
return ERR_PTR(-EINVAL);
- bio = bio_kmalloc(gfp_mask, iov_iter_npages(iter, BIO_MAX_PAGES));
+ bio = bio_kmalloc(gfp_mask, iov_iter_npages(iter, UIO_MAXIOV + 1));
if (!bio)
return ERR_PTR(-ENOMEM);
--
2.21.0
From: Vicente Bergas <vicencb(a)gmail.com>
As explained by Robin Murphy:
> the IOMMU shutdown disables paging, so if the VOP is still
> scanning out then that will result in whatever IOVAs it was using now going
> straight out onto the bus as physical addresses.
We had a more radical approach before in commit
7f3ef5dedb14 ("drm/rockchip: Allow driver to be shutdown on reboot/kexec")
but that resulted in new warnings and oopses on shutdown on rk3399
chromeos devices.
So second try is resurrecting Vicentes shutdown change which should
achieve the same result but in a less drastic way.
Fixes: 63238173b2fa ("Revert drm/rockchip: Allow driver to be shutdown on reboot/kexec")
Cc: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Cc: Robin Murphy <robin.murphy(a)arm.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Doug Anderson <dianders(a)chromium.org>
Cc: stable(a)vger.kernel.org
Suggested-by: JeffyChen <jeffy.chen(a)rock-chips.com>
Suggested-by: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Vicente Bergas <vicencb(a)gmail.com>
[adapted commit message to explain the history]
Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 8d7a634c12c2..cb938d3cd3c2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -448,6 +448,14 @@ static int rockchip_drm_platform_remove(struct platform_device *pdev)
return 0;
}
+static void rockchip_drm_platform_shutdown(struct platform_device *pdev)
+{
+ struct drm_device *drm = platform_get_drvdata(pdev);
+
+ if (drm)
+ drm_atomic_helper_shutdown(drm);
+}
+
static const struct of_device_id rockchip_drm_dt_ids[] = {
{ .compatible = "rockchip,display-subsystem", },
{ /* sentinel */ },
@@ -457,6 +465,7 @@ MODULE_DEVICE_TABLE(of, rockchip_drm_dt_ids);
static struct platform_driver rockchip_drm_platform_driver = {
.probe = rockchip_drm_platform_probe,
.remove = rockchip_drm_platform_remove,
+ .shutdown = rockchip_drm_platform_shutdown,
.driver = {
.name = "rockchip-drm",
.of_match_table = rockchip_drm_dt_ids,
--
2.20.1
From: Fuqian Huang <huangfq.daxian(a)gmail.com>
As there is still no hash for %p to print the address in linux 4.14,
the address of function idt77252_init will be printed to syslog.
Outputting kernel addresses will reveal the locations of kernel code
and data. This case is similar to CVE-2018-7273[1].
Also, there is no need to print the address of
function idt77252_init in idt77252_init.
Just remove the print statement.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7273
Cc: <Stable(a)vger.kernel.org> # v4.14+
Signed-off-by: Fuqian Huang <huangfq.daxian(a)gmail.com>
---
drivers/atm/idt77252.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index 47f3c4a..76e7736 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -3743,8 +3743,6 @@ static int __init idt77252_init(void)
{
struct sk_buff *skb;
- printk("%s: at %p\n", __func__, idt77252_init);
-
if (sizeof(skb->cb) < sizeof(struct atm_skb_data) +
sizeof(struct idt77252_skb_prv)) {
printk(KERN_ERR "%s: skb->cb is too small (%lu < %lu)\n",
--
2.11.0
I'm occasionally seeing a kmemleak warning in xfstest generic/013:
unreferenced object 0xffff8881fccca940 (size 32):
comm "kworker/0:1", pid 12, jiffies 4295005883 (age 130.648s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000d741a1ea>] build_snap_context+0x5b/0x2a0
[<0000000021a00533>] rebuild_snap_realms+0x27/0x90
[<00000000ac538600>] rebuild_snap_realms+0x42/0x90
[<000000000e955fac>] ceph_update_snap_trace+0x2ee/0x610
[<00000000a9550416>] ceph_handle_snap+0x317/0x5f3
[<00000000fc287b83>] dispatch+0x362/0x176c
[<00000000a312c741>] ceph_con_workfn+0x9ce/0x2cf0
[<000000004168e3a9>] process_one_work+0x1d4/0x400
[<000000002188e9e7>] worker_thread+0x2d/0x3c0
[<00000000b593e4b3>] kthread+0x112/0x130
[<00000000a8587dca>] ret_from_fork+0x35/0x40
[<00000000ba1c9c1d>] 0xffffffffffffffff
It looks like it is possible that we miss a flush_ack from the MDS when,
for example, umounting the filesystem. In that case, we can simply drop
the reference to the ceph_snap_context obtained in ceph_queue_cap_snap().
Link: https://tracker.ceph.com/issues/38224
Cc: stable(a)vger.kernel.org
Signed-off-by: Luis Henriques <lhenriques(a)suse.com>
---
fs/ceph/caps.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index 36a8dc699448..208f4dc6f574 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -1054,6 +1054,7 @@ int ceph_is_any_caps(struct inode *inode)
static void drop_inode_snap_realm(struct ceph_inode_info *ci)
{
struct ceph_snap_realm *realm = ci->i_snap_realm;
+
spin_lock(&realm->inodes_with_caps_lock);
list_del_init(&ci->i_snap_realm_item);
ci->i_snap_realm_counter++;
@@ -1063,6 +1064,12 @@ static void drop_inode_snap_realm(struct ceph_inode_info *ci)
spin_unlock(&realm->inodes_with_caps_lock);
ceph_put_snap_realm(ceph_sb_to_client(ci->vfs_inode.i_sb)->mdsc,
realm);
+ /*
+ * ci->i_head_snapc should be NULL, but we may still be waiting for a
+ * flush_ack from the MDS. In that case, we still hold a ref for the
+ * ceph_snap_context and we need to drop it.
+ */
+ ceph_put_snap_context(ci->i_head_snapc);
}
/*
The patch titled
Subject: zram: pass down the bvec we need to read into in the work struct
has been added to the -mm tree. Its filename is
zram-pass-down-the-bvec-we-need-to-read-into-in-the-work-struct.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/zram-pass-down-the-bvec-we-need-to…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/zram-pass-down-the-bvec-we-need-to…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jérôme Glisse <jglisse(a)redhat.com>
Subject: zram: pass down the bvec we need to read into in the work struct
When scheduling work item to read page we need to pass down the proper
bvec struct which points to the page to read into. Before this patch it
uses a randomly initialized bvec (only if PAGE_SIZE != 4096) which is
wrong.
Note that without this patch on arch/kernel where PAGE_SIZE != 4096
userspace could read random memory through a zram block device (thought
userspace probably would have no control on the address being read).
Link: http://lkml.kernel.org/r/20190408183219.26377-1-jglisse@redhat.com
Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Nitin Gupta <ngupta(a)vflare.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/block/zram/zram_drv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/block/zram/zram_drv.c~zram-pass-down-the-bvec-we-need-to-read-into-in-the-work-struct
+++ a/drivers/block/zram/zram_drv.c
@@ -774,18 +774,18 @@ struct zram_work {
struct zram *zram;
unsigned long entry;
struct bio *bio;
+ struct bio_vec bvec;
};
#if PAGE_SIZE != 4096
static void zram_sync_read(struct work_struct *work)
{
- struct bio_vec bvec;
struct zram_work *zw = container_of(work, struct zram_work, work);
struct zram *zram = zw->zram;
unsigned long entry = zw->entry;
struct bio *bio = zw->bio;
- read_from_bdev_async(zram, &bvec, entry, bio);
+ read_from_bdev_async(zram, &zw->bvec, entry, bio);
}
/*
@@ -798,6 +798,7 @@ static int read_from_bdev_sync(struct zr
{
struct zram_work work;
+ work.bvec = *bvec;
work.zram = zram;
work.entry = entry;
work.bio = bio;
_
Patches currently in -mm which might be from jglisse(a)redhat.com are
zram-pass-down-the-bvec-we-need-to-read-into-in-the-work-struct.patch
mm-hmm-select-mmu-notifier-when-selecting-hmm-v2.patch
mm-hmm-use-reference-counting-for-hmm-struct-v3.patch
mm-hmm-do-not-erase-snapshot-when-a-range-is-invalidated.patch
mm-hmm-improve-and-rename-hmm_vma_get_pfns-to-hmm_range_snapshot-v2.patch
mm-hmm-improve-and-rename-hmm_vma_fault-to-hmm_range_fault-v3.patch
mm-hmm-improve-driver-api-to-work-and-wait-over-a-range-v3.patch
mm-hmm-add-default-fault-flags-to-avoid-the-need-to-pre-fill-pfns-arrays-v2.patch
mm-hmm-mirror-hugetlbfs-snapshoting-faulting-and-dma-mapping-v3.patch
mm-hmm-allow-to-mirror-vma-of-a-file-on-a-dax-backed-filesystem-v3.patch
mm-hmm-add-helpers-to-test-if-mm-is-still-alive-or-not.patch
mm-hmm-add-an-helper-function-that-fault-pages-and-map-them-to-a-device-v3.patch
mm-hmm-add-an-helper-function-that-fault-pages-and-map-them-to-a-device-v3-fix.patch
mm-hmm-convert-various-hmm_pfn_-to-device_entry-which-is-a-better-name.patch
mm-mmu_notifier-helper-to-test-if-a-range-invalidation-is-blockable.patch
mm-mmu_notifier-convert-user-range-blockable-to-helper-function.patch
mm-mmu_notifier-convert-mmu_notifier_range-blockable-to-a-flags.patch
mm-mmu_notifier-contextual-information-for-event-enums.patch
mm-mmu_notifier-contextual-information-for-event-triggering-invalidation-v2.patch
mm-mmu_notifier-use-correct-mmu_notifier-events-for-each-invalidation.patch
mm-mmu_notifier-pass-down-vma-and-reasons-why-mmu-notifier-is-happening-v2.patch
mm-mmu_notifier-mmu_notifier_range_update_to_read_only-helper.patch
The patch titled
Subject: libnvdimm/pfn: fix fsdax-mode namespace info-block zero-fields
has been added to the -mm tree. Its filename is
libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/libnvdimm-pfn-fix-fsdax-mode-names…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/libnvdimm-pfn-fix-fsdax-mode-names…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Dan Williams <dan.j.williams(a)intel.com>
Subject: libnvdimm/pfn: fix fsdax-mode namespace info-block zero-fields
At namespace creation time there is the potential for the "expected to be
zero" fields of a 'pfn' info-block to be filled with indeterminate data.
While the kernel buffer is zeroed on allocation it is immediately
overwritten by nd_pfn_validate() filling it with the current contents of
the on-media info-block location. For fields like, 'flags' and the
'padding' it potentially means that future implementations can not rely on
those fields being zero.
In preparation to stop using the 'start_pad' and 'end_trunc' fields for
section alignment, arrange for fields that are not explicitly initialized
to be guaranteed zero. Bump the minor version to indicate it is safe to
assume the 'padding' and 'flags' are zero. Otherwise, this corruption is
expected to benign since all other critical fields are explicitly
initialized.
Link: http://lkml.kernel.org/r/155552639290.2015392.17304211251966796338.stgit@dw…
Fixes: 32ab0a3f5170 ("libnvdimm, pmem: 'struct page' for pmem")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Jeff Moyer <jmoyer(a)redhat.com>
Cc: Jérôme Glisse <jglisse(a)redhat.com>
Cc: Logan Gunthorpe <logang(a)deltatee.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Toshi Kani <toshi.kani(a)hpe.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/nvdimm/dax_devs.c | 2 +-
drivers/nvdimm/pfn.h | 1 +
drivers/nvdimm/pfn_devs.c | 18 +++++++++++++++---
3 files changed, 17 insertions(+), 4 deletions(-)
--- a/drivers/nvdimm/dax_devs.c~libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields
+++ a/drivers/nvdimm/dax_devs.c
@@ -126,7 +126,7 @@ int nd_dax_probe(struct device *dev, str
nvdimm_bus_unlock(&ndns->dev);
if (!dax_dev)
return -ENOMEM;
- pfn_sb = devm_kzalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
+ pfn_sb = devm_kmalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
nd_pfn->pfn_sb = pfn_sb;
rc = nd_pfn_validate(nd_pfn, DAX_SIG);
dev_dbg(dev, "dax: %s\n", rc == 0 ? dev_name(dax_dev) : "<none>");
--- a/drivers/nvdimm/pfn_devs.c~libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields
+++ a/drivers/nvdimm/pfn_devs.c
@@ -420,6 +420,15 @@ static int nd_pfn_clear_memmap_errors(st
return 0;
}
+/**
+ * nd_pfn_validate - read and validate info-block
+ * @nd_pfn: fsdax namespace runtime state / properties
+ * @sig: 'devdax' or 'fsdax' signature
+ *
+ * Upon return the info-block buffer contents (->pfn_sb) are
+ * indeterminate when validation fails, and a coherent info-block
+ * otherwise.
+ */
int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
{
u64 checksum, offset;
@@ -565,7 +574,7 @@ int nd_pfn_probe(struct device *dev, str
nvdimm_bus_unlock(&ndns->dev);
if (!pfn_dev)
return -ENOMEM;
- pfn_sb = devm_kzalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
+ pfn_sb = devm_kmalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
nd_pfn = to_nd_pfn(pfn_dev);
nd_pfn->pfn_sb = pfn_sb;
rc = nd_pfn_validate(nd_pfn, PFN_SIG);
@@ -702,7 +711,7 @@ static int nd_pfn_init(struct nd_pfn *nd
u64 checksum;
int rc;
- pfn_sb = devm_kzalloc(&nd_pfn->dev, sizeof(*pfn_sb), GFP_KERNEL);
+ pfn_sb = devm_kmalloc(&nd_pfn->dev, sizeof(*pfn_sb), GFP_KERNEL);
if (!pfn_sb)
return -ENOMEM;
@@ -711,11 +720,14 @@ static int nd_pfn_init(struct nd_pfn *nd
sig = DAX_SIG;
else
sig = PFN_SIG;
+
rc = nd_pfn_validate(nd_pfn, sig);
if (rc != -ENODEV)
return rc;
/* no info block, do init */;
+ memset(pfn_sb, 0, sizeof(*pfn_sb));
+
nd_region = to_nd_region(nd_pfn->dev.parent);
if (nd_region->ro) {
dev_info(&nd_pfn->dev,
@@ -768,7 +780,7 @@ static int nd_pfn_init(struct nd_pfn *nd
memcpy(pfn_sb->uuid, nd_pfn->uuid, 16);
memcpy(pfn_sb->parent_uuid, nd_dev_to_uuid(&ndns->dev), 16);
pfn_sb->version_major = cpu_to_le16(1);
- pfn_sb->version_minor = cpu_to_le16(2);
+ pfn_sb->version_minor = cpu_to_le16(3);
pfn_sb->start_pad = cpu_to_le32(start_pad);
pfn_sb->end_trunc = cpu_to_le32(end_trunc);
pfn_sb->align = cpu_to_le32(nd_pfn->align);
--- a/drivers/nvdimm/pfn.h~libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields
+++ a/drivers/nvdimm/pfn.h
@@ -36,6 +36,7 @@ struct nd_pfn_sb {
__le32 end_trunc;
/* minor-version-2 record the base alignment of the mapping */
__le32 align;
+ /* minor-version-3 guarantee the padding and flags are zero */
u8 padding[4000];
__le64 checksum;
};
_
Patches currently in -mm which might be from dan.j.williams(a)intel.com are
init-initialize-jump-labels-before-command-line-option-parsing.patch
mm-sparsemem-introduce-struct-mem_section_usage.patch
mm-sparsemem-introduce-common-definitions-for-the-size-and-mask-of-a-section.patch
mm-sparsemem-add-helpers-track-active-portions-of-a-section-at-boot.patch
mm-hotplug-prepare-shrink_zone-pgdat_span-for-sub-section-removal.patch
mm-sparsemem-convert-kmalloc_section_memmap-to-populate_section_memmap.patch
mm-hotplug-add-mem-hotplug-restrictions-for-remove_memory.patch
mm-kill-is_dev_zone-helper.patch
mm-sparsemem-prepare-for-sub-section-ranges.patch
mm-sparsemem-support-sub-section-hotplug.patch
mm-devm_memremap_pages-enable-sub-section-remap.patch
libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch
libnvdimm-pfn-stop-padding-pmem-namespaces-to-section-alignment.patch
mm-shuffle-initial-free-memory-to-improve-memory-side-cache-utilization.patch
mm-shuffle-initial-free-memory-to-improve-memory-side-cache-utilization-fix.patch
mm-move-buddy-list-manipulations-into-helpers.patch
mm-move-buddy-list-manipulations-into-helpers-fix.patch
mm-maintain-randomization-of-page-free-lists.patch
The ceph_ioctl function is used both for files and directories, but only
the files support doing that in 32-bit compat mode.
For consistency, add the same compat handler to the dir operations
as well.
Reviewed-by: "Yan, Zheng" <zyan(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
fs/ceph/dir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
index a8f429882249..7c060cb22aa3 100644
--- a/fs/ceph/dir.c
+++ b/fs/ceph/dir.c
@@ -1785,6 +1785,7 @@ const struct file_operations ceph_dir_fops = {
.open = ceph_open,
.release = ceph_release,
.unlocked_ioctl = ceph_ioctl,
+ .compat_ioctl = ceph_ioctl,
.fsync = ceph_fsync,
.lock = ceph_lock,
.flock = ceph_flock,
--
2.20.0
This was fixed in upstream by commit 7d9e6c5afab6 ("net: stmmac: Integrate
XGMAC into main driver flow") that is a new feature commit.
We found a race condition in the DMA init sequence that hits if the
PHY already has link up during stmmac_hw_setup. Since the ring length
was programmed after enabling the RX path, we might receive a packet
before the correct ring length is programmed. When that happened we
could not get reliable interrupts for DMA RX and the MTL complained
about RX FIFO overrun.
Signed-off-by: Lars Persson <larper(a)axis.com>
Cc: stable(a)vger.kernel.org # 4.14.x
Cc: Giuseppe Cavallaro <peppe.cavallaro(a)st.com>
Cc: Alexandre Torgue <alexandre.torgue(a)st.com>
Cc: Jose Abreu <joabreu(a)synopsys.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4a9dbee6f054..f2429ec07b57 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2536,9 +2536,6 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
netdev_warn(priv->dev, "%s: failed debugFS registration\n",
__func__);
#endif
- /* Start the ball rolling... */
- stmmac_start_all_dma(priv);
-
priv->tx_lpi_timer = STMMAC_DEFAULT_TWT_LS;
if ((priv->use_riwt) && (priv->hw->dma->rx_watchdog)) {
@@ -2558,6 +2555,9 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
priv->hw->dma->enable_tso(priv->ioaddr, 1, chan);
}
+ /* Start the ball rolling... */
+ stmmac_start_all_dma(priv);
+
return 0;
}
--
2.11.0
Hi Greg and Sasha,
Please apply the following mbox files to their respective trees. They
contain upstream patches that allow a tip of tree LLD to link an x86
kernel image as well as a patch to avoid using $(LD) to check for
the location of binutils, which won't always be accurate when linking
with LLD. This was tested with both the upstream defconfig and Android's
x86_64_cuttlefish_defconfig in their respective trees (building/linking
with both Clang/LLD and GCC/ld.bfd then booting in QEMU).
For 5.0, a simple cherry-pick of commit ad15006cc784 ("kbuild: clang:
choose GCC_TOOLCHAIN_DIR not on LD") will do.
Greg, the merge into kernel/common will result in two conflicts:
* Makefile:
Make the diff match upstream commit
ad15006cc784 ("kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD")
* arch/x86/entry/vdso/Makefile:
Take the right hand side, effectively replacing common commit
35b779802c2e ("x86: vdso: Fix leaky vdso linker with CC=clang.")
with the proper upstream commit
379d98ddf413 ("x86: vdso: Use $LD instead of $CC to link")
Also, while you are at it, would you mind picking up upstream commit
5f074f3e192f ("lib/string.c: implement a basic bcmp")? It is cc'd for
stable but it's worth mentioning now so we can stop carrying it out of
tree :)
Let me know if there are any issues, comments, or concerns,
Nathan