- Linux-stable-mirror - lists.linaro.org

[patch 087/167] mm, devm_memremap_pages: add MEMORY_DEVICE_PRIVATE support

by akpm＠linux-foundation.org

From: Dan Williams <dan.j.williams(a)intel.com> Subject: mm, devm_memremap_pages: add MEMORY_DEVICE_PRIVATE support In preparation for consolidating all ZONE_DEVICE enabling via devm_memremap_pages(), teach it how to handle the constraints of MEMORY_DEVICE_PRIVATE ranges. [jglisse(a)redhat.com: call move_pfn_range_to_zone for MEMORY_DEVICE_PRIVATE] Link: http://lkml.kernel.org/r/154275559036.76910.12434636179931292607.stgit@dwil… Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Reviewed-by: Jérôme Glisse <jglisse(a)redhat.com> Acked-by: Christoph Hellwig <hch(a)lst.de> Reported-by: Logan Gunthorpe <logang(a)deltatee.com> Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com> Cc: Balbir Singh <bsingharora(a)gmail.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/kernel/memremap.c~mm-devm_memremap_pages-add-memory_device_private-support +++ a/kernel/memremap.c @@ -98,9 +98,15 @@ static void devm_memremap_pages_release( - align_start; mem_hotplug_begin(); - arch_remove_memory(align_start, align_size, pgmap->altmap_valid ? - &pgmap->altmap : NULL); - kasan_remove_zero_shadow(__va(align_start), align_size); + if (pgmap->type == MEMORY_DEVICE_PRIVATE) { + pfn = align_start >> PAGE_SHIFT; + __remove_pages(page_zone(pfn_to_page(pfn)), pfn, + align_size >> PAGE_SHIFT, NULL); + } else { + arch_remove_memory(align_start, align_size, + pgmap->altmap_valid ? &pgmap->altmap : NULL); + kasan_remove_zero_shadow(__va(align_start), align_size); + } mem_hotplug_done(); untrack_pfn(NULL, PHYS_PFN(align_start), align_size); @@ -187,17 +193,40 @@ void *devm_memremap_pages(struct device goto err_pfn_remap; mem_hotplug_begin(); - error = kasan_add_zero_shadow(__va(align_start), align_size); - if (error) { - mem_hotplug_done(); - goto err_kasan; + + /* + * For device private memory we call add_pages() as we only need to + * allocate and initialize struct page for the device memory. More- + * over the device memory is un-accessible thus we do not want to + * create a linear mapping for the memory like arch_add_memory() + * would do. + * + * For all other device memory types, which are accessible by + * the CPU, we do want the linear mapping and thus use + * arch_add_memory(). + */ + if (pgmap->type == MEMORY_DEVICE_PRIVATE) { + error = add_pages(nid, align_start >> PAGE_SHIFT, + align_size >> PAGE_SHIFT, NULL, false); + } else { + error = kasan_add_zero_shadow(__va(align_start), align_size); + if (error) { + mem_hotplug_done(); + goto err_kasan; + } + + error = arch_add_memory(nid, align_start, align_size, altmap, + false); + } + + if (!error) { + struct zone *zone; + + zone = &NODE_DATA(nid)->node_zones[ZONE_DEVICE]; + move_pfn_range_to_zone(zone, align_start >> PAGE_SHIFT, + align_size >> PAGE_SHIFT, altmap); } - error = arch_add_memory(nid, align_start, align_size, altmap, false); - if (!error) - move_pfn_range_to_zone(&NODE_DATA(nid)->node_zones[ZONE_DEVICE], - align_start >> PAGE_SHIFT, - align_size >> PAGE_SHIFT, altmap); mem_hotplug_done(); if (error) goto err_add_memory; _

6 years, 8 months

1
0
0 0

[patch 086/167] mm, devm_memremap_pages: fix shutdown handling

by akpm＠linux-foundation.org

