* [merged] coredump-fix-unfreezable-coredumping-task.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: aryabinin, mhocko, oleg, pavel, rjw, stable, tj, viro, mm-commits
The patch titled
Subject: coredump: fix unfreezable coredumping task
has been removed from the -mm tree. Its filename was
coredump-fix-unfreezable-coredumping-task.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: coredump: fix unfreezable coredumping task
It could be not possible to freeze coredumping task when it waits for
'core_state->startup' completion, because threads are frozen in
get_signal() before they got a chance to complete 'core_state->startup'.
Inability to freeze a task during suspend will cause suspend to fail.
Also CRIU uses cgroup freezer during dump operation. So with an
unfreezable task the CRIU dump will fail because it waits for a
transition from 'FREEZING' to 'FROZEN' state which will never happen.
Use freezer_do_not_count() to tell freezer to ignore coredumping task
while it waits for core_state->startup completion.
Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/coredump.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN fs/coredump.c~coredump-fix-unfreezable-coredumping-task fs/coredump.c
--- a/fs/coredump.c~coredump-fix-unfreezable-coredumping-task
+++ a/fs/coredump.c
@@ -1,6 +1,7 @@
#include <linux/slab.h>
#include <linux/file.h>
#include <linux/fdtable.h>
+#include <linux/freezer.h>
#include <linux/mm.h>
#include <linux/stat.h>
#include <linux/fcntl.h>
@@ -423,7 +424,9 @@ static int coredump_wait(int exit_code,
if (core_waiters > 0) {
struct core_thread *ptr;
+ freezer_do_not_count();
wait_for_completion(&core_state->startup);
+ freezer_count();
/*
* Wait for all the threads to become inactive, so that
* all the thread context (extended register state, like
_
Patches currently in -mm which might be from aryabinin@virtuozzo.com are
^ permalink raw reply
* [merged] coredump-fix-unfreezable-coredumping-task.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: aryabinin, mhocko, oleg, pavel, rjw, stable, tj, viro, mm-commits
The patch titled
Subject: coredump: fix unfreezable coredumping task
has been removed from the -mm tree. Its filename was
coredump-fix-unfreezable-coredumping-task.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: coredump: fix unfreezable coredumping task
It could be not possible to freeze coredumping task when it waits for
'core_state->startup' completion, because threads are frozen in
get_signal() before they got a chance to complete 'core_state->startup'.
Inability to freeze a task during suspend will cause suspend to fail.
Also CRIU uses cgroup freezer during dump operation. So with an
unfreezable task the CRIU dump will fail because it waits for a
transition from 'FREEZING' to 'FROZEN' state which will never happen.
Use freezer_do_not_count() to tell freezer to ignore coredumping task
while it waits for core_state->startup completion.
Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/coredump.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN fs/coredump.c~coredump-fix-unfreezable-coredumping-task fs/coredump.c
--- a/fs/coredump.c~coredump-fix-unfreezable-coredumping-task
+++ a/fs/coredump.c
@@ -1,6 +1,7 @@
#include <linux/slab.h>
#include <linux/file.h>
#include <linux/fdtable.h>
+#include <linux/freezer.h>
#include <linux/mm.h>
#include <linux/stat.h>
#include <linux/fcntl.h>
@@ -423,7 +424,9 @@ static int coredump_wait(int exit_code,
if (core_waiters > 0) {
struct core_thread *ptr;
+ freezer_do_not_count();
wait_for_completion(&core_state->startup);
+ freezer_count();
/*
* Wait for all the threads to become inactive, so that
* all the thread context (extended register state, like
_
Patches currently in -mm which might be from aryabinin@virtuozzo.com are
^ permalink raw reply
* [merged] mm-filemap-dont-allow-partially-uptodate-page-for-pipes.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: guaneryu, jack, viro, mm-commits
The patch titled
Subject: mm/filemap: don't allow partially uptodate page for pipes
has been removed from the -mm tree. Its filename was
mm-filemap-dont-allow-partially-uptodate-page-for-pipes.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Eryu Guan <guaneryu@gmail.com>
Subject: mm/filemap: don't allow partially uptodate page for pipes
Starting from 4.9-rc1 kernel, I started noticing some test failures of
sendfile(2) and splice(2) (sendfile0N and splice01 from LTP) when testing
on sub-page block size filesystems (tested both XFS and ext4), these
syscalls start to return EIO in the tests. e.g.
sendfile02 1 TFAIL : sendfile02.c:133: sendfile(2) failed to return expected value, expected: 26, got: -1
sendfile02 2 TFAIL : sendfile02.c:133: sendfile(2) failed to return expected value, expected: 24, got: -1
sendfile02 3 TFAIL : sendfile02.c:133: sendfile(2) failed to return expected value, expected: 22, got: -1
sendfile02 4 TFAIL : sendfile02.c:133: sendfile(2) failed to return expected value, expected: 20, got: -1
This is because that in sub-page block size cases, we don't need the whole
page to be uptodate, only the part we care about is uptodate is OK (if fs
has ->is_partially_uptodate defined). But page_cache_pipe_buf_confirm()
doesn't have the ability to check the partially-uptodate case, it needs
the whole page to be uptodate. So it returns EIO in this case.
This is a regression introduced by commit 82c156f85384 ("switch
generic_file_splice_read() to use of ->read_iter()"). Prior to the
change, generic_file_splice_read() doesn't allow partially-uptodate page
either, so it worked fine.
Fix it by skipping the partially-uptodate check if we're working on a pipe
in do_generic_file_read(), so we read the whole page from disk as long as
the page is not uptodate.
I think the other way to fix it is to add the ability to check & allow
partially-uptodate page to page_cache_pipe_buf_confirm(), but that is much
harder to do and seems gain little.
Link: http://lkml.kernel.org/r/1477986187-12717-1-git-send-email-guaneryu@gmail.com
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/filemap.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN mm/filemap.c~mm-filemap-dont-allow-partially-uptodate-page-for-pipes mm/filemap.c
--- a/mm/filemap.c~mm-filemap-dont-allow-partially-uptodate-page-for-pipes
+++ a/mm/filemap.c
@@ -1732,6 +1732,9 @@ find_page:
if (inode->i_blkbits == PAGE_SHIFT ||
!mapping->a_ops->is_partially_uptodate)
goto page_not_up_to_date;
+ /* pipes can't handle partially uptodate pages */
+ if (unlikely(iter->type & ITER_PIPE))
+ goto page_not_up_to_date;
if (!trylock_page(page))
goto page_not_up_to_date;
/* Did it get truncated before we got the lock? */
_
Patches currently in -mm which might be from guaneryu@gmail.com are
^ permalink raw reply
* [merged] mm-hugetlb-fix-huge-page-reservation-leak-in-private-mapping-error-paths.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: mike.kravetz, aneesh.kumar, dave.hansen, hillf.zj, jstancek,
kirill.shutemov, mhocko, n-horiguchi, stable, mm-commits
The patch titled
Subject: mm/hugetlb: fix huge page reservation leak in private mapping error paths
has been removed from the -mm tree. Its filename was
mm-hugetlb-fix-huge-page-reservation-leak-in-private-mapping-error-paths.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Mike Kravetz <mike.kravetz@oracle.com>
Subject: mm/hugetlb: fix huge page reservation leak in private mapping error paths
Error paths in hugetlb_cow() and hugetlb_no_page() may free a newly
allocated huge page. If a reservation was associated with the huge page,
alloc_huge_page() consumed the reservation while allocating. When the
newly allocated page is freed in free_huge_page(), it will increment the
global reservation count. However, the reservation entry in the reserve
map will remain. This is not an issue for shared mappings as the entry in
the reserve map indicates a reservation exists. But, an entry in a
private mapping reserve map indicates the reservation was consumed and no
longer exists. This results in an inconsistency between the reserve map
and the global reservation count. This 'leaks' a reserved huge page.
Create a new routine restore_reserve_on_error() to restore the reserve
entry in these specific error paths. This routine makes use of a new
function vma_add_reservation() which will add a reserve entry for a
specific address/page.
In general, these error paths were rarely (if ever) taken on most
architectures. However, powerpc contained arch specific code that that
resulted in an extra fault and execution of these error paths on all
private mappings.
Fixes: 67961f9db8c4 ("mm/hugetlb: fix huge page reserve accounting for private mappings)
Link: http://lkml.kernel.org/r/1476933077-23091-2-git-send-email-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reported-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/hugetlb.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff -puN mm/hugetlb.c~mm-hugetlb-fix-huge-page-reservation-leak-in-private-mapping-error-paths mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-fix-huge-page-reservation-leak-in-private-mapping-error-paths
+++ a/mm/hugetlb.c
@@ -1826,11 +1826,17 @@ static void return_unused_surplus_pages(
* is not the case is if a reserve map was changed between calls. It
* is the responsibility of the caller to notice the difference and
* take appropriate action.
+ *
+ * vma_add_reservation is used in error paths where a reservation must
+ * be restored when a newly allocated huge page must be freed. It is
+ * to be called after calling vma_needs_reservation to determine if a
+ * reservation exists.
*/
enum vma_resv_mode {
VMA_NEEDS_RESV,
VMA_COMMIT_RESV,
VMA_END_RESV,
+ VMA_ADD_RESV,
};
static long __vma_reservation_common(struct hstate *h,
struct vm_area_struct *vma, unsigned long addr,
@@ -1856,6 +1862,14 @@ static long __vma_reservation_common(str
region_abort(resv, idx, idx + 1);
ret = 0;
break;
+ case VMA_ADD_RESV:
+ if (vma->vm_flags & VM_MAYSHARE)
+ ret = region_add(resv, idx, idx + 1);
+ else {
+ region_abort(resv, idx, idx + 1);
+ ret = region_del(resv, idx, idx + 1);
+ }
+ break;
default:
BUG();
}
@@ -1903,6 +1917,56 @@ static void vma_end_reservation(struct h
(void)__vma_reservation_common(h, vma, addr, VMA_END_RESV);
}
+static long vma_add_reservation(struct hstate *h,
+ struct vm_area_struct *vma, unsigned long addr)
+{
+ return __vma_reservation_common(h, vma, addr, VMA_ADD_RESV);
+}
+
+/*
+ * This routine is called to restore a reservation on error paths. In the
+ * specific error paths, a huge page was allocated (via alloc_huge_page)
+ * and is about to be freed. If a reservation for the page existed,
+ * alloc_huge_page would have consumed the reservation and set PagePrivate
+ * in the newly allocated page. When the page is freed via free_huge_page,
+ * the global reservation count will be incremented if PagePrivate is set.
+ * However, free_huge_page can not adjust the reserve map. Adjust the
+ * reserve map here to be consistent with global reserve count adjustments
+ * to be made by free_huge_page.
+ */
+static void restore_reserve_on_error(struct hstate *h,
+ struct vm_area_struct *vma, unsigned long address,
+ struct page *page)
+{
+ if (unlikely(PagePrivate(page))) {
+ long rc = vma_needs_reservation(h, vma, address);
+
+ if (unlikely(rc < 0)) {
+ /*
+ * Rare out of memory condition in reserve map
+ * manipulation. Clear PagePrivate so that
+ * global reserve count will not be incremented
+ * by free_huge_page. This will make it appear
+ * as though the reservation for this page was
+ * consumed. This may prevent the task from
+ * faulting in the page at a later time. This
+ * is better than inconsistent global huge page
+ * accounting of reserve counts.
+ */
+ ClearPagePrivate(page);
+ } else if (rc) {
+ rc = vma_add_reservation(h, vma, address);
+ if (unlikely(rc < 0))
+ /*
+ * See above comment about rare out of
+ * memory condition.
+ */
+ ClearPagePrivate(page);
+ } else
+ vma_end_reservation(h, vma, address);
+ }
+}
+
struct page *alloc_huge_page(struct vm_area_struct *vma,
unsigned long addr, int avoid_reserve)
{
@@ -3498,6 +3562,7 @@ retry_avoidcopy:
spin_unlock(ptl);
mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
out_release_all:
+ restore_reserve_on_error(h, vma, address, new_page);
put_page(new_page);
out_release_old:
put_page(old_page);
@@ -3680,6 +3745,7 @@ backout:
spin_unlock(ptl);
backout_unlocked:
unlock_page(page);
+ restore_reserve_on_error(h, vma, address, page);
put_page(page);
goto out;
}
_
Patches currently in -mm which might be from mike.kravetz@oracle.com are
^ permalink raw reply
* [ANNOUNCE] libdrm 2.4.73
From: Emil Velikov @ 2016-11-14 20:03 UTC (permalink / raw)
To: xorg-announce; +Cc: ML dri-devel
Emil Velikov (3):
headers: Add README file
xd86drm: read more than 128 bytes of uevent in drmParsePciBusInfo
Bump version for release
git tag: libdrm-2.4.73
https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.bz2
MD5: bc1cee09cde72ffe3b952e8f50ccdaa8 libdrm-2.4.73.tar.bz2
SHA1: 7abe64965ac4aa77d51746e70d6f2a38f100483d libdrm-2.4.73.tar.bz2
SHA256: 96bfd39242fe168017d95f22e141645a35591f5902a7d98c2fa4ca8c31df5e4d
libdrm-2.4.73.tar.bz2
PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.bz2.sig
https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.gz
MD5: 595a17e209f27602d3b1198e9a03e2d0 libdrm-2.4.73.tar.gz
SHA1: dd2e4993c8ee56b8f363e667e00e8aef1a7a733b libdrm-2.4.73.tar.gz
SHA256: 047d3073e3ecdf06e5419f74f8de8543e59f83d451c37519db4b6c8393620bfe
libdrm-2.4.73.tar.gz
PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.gz.sig
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [merged] ocfs2-fix-not-enough-credit-panic.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: junxiao.bi, jlbec, joseph.qi, mfasheh, mm-commits
The patch titled
Subject: ocfs2: fix not enough credit panic
has been removed from the -mm tree. Its filename was
ocfs2-fix-not-enough-credit-panic.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Junxiao Bi <junxiao.bi@oracle.com>
Subject: ocfs2: fix not enough credit panic
The following panic was caught when run ocfs2 disconfig single test (block
size 512 and cluster size 8192). ocfs2_journal_dirty() return -ENOSPC,
that means credits were used up. The total credit should include 3 times
of "num_dx_leaves" from ocfs2_dx_dir_rebalance(), because 2 times will be
consumed in ocfs2_dx_dir_transfer_leaf() and 1 time will be consumed in
ocfs2_dx_dir_new_cluster()->
__ocfs2_dx_dir_new_cluster()->ocfs2_dx_dir_format_cluster(). But only two
times is included in ocfs2_dx_dir_rebalance_credits(), fix it. This can
cause read-only fs(v4.1+) or panic for mainline linux depending on mount
option.
[34377.331151] ------------[ cut here ]------------
[34377.332007] kernel BUG at fs/ocfs2/journal.c:775!
[34377.344107] invalid opcode: 0000 [#1] SMP
[34377.346090] Modules linked in: ocfs2 nfsd lockd grace nfs_acl auth_rpcgss sunrpc autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sd_mod sg ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ppdev xen_kbdfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea parport_pc parport acpi_cpufreq i2c_piix4 i2c_core pcspkr ext4 jbd2 mbcache xen_blkfront floppy pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod
[34377.346090] CPU: 2 PID: 10601 Comm: dd Not tainted 4.1.12-71.el6uek.bug24939243.x86_64 #2
[34377.346090] Hardware name: Xen HVM domU, BIOS 4.4.4OVM 02/11/2016
[34377.346090] task: ffff8800b6de6200 ti: ffff8800a7d48000 task.ti: ffff8800a7d48000
[34377.346090] RIP: 0010:[<ffffffffa06e7397>] [<ffffffffa06e7397>] ocfs2_journal_dirty+0xa7/0xb0 [ocfs2]
[34377.346090] RSP: 0018:ffff8800a7d4b6d8 EFLAGS: 00010286
[34377.346090] RAX: 00000000ffffffe4 RBX: 00000000814d0a9c RCX: 00000000000004f9
[34377.346090] RDX: ffffffffa008e990 RSI: ffffffffa008f1ee RDI: ffff8800622b6460
[34377.346090] RBP: ffff8800a7d4b6f8 R08: ffffffffa008f288 R09: ffff8800622b6460
[34377.346090] R10: 0000000000000000 R11: 0000000000000282 R12: 0000000002c8421e
[34377.346090] R13: ffff88006d0cad00 R14: ffff880092beef60 R15: 0000000000000070
[34377.346090] FS: 00007f9b83e92700(0000) GS:ffff8800be880000(0000) knlGS:0000000000000000
[34377.346090] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[34377.346090] CR2: 00007fb2c0d1a000 CR3: 0000000008f80000 CR4: 00000000000406e0
[34377.346090] Stack:
[34377.346090] 00000000814d0a9c ffff88005fe61e00 ffff88006e995c00 ffff880009847c00
[34377.346090] ffff8800a7d4b768 ffffffffa06c0999 ffff88009d3c2a10 ffff88005fe61e30
[34377.346090] ffff8800997ce500 ffff8800997ce980 ffff880092beef60 000000100000000e
[34377.346090] Call Trace:
[34377.346090] [<ffffffffa06c0999>] ocfs2_dx_dir_transfer_leaf+0x159/0x1a0 [ocfs2]
[34377.346090] [<ffffffffa06c3eeb>] ocfs2_dx_dir_rebalance+0xd9b/0xea0 [ocfs2]
[34377.346090] [<ffffffffa06dedb2>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2]
[34377.346090] [<ffffffffa0761180>] ? ocfs2_refcount_tree_et_ops+0x60/0xfffffffffffe4b31 [ocfs2]
[34377.346090] [<ffffffffa06e7730>] ? ocfs2_journal_access_dl+0x20/0x20 [ocfs2]
[34377.346090] [<ffffffffa06c6b63>] ocfs2_find_dir_space_dx+0xd3/0x300 [ocfs2]
[34377.346090] [<ffffffffa06c9709>] ocfs2_prepare_dx_dir_for_insert+0x219/0x450 [ocfs2]
[34377.346090] [<ffffffffa06c9b16>] ocfs2_prepare_dir_for_insert+0x1d6/0x580 [ocfs2]
[34377.346090] [<ffffffffa06dee90>] ? ocfs2_read_inode_block+0x10/0x20 [ocfs2]
[34377.346090] [<ffffffffa06f38e2>] ocfs2_mknod+0x5a2/0x1400 [ocfs2]
[34377.346090] [<ffffffffa06f4933>] ocfs2_create+0x73/0x180 [ocfs2]
[34377.346090] [<ffffffff81211de8>] vfs_create+0xd8/0x100
[34377.346090] [<ffffffff8120f5fd>] ? lookup_real+0x1d/0x60
[34377.346090] [<ffffffff81212535>] lookup_open+0x185/0x1c0
[34377.346090] [<ffffffff8121571d>] do_last+0x36d/0x780
[34377.346090] [<ffffffff812a85d6>] ? security_file_alloc+0x16/0x20
[34377.346090] [<ffffffff81215bc2>] path_openat+0x92/0x470
[34377.346090] [<ffffffff81215fea>] do_filp_open+0x4a/0xa0
[34377.346090] [<ffffffff8132c570>] ? find_next_zero_bit+0x10/0x20
[34377.346090] [<ffffffff812232ec>] ? __alloc_fd+0xac/0x150
[34377.346090] [<ffffffff8120459a>] do_sys_open+0x11a/0x230
[34377.346090] [<ffffffff810259d3>] ? syscall_trace_enter_phase1+0x153/0x180
[34377.346090] [<ffffffff812046ee>] SyS_open+0x1e/0x20
[34377.346090] [<ffffffff816cb6ee>] system_call_fastpath+0x12/0x71
[34377.346090] Code: 1d 3f 29 09 00 48 85 db 74 1f 48 8b 03 0f 1f 80 00 00 00 00 48 8b 7b 08 48 83 c3 10 4c 89 e6 ff d0 48 8b 03 48 85 c0 75 eb eb 90 <0f> 0b eb fe 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54
[34377.346090] RIP [<ffffffffa06e7397>] ocfs2_journal_dirty+0xa7/0xb0 [ocfs2]
[34377.346090] RSP <ffff8800a7d4b6d8>
[34377.615401] ---[ end trace 91ac5312a6ee1288 ]---
[34377.618919] Kernel panic - not syncing: Fatal exception
[34377.619910] Kernel Offset: disabled
Link: http://lkml.kernel.org/r/1478248135-31963-1-git-send-email-junxiao.bi@oracle.com
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Mark Fasheh <mfasheh@versity.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Joseph Qi <joseph.qi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/ocfs2/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/ocfs2/dir.c~ocfs2-fix-not-enough-credit-panic fs/ocfs2/dir.c
--- a/fs/ocfs2/dir.c~ocfs2-fix-not-enough-credit-panic
+++ a/fs/ocfs2/dir.c
@@ -3699,7 +3699,7 @@ static void ocfs2_dx_dir_transfer_leaf(s
static int ocfs2_dx_dir_rebalance_credits(struct ocfs2_super *osb,
struct ocfs2_dx_root_block *dx_root)
{
- int credits = ocfs2_clusters_to_blocks(osb->sb, 2);
+ int credits = ocfs2_clusters_to_blocks(osb->sb, 3);
credits += ocfs2_calc_extend_credits(osb->sb, &dx_root->dr_list);
credits += ocfs2_quota_trans_credits(osb->sb);
_
Patches currently in -mm which might be from junxiao.bi@oracle.com are
^ permalink raw reply
* [merged] revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: hdegoede, frowand.list, gregkh, paul.burton, regressions, robh+dt,
stable, tj, mm-commits
The patch titled
Subject: Revert "console: don't prefer first registered if DT specifies stdout-path"
has been removed from the -mm tree. Its filename was
revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Hans de Goede <hdegoede@redhat.com>
Subject: Revert "console: don't prefer first registered if DT specifies stdout-path"
This reverts commit 05fd007e4629 ("console: don't prefer first registered
if DT specifies stdout-path").
The reverted commit changes existing behavior on which many ARM boards
rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
both a video output and a serial console. Depending on whether the user
is using the device as a more regular computer; or as a headless device we
need to have the console on either one or the other.
Many users rely on the kernel behavior of the console being present on
both outputs, before the reverted commit the console setup with no
console= kernel arguments on an ARM board which sets stdout-path in dt
would look like this:
[root@localhost ~]# cat /proc/consoles
ttyS0 -W- (EC p a) 4:64
tty0 -WU (E p ) 4:1
Where as after the reverted commit, it looks like this:
[root@localhost ~]# cat /proc/consoles
ttyS0 -W- (EC p a) 4:64
This commit reverts commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") restoring the original behavior.
Fixes: 05fd007e4629 ("console: don't prefer first registered if DT specifies stdout-path")
Link: http://lkml.kernel.org/r/20161104121135.4780-2-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/of/base.c | 2 --
include/linux/console.h | 6 ------
kernel/printk/printk.c | 13 +------------
3 files changed, 1 insertion(+), 20 deletions(-)
diff -puN drivers/of/base.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path drivers/of/base.c
--- a/drivers/of/base.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/drivers/of/base.c
@@ -2077,8 +2077,6 @@ void of_alias_scan(void * (*dt_alloc)(u6
name = of_get_property(of_aliases, "stdout", NULL);
if (name)
of_stdout = of_find_node_opts_by_path(name, &of_stdout_options);
- if (of_stdout)
- console_set_by_of();
}
if (!of_aliases)
diff -puN include/linux/console.h~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path include/linux/console.h
--- a/include/linux/console.h~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/include/linux/console.h
@@ -173,12 +173,6 @@ static inline void console_sysfs_notify(
#endif
extern bool console_suspend_enabled;
-#ifdef CONFIG_OF
-extern void console_set_by_of(void);
-#else
-static inline void console_set_by_of(void) {}
-#endif
-
/* Suspend and resume console messages over PM events */
extern void suspend_console(void);
extern void resume_console(void);
diff -puN kernel/printk/printk.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path kernel/printk/printk.c
--- a/kernel/printk/printk.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/kernel/printk/printk.c
@@ -253,17 +253,6 @@ static int preferred_console = -1;
int console_set_on_cmdline;
EXPORT_SYMBOL(console_set_on_cmdline);
-#ifdef CONFIG_OF
-static bool of_specified_console;
-
-void console_set_by_of(void)
-{
- of_specified_console = true;
-}
-#else
-# define of_specified_console false
-#endif
-
/* Flag: console code may call schedule() */
static int console_may_schedule;
@@ -2657,7 +2646,7 @@ void register_console(struct console *ne
* didn't select a console we take the first one
* that registers here.
*/
- if (preferred_console < 0 && !of_specified_console) {
+ if (preferred_console < 0) {
if (newcon->index < 0)
newcon->index = 0;
if (newcon->setup == NULL ||
_
Patches currently in -mm which might be from hdegoede@redhat.com are
^ permalink raw reply
* [merged] revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: hdegoede, frowand.list, gregkh, paul.burton, regressions, robh+dt,
stable, tj, mm-commits
The patch titled
Subject: Revert "console: don't prefer first registered if DT specifies stdout-path"
has been removed from the -mm tree. Its filename was
revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Hans de Goede <hdegoede@redhat.com>
Subject: Revert "console: don't prefer first registered if DT specifies stdout-path"
This reverts commit 05fd007e4629 ("console: don't prefer first registered
if DT specifies stdout-path").
The reverted commit changes existing behavior on which many ARM boards
rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
both a video output and a serial console. Depending on whether the user
is using the device as a more regular computer; or as a headless device we
need to have the console on either one or the other.
Many users rely on the kernel behavior of the console being present on
both outputs, before the reverted commit the console setup with no
console= kernel arguments on an ARM board which sets stdout-path in dt
would look like this:
[root@localhost ~]# cat /proc/consoles
ttyS0 -W- (EC p a) 4:64
tty0 -WU (E p ) 4:1
Where as after the reverted commit, it looks like this:
[root@localhost ~]# cat /proc/consoles
ttyS0 -W- (EC p a) 4:64
This commit reverts commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") restoring the original behavior.
Fixes: 05fd007e4629 ("console: don't prefer first registered if DT specifies stdout-path")
Link: http://lkml.kernel.org/r/20161104121135.4780-2-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/of/base.c | 2 --
include/linux/console.h | 6 ------
kernel/printk/printk.c | 13 +------------
3 files changed, 1 insertion(+), 20 deletions(-)
diff -puN drivers/of/base.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path drivers/of/base.c
--- a/drivers/of/base.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/drivers/of/base.c
@@ -2077,8 +2077,6 @@ void of_alias_scan(void * (*dt_alloc)(u6
name = of_get_property(of_aliases, "stdout", NULL);
if (name)
of_stdout = of_find_node_opts_by_path(name, &of_stdout_options);
- if (of_stdout)
- console_set_by_of();
}
if (!of_aliases)
diff -puN include/linux/console.h~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path include/linux/console.h
--- a/include/linux/console.h~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/include/linux/console.h
@@ -173,12 +173,6 @@ static inline void console_sysfs_notify(
#endif
extern bool console_suspend_enabled;
-#ifdef CONFIG_OF
-extern void console_set_by_of(void);
-#else
-static inline void console_set_by_of(void) {}
-#endif
-
/* Suspend and resume console messages over PM events */
extern void suspend_console(void);
extern void resume_console(void);
diff -puN kernel/printk/printk.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path kernel/printk/printk.c
--- a/kernel/printk/printk.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/kernel/printk/printk.c
@@ -253,17 +253,6 @@ static int preferred_console = -1;
int console_set_on_cmdline;
EXPORT_SYMBOL(console_set_on_cmdline);
-#ifdef CONFIG_OF
-static bool of_specified_console;
-
-void console_set_by_of(void)
-{
- of_specified_console = true;
-}
-#else
-# define of_specified_console false
-#endif
^ permalink raw reply
* [merged] mm-hwpoison-fix-thp-split-handling-in-memory_failure.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: n-horiguchi, stable, mm-commits
The patch titled
Subject: mm: hwpoison: fix thp split handling in memory_failure()
has been removed from the -mm tree. Its filename was
mm-hwpoison-fix-thp-split-handling-in-memory_failure.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: mm: hwpoison: fix thp split handling in memory_failure()
When memory_failure() runs on a thp tail page after pmd is split, we
trigger the following VM_BUG_ON_PAGE():
[ 619.550520] page:ffffd7cd819b0040 count:0 mapcount:0 mapping: (null) index:0x1
[ 619.555486] flags: 0x1fffc000400000(hwpoison)
[ 619.556408] page dumped because: VM_BUG_ON_PAGE(!page_count(p))
[ 619.558998] ------------[ cut here ]------------
[ 619.561388] kernel BUG at /src/linux-dev/mm/memory-failure.c:1132!
memory_failure() passed refcount and page lock from tail page to head
page, which is not needed because we can pass any subpage to
split_huge_page().
Fixes: 61f5d698cc97 ("mm: re-enable THP")
Link: http://lkml.kernel.org/r/1477961577-7183-1-git-send-email-n-horiguchi@ah.jp.nec.com
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: <stable@vger.kernel.org> [4.5+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory-failure.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff -puN mm/memory-failure.c~mm-hwpoison-fix-thp-split-handling-in-memory_failure mm/memory-failure.c
--- a/mm/memory-failure.c~mm-hwpoison-fix-thp-split-handling-in-memory_failure
+++ a/mm/memory-failure.c
@@ -1112,10 +1112,10 @@ int memory_failure(unsigned long pfn, in
}
if (!PageHuge(p) && PageTransHuge(hpage)) {
- lock_page(hpage);
- if (!PageAnon(hpage) || unlikely(split_huge_page(hpage))) {
- unlock_page(hpage);
- if (!PageAnon(hpage))
+ lock_page(p);
+ if (!PageAnon(p) || unlikely(split_huge_page(p))) {
+ unlock_page(p);
+ if (!PageAnon(p))
pr_err("Memory failure: %#lx: non anonymous thp\n",
pfn);
else
@@ -1126,9 +1126,7 @@ int memory_failure(unsigned long pfn, in
put_hwpoison_page(p);
return -EBUSY;
}
- unlock_page(hpage);
- get_hwpoison_page(p);
- put_hwpoison_page(hpage);
+ unlock_page(p);
VM_BUG_ON_PAGE(!page_count(p), p);
hpage = compound_head(p);
}
_
Patches currently in -mm which might be from n-horiguchi@ah.jp.nec.com are
^ permalink raw reply
* [merged] mm-hwpoison-fix-thp-split-handling-in-memory_failure.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: n-horiguchi, stable, mm-commits
The patch titled
Subject: mm: hwpoison: fix thp split handling in memory_failure()
has been removed from the -mm tree. Its filename was
mm-hwpoison-fix-thp-split-handling-in-memory_failure.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: mm: hwpoison: fix thp split handling in memory_failure()
When memory_failure() runs on a thp tail page after pmd is split, we
trigger the following VM_BUG_ON_PAGE():
[ 619.550520] page:ffffd7cd819b0040 count:0 mapcount:0 mapping: (null) index:0x1
[ 619.555486] flags: 0x1fffc000400000(hwpoison)
[ 619.556408] page dumped because: VM_BUG_ON_PAGE(!page_count(p))
[ 619.558998] ------------[ cut here ]------------
[ 619.561388] kernel BUG at /src/linux-dev/mm/memory-failure.c:1132!
memory_failure() passed refcount and page lock from tail page to head
page, which is not needed because we can pass any subpage to
split_huge_page().
Fixes: 61f5d698cc97 ("mm: re-enable THP")
Link: http://lkml.kernel.org/r/1477961577-7183-1-git-send-email-n-horiguchi@ah.jp.nec.com
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: <stable@vger.kernel.org> [4.5+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory-failure.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff -puN mm/memory-failure.c~mm-hwpoison-fix-thp-split-handling-in-memory_failure mm/memory-failure.c
--- a/mm/memory-failure.c~mm-hwpoison-fix-thp-split-handling-in-memory_failure
+++ a/mm/memory-failure.c
@@ -1112,10 +1112,10 @@ int memory_failure(unsigned long pfn, in
}
if (!PageHuge(p) && PageTransHuge(hpage)) {
- lock_page(hpage);
- if (!PageAnon(hpage) || unlikely(split_huge_page(hpage))) {
- unlock_page(hpage);
- if (!PageAnon(hpage))
+ lock_page(p);
+ if (!PageAnon(p) || unlikely(split_huge_page(p))) {
+ unlock_page(p);
+ if (!PageAnon(p))
pr_err("Memory failure: %#lx: non anonymous thp\n",
pfn);
else
@@ -1126,9 +1126,7 @@ int memory_failure(unsigned long pfn, in
put_hwpoison_page(p);
return -EBUSY;
}
- unlock_page(hpage);
- get_hwpoison_page(p);
- put_hwpoison_page(hpage);
+ unlock_page(p);
VM_BUG_ON_PAGE(!page_count(p), p);
hpage = compound_head(p);
}
_
Patches currently in -mm which might be from n-horiguchi@ah.jp.nec.com are
^ permalink raw reply
* [merged] swapfile-fix-memory-corruption-via-malformed-swapfile.patch removed from -mm tree
From: akpm @ 2016-11-14 20:02 UTC (permalink / raw)
To: jann, hannes, hughd, jmarchan, keescook, kirill.shutemov, stable,
vbabka, mm-commits
The patch titled
Subject: swapfile: fix memory corruption via malformed swapfile
has been removed from the -mm tree. Its filename was
swapfile-fix-memory-corruption-via-malformed-swapfile.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Jann Horn <jann@thejh.net>
Subject: swapfile: fix memory corruption via malformed swapfile
When root activates a swap partition whose header has the wrong endianness,
nr_badpages elements of badpages are swabbed before nr_badpages has been
checked, leading to a buffer overrun of up to 8GB.
This normally is not a security issue because it can only be exploited by
root (more specifically, a process with CAP_SYS_ADMIN or the ability to
modify a swap file/partition), and such a process can already e.g. modify
swapped-out memory of any other userspace process on the system.
Testcase for reproducing the bug (must be run as root, should crash your
kernel):
=================
#include <stdlib.h>
#include <unistd.h>
#include <sys/swap.h>
#include <limits.h>
#include <err.h>
#include <string.h>
#include <stdio.h>
#define PAGE_SIZE 4096
#define __u32 unsigned int
// from include/linux/swap.h
union swap_header {
struct {
char reserved[PAGE_SIZE - 10];
char magic[10]; /* SWAP-SPACE or SWAPSPACE2 */
} magic;
struct {
char bootbits[1024]; /* Space for disklabel etc. */
__u32 version;
__u32 last_page;
__u32 nr_badpages;
unsigned char sws_uuid[16];
unsigned char sws_volume[16];
__u32 padding[117];
__u32 badpages[1];
} info;
};
int main(void) {
char file[] = "/tmp/swapfile.XXXXXX";
int file_fd = mkstemp(file);
if (file_fd == -1)
err(1, "mkstemp");
if (ftruncate(file_fd, PAGE_SIZE))
err(1, "ftruncate");
union swap_header swap_header = {
.info = {
.version = __builtin_bswap32(1),
.nr_badpages = __builtin_bswap32(INT_MAX)
}
};
memcpy(swap_header.magic.magic, "SWAPSPACE2", 10);
if (write(file_fd, &swap_header, sizeof(swap_header)) !=
sizeof(swap_header))
err(1, "write");
// not because the attack needs it, just in case you forgot to
// sync yourself before crashing your machine
sync();
// now die
if (swapon(file, 0))
err(1, "swapon");
puts("huh, we survived");
if (swapoff(file))
err(1, "swapoff");
unlink(file);
}
=================
Link: http://lkml.kernel.org/r/1477949533-2509-1-git-send-email-jann@thejh.net
Signed-off-by: Jann Horn <jann@thejh.net>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/swapfile.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN mm/swapfile.c~swapfile-fix-memory-corruption-via-malformed-swapfile mm/swapfile.c
--- a/mm/swapfile.c~swapfile-fix-memory-corruption-via-malformed-swapfile
+++ a/mm/swapfile.c
@@ -2224,6 +2224,8 @@ static unsigned long read_swap_header(st
swab32s(&swap_header->info.version);
swab32s(&swap_header->info.last_page);
swab32s(&swap_header->info.nr_badpages);
+ if (swap_header->info.nr_badpages > MAX_SWAP_BADPAGES)
+ return 0;
for (i = 0; i < swap_header->info.nr_badpages; i++)
swab32s(&swap_header->info.badpages[i]);
}
_
Patches currently in -mm which might be from jann@thejh.net are
^ permalink raw reply
* [merged] mm-cma-check-the-max-limit-for-cma-allocation.patch removed from -mm tree
From: akpm @ 2016-11-14 20:02 UTC (permalink / raw)
To: shashim, catalin.marinas, sfr, mm-commits
The patch titled
Subject: mm/cma.c: check the max limit for cma allocation
has been removed from the -mm tree. Its filename was
mm-cma-check-the-max-limit-for-cma-allocation.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Shiraz Hashim <shashim@codeaurora.org>
Subject: mm/cma.c: check the max limit for cma allocation
CMA allocation request size is represented by size_t that gets truncated
when same is passed as int to bitmap_find_next_zero_area_off.
We observe that during fuzz testing when cma allocation request is too
high, bitmap_find_next_zero_area_off still returns success due to the
truncation. This leads to kernel crash, as subsequent code assumes that
requested memory is available.
Fail cma allocation in case the request breaches the corresponding cma
region size.
Link: http://lkml.kernel.org/r/1478189211-3467-1-git-send-email-shashim@codeaurora.org
Signed-off-by: Shiraz Hashim <shashim@codeaurora.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/cma.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN mm/cma.c~mm-cma-check-the-max-limit-for-cma-allocation mm/cma.c
--- a/mm/cma.c~mm-cma-check-the-max-limit-for-cma-allocation
+++ a/mm/cma.c
@@ -385,6 +385,9 @@ struct page *cma_alloc(struct cma *cma,
bitmap_maxno = cma_bitmap_maxno(cma);
bitmap_count = cma_bitmap_pages_to_bits(cma, count);
+ if (bitmap_count > bitmap_maxno)
+ return NULL;
+
for (;;) {
mutex_lock(&cma->lock);
bitmap_no = bitmap_find_next_zero_area_off(cma->bitmap,
_
Patches currently in -mm which might be from shashim@codeaurora.org are
^ permalink raw reply
* [merged] scripts-bloat-o-meter-fix-sigpipe.patch removed from -mm tree
From: akpm @ 2016-11-14 20:02 UTC (permalink / raw)
To: adobriyan, mpm, mm-commits
The patch titled
Subject: scripts/bloat-o-meter: fix SIGPIPE
has been removed from the -mm tree. Its filename was
scripts-bloat-o-meter-fix-sigpipe.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Alexey Dobriyan <adobriyan@gmail.com>
Subject: scripts/bloat-o-meter: fix SIGPIPE
Fix piping output to a program which quickly exits (read: head -n1)
$ ./scripts/bloat-o-meter ../vmlinux-000 ../obj/vmlinux | head -n1
add/remove: 0/0 grow/shrink: 9/60 up/down: 124/-305 (-181)
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Link: http://lkml.kernel.org/r/20161028204618.GA29923@avx2
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/bloat-o-meter | 3 +++
1 file changed, 3 insertions(+)
diff -puN scripts/bloat-o-meter~scripts-bloat-o-meter-fix-sigpipe scripts/bloat-o-meter
--- a/scripts/bloat-o-meter~scripts-bloat-o-meter-fix-sigpipe
+++ a/scripts/bloat-o-meter
@@ -8,6 +8,9 @@
# of the GNU General Public License, incorporated herein by reference.
import sys, os, re
+from signal import signal, SIGPIPE, SIG_DFL
+
+signal(SIGPIPE, SIG_DFL)
if len(sys.argv) != 3:
sys.stderr.write("usage: %s file1 file2\n" % sys.argv[0])
_
Patches currently in -mm which might be from adobriyan@gmail.com are
kbuild-simpler-generation-of-assembly-constants.patch
proc-make-struct-pid_entry-len-unsigned.patch
proc-make-struct-struct-map_files_info-len-unsigned-int.patch
proc-just-list_del-struct-pde_opener.patch
proc-fix-type-of-struct-pde_opener-closing-field.patch
proc-kmalloc-struct-pde_opener.patch
proc-tweak-comments-about-2-stage-open-and-everything.patch
coredump-clarify-unsafe-core_pattern-warning.patch
^ permalink raw reply
* [merged] shmem-fix-pageflags-after-swapping-dma32-object.patch removed from -mm tree
From: akpm @ 2016-11-14 20:02 UTC (permalink / raw)
To: hughd, kirill.shutemov, stable, mm-commits
The patch titled
Subject: shmem: fix pageflags after swapping DMA32 object
has been removed from the -mm tree. Its filename was
shmem-fix-pageflags-after-swapping-dma32-object.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Hugh Dickins <hughd@google.com>
Subject: shmem: fix pageflags after swapping DMA32 object
If shmem_alloc_page() does not set PageLocked and PageSwapBacked, then
shmem_replace_page() needs to do so for itself. Without this, it puts
newpage on the wrong lru, re-unlocks the unlocked newpage, and system
descends into "Bad page" reports and freeze; or if CONFIG_DEBUG_VM=y, it
hits an earlier VM_BUG_ON_PAGE(!PageLocked), depending on config.
But shmem_replace_page() is not a common path: it's only called when
swapin (or swapoff) finds the page was already read into an unsuitable
zone: usually all zones are suitable, but gem objects for a few drm
devices (gma500, omapdrm, crestline, broadwater) require zone DMA32 if
there's more than 4GB of ram.
Fixes: 800d8c63b2e9 ("shmem: add huge pages support")
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1611062003510.11253@eggly.anvils
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org> [4.8.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/shmem.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN mm/shmem.c~shmem-fix-pageflags-after-swapping-dma32-object mm/shmem.c
--- a/mm/shmem.c~shmem-fix-pageflags-after-swapping-dma32-object
+++ a/mm/shmem.c
@@ -1483,6 +1483,8 @@ static int shmem_replace_page(struct pag
copy_highpage(newpage, oldpage);
flush_dcache_page(newpage);
+ __SetPageLocked(newpage);
+ __SetPageSwapBacked(newpage);
SetPageUptodate(newpage);
set_page_private(newpage, swap_index);
SetPageSwapCache(newpage);
_
Patches currently in -mm which might be from hughd@google.com are
^ permalink raw reply
* [merged] mm-frontswap-make-sure-allocated-frontswap-map-is-assigned.patch removed from -mm tree
From: akpm @ 2016-11-14 20:02 UTC (permalink / raw)
To: vbabka, boris.ostrovsky, borntraeger, david.vrabel, jgross,
kirill.shutemov, konrad.wilk, stable, mm-commits
The patch titled
Subject: mm, frontswap: make sure allocated frontswap map is assigned
has been removed from the -mm tree. Its filename was
mm-frontswap-make-sure-allocated-frontswap-map-is-assigned.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Vlastimil Babka <vbabka@suse.cz>
Subject: mm, frontswap: make sure allocated frontswap map is assigned
Christian Borntraeger reports:
with commit 8ea1d2a1985a7ae096e ("mm, frontswap: convert frontswap_enabled
to static key") kmemleak complains about a memory leak in swapon
unreferenced object 0x3e09ba56000 (size 32112640):
comm "swapon", pid 7852, jiffies 4294968787 (age 1490.770s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000003a2504>] __vmalloc_node_range+0x194/0x2d8
[<00000000003a2918>] vzalloc+0x58/0x68
[<00000000003b0af0>] SyS_swapon+0xd60/0x12f8
[<0000000000a3dc2e>] system_call+0xd6/0x270
[<ffffffffffffffff>] 0xffffffffffffffff
Turns out kmemleak is right. We now allocate the frontswap map depending on the
kernel config (and no longer on the enablement)
swapfile.c:
[...]
if (IS_ENABLED(CONFIG_FRONTSWAP))
frontswap_map = vzalloc(BITS_TO_LONGS(maxpages) * sizeof(long));
but later on this is passed along
--> enable_swap_info(p, prio, swap_map, cluster_info, frontswap_map);
and ignored if frontswap is disabled
--> frontswap_init(p->type, frontswap_map);
static inline void frontswap_init(unsigned type, unsigned long *map)
{
if (frontswap_enabled())
__frontswap_init(type, map);
}
Thing is, that frontswap map is never freed.
===
The leakage is relatively not that bad, because swapon is an infrequent
and privileged operation. However, if the first frontswap backend is
registered after a swap type has been already enabled, it will WARN_ON in
frontswap_register_ops() and frontswap will not be available for the swap
type.
Fix this by making sure the map is assigned by frontswap_init() as long as
CONFIG_FRONTSWAP is enabled.
Fixes: 8ea1d2a1985a ("mm, frontswap: convert frontswap_enabled to static key")
Link: http://lkml.kernel.org/r/20161026134220.2566-1-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/frontswap.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff -puN include/linux/frontswap.h~mm-frontswap-make-sure-allocated-frontswap-map-is-assigned include/linux/frontswap.h
--- a/include/linux/frontswap.h~mm-frontswap-make-sure-allocated-frontswap-map-is-assigned
+++ a/include/linux/frontswap.h
@@ -106,8 +106,9 @@ static inline void frontswap_invalidate_
static inline void frontswap_init(unsigned type, unsigned long *map)
{
- if (frontswap_enabled())
- __frontswap_init(type, map);
+#ifdef CONFIG_FRONTSWAP
+ __frontswap_init(type, map);
+#endif
}
#endif /* _LINUX_FRONTSWAP_H */
_
Patches currently in -mm which might be from vbabka@suse.cz are
^ permalink raw reply
* [merged] mm-remove-extra-newline-from-allocation-stall-warning.patch removed from -mm tree
From: akpm @ 2016-11-14 20:02 UTC (permalink / raw)
To: penguin-kernel, mhocko, mm-commits
The patch titled
Subject: mm: remove extra newline from allocation stall warning
has been removed from the -mm tree. Its filename was
mm-remove-extra-newline-from-allocation-stall-warning.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Subject: mm: remove extra newline from allocation stall warning
63f53dea0c9866e9 ("mm: warn about allocations which stall for too long")
by error embedded "\n" in the format string, resulting in strange output.
[ 722.876655] kworker/0:1: page alloction stalls for 160001ms, order:0
[ 722.876656] , mode:0x2400000(GFP_NOIO)
[ 722.876657] CPU: 0 PID: 6966 Comm: kworker/0:1 Not tainted 4.8.0+ #69
Link: http://lkml.kernel.org/r/1476026219-7974-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/page_alloc.c~mm-remove-extra-newline-from-allocation-stall-warning mm/page_alloc.c
--- a/mm/page_alloc.c~mm-remove-extra-newline-from-allocation-stall-warning
+++ a/mm/page_alloc.c
@@ -3658,7 +3658,7 @@ retry:
/* Make sure we know about allocations which stall for too long */
if (time_after(jiffies, alloc_start + stall_timeout)) {
warn_alloc(gfp_mask,
- "page alloction stalls for %ums, order:%u\n",
+ "page allocation stalls for %ums, order:%u",
jiffies_to_msecs(jiffies-alloc_start), order);
stall_timeout += 10 * HZ;
}
_
Patches currently in -mm which might be from penguin-kernel@I-love.SAKURA.ne.jp are
hung_task-decrement-sysctl_hung_task_warnings-only-if-it-is-positive.patch
^ permalink raw reply
* + linux-next-git-rejects.patch added to -mm tree
From: akpm @ 2016-11-14 20:01 UTC (permalink / raw)
To: akpm, mm-commits
The patch titled
Subject: linux-next-git-rejects
has been added to the -mm tree. Its filename is
linux-next-git-rejects.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/linux-next-git-rejects.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/linux-next-git-rejects.patch
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/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: linux-next-git-rejects
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/kernel/cpu/amd.c | 12 ------------
1 file changed, 12 deletions(-)
diff -puN arch/x86/kernel/cpu/amd.c~linux-next-git-rejects arch/x86/kernel/cpu/amd.c
--- a/arch/x86/kernel/cpu/amd.c~linux-next-git-rejects
+++ a/arch/x86/kernel/cpu/amd.c
@@ -372,18 +372,6 @@ static void amd_detect_cmp(struct cpuinf
/* use socket ID also for last level cache */
per_cpu(cpu_llc_id, cpu) = c->phys_proc_id;
amd_get_topology(c);
-<<<<<<< HEAD
-
- /*
- * Fix percpu cpu_llc_id here as LLC topology is different
- * for Fam17h systems.
- */
- if (c->x86 != 0x17 || !cpuid_edx(0x80000006))
- return;
-
- per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
-=======
->>>>>>> linux-next/akpm-base
#endif
}
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
i-need-old-gcc.patch
arm-arch-arm-include-asm-pageh-needs-personalityh.patch
prctl-remove-one-shot-limitation-for-changing-exe-link-fix.patch
mm.patch
mm-compaction-allow-compaction-for-gfp_nofs-requests-fix.patch
mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist-checkpatch-fixes.patch
mm-unexport-__get_user_pages_unlocked-checkpatch-fixes.patch
scripts-checkpatchpl-fix-spelling.patch
debug-more-properly-delay-for-secondary-cpus-fix.patch
ipc-sem-rework-task-wakeups-checkpatch-fixes.patch
ipc-sem-optimize-perform_atomic_semop-checkpatch-fixes.patch
ipc-sem-simplify-wait-wake-loop-checkpatch-fixes.patch
linux-next-git-rejects.patch
linux-next-rejects.patch
drivers-net-wireless-intel-iwlwifi-dvm-calibc-fix-min-warning.patch
kernel-forkc-export-kernel_thread-to-modules.patch
slab-leaks3-default-y.patch
^ permalink raw reply
* Re: [RFC PATCH v3 06/20] x86: Add support to enable SME during early boot processing
From: Borislav Petkov @ 2016-11-14 20:01 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-arch, linux-efi, kvm, linux-doc, x86, linux-kernel,
kasan-dev, linux-mm, iommu, Rik van Riel,
Radim Krčmář, Arnd Bergmann, Jonathan Corbet,
Matt Fleming, Joerg Roedel, Konrad Rzeszutek Wilk, Paolo Bonzini,
Larry Woodman, Ingo Molnar, Andy Lutomirski, H. Peter Anvin,
Andrey Ryabinin, Alexander Potapenko, Thomas Gleixner,
Dmitry Vyukov
In-Reply-To: <178d7d21-ffbd-1083-9c64-f05378147e27@amd.com>
On Mon, Nov 14, 2016 at 12:18:44PM -0600, Tom Lendacky wrote:
> The %rsi register can be clobbered by the called function so I'm saving
> it since it points to the real mode data. I might be able to look into
> saving it earlier and restoring it before needed, but I though this
> might be clearer.
Ah, that's already in the comment earlier, I missed that.
> I can expand on the commit message about that. I was trying to keep the
> early boot-related code separate from the main code in arch/x86/mm dir.
... because?
It all gets linked into one monolithic image anyway and mem_encrypt.c
is not, like, really huge, right? IOW, I don't see a reason to spread
the code around the tree. OTOH, having everything in one file is much
better.
Or am I missing a good reason?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [RFC PATCH v3 06/20] x86: Add support to enable SME during early boot processing
From: Borislav Petkov @ 2016-11-14 20:01 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-arch, linux-efi, kvm, linux-doc, x86, linux-kernel,
kasan-dev, linux-mm, iommu, Rik van Riel,
Radim Krčmář, Arnd Bergmann, Jonathan Corbet,
Matt Fleming, Joerg Roedel, Konrad Rzeszutek Wilk, Paolo Bonzini,
Larry Woodman, Ingo Molnar, Andy Lutomirski, H. Peter Anvin,
Andrey Ryabinin, Alexander Potapenko
In-Reply-To: <178d7d21-ffbd-1083-9c64-f05378147e27@amd.com>
On Mon, Nov 14, 2016 at 12:18:44PM -0600, Tom Lendacky wrote:
> The %rsi register can be clobbered by the called function so I'm saving
> it since it points to the real mode data. I might be able to look into
> saving it earlier and restoring it before needed, but I though this
> might be clearer.
Ah, that's already in the comment earlier, I missed that.
> I can expand on the commit message about that. I was trying to keep the
> early boot-related code separate from the main code in arch/x86/mm dir.
... because?
It all gets linked into one monolithic image anyway and mem_encrypt.c
is not, like, really huge, right? IOW, I don't see a reason to spread
the code around the tree. OTOH, having everything in one file is much
better.
Or am I missing a good reason?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH v7 04/14] ARM: dts: Add xo_clock to sdhc nodes on qcom platforms
From: Stephen Boyd @ 2016-11-14 20:01 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-5-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> Add xo_clock to sdhc clock node on all qcom platforms.
>
> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
> ---
> arch/arm/boot/dts/qcom-apq8084.dtsi | 14 ++++++++------
> arch/arm/boot/dts/qcom-msm8974.dtsi | 14 ++++++++------
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 10 ++++++----
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 +++++----
> 4 files changed, 27 insertions(+), 20 deletions(-)
>
Is there an update to
Documentation/devicetree/bindings/mmc/sdhci-msm.txt as well?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [GIT PULL] fbdev fixes for 4.9
From: Mathieu Malaterre @ 2016-11-14 20:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <b74835d1-b878-55ec-65d3-dd3766a5b194@ti.com>
Tomi,
On Mon, Nov 14, 2016 at 5:25 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Nov 14, 2016 at 3:44 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>
>> Please pull two fbdev fixes for 4.9.
>
> No.
>
> This has obviously never even been test-compiled. It introduces two
> new annoying warnings.
Sorry about that noob error. I've just send a v2 a minute ago.
Thanks
^ permalink raw reply
* + linux-next-rejects.patch added to -mm tree
From: akpm @ 2016-11-14 20:01 UTC (permalink / raw)
To: akpm, mm-commits
The patch titled
Subject: linux-next-rejects
has been added to the -mm tree. Its filename is
linux-next-rejects.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/linux-next-rejects.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/linux-next-rejects.patch
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/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: linux-next-rejects
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memcontrol.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff -puN mm/memcontrol.c~linux-next-rejects mm/memcontrol.c
--- a/mm/memcontrol.c~linux-next-rejects
+++ a/mm/memcontrol.c
@@ -5767,10 +5767,10 @@ __setup("cgroup.memory=", cgroup_memory)
/*
* subsys_initcall() for memory controller.
*
- * Some parts like hotcpu_notifier() have to be initialized from this context
- * because of lock dependencies (cgroup_lock -> cpu hotplug) but basically
- * everything that doesn't depend on a specific mem_cgroup structure should
- * be initialized from here.
+ * Some parts like memcg_hotplug_cpu_dead() have to be initialized from this
+ * context because of lock dependencies (cgroup_lock -> cpu hotplug) but
+ * basically everything that doesn't depend on a specific mem_cgroup structure
+ * should be initialized from here.
*/
static int __init mem_cgroup_init(void)
{
@@ -5787,7 +5787,8 @@ static int __init mem_cgroup_init(void)
BUG_ON(!memcg_kmem_cache_create_wq);
#endif
- hotcpu_notifier(memcg_cpu_hotplug_callback, 0);
+ cpuhp_setup_state_nocalls(CPUHP_MM_MEMCQ_DEAD, "mm/memctrl:dead", NULL,
+ memcg_hotplug_cpu_dead);
for_each_possible_cpu(cpu)
INIT_WORK(&per_cpu_ptr(&memcg_stock, cpu)->work,
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
i-need-old-gcc.patch
arm-arch-arm-include-asm-pageh-needs-personalityh.patch
prctl-remove-one-shot-limitation-for-changing-exe-link-fix.patch
mm.patch
mm-compaction-allow-compaction-for-gfp_nofs-requests-fix.patch
mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist-checkpatch-fixes.patch
mm-unexport-__get_user_pages_unlocked-checkpatch-fixes.patch
scripts-checkpatchpl-fix-spelling.patch
debug-more-properly-delay-for-secondary-cpus-fix.patch
ipc-sem-rework-task-wakeups-checkpatch-fixes.patch
ipc-sem-optimize-perform_atomic_semop-checkpatch-fixes.patch
ipc-sem-simplify-wait-wake-loop-checkpatch-fixes.patch
drivers-net-wireless-intel-iwlwifi-dvm-calibc-fix-min-warning.patch
kernel-forkc-export-kernel_thread-to-modules.patch
slab-leaks3-default-y.patch
linux-next-rejects.patch
^ permalink raw reply
* Re: [PATCH] attr: mark a file-local symbol as static
From: Stefan Beller @ 2016-11-14 20:00 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <83508d1f-e809-f6be-5afc-4c23195dbd08@ramsayjones.plus.com>
On Sun, Nov 13, 2016 at 8:42 AM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
>
> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
> ---
>
> Hi Stefan,
>
> If you need to re-roll your 'sb/attr' branch, could you please
> squash this into the relevant patch.
will do. I have it applied locally
>
> Alternatively, since there is only a single call site for git_attr()
> (on line #1005), you could perhaps remove git_attr() and inline that
> call. (However, that does make that line exceed 80 columns).
I'll look into that.
Thanks,
Stefan
>
> Thanks!
>
> ATB,
> Ramsay Jones
>
> attr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/attr.c b/attr.c
> index 667ba85..84c4b08 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -169,7 +169,7 @@ static struct git_attr *git_attr_internal(const char *name, int len)
> return a;
> }
>
> -struct git_attr *git_attr(const char *name)
> +static struct git_attr *git_attr(const char *name)
> {
> return git_attr_internal(name, strlen(name));
> }
> --
> 2.10.0
^ permalink raw reply
* Re: [PATCH 1/3] block: fast-path for small and simple direct I/O requests
From: Jens Axboe @ 2016-11-14 20:00 UTC (permalink / raw)
To: Omar Sandoval; +Cc: axboe, linux-block, linux-fsdevel, hch, Christoph Hellwig
In-Reply-To: <20161114193339.GA31821@vader.DHCP.thefacebook.com>
On 11/14/2016 12:33 PM, Omar Sandoval wrote:
> On Fri, Nov 11, 2016 at 10:11:25PM -0700, Jens Axboe wrote:
>> From: Christoph Hellwig <hch@lst.de>
>>
>> This patch adds a small and simple fast patch for small direct I/O
>> requests on block devices that don't use AIO. Between the neat
>> bio_iov_iter_get_pages helper that avoids allocating a page array
>> for get_user_pages and the on-stack bio and biovec this avoid memory
>> allocations and atomic operations entirely in the direct I/O code
>> (lower levels might still do memory allocations and will usually
>> have at least some atomic operations, though).
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Jens Axboe <axboe@fb.com>
>> ---
>> fs/block_dev.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 80 insertions(+)
>>
>
> [snip]
>
>> static ssize_t
>> blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
>> {
>> struct file *file = iocb->ki_filp;
>> struct inode *inode = bdev_file_inode(file);
>> + int nr_pages;
>>
>> + nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES);
>> + if (!nr_pages)
>> + return 0;
>> + if (is_sync_kiocb(iocb) && nr_pages <= DIO_INLINE_BIO_VECS)
>> + return __blkdev_direct_IO_simple(iocb, iter, nr_pages);
>> return __blockdev_direct_IO(iocb, inode, I_BDEV(inode), iter,
>> blkdev_get_block, NULL, NULL,
>> DIO_SKIP_DIO_COUNT);
>
> __blockdev_direct_IO() does a few cache prefetches that we're now
> bypassing, do we want to do the same in __blkdev_direct_IO_simple()?
> That's the stuff added in 65dd2aa90aa1 ("dio: optimize cache misses in
> the submission path").
Prefetches like that tend to grow stale, in my experience. So we should
probably just evaluate the new path cache behavior and see if it makes
sense.
--
Jens Axboe
^ permalink raw reply
* [PATCH v2] Fix loading of module radeonfb on PowerMac
From: Mathieu Malaterre @ 2016-11-14 19:59 UTC (permalink / raw)
To: linux-fbdev
Cc: Lennart Sorensen, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Benjamin Herrenschmidt,
linuxppc-dev, Mathieu Malaterre
When the linux kernel is build with (typical kernel ship with Debian
installer):
CONFIG_FB_OF=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_FB_RADEON=m
The offb driver takes precedence over module radeonfb. It is then
impossible to load the module, error reported is:
[ 96.551486] radeonfb 0000:00:10.0: enabling device (0006 -> 0007)
[ 96.551526] radeonfb 0000:00:10.0: BAR 0: can't reserve [mem 0x98000000-0x9fffffff pref]
[ 96.551531] radeonfb (0000:00:10.0): cannot request region 0.
[ 96.551545] radeonfb: probe of 0000:00:10.0 failed with error -16
This patch reproduce the behavior of the module radeon, so as to make it
possible to load radeonfb when offb is first loaded.
It should be noticed that `offb_destroy` is never called which explain the
need to skip error detection on the radeon side.
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Link: https://bugs.debian.org/826629#57
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
Suggested-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
---
drivers/video/fbdev/aty/radeon_base.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index 218339a..84d634b 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2259,6 +2259,22 @@ static struct bin_attribute edid2_attr = {
.read = radeon_show_edid2,
};
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+ struct apertures_struct *ap;
+
+ ap = alloc_apertures(1);
+ if (!ap)
+ return -ENOMEM;
+
+ ap->ranges[0].base = pci_resource_start(pdev, 0);
+ ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+ remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+ kfree(ap);
+
+ return 0;
+}
static int radeonfb_pci_register(struct pci_dev *pdev,
const struct pci_device_id *ent)
@@ -2314,19 +2330,27 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->fb_base_phys = pci_resource_start (pdev, 0);
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
+ ret = radeon_kick_out_firmware_fb(pdev);
+ if (ret)
+ return ret;
+
/* request the mem regions */
ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
+#ifndef CONFIG_PPC
goto err_release_fb;
+#endif
}
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
+#ifndef CONFIG_PPC
goto err_release_pci0;
+#endif
}
/* map the regions */
@@ -2511,10 +2535,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
iounmap(rinfo->mmio_base);
err_release_pci2:
pci_release_region(pdev, 2);
+#ifndef CONFIG_PPC
err_release_pci0:
pci_release_region(pdev, 0);
err_release_fb:
framebuffer_release(info);
+#endif
err_disable:
err_out:
return ret;
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.