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