From: Dan Williams <dan.j.williams(a)intel.com> Subject: mm, devm_memremap_pages: fix shutdown handling The last step before devm_memremap_pages() returns success is to allocate a release action, devm_memremap_pages_release(), to tear the entire setup down. However, the result from devm_add_action() is not checked. Checking the error from devm_add_action() is not enough. The api currently relies on the fact that the percpu_ref it is using is killed by the time the devm_memremap_pages_release() is run. Rather than continue this awkward situation, offload the responsibility of killing the percpu_ref to devm_memremap_pages_release() directly. This allows devm_memremap_pages() to do the right thing relative to init failures and shutdown. Without this change we could fail to register the teardown of devm_memremap_pages(). The likelihood of hitting this failure is tiny as small memory allocations almost always succeed. However, the impact of the failure is large given any future reconfiguration, or disable/enable, of an nvdimm namespace will fail forever as subsequent calls to devm_memremap_pages() will fail to setup the pgmap_radix since there will be stale entries for the physical address range. An argument could be made to require that the ->kill() operation be set in the @pgmap arg rather than passed in separately. However, it helps code readability, tracking the lifetime of a given instance, to be able to grep the kill routine directly at the devm_memremap_pages() call site. Link: http://lkml.kernel.org/r/154275558526.76910.7535251937849268605.stgit@dwill… Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Fixes: e8d513483300 ("memremap: change devm_memremap_pages interface...") Reviewed-by: "Jérôme Glisse" <jglisse(a)redhat.com> Reported-by: Logan Gunthorpe <logang(a)deltatee.com> Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Cc: Balbir Singh <bsingharora(a)gmail.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/drivers/dax/pmem.c~mm-devm_memremap_pages-fix-shutdown-handling +++ a/drivers/dax/pmem.c @@ -48,9 +48,8 @@ static void dax_pmem_percpu_exit(void *d percpu_ref_exit(ref); } -static void dax_pmem_percpu_kill(void *data) +static void dax_pmem_percpu_kill(struct percpu_ref *ref) { - struct percpu_ref *ref = data; struct dax_pmem *dax_pmem = to_dax_pmem(ref); dev_dbg(dax_pmem->dev, "trace\n"); @@ -112,17 +111,10 @@ static int dax_pmem_probe(struct device } dax_pmem->pgmap.ref = &dax_pmem->ref; + dax_pmem->pgmap.kill = dax_pmem_percpu_kill; addr = devm_memremap_pages(dev, &dax_pmem->pgmap); - if (IS_ERR(addr)) { - devm_remove_action(dev, dax_pmem_percpu_exit, &dax_pmem->ref); - percpu_ref_exit(&dax_pmem->ref); + if (IS_ERR(addr)) return PTR_ERR(addr); - } - - rc = devm_add_action_or_reset(dev, dax_pmem_percpu_kill, - &dax_pmem->ref); - if (rc) - return rc; /* adjust the dax_region resource to the start of data */ memcpy(&res, &dax_pmem->pgmap.res, sizeof(res)); --- a/drivers/nvdimm/pmem.c~mm-devm_memremap_pages-fix-shutdown-handling +++ a/drivers/nvdimm/pmem.c @@ -309,8 +309,11 @@ static void pmem_release_queue(void *q) blk_cleanup_queue(q); } -static void pmem_freeze_queue(void *q) +static void pmem_freeze_queue(struct percpu_ref *ref) { + struct request_queue *q; + + q = container_of(ref, typeof(*q), q_usage_counter); blk_freeze_queue_start(q); } @@ -402,6 +405,7 @@ static int pmem_attach_disk(struct devic pmem->pfn_flags = PFN_DEV; pmem->pgmap.ref = &q->q_usage_counter; + pmem->pgmap.kill = pmem_freeze_queue; if (is_nd_pfn(dev)) { if (setup_pagemap_fsdax(dev, &pmem->pgmap)) return -ENOMEM; @@ -427,13 +431,6 @@ static int pmem_attach_disk(struct devic memcpy(&bb_res, &nsio->res, sizeof(bb_res)); } - /* - * At release time the queue must be frozen before - * devm_memremap_pages is unwound - */ - if (devm_add_action_or_reset(dev, pmem_freeze_queue, q)) - return -ENOMEM; - if (IS_ERR(addr)) return PTR_ERR(addr); pmem->virt_addr = addr; --- a/include/linux/memremap.h~mm-devm_memremap_pages-fix-shutdown-handling +++ a/include/linux/memremap.h @@ -111,6 +111,7 @@ typedef void (*dev_page_free_t)(struct p * @altmap: pre-allocated/reserved memory for vmemmap allocations * @res: physical address range covered by @ref * @ref: reference count that pins the devm_memremap_pages() mapping + * @kill: callback to transition @ref to the dead state * @dev: host device of the mapping for debug * @data: private data pointer for page_free() * @type: memory type: see MEMORY_* in memory_hotplug.h @@ -122,6 +123,7 @@ struct dev_pagemap { bool altmap_valid; struct resource res; struct percpu_ref *ref; + void (*kill)(struct percpu_ref *ref); struct device *dev; void *data; enum memory_type type; --- a/kernel/memremap.c~mm-devm_memremap_pages-fix-shutdown-handling +++ a/kernel/memremap.c @@ -88,14 +88,10 @@ static void devm_memremap_pages_release( resource_size_t align_start, align_size; unsigned long pfn; + pgmap->kill(pgmap->ref); for_each_device_pfn(pfn, pgmap) put_page(pfn_to_page(pfn)); - if (percpu_ref_tryget_live(pgmap->ref)) { - dev_WARN(dev, "%s: page mapping is still live!\n", __func__); - percpu_ref_put(pgmap->ref); - } - /* pages are dead and unused, undo the arch mapping */ align_start = res->start & ~(SECTION_SIZE - 1); align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE) @@ -116,7 +112,7 @@ static void devm_memremap_pages_release( /** * devm_memremap_pages - remap and provide memmap backing for the given resource * @dev: hosting device for @res - * @pgmap: pointer to a struct dev_pgmap + * @pgmap: pointer to a struct dev_pagemap * * Notes: * 1/ At a minimum the res, ref and type members of @pgmap must be initialized @@ -125,11 +121,8 @@ static void devm_memremap_pages_release( * 2/ The altmap field may optionally be initialized, in which case altmap_valid * must be set to true * - * 3/ pgmap.ref must be 'live' on entry and 'dead' before devm_memunmap_pages() - * time (or devm release event). The expected order of events is that ref has - * been through percpu_ref_kill() before devm_memremap_pages_release(). The - * wait for the completion of all references being dropped and - * percpu_ref_exit() must occur after devm_memremap_pages_release(). + * 3/ pgmap->ref must be 'live' on entry and will be killed at + * devm_memremap_pages_release() time, or if this routine fails. * * 4/ res is expected to be a host memory range that could feasibly be * treated as a "System RAM" range, i.e. not a device mmio range, but @@ -145,6 +138,9 @@ void *devm_memremap_pages(struct device pgprot_t pgprot = PAGE_KERNEL; int error, nid, is_ram; + if (!pgmap->ref || !pgmap->kill) + return ERR_PTR(-EINVAL); + align_start = res->start & ~(SECTION_SIZE - 1); align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE) - align_start; @@ -170,12 +166,10 @@ void *devm_memremap_pages(struct device if (is_ram != REGION_DISJOINT) { WARN_ONCE(1, "%s attempted on %s region %pr\n", __func__, is_ram == REGION_MIXED ? "mixed" : "ram", res); - return ERR_PTR(-ENXIO); + error = -ENXIO; + goto err_array; } - if (!pgmap->ref) - return ERR_PTR(-EINVAL); - pgmap->dev = dev; error = xa_err(xa_store_range(&pgmap_array, PHYS_PFN(res->start), @@ -217,7 +211,10 @@ void *devm_memremap_pages(struct device align_size >> PAGE_SHIFT, pgmap); percpu_ref_get_many(pgmap->ref, pfn_end(pgmap) - pfn_first(pgmap)); - devm_add_action(dev, devm_memremap_pages_release, pgmap); + error = devm_add_action_or_reset(dev, devm_memremap_pages_release, + pgmap); + if (error) + return ERR_PTR(error); return __va(res->start); @@ -228,6 +225,7 @@ void *devm_memremap_pages(struct device err_pfn_remap: pgmap_array_delete(res); err_array: + pgmap->kill(pgmap->ref); return ERR_PTR(error); } EXPORT_SYMBOL_GPL(devm_memremap_pages); --- a/tools/testing/nvdimm/test/iomap.c~mm-devm_memremap_pages-fix-shutdown-handling +++ a/tools/testing/nvdimm/test/iomap.c @@ -104,13 +104,26 @@ void *__wrap_devm_memremap(struct device } EXPORT_SYMBOL(__wrap_devm_memremap); +static void nfit_test_kill(void *_pgmap) +{ + struct dev_pagemap *pgmap = _pgmap; + + pgmap->kill(pgmap->ref); +} + void *__wrap_devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap) { resource_size_t offset = pgmap->res.start; struct nfit_test_resource *nfit_res = get_nfit_res(offset); - if (nfit_res) + if (nfit_res) { + int rc; + + rc = devm_add_action_or_reset(dev, nfit_test_kill, pgmap); + if (rc) + return ERR_PTR(rc); return nfit_res->buf + offset - nfit_res->res.start; + } return devm_memremap_pages(dev, pgmap); } EXPORT_SYMBOL_GPL(__wrap_devm_memremap_pages); _

6 years, 8 months

1
0
0 0

[patch 085/167] mm, devm_memremap_pages: kill mapping "System RAM" support

by akpm＠linux-foundation.org

From: Dan Williams <dan.j.williams(a)intel.com> Subject: mm, devm_memremap_pages: kill mapping "System RAM" support Given the fact that devm_memremap_pages() requires a percpu_ref that is torn down by devm_memremap_pages_release() the current support for mapping RAM is broken. Support for remapping "System RAM" has been broken since the beginning and there is no existing user of this this code path, so just kill the support and make it an explicit error. This cleanup also simplifies a follow-on patch to fix the error path when setting a devm release action for devm_memremap_pages_release() fails. Link: http://lkml.kernel.org/r/154275557997.76910.14689813630968180480.stgit@dwil… Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Reviewed-by: "Jérôme Glisse" <jglisse(a)redhat.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com> Cc: Balbir Singh <bsingharora(a)gmail.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/kernel/memremap.c~mm-devm_memremap_pages-kill-mapping-system-ram-support +++ a/kernel/memremap.c @@ -167,15 +167,12 @@ void *devm_memremap_pages(struct device is_ram = region_intersects(align_start, align_size, IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE); - if (is_ram == REGION_MIXED) { - WARN_ONCE(1, "%s attempted on mixed region %pr\n", - __func__, res); + if (is_ram != REGION_DISJOINT) { + WARN_ONCE(1, "%s attempted on %s region %pr\n", __func__, + is_ram == REGION_MIXED ? "mixed" : "ram", res); return ERR_PTR(-ENXIO); } - if (is_ram == REGION_INTERSECTS) - return __va(res->start); - if (!pgmap->ref) return ERR_PTR(-EINVAL); _

6 years, 8 months

1
0
0 0

[patch 084/167] mm, devm_memremap_pages: mark devm_memremap_pages() EXPORT_SYMBOL_GPL

by akpm＠linux-foundation.org

From: Dan Williams <dan.j.williams(a)intel.com> Subject: mm, devm_memremap_pages: mark devm_memremap_pages() EXPORT_SYMBOL_GPL devm_memremap_pages() is a facility that can create struct page entries for any arbitrary range and give drivers the ability to subvert core aspects of page management. Specifically the facility is tightly integrated with the kernel's memory hotplug functionality. It injects an altmap argument deep into the architecture specific vmemmap implementation to allow allocating from specific reserved pages, and it has Linux specific assumptions about page structure reference counting relative to get_user_pages() and get_user_pages_fast(). It was an oversight and a mistake that this was not marked EXPORT_SYMBOL_GPL from the outset. Again, devm_memremap_pagex() exposes and relies upon core kernel internal assumptions and will continue to evolve along with 'struct page', memory hotplug, and support for new memory types / topologies. Only an in-kernel GPL-only driver is expected to keep up with this ongoing evolution. This interface, and functionality derived from this interface, is not suitable for kernel-external drivers. Link: http://lkml.kernel.org/r/154275557457.76910.16923571232582744134.stgit@dwil… Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: "Jérôme Glisse" <jglisse(a)redhat.com> Cc: Balbir Singh <bsingharora(a)gmail.com> Cc: Logan Gunthorpe <logang(a)deltatee.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/kernel/memremap.c~mm-devm_memremap_pages-mark-devm_memremap_pages-export_symbol_gpl +++ a/kernel/memremap.c @@ -233,7 +233,7 @@ void *devm_memremap_pages(struct device err_array: return ERR_PTR(error); } -EXPORT_SYMBOL(devm_memremap_pages); +EXPORT_SYMBOL_GPL(devm_memremap_pages); unsigned long vmem_altmap_offset(struct vmem_altmap *altmap) { --- a/tools/testing/nvdimm/test/iomap.c~mm-devm_memremap_pages-mark-devm_memremap_pages-export_symbol_gpl +++ a/tools/testing/nvdimm/test/iomap.c @@ -113,7 +113,7 @@ void *__wrap_devm_memremap_pages(struct return nfit_res->buf + offset - nfit_res->res.start; return devm_memremap_pages(dev, pgmap); } -EXPORT_SYMBOL(__wrap_devm_memremap_pages); +EXPORT_SYMBOL_GPL(__wrap_devm_memremap_pages); pfn_t __wrap_phys_to_pfn_t(phys_addr_t addr, unsigned long flags) { _

6 years, 8 months

1
0
0 0

[folded-merged] hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3 has been removed from the -mm tree. Its filename was hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3.patch This patch was dropped because it was folded into hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race.patch ------------------------------------------------------ From: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3 Incorporated suggestions from Kirill. Code change to hold i_mmap_rwsem for duration of copy in copy_hugetlb_page_range. Took i_mmap_rwsem in hugetlbfs_evict_inode to be consistent with other callers. Other changes were to documentation/comments. Link: http://lkml.kernel.org/r/20181222223013.22193-3-mike.kravetz@oracle.com Cc: <stable(a)vger.kernel.org> Fixes: ebed4bfc8da8 ("hugetlb: fix absurd HugePages_Rsvd") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: "Aneesh Kumar K . V" <aneesh.kumar(a)linux.vnet.ibm.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Hugh Dickins <hughd(a)google.com> Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Prakash Sangappa <prakash.sangappa(a)oracle.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/fs/hugetlbfs/inode.c~hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3 +++ a/fs/hugetlbfs/inode.c @@ -462,9 +462,20 @@ static void remove_inode_hugepages(struc static void hugetlbfs_evict_inode(struct inode *inode) { + struct address_space *mapping = inode->i_mapping; struct resv_map *resv_map; + /* + * The vfs layer guarantees that there are no other users of this + * inode. Therefore, it would be safe to call remove_inode_hugepages + * without holding i_mmap_rwsem. We acquire and hold here to be + * consistent with other callers. Since there will be no contention + * on the semaphore, overhead is negligible. + */ + i_mmap_lock_write(mapping); remove_inode_hugepages(inode, 0, LLONG_MAX); + i_mmap_unlock_write(mapping); + resv_map = (struct resv_map *)inode->i_mapping->private_data; /* root inode doesn't have the resv_map, so we should check it */ if (resv_map) _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are hugetlbfs-use-i_mmap_rwsem-for-more-pmd-sharing-synchronization.patch hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race.patch

6 years, 8 months

1
0
0 0

+ hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3 has been added to the -mm tree. Its filename is hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/hugetlbfs-use-i_mmap_rwsem-to-fix-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/hugetlbfs-use-i_mmap_rwsem-to-fix-… 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: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3 Incorporated suggestions from Kirill. Code change to hold i_mmap_rwsem for duration of copy in copy_hugetlb_page_range. Took i_mmap_rwsem in hugetlbfs_evict_inode to be consistent with other callers. Other changes were to documentation/comments. Link: http://lkml.kernel.org/r/20181222223013.22193-3-mike.kravetz@oracle.com Cc: <stable(a)vger.kernel.org> Fixes: ebed4bfc8da8 ("hugetlb: fix absurd HugePages_Rsvd") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: "Aneesh Kumar K . V" <aneesh.kumar(a)linux.vnet.ibm.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Hugh Dickins <hughd(a)google.com> Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Prakash Sangappa <prakash.sangappa(a)oracle.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/fs/hugetlbfs/inode.c~hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3 +++ a/fs/hugetlbfs/inode.c @@ -462,9 +462,20 @@ static void remove_inode_hugepages(struc static void hugetlbfs_evict_inode(struct inode *inode) { + struct address_space *mapping = inode->i_mapping; struct resv_map *resv_map; + /* + * The vfs layer guarantees that there are no other users of this + * inode. Therefore, it would be safe to call remove_inode_hugepages + * without holding i_mmap_rwsem. We acquire and hold here to be + * consistent with other callers. Since there will be no contention + * on the semaphore, overhead is negligible. + */ + i_mmap_lock_write(mapping); remove_inode_hugepages(inode, 0, LLONG_MAX); + i_mmap_unlock_write(mapping); + resv_map = (struct resv_map *)inode->i_mapping->private_data; /* root inode doesn't have the resv_map, so we should check it */ if (resv_map) _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are hugetlbfs-use-i_mmap_rwsem-for-more-pmd-sharing-synchronization.patch hugetlbfs-use-i_mmap_rwsem-for-more-pmd-sharing-synchronization-fix.patch hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race.patch hugetlbfs-use-i_mmap_rwsem-to-fix-page-fault-truncate-race-v3.patch

6 years, 8 months

1
0
0 0

bug report: hugetlbfs: use i_mmap_rwsem for more pmd sharing, synchronization

by Colin Ian King

Hi, Static analysis with CoverityScan on linux-next detected a potential null pointer dereference with the following commit: >From d8a1051ed4ba55679ef24e838a1942c9c40f0a14 Mon Sep 17 00:00:00 2001 From: Mike Kravetz <mike.kravetz(a)oracle.com> Date: Sat, 22 Dec 2018 10:55:57 +1100 Subject: [PATCH] hugetlbfs: use i_mmap_rwsem for more pmd sharing The earlier check implies that "mapping" may be a null pointer: var_compare_op: Comparing mapping to null implies that mapping might be null. 1008 if (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping && 1009 mapping_cap_writeback_dirty(mapping)) { ..however later "mapper" is dereferenced when it may be potentially null: 1034 /* 1035 * For hugetlb pages, try_to_unmap could potentially call 1036 * huge_pmd_unshare. Because of this, take semaphore in 1037 * write mode here and set TTU_RMAP_LOCKED to indicate we 1038 * have taken the lock at this higer level. 1039 */ CID 1476097 (#1 of 1): Dereference after null check (FORWARD_NULL) var_deref_model: Passing null pointer mapping to i_mmap_lock_write, which dereferences it. 1040 i_mmap_lock_write(mapping); 1041 unmap_success = try_to_unmap(hpage, ttu|TTU_RMAP_LOCKED); 1042 i_mmap_unlock_write(mapping); Colin

6 years, 8 months

3
3
0 0

+ memcg-oom-notify-on-oom-killer-invocation-from-the-charge-path.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: memcg, oom: notify on oom killer invocation from the charge path has been added to the -mm tree. Its filename is memcg-oom-notify-on-oom-killer-invocation-from-the-charge-path.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/memcg-oom-notify-on-oom-killer-inv… and later at http://ozlabs.org/~akpm/mmotm/broken-out/memcg-oom-notify-on-oom-killer-inv… 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: Michal Hocko <mhocko(a)suse.com> Subject: memcg, oom: notify on oom killer invocation from the charge path Burt Holzman has noticed that memcg v1 doesn't notify about OOM events via eventfd anymore. The reason is that 29ef680ae7c2 ("memcg, oom: move out_of_memory back to the charge path") has moved the oom handling back to the charge path. While doing so the notification was left behind in mem_cgroup_oom_synchronize. Fix the issue by replicating the oom hierarchy locking and the notification. Link: http://lkml.kernel.org/r/20181224091107.18354-1-mhocko@kernel.org Fixes: 29ef680ae7c2 ("memcg, oom: move out_of_memory back to the charge path") Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Burt Holzman <burt(a)fnal.gov> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com Cc: <stable(a)vger.kernel.org> [4.19+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/mm/memcontrol.c~memcg-oom-notify-on-oom-killer-invocation-from-the-charge-path +++ a/mm/memcontrol.c @@ -1673,6 +1673,9 @@ enum oom_status { static enum oom_status mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order) { + enum oom_status ret; + bool locked; + if (order > PAGE_ALLOC_COSTLY_ORDER) return OOM_SKIPPED; @@ -1707,10 +1710,23 @@ static enum oom_status mem_cgroup_oom(st return OOM_ASYNC; } + mem_cgroup_mark_under_oom(memcg); + + locked = mem_cgroup_oom_trylock(memcg); + + if (locked) + mem_cgroup_oom_notify(memcg); + + mem_cgroup_unmark_under_oom(memcg); if (mem_cgroup_out_of_memory(memcg, mask, order)) - return OOM_SUCCESS; + ret = OOM_SUCCESS; + else + ret = OOM_FAILED; + + if (locked) + mem_cgroup_oom_unlock(memcg); - return OOM_FAILED; + return ret; } /** _ Patches currently in -mm which might be from mhocko(a)suse.com are mm-memcg-fix-reclaim-deadlock-with-writeback.patch mm-print-more-information-about-mapping-in-__dump_page.patch mm-lower-the-printk-loglevel-for-__dump_page-messages.patch mm-memory_hotplug-drop-pointless-block-alignment-checks-from-__offline_pages.patch mm-memory_hotplug-print-reason-for-the-offlining-failure.patch mm-memory_hotplug-be-more-verbose-for-memory-offline-failures.patch mm-memory_hotplug-be-more-verbose-for-memory-offline-failures-update.patch mm-only-report-isolation-failures-when-offlining-memory.patch mm-memory_hotplug-do-not-clear-numa_node-association-after-hot_remove.patch hwpoison-memory_hotplug-allow-hwpoisoned-pages-to-be-offlined.patch mm-proc-be-more-verbose-about-unstable-vma-flags-in-proc-pid-smaps.patch mm-thp-proc-report-thp-eligibility-for-each-vma.patch mm-proc-report-pr_set_thp_disable-in-proc.patch mm-memory_hotplug-try-to-migrate-full-pfn-range.patch mm-memory_hotplug-deobfuscate-migration-part-of-offlining.patch mm-fault_around-do-not-take-a-reference-to-a-locked-page.patch memory_hotplug-add-missing-newlines-to-debugging-output.patch memcg-oom-notify-on-oom-killer-invocation-from-the-charge-path.patch

6 years, 8 months

1
0
0 0

4.19.5 and later has tons of false messages "BUG: non-zero pgtables_bytes on freeing mm: -16384"

by Christian Borntraeger

Martin, Right now you get a message "BUG: non-zero pgtables_bytes on freeing mm: -16384" for EVERY process that exits in 4.19.5 and later. bisect points to commit 4136161d676a93fc8df6bdb80d720c15522d6c24 Author: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Date: Mon Oct 15 11:09:16 2018 +0200 s390/mm: fix mis-accounting of pgtable_bytes [ Upstream commit e12e4044aede97974f2222eb7f0ed726a5179a32 ] Turns out that this patch requires several dependencies so the autoselection of this patch was missing that. Can we either revert this patch or add the dependencies? Christian

6 years, 8 months

2
4
0 0

[PATCH stable] ubifs: Handle re-linking of inodes correctly while recovery

by Rafał Miłecki

From: Richard Weinberger <richard(a)nod.at> commit e58725d51fa8da9133f3f1c54170aa2e43056b91 upstream. UBIFS's recovery code strictly assumes that a deleted inode will never come back, therefore it removes all data which belongs to that inode as soon it faces an inode with link count 0 in the replay list. Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE it can lead to data loss upon a power-cut. Consider a journal with entries like: 0: inode X (nlink = 0) /* O_TMPFILE was created */ 1: data for inode X /* Someone writes to the temp file */ 2: inode X (nlink = 0) /* inode was changed, xattr, chmod, … */ 3: inode X (nlink = 1) /* inode was re-linked via linkat() */ Upon replay of entry #2 UBIFS will drop all data that belongs to inode X, this will lead to an empty file after mounting. As solution for this problem, scan the replay list for a re-link entry before dropping data. Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE") Cc: stable(a)vger.kernel.org # 4.9-4.18 Cc: Russell Senior <russell(a)personaltelco.net> Cc: Rafał Miłecki <zajec5(a)gmail.com> Reported-by: Russell Senior <russell(a)personaltelco.net> Reported-by: Rafał Miłecki <zajec5(a)gmail.com> Tested-by: Rafał Miłecki <rafal(a)milecki.pl> Signed-off-by: Richard Weinberger <richard(a)nod.at> [rmilecki: update ubifs_assert() calls to compile with 4.18 and older] Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> (cherry picked from commit e58725d51fa8da9133f3f1c54170aa2e43056b91) --- fs/ubifs/replay.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c index ae5c02f22f3e..d998fbf7de30 100644 --- a/fs/ubifs/replay.c +++ b/fs/ubifs/replay.c @@ -210,6 +210,38 @@ static int trun_remove_range(struct ubifs_info *c, struct replay_entry *r) } /** + * inode_still_linked - check whether inode in question will be re-linked. + * @c: UBIFS file-system description object + * @rino: replay entry to test + * + * O_TMPFILE files can be re-linked, this means link count goes from 0 to 1. + * This case needs special care, otherwise all references to the inode will + * be removed upon the first replay entry of an inode with link count 0 + * is found. + */ +static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino) +{ + struct replay_entry *r; + + ubifs_assert(rino->deletion); + ubifs_assert(key_type(c, &rino->key) == UBIFS_INO_KEY); + + /* + * Find the most recent entry for the inode behind @rino and check + * whether it is a deletion. + */ + list_for_each_entry_reverse(r, &c->replay_list, list) { + ubifs_assert(r->sqnum >= rino->sqnum); + if (key_inum(c, &r->key) == key_inum(c, &rino->key)) + return r->deletion == 0; + + } + + ubifs_assert(0); + return false; +} + +/** * apply_replay_entry - apply a replay entry to the TNC. * @c: UBIFS file-system description object * @r: replay entry to apply @@ -239,6 +271,11 @@ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r) { ino_t inum = key_inum(c, &r->key); + if (inode_still_linked(c, r)) { + err = 0; + break; + } + err = ubifs_tnc_remove_ino(c, inum); break; } -- 2.13.7

6 years, 8 months

2
1
0 0

suggest 00b80ac93553 ("spi: imx: mx51-ecspi: Move some initialisation to prepare_message hook.") for stable backports

by Uwe Kleine-König

Hello, even though the subject sounds harmless it fixes a real bug. (Yes, I'm aware that commit isn't in Linus' tree yet, but I assume your tracking of patches targetting stable is better than mine, so I didn't wait :-) For backporting you also need its parent commit (i.e. e697271c4e29 ("spi: imx: add a device specific prepare_message callback")). I have a local backport to v4.14 here which isn't entirely trivial. So just tell me if you need help. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |

6 years, 8 months

3
5
0 0

Re: [PATCH 2/2] USB: storage: add quirk for SMI SM3350

by Icenowy Zheng

在 2018-12-27四的 22:34 +0800，Icenowy Zheng写道： > The SMI SM3350 USB-UFS bridge controller cannot handle long sense > request > correctly and will make the chip refuse to do read/write when > requested > long sense. > > Add a bad sense quirk for it. > > Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> > --- I forgot to: Cc: stable(a)vger.kernel.org > drivers/usb/storage/unusual_devs.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/usb/storage/unusual_devs.h > b/drivers/usb/storage/unusual_devs.h > index f7f83b21dc74..ea0d27a94afe 100644 > --- a/drivers/usb/storage/unusual_devs.h > +++ b/drivers/usb/storage/unusual_devs.h > @@ -1265,6 +1265,18 @@ UNUSUAL_DEV( 0x090c, 0x1132, 0x0000, 0xffff, > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > US_FL_FIX_CAPACITY ), > > +/* > + * Reported by Icenowy Zheng <icenowy(a)aosc.io> > + * The SMI SM3350 USB-UFS bridge controller will enter a wrong state > + * that do not process read/write command if a long sense is > requested, > + * so force to use 18-byte sense. > + */ > +UNUSUAL_DEV( 0x090c, 0x3350, 0x0000, 0xffff, > + "SMI", > + "SM3350 UFS-to-USB-Mass-Storage bridge", > + USB_SC_DEVICE, USB_PR_DEVICE, NULL, > + US_FL_BAD_SENSE ), > + > /* > * Reported by Paul Hartman <paul.hartman+linux(a)gmail.com> > * This card reader returns "Illegal Request, Logical Block Address

6 years, 8 months

1
0
0 0

Re: [PATCH 1/2] USB: storage: don't insert sane sense for SPC3+ when bad sense specified

by Icenowy Zheng

在 2018-12-27四的 22:34 +0800，Icenowy Zheng写道： > Currently the code will set US_FL_SANE_SENSE flag unconditionally if > device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to > prevent this behavior, because SMI SM3350 UFS-USB bridge controller, > which claims SPC4, will show strange behavior with 96-byte sense > (put the chip into a wrong state that cannot read/write anything). > > Check the presence of US_FL_BAD_SENSE when assuming US_FL_SANE_SENSE > on > SPC4+ devices. > > Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> > --- I forgot to: Cc: stable(a)vger.kernel.org > drivers/usb/storage/scsiglue.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/storage/scsiglue.c > b/drivers/usb/storage/scsiglue.c > index fde2e71a6ade..699fe9557127 100644 > --- a/drivers/usb/storage/scsiglue.c > +++ b/drivers/usb/storage/scsiglue.c > @@ -236,7 +236,8 @@ static int slave_configure(struct scsi_device > *sdev) > sdev->try_rc_10_first = 1; > > /* assume SPC3 or latter devices support sense size > > 18 */ > - if (sdev->scsi_level > SCSI_SPC_2) > + if (sdev->scsi_level > SCSI_SPC_2 && > + !(us->fflags & US_FL_BAD_SENSE)) > us->fflags |= US_FL_SANE_SENSE; > > /*

6 years, 8 months

1
0
0 0

[PATCH] f2fs: sanity check of xattr entry size

by Jaegeuk Kim

There is a security report where f2fs_getxattr() has a hole to expose wrong memory region when the image is malformed like this. f2fs_getxattr: entry->e_name_len: 4, size: 12288, buffer_size: 16384, len: 4 Cc: <stable(a)vger.kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> --- fs/f2fs/xattr.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c index f44b0c38398b..18d5ffbc5e8c 100644 --- a/fs/f2fs/xattr.c +++ b/fs/f2fs/xattr.c @@ -288,7 +288,7 @@ static int read_xattr_block(struct inode *inode, void *txattr_addr) static int lookup_all_xattrs(struct inode *inode, struct page *ipage, unsigned int index, unsigned int len, const char *name, struct f2fs_xattr_entry **xe, - void **base_addr) + void **base_addr, int *base_size) { void *cur_addr, *txattr_addr, *last_addr = NULL; nid_t xnid = F2FS_I(inode)->i_xattr_nid; @@ -299,8 +299,8 @@ static int lookup_all_xattrs(struct inode *inode, struct page *ipage, if (!size && !inline_size) return -ENODATA; - txattr_addr = f2fs_kzalloc(F2FS_I_SB(inode), - inline_size + size + XATTR_PADDING_SIZE, GFP_NOFS); + *base_size = inline_size + size + XATTR_PADDING_SIZE; + txattr_addr = f2fs_kzalloc(F2FS_I_SB(inode), *base_size, GFP_NOFS); if (!txattr_addr) return -ENOMEM; @@ -312,8 +312,10 @@ static int lookup_all_xattrs(struct inode *inode, struct page *ipage, *xe = __find_inline_xattr(inode, txattr_addr, &last_addr, index, len, name); - if (*xe) + if (*xe) { + *base_size = inline_size; goto check; + } } /* read from xattr node block */ @@ -474,6 +476,7 @@ int f2fs_getxattr(struct inode *inode, int index, const char *name, int error = 0; unsigned int size, len; void *base_addr = NULL; + int base_size; if (name == NULL) return -EINVAL; @@ -484,7 +487,7 @@ int f2fs_getxattr(struct inode *inode, int index, const char *name, down_read(&F2FS_I(inode)->i_xattr_sem); error = lookup_all_xattrs(inode, ipage, index, len, name, - &entry, &base_addr); + &entry, &base_addr, &base_size); up_read(&F2FS_I(inode)->i_xattr_sem); if (error) return error; @@ -498,6 +501,11 @@ int f2fs_getxattr(struct inode *inode, int index, const char *name, if (buffer) { char *pval = entry->e_name + entry->e_name_len; + + if (base_size - (pval - (char *)base_addr) < size) { + error = -ERANGE; + goto out; + } memcpy(buffer, pval, size); } error = size; -- 2.19.0.605.g01d371f741-goog

6 years, 8 months

1
0
0 0

v4.20 build: 0 failures 4 warnings (v4.20)

by Build bot for Mark Brown

Tree/Branch: v4.20 Git describe: v4.20 Commit: 8fe28cb58b Linux 4.20 Build Time: 129 min 44 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 4 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : arm64-allmodconfig 3 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Warnings Summary: 4 1 ../drivers/staging/erofs/unzip_vle.c:188:29: warning: array subscript is above array bounds [-Warray-bounds] 1 ../drivers/scsi/myrs.c:821:24: warning: 'sshdr.sense_key' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 ../drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:216:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] 1 ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] ------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 3 warnings, 0 section mismatches Warnings: ../drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:216:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] ../drivers/scsi/myrs.c:821:24: warning: 'sshdr.sense_key' may be used uninitialized in this function [-Wmaybe-uninitialized] ../drivers/staging/erofs/unzip_vle.c:188:29: warning: array subscript is above array bounds [-Warray-bounds] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig x86_64-allmodconfig arm64-defconfig

6 years, 8 months

1
0
0 0

[merged] mm-page_alloc-fix-has_unmovable_pages-for-hugepages.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, page_alloc: fix has_unmovable_pages for HugePages has been removed from the -mm tree. Its filename was mm-page_alloc-fix-has_unmovable_pages-for-hugepages.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Oscar Salvador <osalvador(a)suse.de> Subject: mm, page_alloc: fix has_unmovable_pages for HugePages While playing with gigantic hugepages and memory_hotplug, I triggered the following #PF when "cat memoryX/removable": <--- kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 kernel: #PF error: [normal kernel read fault] kernel: PGD 0 P4D 0 kernel: Oops: 0000 [#1] SMP PTI kernel: CPU: 1 PID: 1481 Comm: cat Tainted: G E 4.20.0-rc6-mm1-1-default+ #18 kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 kernel: RIP: 0010:has_unmovable_pages+0x154/0x210 kernel: Code: 1b ff ff ff eb 32 48 8b 45 00 bf 00 10 00 00 a9 00 00 01 00 74 07 0f b6 4d 51 48 d3 e7 e8 c4 81 05 00 48 85 c0 49 89 c1 75 7e <41> 8b 41 08 83 f8 09 74 41 83 f8 1b 74 3c 4d 2b 64 24 58 49 81 ec kernel: RSP: 0018:ffffc90000a1fd30 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000009 kernel: RDX: ffffffff82aed4f0 RSI: 0000000000001000 RDI: 0000000000001000 kernel: RBP: ffffea0001800000 R08: 0000000000200000 R09: 0000000000000000 kernel: R10: 0000000000001000 R11: 0000000000000003 R12: ffff88813ffd45c0 kernel: R13: 0000000000060000 R14: 0000000000000001 R15: ffffea0000000000 kernel: FS: 00007fd71d9b3500(0000) GS:ffff88813bb00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000008 CR3: 00000001371c2002 CR4: 00000000003606e0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 kernel: Call Trace: kernel: is_mem_section_removable+0x7d/0x100 kernel: removable_show+0x90/0xb0 kernel: dev_attr_show+0x1c/0x50 kernel: sysfs_kf_seq_show+0xca/0x1b0 kernel: seq_read+0x133/0x380 kernel: __vfs_read+0x26/0x180 kernel: vfs_read+0x89/0x140 kernel: ksys_read+0x42/0x90 kernel: do_syscall_64+0x5b/0x180 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel: RIP: 0033:0x7fd71d4c8b41 kernel: Code: fe ff ff 48 8d 3d 27 9e 09 00 48 83 ec 08 e8 96 02 02 00 66 0f 1f 44 00 00 8b 05 ea fc 2c 00 48 63 ff 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 55 53 48 89 d5 48 89 kernel: RSP: 002b:00007ffeab5f6448 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 kernel: RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fd71d4c8b41 kernel: RDX: 0000000000020000 RSI: 00007fd71d809000 RDI: 0000000000000003 kernel: RBP: 0000000000020000 R08: ffffffffffffffff R09: 0000000000000000 kernel: R10: 000000000000038b R11: 0000000000000246 R12: 00007fd71d809000 kernel: R13: 0000000000000003 R14: 00007fd71d80900f R15: 0000000000020000 kernel: Modules linked in: af_packet(E) xt_tcpudp(E) ipt_REJECT(E) xt_conntrack(E) nf_conntrack(E) nf_defrag_ipv4(E) ip_set(E) nfnetlink(E) ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ebtable_filter(E) ebtables(E) iptable_filter(E) ip_tables(E) x_tables(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) bochs_drm(E) ttm(E) drm_kms_helper(E) drm(E) aesni_intel(E) virtio_net(E) syscopyarea(E) net_failover(E) sysfillrect(E) failover(E) aes_x86_64(E) crypto_simd(E) sysimgblt(E) cryptd(E) pcspkr(E) glue_helper(E) parport_pc(E) fb_sys_fops(E) i2c_piix4(E) parport(E) button(E) btrfs(E) libcrc32c(E) xor(E) zstd_decompress(E) zstd_compress(E) raid6_pq(E) sd_mod(E) ata_generic(E) ata_piix(E) ahci(E) libahci(E) serio_raw(E) crc32c_intel(E) virtio_pci(E) virtio_ring(E) virtio(E) libata(E) sg(E) scsi_mod(E) autofs4(E) kernel: CR2: 0000000000000008 kernel: ---[ end trace 49cade81474e40e7 ]--- kernel: RIP: 0010:has_unmovable_pages+0x154/0x210 kernel: Code: 1b ff ff ff eb 32 48 8b 45 00 bf 00 10 00 00 a9 00 00 01 00 74 07 0f b6 4d 51 48 d3 e7 e8 c4 81 05 00 48 85 c0 49 89 c1 75 7e <41> 8b 41 08 83 f8 09 74 41 83 f8 1b 74 3c 4d 2b 64 24 58 49 81 ec kernel: RSP: 0018:ffffc90000a1fd30 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000009 kernel: RDX: ffffffff82aed4f0 RSI: 0000000000001000 RDI: 0000000000001000 kernel: RBP: ffffea0001800000 R08: 0000000000200000 R09: 0000000000000000 kernel: R10: 0000000000001000 R11: 0000000000000003 R12: ffff88813ffd45c0 kernel: R13: 0000000000060000 R14: 0000000000000001 R15: ffffea0000000000 kernel: FS: 00007fd71d9b3500(0000) GS:ffff88813bb00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000008 CR3: 00000001371c2002 CR4: 00000000003606e0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 ---> The reason is we do not pass the Head to page_hstate(), and so, the call to compound_order() in page_hstate() returns 0, so we end up checking all hstates's size to match PAGE_SIZE. Obviously, we do not find any hstate matching that size, and we return NULL. Then, we dereference that NULL pointer in hugepage_migration_supported() and we got the #PF from above. Fix that by getting the head page before calling page_hstate(). Also, since gigantic pages span several pageblocks, re-adjust the logic for skipping pages. While are it, we can also get rid of the round_up(). [osalvador(a)suse.de: remove round_up(), adjust skip pages logic per Michal] Link: http://lkml.kernel.org/r/20181221062809.31771-1-osalvador@suse.de Link: http://lkml.kernel.org/r/20181217225113.17864-1-osalvador@suse.de Signed-off-by: Oscar Salvador <osalvador(a)suse.de> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Pavel Tatashin <pavel.tatashin(a)microsoft.com> Cc: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/mm/page_alloc.c~mm-page_alloc-fix-has_unmovable_pages-for-hugepages +++ a/mm/page_alloc.c @@ -7814,11 +7814,14 @@ bool has_unmovable_pages(struct zone *zo * handle each tail page individually in migration. */ if (PageHuge(page)) { + struct page *head = compound_head(page); + unsigned int skip_pages; - if (!hugepage_migration_supported(page_hstate(page))) + if (!hugepage_migration_supported(page_hstate(head))) goto unmovable; - iter = round_up(iter + 1, 1<<compound_order(page)) - 1; + skip_pages = (1 << compound_order(head)) - (page - head); + iter += skip_pages - 1; continue; } _ Patches currently in -mm which might be from osalvador(a)suse.de are kernel-resource-check-for-ioresource_sysram-in-release_mem_region_adjustable.patch mm-page_alloc-drop-uneeded-__meminit-and-__meminitdata.patch mm-kmemleak-little-optimization-while-scanning.patch mm-memory_hotplug-dont-bail-out-in-do_migrate_range-prematurely.patch

6 years, 8 months

1
0
0 0

[merged] forkmemcg-fix-crash-in-free_thread_stack-on-memcg-charge-fail.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: fork,memcg: fix crash in free_thread_stack on memcg charge fail has been removed from the -mm tree. Its filename was forkmemcg-fix-crash-in-free_thread_stack-on-memcg-charge-fail.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Rik van Riel <riel(a)surriel.com> Subject: fork,memcg: fix crash in free_thread_stack on memcg charge fail Changeset 9b6f7e163cd0 ("mm: rework memcg kernel stack accounting") will result in fork failing if allocating a kernel stack for a task in dup_task_struct exceeds the kernel memory allowance for that cgroup. Unfortunately, it also results in a crash. This is due to the code jumping to free_stack and calling free_thread_stack when the memcg kernel stack charge fails, but without tsk->stack pointing at the freshly allocated stack. This in turn results in the vfree_atomic in free_thread_stack oopsing with a backtrace like this: #5 [ffffc900244efc88] die at ffffffff8101f0ab #6 [ffffc900244efcb8] do_general_protection at ffffffff8101cb86 #7 [ffffc900244efce0] general_protection at ffffffff818ff082 [exception RIP: llist_add_batch+7] RIP: ffffffff8150d487 RSP: ffffc900244efd98 RFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88085ef55980 RCX: 0000000000000000 RDX: ffff88085ef55980 RSI: 343834343531203a RDI: 343834343531203a RBP: ffffc900244efd98 R8: 0000000000000001 R9: ffff8808578c3600 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88029f6c21c0 R13: 0000000000000286 R14: ffff880147759b00 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffffc900244efda0] vfree_atomic at ffffffff811df2c7 #9 [ffffc900244efdb8] copy_process at ffffffff81086e37 #10 [ffffc900244efe98] _do_fork at ffffffff810884e0 #11 [ffffc900244eff10] sys_vfork at ffffffff810887ff #12 [ffffc900244eff20] do_syscall_64 at ffffffff81002a43 RIP: 000000000049b948 RSP: 00007ffcdb307830 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 0000000000896030 RCX: 000000000049b948 RDX: 0000000000000000 RSI: 00007ffcdb307790 RDI: 00000000005d7421 RBP: 000000000067370f R8: 00007ffcdb3077b0 R9: 000000000001ed00 R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000040 R13: 000000000000000f R14: 0000000000000000 R15: 000000000088d018 ORIG_RAX: 000000000000003a CS: 0033 SS: 002b The simplest fix is to assign tsk->stack right where it is allocated. Link: http://lkml.kernel.org/r/20181214231726.7ee4843c@imladris.surriel.com Fixes: 9b6f7e163cd0 ("mm: rework memcg kernel stack accounting") Signed-off-by: Rik van Riel <riel(a)surriel.com> Acked-by: Roman Gushchin <guro(a)fb.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Tejun Heo <tj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/fork.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/kernel/fork.c~forkmemcg-fix-crash-in-free_thread_stack-on-memcg-charge-fail +++ a/kernel/fork.c @@ -240,8 +240,10 @@ static unsigned long *alloc_thread_stack * free_thread_stack() can be called in interrupt context, * so cache the vm_struct. */ - if (stack) + if (stack) { tsk->stack_vm_area = find_vm_area(stack); + tsk->stack = stack; + } return stack; #else struct page *page = alloc_pages_node(node, THREADINFO_GFP, @@ -288,7 +290,10 @@ static struct kmem_cache *thread_stack_c static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) { - return kmem_cache_alloc_node(thread_stack_cache, THREADINFO_GFP, node); + unsigned long *stack; + stack = kmem_cache_alloc_node(thread_stack_cache, THREADINFO_GFP, node); + tsk->stack = stack; + return stack; } static void free_thread_stack(struct task_struct *tsk) _ Patches currently in -mm which might be from riel(a)surriel.com are

6 years, 8 months

1
0
0 0

[merged] mm-thp-fix-flags-for-pmd-migration-when-split.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: thp: fix flags for pmd migration when split has been removed from the -mm tree. Its filename was mm-thp-fix-flags-for-pmd-migration-when-split.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Peter Xu <peterx(a)redhat.com> Subject: mm: thp: fix flags for pmd migration when split When splitting a huge migrating PMD, we'll transfer all the existing PMD bits and apply them again onto the small PTEs. However we are fetching the bits unconditionally via pmd_soft_dirty(), pmd_write() or pmd_yound() while actually they don't make sense at all when it's a migration entry. Fix them up. Since at it, drop the ifdef together as not needed. Note that if my understanding is correct about the problem then if without the patch there is chance to lose some of the dirty bits in the migrating pmd pages (on x86_64 we're fetching bit 11 which is part of swap offset instead of bit 2) and it could potentially corrupt the memory of an userspace program which depends on the dirty bit. Link: http://lkml.kernel.org/r/20181213051510.20306-1-peterx@redhat.com Signed-off-by: Peter Xu <peterx(a)redhat.com> Reviewed-by: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> Reviewed-by: William Kucharski <william.kucharski(a)oracle.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Dave Jiang <dave.jiang(a)intel.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.vnet.ibm.com> Cc: Souptick Joarder <jrdr.linux(a)gmail.com> Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> Cc: Zi Yan <zi.yan(a)cs.rutgers.edu> Cc: <stable(a)vger.kernel.org> [4.14+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) --- a/mm/huge_memory.c~mm-thp-fix-flags-for-pmd-migration-when-split +++ a/mm/huge_memory.c @@ -2144,23 +2144,25 @@ static void __split_huge_pmd_locked(stru */ old_pmd = pmdp_invalidate(vma, haddr, pmd); -#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION pmd_migration = is_pmd_migration_entry(old_pmd); - if (pmd_migration) { + if (unlikely(pmd_migration)) { swp_entry_t entry; entry = pmd_to_swp_entry(old_pmd); page = pfn_to_page(swp_offset(entry)); - } else -#endif + write = is_write_migration_entry(entry); + young = false; + soft_dirty = pmd_swp_soft_dirty(old_pmd); + } else { page = pmd_page(old_pmd); + if (pmd_dirty(old_pmd)) + SetPageDirty(page); + write = pmd_write(old_pmd); + young = pmd_young(old_pmd); + soft_dirty = pmd_soft_dirty(old_pmd); + } VM_BUG_ON_PAGE(!page_count(page), page); page_ref_add(page, HPAGE_PMD_NR - 1); - if (pmd_dirty(old_pmd)) - SetPageDirty(page); - write = pmd_write(old_pmd); - young = pmd_young(old_pmd); - soft_dirty = pmd_soft_dirty(old_pmd); /* * Withdraw the table only after we mark the pmd entry invalid. _ Patches currently in -mm which might be from peterx(a)redhat.com are userfaultfd-clear-flag-if-remap-event-not-enabled.patch

6 years, 8 months

1
0
0 0

[merged] mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, memory_hotplug: initialize struct pages for the full memory section has been removed from the -mm tree. Its filename was mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Mikhail Zaslonko <zaslonko(a)linux.ibm.com> Subject: mm, memory_hotplug: initialize struct pages for the full memory section If memory end is not aligned with the sparse memory section boundary, the mapping of such a section is only partly initialized. This may lead to VM_BUG_ON due to uninitialized struct page access from is_mem_section_removable() or test_pages_in_a_zone() function triggered by memory_hotplug sysfs handlers: Here are the the panic examples: CONFIG_DEBUG_VM=y CONFIG_DEBUG_VM_PGFLAGS=y kernel parameter mem=2050M -------------------------- page:000003d082008000 is uninitialized and poisoned page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) Call Trace: ([<0000000000385b26>] test_pages_in_a_zone+0xde/0x160) [<00000000008f15c4>] show_valid_zones+0x5c/0x190 [<00000000008cf9c4>] dev_attr_show+0x34/0x70 [<0000000000463ad0>] sysfs_kf_seq_show+0xc8/0x148 [<00000000003e4194>] seq_read+0x204/0x480 [<00000000003b53ea>] __vfs_read+0x32/0x178 [<00000000003b55b2>] vfs_read+0x82/0x138 [<00000000003b5be2>] ksys_read+0x5a/0xb0 [<0000000000b86ba0>] system_call+0xdc/0x2d8 Last Breaking-Event-Address: [<0000000000385b26>] test_pages_in_a_zone+0xde/0x160 Kernel panic - not syncing: Fatal exception: panic_on_oops kernel parameter mem=3075M -------------------------- page:000003d08300c000 is uninitialized and poisoned page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) Call Trace: ([<000000000038596c>] is_mem_section_removable+0xb4/0x190) [<00000000008f12fa>] show_mem_removable+0x9a/0xd8 [<00000000008cf9c4>] dev_attr_show+0x34/0x70 [<0000000000463ad0>] sysfs_kf_seq_show+0xc8/0x148 [<00000000003e4194>] seq_read+0x204/0x480 [<00000000003b53ea>] __vfs_read+0x32/0x178 [<00000000003b55b2>] vfs_read+0x82/0x138 [<00000000003b5be2>] ksys_read+0x5a/0xb0 [<0000000000b86ba0>] system_call+0xdc/0x2d8 Last Breaking-Event-Address: [<000000000038596c>] is_mem_section_removable+0xb4/0x190 Kernel panic - not syncing: Fatal exception: panic_on_oops Fix the problem by initializing the last memory section of each zone in memmap_init_zone() till the very end, even if it goes beyond the zone end. Michal said: : This has alwways been problem AFAIU. It just went unnoticed because we : have zeroed memmaps during allocation before f7f99100d8d9 ("mm: stop : zeroing memory during allocation in vmemmap") and so the above test : would simply skip these ranges as belonging to zone 0 or provided a : garbage. : : So I guess we do care for post f7f99100d8d9 kernels mostly and : therefore Fixes: f7f99100d8d9 ("mm: stop zeroing memory during : allocation in vmemmap") Link: http://lkml.kernel.org/r/20181212172712.34019-2-zaslonko@linux.ibm.com Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: Mikhail Zaslonko <zaslonko(a)linux.ibm.com> Reviewed-by: Gerald Schaefer <gerald.schaefer(a)de.ibm.com> Suggested-by: Michal Hocko <mhocko(a)kernel.org> Acked-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Alexander Duyck <alexander.h.duyck(a)linux.intel.com> Cc: Pasha Tatashin <Pavel.Tatashin(a)microsoft.com> Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/mm/page_alloc.c~mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section +++ a/mm/page_alloc.c @@ -5542,6 +5542,18 @@ void __meminit memmap_init_zone(unsigned cond_resched(); } } +#ifdef CONFIG_SPARSEMEM + /* + * If the zone does not span the rest of the section then + * we should at least initialize those pages. Otherwise we + * could blow up on a poisoned page in some paths which depend + * on full sections being initialized (e.g. memory hotplug). + */ + while (end_pfn % PAGES_PER_SECTION) { + __init_single_page(pfn_to_page(end_pfn), end_pfn, zone, nid); + end_pfn++; + } +#endif } #ifdef CONFIG_ZONE_DEVICE _ Patches currently in -mm which might be from zaslonko(a)linux.ibm.com are

6 years, 8 months

1
0
0 0

stable-rc/linux-4.19.y boot: 93 boots: 0 failed, 92 passed with 1 offline (v4.19.11-68-g2a7cb228d29c)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 93 boots: 0 failed, 92 passed with 1 offline (v4.19.11-68-g2a7cb228d29c) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.11-68… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.11-68-g2a7cb228d29c Git Commit: 2a7cb228d29c3882c1414c10a44c5f3f59bfa44d Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 55 unique boards, 21 SoC families, 12 builds out of 202 Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

stable-rc/linux-4.9.y boot: 87 boots: 0 failed, 86 passed with 1 offline (v4.9.146-62-gbbfc30f29cb3)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 87 boots: 0 failed, 86 passed with 1 offline (v4.9.146-62-gbbfc30f29cb3) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.146-62-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.146-62-gbbfc30f29cb3 Git Commit: bbfc30f29cb328111fec12975ded8223ecc8e1a5 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 46 unique boards, 20 SoC families, 13 builds out of 193 Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

stable-rc/linux-4.4.y boot: 79 boots: 1 failed, 76 passed with 1 offline, 1 untried/unknown (v4.4.168-41-gba0da581b466)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 79 boots: 1 failed, 76 passed with 1 offline, 1 untried/unknown (v4.4.168-41-gba0da581b466) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.168-41-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.168-41-gba0da581b466 Git Commit: ba0da581b466dcd333eeb326919a698116926258 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 40 unique boards, 19 SoC families, 12 builds out of 187 Boot Failure Detected: arm64: defconfig qcom-qdf2400: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

[PATCH AUTOSEL 3.18 01/12] powerpc: Fix COFF zImage booting on old powermacs

by Sasha Levin

From: Paul Mackerras <paulus(a)ozlabs.org> [ Upstream commit 5564597d51c8ff5b88d95c76255e18b13b760879 ] Commit 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN", 2011-04-12) changed the procedure descriptor at the start of crt0.S to have a hard-coded start address of 0x500000 rather than a reference to _zimage_start, presumably because having a reference to a symbol introduced a relocation which is awkward to handle in a position-independent executable. Unfortunately, what is at 0x500000 in the COFF image is not the first instruction, but the procedure descriptor itself, that is, a word containing 0x500000, which is not a valid instruction. Hence, booting a COFF zImage results in a "DEFAULT CATCH!, code=FFF00700" message from Open Firmware. This fixes the problem by (a) putting the procedure descriptor in the data section and (b) adding a branch to _zimage_start as the first instruction in the program. Fixes: 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN") Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/powerpc/boot/crt0.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S index 8539ac93b0de..dbb06588b594 100644 --- a/arch/powerpc/boot/crt0.S +++ b/arch/powerpc/boot/crt0.S @@ -15,7 +15,7 @@ RELA = 7 RELACOUNT = 0x6ffffff9 - .text + .data /* A procedure descriptor used when booting this as a COFF file. * When making COFF, this comes first in the link and we're * linked at 0x500000. @@ -23,6 +23,8 @@ RELACOUNT = 0x6ffffff9 .globl _zimage_start_opd _zimage_start_opd: .long 0x500000, 0, 0, 0 + .text + b _zimage_start #ifdef __powerpc64__ .balign 8 -- 2.19.1

6 years, 8 months

1
11
0 0

[PATCH AUTOSEL 4.4 01/21] powerpc: Fix COFF zImage booting on old powermacs

by Sasha Levin

From: Paul Mackerras <paulus(a)ozlabs.org> [ Upstream commit 5564597d51c8ff5b88d95c76255e18b13b760879 ] Commit 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN", 2011-04-12) changed the procedure descriptor at the start of crt0.S to have a hard-coded start address of 0x500000 rather than a reference to _zimage_start, presumably because having a reference to a symbol introduced a relocation which is awkward to handle in a position-independent executable. Unfortunately, what is at 0x500000 in the COFF image is not the first instruction, but the procedure descriptor itself, that is, a word containing 0x500000, which is not a valid instruction. Hence, booting a COFF zImage results in a "DEFAULT CATCH!, code=FFF00700" message from Open Firmware. This fixes the problem by (a) putting the procedure descriptor in the data section and (b) adding a branch to _zimage_start as the first instruction in the program. Fixes: 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN") Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/powerpc/boot/crt0.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S index 5c2199857aa8..a3550e8f1a77 100644 --- a/arch/powerpc/boot/crt0.S +++ b/arch/powerpc/boot/crt0.S @@ -15,7 +15,7 @@ RELA = 7 RELACOUNT = 0x6ffffff9 - .text + .data /* A procedure descriptor used when booting this as a COFF file. * When making COFF, this comes first in the link and we're * linked at 0x500000. @@ -23,6 +23,8 @@ RELACOUNT = 0x6ffffff9 .globl _zimage_start_opd _zimage_start_opd: .long 0x500000, 0, 0, 0 + .text + b _zimage_start #ifdef __powerpc64__ .balign 8 -- 2.19.1

6 years, 8 months

1
20
0 0

PASS: Test report for kernel 4.19.12.skt+ (linux-stable-rc)

by CKI

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 2a7cb228d29c Linux 4.19.12 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Kernel tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/s390x/2a7cb228d29c3882c1414c10a44c… powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/2a7cb228d29c3882c1414c10a4… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/2a7cb228d29c3882c1414c10a4… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/2a7cb228d29c3882c1414c10a44… Hardware testing ---------------- We booted each kernel and ran the following tests: s390: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… NFS Connectathon - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… Networking route: pmtu - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu powerpc: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… NFS Connectathon - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… xfstests: ext4 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… Networking route: pmtu - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… arm64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… NFS Connectathon - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… xfstests: ext4 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… Networking route: pmtu - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… NFS Connectathon - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… xfstests: ext4 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… Networking route: pmtu - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

6 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror