* [folded] lis3-remove-the-references-to-the-global-variable-in-core-driver-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:48 UTC (permalink / raw)
To: ilkka.koskinen, eric.piel, mm-commits
The patch titled
Subject: lis3-remove-the-references-to-the-global-variable-in-core-driver-fix
has been removed from the -mm tree. Its filename was
lis3-remove-the-references-to-the-global-variable-in-core-driver-fix.patch
This patch was dropped because it was folded into lis3-remove-the-references-to-the-global-variable-in-core-driver.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Subject: lis3-remove-the-references-to-the-global-variable-in-core-driver-fix
Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/misc/lis3lv02d/lis3lv02d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/misc/lis3lv02d/lis3lv02d.c~lis3-remove-the-references-to-the-global-variable-in-core-driver-fix drivers/misc/lis3lv02d/lis3lv02d.c
--- a/drivers/misc/lis3lv02d/lis3lv02d.c~lis3-remove-the-references-to-the-global-variable-in-core-driver-fix
+++ a/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -200,7 +200,7 @@ static int lis3lv02d_get_odr(struct lis3
u8 ctrl;
int shift;
- lis3->read(&lis3, CTRL_REG1, &ctrl);
+ lis3->read(lis3, CTRL_REG1, &ctrl);
ctrl &= lis3->odr_mask;
shift = ffs(lis3->odr_mask) - 1;
return lis3->odrs[(ctrl >> shift)];
_
Patches currently in -mm which might be from ilkka.koskinen@nokia.com are
lis3lv02d-avoid-divide-by-zero-due-to-unchecked.patch
lis3-update-maintainer-information.patch
lis3-add-support-for-hp-elitebook-2730p.patch
lis3-add-support-for-hp-elitebook-8540w.patch
hp_accel-add-hp-probook-655x.patch
lis3-free-regulators-if-probe-fails.patch
lis3-change-naming-to-consistent.patch
lis3-change-exported-function-to-use-given.patch
lis3-remove-the-references-to-the-global-variable-in-core-driver.patch
lis3lv02d-make-regulator-api-usage-unconditional.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] netbase: follow oe-core update to 4.46
From: Andreas Müller @ 2011-10-31 23:52 UTC (permalink / raw)
To: meta-ti
Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
---
.../beagleboard/interfaces | 0
...netbase_4.45.bbappend => netbase_4.46.bbappend} | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename recipes-core/netbase/{netbase-4.45 => netbase-4.46}/beagleboard/interfaces (100%)
rename recipes-core/netbase/{netbase_4.45.bbappend => netbase_4.46.bbappend} (100%)
diff --git a/recipes-core/netbase/netbase-4.45/beagleboard/interfaces b/recipes-core/netbase/netbase-4.46/beagleboard/interfaces
similarity index 100%
rename from recipes-core/netbase/netbase-4.45/beagleboard/interfaces
rename to recipes-core/netbase/netbase-4.46/beagleboard/interfaces
diff --git a/recipes-core/netbase/netbase_4.45.bbappend b/recipes-core/netbase/netbase_4.46.bbappend
similarity index 100%
rename from recipes-core/netbase/netbase_4.45.bbappend
rename to recipes-core/netbase/netbase_4.46.bbappend
--
1.7.4.4
^ permalink raw reply
* [folded] mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:47 UTC (permalink / raw)
To: akpm, hughd, walken, mm-commits
The patch titled
Subject: mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix
has been removed from the -mm tree. Its filename was
mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix.patch
This patch was dropped because it was folded into mm-munlock-use-mapcount-to-avoid-terrible-overhead.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix
add comment
Cc: Hugh Dickins <hughd@google.com>
Cc: Michel Lespinasse <walken@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/mlock.c | 5 +++++
1 file changed, 5 insertions(+)
diff -puN mm/mlock.c~mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix mm/mlock.c
--- a/mm/mlock.c~mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix
+++ a/mm/mlock.c
@@ -112,6 +112,11 @@ void munlock_vma_page(struct page *page)
if (!isolate_lru_page(page)) {
int ret = SWAP_AGAIN;
+ /*
+ * Optimization: if the page was mapped just once,
+ * that's our mapping and we don't need to check all the
+ * other vmas.
+ */
if (page_mapcount(page) > 1)
ret = try_to_munlock(page);
/*
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
origin.patch
dma-mapping-fix-sync_single_range_-dma-debugging.patch
include-linux-dmarh-forward-declare-struct-acpi_dmar_header.patch
proc-self-numa_maps-restore-huge-tag-for-hugetlb-vmas.patch
mm-add-comments-to-explain-mm_struct-fields.patch
mm-avoid-null-pointer-access-in-vm_struct-via-proc-vmallocinfo.patch
thp-mremap-support-and-tlb-optimization.patch
mm-neaten-warn_alloc_failed.patch
debug-pagealloc-add-support-for-highmem-pages.patch
mm-add-comment-explaining-task-state-setting-in-bdi_forker_thread-fix.patch
mm-munlock-use-mapcount-to-avoid-terrible-overhead.patch
kernel-sysctlc-add-cap_last_cap-to-proc-sys-kernel-fix.patch
drivers-leds-leds-lp5521c-check-if-reset-is-successful-fix.patch
lib-bitmapc-quiet-sparse-noise-about-address-space-fix.patch
llist-return-whether-list-is-empty-before-adding-in-llist_add-fix.patch
checkpatch-add-a-strict-check-for-utf-8-in-commit-logs.patch
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Claudio Moretti @ 2011-10-31 23:46 UTC (permalink / raw)
To: Jonas Meurer; +Cc: dm-crypt
In-Reply-To: <4EAF25AD.9080200@freesources.org>
[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]
> I don't suggest to hide the backup header. In fact the exact place of
> it should be obvious (either fixed, or better: random but written to
> the first header). Thus the second header is as obvious as the first
> one. Only difference: it's not at the beginning of the device.
> Unfortunately the first sectors of a device are overwritten much more
> often than later sectors.
>
>
AFAIK, the LUKS header is not on the beginning of the partition, but it's
distributed in it; there's a piece of it at the beginning (the "0x0A L U K
S" part) but the rest is not there (because of anti-forensic stuff).. That
said, if you overwrite the beginning of the disk (or it gets corrupted) you
damage data that cannot be reconstructed, so you lose access to the disk.
> I see that a backup header - which for sure needs to be overwritten by
> new luksFormat - wouldn't prevent accidents like the one explained in
> the first message to this thread. Only in cases where people
> accidently overwrite the first sectors of a luks device, this kind of
> backup header could prevent data loss.
>
True, and that can be done: the header is not big, so there should be no
problem in doing this. But if I'm right, and the header is in a
unknown-but-reconstructable position (i.e. with the right passphrase, you
access the right positions for keyslots/master key), doing so would expose
the entire header: one simply has to look for identical data on the disk
(if your header is - for example - "0x0123456789abcdef", an attacker that
finds two occurrences of "0x0123456789abcdef" on the disk may assume that
this is your header) and your anti-forensic measures are gone.
Also, suppose you have something really really secret on your LUKS disk, so
secret that you'd rather lose it than admitting you have it; if you don't
have a header backup on the disk, you should simply overwrite something
like 1KB of data on your disk (and running dd if=/dev/urandom of=/dev/sdX
ensures you can do it instantly: no way one can stop it in time) and you're
safe. If there's a header backup somewhere, and you don't know where, how
can you do it? dd-ing the entire disk takes hours, even with a "small" one
(80GB?)..
Better idea is: you advise your users to backup their header (like
Truecrypt does with its "boot rescue disk" or something) and you provide a
stupid-proof procedure to do it (like modifying partman in every
distribution to be able to create a header backup on an external disk or
something..
But that's something that should be done from distribution mantainers, not
from cryptsetup itself.
Claudio
[-- Attachment #2: Type: text/html, Size: 3084 bytes --]
^ permalink raw reply
* [folded] vmscan-limit-direct-reclaim-for-higher-order-allocations-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:46 UTC (permalink / raw)
To: jweiner, aarcange, mgorman, minchan.kim, mm-commits
The patch titled
Subject: vmscan-limit-direct-reclaim-for-higher-order-allocations-fix
has been removed from the -mm tree. Its filename was
vmscan-limit-direct-reclaim-for-higher-order-allocations-fix.patch
This patch was dropped because it was folded into vmscan-limit-direct-reclaim-for-higher-order-allocations.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Johannes Weiner <jweiner@redhat.com>
Subject: vmscan-limit-direct-reclaim-for-higher-order-allocations-fix
change comment to explain the order check
Signed-off-by: Johannes Weiner <jweiner@redhat.com>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/vmscan.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff -puN mm/vmscan.c~vmscan-limit-direct-reclaim-for-higher-order-allocations-fix mm/vmscan.c
--- a/mm/vmscan.c~vmscan-limit-direct-reclaim-for-higher-order-allocations-fix
+++ a/mm/vmscan.c
@@ -2115,8 +2115,14 @@ static void shrink_zones(int priority, s
continue; /* Let kswapd poll it */
if (COMPACTION_BUILD) {
/*
- * If we already have plenty of memory free
- * for compaction, don't free any more.
+ * If we already have plenty of memory
+ * free for compaction, don't free any
+ * more. Even though compaction is
+ * invoked for any non-zero order,
+ * only frequent costly order
+ * reclamation is disruptive enough to
+ * become a noticable problem, like
+ * transparent huge page allocations.
*/
if (sc->order > PAGE_ALLOC_COSTLY_ORDER &&
(compaction_suitable(zone, sc->order) ||
_
Patches currently in -mm which might be from jweiner@redhat.com are
mm-page-writebackc-document-bdi_min_ratio.patch
mm-vmscan-drop-nr_force_scan-from-get_scan_count.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-direct-reclaim.patch
mm-vmscan-remove-dead-code-related-to-lumpy-reclaim-waiting-on-pages-under-writeback.patch
xfs-warn-if-direct-reclaim-tries-to-writeback-pages.patch
ext4-warn-if-direct-reclaim-tries-to-writeback-pages.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-kswapd-except-in-high-priority.patch
mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback.patch
mm-vmscan-immediately-reclaim-end-of-lru-dirty-pages-when-writeback-completes.patch
mremap-check-for-overflow-using-deltas.patch
mremap-avoid-sending-one-ipi-per-page.patch
thp-mremap-support-and-tlb-optimization.patch
vmscanc-fix-invalid-strict_strtoul-check-in-write_scan_unevictable_node.patch
mm-disable-user-interface-to-manually-rescue-unevictable-pages.patch
mm-huge_memoryc-quiet-sparse-noise.patch
vmscan-add-barrier-to-prevent-evictable-page-in-unevictable-list.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations.patch
vmscan-abort-reclaim-compaction-if-compaction-can-proceed.patch
mm-do-not-drain-pagevecs-for-mlockallmcl_future.patch
mm-huge_memory-fix-copying-user-highpage.patch
mm-huge_memory-fix-typo-when-updating-mmu-cache.patch
^ permalink raw reply
* [folded] mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:46 UTC (permalink / raw)
To: akpm, consul.kautuk, mm-commits
The patch titled
Subject: mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix
has been removed from the -mm tree. Its filename was
mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix.patch
This patch was dropped because it was folded into mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix
Cc: Kautuk Consul <consul.kautuk@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/mmap.c | 1 -
1 file changed, 1 deletion(-)
diff -puN mm/mmap.c~mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix mm/mmap.c
--- a/mm/mmap.c~mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix
+++ a/mm/mmap.c
@@ -2582,7 +2582,6 @@ int mm_take_all_locks(struct mm_struct *
out_unlock:
mm_drop_all_locks(mm);
-
return -EINTR;
}
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
origin.patch
dma-mapping-fix-sync_single_range_-dma-debugging.patch
include-linux-dmarh-forward-declare-struct-acpi_dmar_header.patch
proc-self-numa_maps-restore-huge-tag-for-hugetlb-vmas.patch
mm-add-comments-to-explain-mm_struct-fields.patch
mm-avoid-null-pointer-access-in-vm_struct-via-proc-vmallocinfo.patch
thp-mremap-support-and-tlb-optimization.patch
mm-neaten-warn_alloc_failed.patch
debug-pagealloc-add-support-for-highmem-pages.patch
mm-add-comment-explaining-task-state-setting-in-bdi_forker_thread-fix.patch
mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks.patch
mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix.patch
kernel-sysctlc-add-cap_last_cap-to-proc-sys-kernel-fix.patch
drivers-leds-leds-lp5521c-check-if-reset-is-successful-fix.patch
lib-bitmapc-quiet-sparse-noise-about-address-space-fix.patch
llist-return-whether-list-is-empty-before-adding-in-llist_add-fix.patch
checkpatch-add-a-strict-check-for-utf-8-in-commit-logs.patch
^ permalink raw reply
* [folded] debug-pagealloc-add-support-for-highmem-pages-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:45 UTC (permalink / raw)
To: akpm, akinobu.mita, mm-commits
The patch titled
Subject: debug-pagealloc-add-support-for-highmem-pages-fix
has been removed from the -mm tree. Its filename was
debug-pagealloc-add-support-for-highmem-pages-fix.patch
This patch was dropped because it was folded into debug-pagealloc-add-support-for-highmem-pages.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: debug-pagealloc-add-support-for-highmem-pages-fix
remove unneeded preempt_disable/enable
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/debug-pagealloc.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff -puN mm/debug-pagealloc.c~debug-pagealloc-add-support-for-highmem-pages-fix mm/debug-pagealloc.c
--- a/mm/debug-pagealloc.c~debug-pagealloc-add-support-for-highmem-pages-fix
+++ a/mm/debug-pagealloc.c
@@ -23,14 +23,11 @@ static inline bool page_poison(struct pa
static void poison_page(struct page *page)
{
- void *addr;
+ void *addr = kmap_atomic(page);
- preempt_disable();
- addr = kmap_atomic(page);
set_page_poison(page);
memset(addr, PAGE_POISON, PAGE_SIZE);
kunmap_atomic(addr);
- preempt_enable();
}
static void poison_pages(struct page *page, int n)
@@ -82,12 +79,10 @@ static void unpoison_page(struct page *p
if (!page_poison(page))
return;
- preempt_disable();
addr = kmap_atomic(page);
check_poison_mem(addr, PAGE_SIZE);
clear_page_poison(page);
kunmap_atomic(addr);
- preempt_enable();
}
static void unpoison_pages(struct page *page, int n)
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
origin.patch
dma-mapping-fix-sync_single_range_-dma-debugging.patch
include-linux-dmarh-forward-declare-struct-acpi_dmar_header.patch
proc-self-numa_maps-restore-huge-tag-for-hugetlb-vmas.patch
mm-add-comments-to-explain-mm_struct-fields.patch
mm-avoid-null-pointer-access-in-vm_struct-via-proc-vmallocinfo.patch
thp-mremap-support-and-tlb-optimization.patch
mm-neaten-warn_alloc_failed.patch
debug-pagealloc-add-support-for-highmem-pages.patch
mm-add-comment-explaining-task-state-setting-in-bdi_forker_thread-fix.patch
mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix.patch
mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix.patch
kernel-sysctlc-add-cap_last_cap-to-proc-sys-kernel-fix.patch
drivers-leds-leds-lp5521c-check-if-reset-is-successful-fix.patch
lib-bitmapc-quiet-sparse-noise-about-address-space-fix.patch
llist-return-whether-list-is-empty-before-adding-in-llist_add-fix.patch
checkpatch-add-a-strict-check-for-utf-8-in-commit-logs.patch
^ permalink raw reply
* Re: [RFC PATCH] freezer: revert 27920651fe "PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too"
From: Steve French @ 2011-10-31 23:45 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Tejun Heo, Jeff Layton, Steve French, linux-kernel, Oleg Nesterov,
linux-pm, linux-cifs, J. Bruce Fields, Neil Brown
In-Reply-To: <201111010024.16659.rjw@sisk.pl>
On Mon, Oct 31, 2011 at 6:24 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday, October 31, 2011, Tejun Heo wrote:
>> Commit 27920651fe "PM / Freezer: Make fake_signal_wake_up() wake
>> TASK_KILLABLE tasks too" made freezer wake up tasks in TASK_KILLABLE
>> sleep too citing non-interruptible but killable sleeps in cifs and
>> nfs.
>>
>> I don't think we can do this. We should not send spurious unsolicited
>> non-interruptible wakeups. Most synchornization constructs are built
>> to cope with spurious wakeups and any INTERRUPTIBLE sleep must be able
>> to handle spurious wakeups but that's not true for KILLABLE sleeps -
>> KILLABLE condition cannot be cancelled.
>>
>> This is probably okay for most cases but circumventing fundamental
>> wakeup condition like this is asking for trouble. Furthermore, I'm
>> not sure the behavior change brought on by this change - breaking
>> nfs/cifs uninterruptible operation guarantee - is correct. If such
>> behavior is desirable, the right thing to do is using intr mount
>> option, not circumventing it from PM layer.
>
> Do you have any specific examples of breakage, or is it just that you _think_
> it's not quite right?
>
> One patch depending on that change has been merged already and I have two
> more in the queue, so I'd like to clarify this ASAP. Jeff, Steve?
>
>> Signed-off-by: Tejun Heo <tj@kernel.org>
>> Cc: Jeff Layton <jlayton@redhat.com>
>> ---
>> Neil, Steve, do the network filesystems need a way to indicate "I can
>> either be killed or enter freezer"?
Probably, yes, but I will defer to Jeff as he has looked
more recently at these issues.
I can explain cifs state, and disconnect/reconnection of sessions
(and smb2 is a little more feature rich in this regard), but will
let Jeff explain the more subtle points you are getting at.
--
Thanks,
Steve
^ permalink raw reply
* Re: [RFC PATCH] freezer: revert 27920651fe "PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too"
From: Steve French @ 2011-10-31 23:45 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Tejun Heo, Jeff Layton, Steve French,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Oleg Nesterov,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-cifs-u79uwXL29TY76Z2rM5mHXA, J. Bruce Fields, Neil Brown
In-Reply-To: <201111010024.16659.rjw-KKrjLPT3xs0@public.gmane.org>
On Mon, Oct 31, 2011 at 6:24 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Monday, October 31, 2011, Tejun Heo wrote:
>> Commit 27920651fe "PM / Freezer: Make fake_signal_wake_up() wake
>> TASK_KILLABLE tasks too" made freezer wake up tasks in TASK_KILLABLE
>> sleep too citing non-interruptible but killable sleeps in cifs and
>> nfs.
>>
>> I don't think we can do this. We should not send spurious unsolicited
>> non-interruptible wakeups. Most synchornization constructs are built
>> to cope with spurious wakeups and any INTERRUPTIBLE sleep must be able
>> to handle spurious wakeups but that's not true for KILLABLE sleeps -
>> KILLABLE condition cannot be cancelled.
>>
>> This is probably okay for most cases but circumventing fundamental
>> wakeup condition like this is asking for trouble. Furthermore, I'm
>> not sure the behavior change brought on by this change - breaking
>> nfs/cifs uninterruptible operation guarantee - is correct. If such
>> behavior is desirable, the right thing to do is using intr mount
>> option, not circumventing it from PM layer.
>
> Do you have any specific examples of breakage, or is it just that you _think_
> it's not quite right?
>
> One patch depending on that change has been merged already and I have two
> more in the queue, so I'd like to clarify this ASAP. Jeff, Steve?
>
>> Signed-off-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> Neil, Steve, do the network filesystems need a way to indicate "I can
>> either be killed or enter freezer"?
Probably, yes, but I will defer to Jeff as he has looked
more recently at these issues.
I can explain cifs state, and disconnect/reconnection of sessions
(and smb2 is a little more feature rich in this regard), but will
let Jeff explain the more subtle points you are getting at.
--
Thanks,
Steve
^ permalink raw reply
* [folded] mm-neaten-warn_alloc_failed-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:45 UTC (permalink / raw)
To: akpm, joe, mm-commits
The patch titled
Subject: mm-neaten-warn_alloc_failed-fix
has been removed from the -mm tree. Its filename was
mm-neaten-warn_alloc_failed-fix.patch
This patch was dropped because it was folded into mm-neaten-warn_alloc_failed.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm-neaten-warn_alloc_failed-fix
use the __printf() macro
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/mm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN include/linux/mm.h~mm-neaten-warn_alloc_failed-fix include/linux/mm.h
--- a/include/linux/mm.h~mm-neaten-warn_alloc_failed-fix
+++ a/include/linux/mm.h
@@ -1335,7 +1335,7 @@ extern void si_meminfo(struct sysinfo *
extern void si_meminfo_node(struct sysinfo *val, int nid);
extern int after_bootmem;
-extern __attribute__((format (printf, 3, 4)))
+extern __printf(3, 4)
void warn_alloc_failed(gfp_t gfp_mask, int order, const char *fmt, ...);
extern void setup_per_cpu_pageset(void);
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
origin.patch
dma-mapping-fix-sync_single_range_-dma-debugging.patch
include-linux-dmarh-forward-declare-struct-acpi_dmar_header.patch
proc-self-numa_maps-restore-huge-tag-for-hugetlb-vmas.patch
mm-add-comments-to-explain-mm_struct-fields.patch
mm-avoid-null-pointer-access-in-vm_struct-via-proc-vmallocinfo.patch
thp-mremap-support-and-tlb-optimization.patch
mm-neaten-warn_alloc_failed.patch
debug-pagealloc-add-support-for-highmem-pages-fix.patch
mm-add-comment-explaining-task-state-setting-in-bdi_forker_thread-fix.patch
mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix.patch
mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix.patch
kernel-sysctlc-add-cap_last_cap-to-proc-sys-kernel-fix.patch
drivers-leds-leds-lp5521c-check-if-reset-is-successful-fix.patch
lib-bitmapc-quiet-sparse-noise-about-address-space-fix.patch
llist-return-whether-list-is-empty-before-adding-in-llist_add-fix.patch
checkpatch-add-a-strict-check-for-utf-8-in-commit-logs.patch
^ permalink raw reply
* [folded] thp-mremap-support-and-tlb-optimization-fix-fix-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:43 UTC (permalink / raw)
To: aarcange, mm-commits
The patch titled
Subject: thp-mremap-support-and-tlb-optimization-fix-fix-fix
has been removed from the -mm tree. Its filename was
thp-mremap-support-and-tlb-optimization-fix-fix-fix.patch
This patch was dropped because it was folded into thp-mremap-support-and-tlb-optimization.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Andrea Arcangeli <aarcange@redhat.com>
Subject: thp-mremap-support-and-tlb-optimization-fix-fix-fix
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/huge_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/huge_memory.c~thp-mremap-support-and-tlb-optimization-fix-fix-fix mm/huge_memory.c
--- a/mm/huge_memory.c~thp-mremap-support-and-tlb-optimization-fix-fix-fix
+++ a/mm/huge_memory.c
@@ -1064,7 +1064,7 @@ int move_huge_pmd(struct vm_area_struct
if ((old_addr & ~HPAGE_PMD_MASK) ||
(new_addr & ~HPAGE_PMD_MASK) ||
- (old_addr + HPAGE_PMD_SIZE) > old_end ||
+ old_end - old_addr < HPAGE_PMD_SIZE ||
(new_vma->vm_flags & VM_NOHUGEPAGE))
goto out;
_
Patches currently in -mm which might be from aarcange@redhat.com are
origin.patch
mm-compaction-trivial-clean-up-in-acct_isolated.patch
mm-change-isolate-mode-from-define-to-bitwise-type.patch
mm-compaction-make-isolate_lru_page-filter-aware.patch
mm-zone_reclaim-make-isolate_lru_page-filter-aware.patch
mm-migration-clean-up-unmap_and_move.patch
mremap-check-for-overflow-using-deltas.patch
mremap-avoid-sending-one-ipi-per-page.patch
thp-mremap-support-and-tlb-optimization.patch
mm-mempolicyc-quiet-sparse-noise.patch
mm-huge_memoryc-quiet-sparse-noise.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations-fix.patch
vmscan-abort-reclaim-compaction-if-compaction-can-proceed.patch
mm-huge_memory-fix-copying-user-highpage.patch
mm-huge_memory-fix-typo-when-updating-mmu-cache.patch
^ permalink raw reply
* [folded] thp-mremap-support-and-tlb-optimization-fix-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:43 UTC (permalink / raw)
To: akpm, aarcange, hughd, jweiner, mgorman, riel, mm-commits
The patch titled
Subject: thp-mremap-support-and-tlb-optimization-fix-fix
has been removed from the -mm tree. Its filename was
thp-mremap-support-and-tlb-optimization-fix-fix.patch
This patch was dropped because it was folded into thp-mremap-support-and-tlb-optimization.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: thp-mremap-support-and-tlb-optimization-fix-fix
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/huge_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/huge_memory.c~thp-mremap-support-and-tlb-optimization-fix-fix mm/huge_memory.c
--- a/mm/huge_memory.c~thp-mremap-support-and-tlb-optimization-fix-fix
+++ a/mm/huge_memory.c
@@ -1072,7 +1072,7 @@ int move_huge_pmd(struct vm_area_struct
* The destination pmd shouldn't be established, free_pgtables()
* should have release it.
*/
- if (!WARN_ON(pmd_none(*new_pmd))) {
+ if (WARN_ON(!pmd_none(*new_pmd))) {
VM_BUG_ON(pmd_trans_huge(*new_pmd));
goto out;
}
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
origin.patch
dma-mapping-fix-sync_single_range_-dma-debugging.patch
include-linux-dmarh-forward-declare-struct-acpi_dmar_header.patch
proc-self-numa_maps-restore-huge-tag-for-hugetlb-vmas.patch
mm-add-comments-to-explain-mm_struct-fields.patch
mm-avoid-null-pointer-access-in-vm_struct-via-proc-vmallocinfo.patch
thp-mremap-support-and-tlb-optimization.patch
mm-neaten-warn_alloc_failed-fix.patch
debug-pagealloc-add-support-for-highmem-pages-fix.patch
mm-add-comment-explaining-task-state-setting-in-bdi_forker_thread-fix.patch
mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix.patch
mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix.patch
kernel-sysctlc-add-cap_last_cap-to-proc-sys-kernel-fix.patch
drivers-leds-leds-lp5521c-check-if-reset-is-successful-fix.patch
lib-bitmapc-quiet-sparse-noise-about-address-space-fix.patch
llist-return-whether-list-is-empty-before-adding-in-llist_add-fix.patch
checkpatch-add-a-strict-check-for-utf-8-in-commit-logs.patch
^ permalink raw reply
* [folded] thp-mremap-support-and-tlb-optimization-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:43 UTC (permalink / raw)
To: akpm, aarcange, hughd, jweiner, mgorman, riel, mm-commits
The patch titled
Subject: thp-mremap-support-and-tlb-optimization-fix
has been removed from the -mm tree. Its filename was
thp-mremap-support-and-tlb-optimization-fix.patch
This patch was dropped because it was folded into thp-mremap-support-and-tlb-optimization.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: thp-mremap-support-and-tlb-optimization-fix
coding-style nitpicking
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/huge_memory.c | 9 ++++-----
mm/mremap.c | 6 +++---
2 files changed, 7 insertions(+), 8 deletions(-)
diff -puN mm/huge_memory.c~thp-mremap-support-and-tlb-optimization-fix mm/huge_memory.c
--- a/mm/huge_memory.c~thp-mremap-support-and-tlb-optimization-fix
+++ a/mm/huge_memory.c
@@ -1065,15 +1065,14 @@ int move_huge_pmd(struct vm_area_struct
if ((old_addr & ~HPAGE_PMD_MASK) ||
(new_addr & ~HPAGE_PMD_MASK) ||
(old_addr + HPAGE_PMD_SIZE) > old_end ||
- new_vma->vm_flags & VM_NOHUGEPAGE)
+ (new_vma->vm_flags & VM_NOHUGEPAGE))
goto out;
/*
* The destination pmd shouldn't be established, free_pgtables()
* should have release it.
*/
- if (!pmd_none(*new_pmd)) {
- WARN_ON(1);
+ if (!WARN_ON(pmd_none(*new_pmd))) {
VM_BUG_ON(pmd_trans_huge(*new_pmd));
goto out;
}
@@ -1091,9 +1090,9 @@ int move_huge_pmd(struct vm_area_struct
spin_unlock(&mm->page_table_lock);
ret = 1;
}
- } else
+ } else {
spin_unlock(&mm->page_table_lock);
-
+ }
out:
return ret;
}
diff -puN mm/mremap.c~thp-mremap-support-and-tlb-optimization-fix mm/mremap.c
--- a/mm/mremap.c~thp-mremap-support-and-tlb-optimization-fix
+++ a/mm/mremap.c
@@ -155,13 +155,13 @@ unsigned long move_page_tables(struct vm
if (err > 0) {
need_flush = true;
continue;
- } else if (!err)
+ } else if (!err) {
split_huge_page_pmd(vma->vm_mm, old_pmd);
+ }
VM_BUG_ON(pmd_trans_huge(*old_pmd));
}
if (pmd_none(*new_pmd) && __pte_alloc(new_vma->vm_mm, new_vma,
- new_pmd,
- new_addr))
+ new_pmd, new_addr))
break;
next = (new_addr + PMD_SIZE) & PMD_MASK;
if (extent > next - new_addr)
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
origin.patch
dma-mapping-fix-sync_single_range_-dma-debugging.patch
include-linux-dmarh-forward-declare-struct-acpi_dmar_header.patch
proc-self-numa_maps-restore-huge-tag-for-hugetlb-vmas.patch
mm-add-comments-to-explain-mm_struct-fields.patch
mm-avoid-null-pointer-access-in-vm_struct-via-proc-vmallocinfo.patch
thp-mremap-support-and-tlb-optimization.patch
thp-mremap-support-and-tlb-optimization-fix-fix.patch
mm-neaten-warn_alloc_failed-fix.patch
debug-pagealloc-add-support-for-highmem-pages-fix.patch
mm-add-comment-explaining-task-state-setting-in-bdi_forker_thread-fix.patch
mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix.patch
mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix.patch
kernel-sysctlc-add-cap_last_cap-to-proc-sys-kernel-fix.patch
drivers-leds-leds-lp5521c-check-if-reset-is-successful-fix.patch
lib-bitmapc-quiet-sparse-noise-about-address-space-fix.patch
llist-return-whether-list-is-empty-before-adding-in-llist_add-fix.patch
checkpatch-add-a-strict-check-for-utf-8-in-commit-logs.patch
^ permalink raw reply
* Re: [PATCH] Btrfs: introduce mount option no_space_cache
From: David Sterba @ 2011-10-31 23:42 UTC (permalink / raw)
To: Josef Bacik, linux-btrfs; +Cc: chris.mason
In-Reply-To: <20111003215130.GN22205@twin.jikos.cz>
Hi Josef,
On Mon, Oct 03, 2011 at 11:51:30PM +0200, David Sterba wrote:
> > --- a/fs/btrfs/super.c
> > +++ b/fs/btrfs/super.c
> > @@ -164,7 +164,7 @@ enum {
> > Opt_notreelog, Opt_ratio, Opt_flushoncommit, Opt_discard,
> > Opt_space_cache, Opt_clear_cache, Opt_user_subvol_rm_allowed,
> > Opt_enospc_debug, Opt_subvolrootid, Opt_defrag,
> > - Opt_inode_cache, Opt_err,
> > + Opt_inode_cache, Opt_no_space_cache, Opt_err,
>
> how about _not_ adding a new optoin and just extend the existing one:
>
> space_cache=off
Thanks for fixing the patch in your tree, however adding the 'no' prefix
seems more in line with other options and their disabling counterparts
(like ssd/nossd, more to come).
I would have asked you to consider changing it to 'nospace_cache' and
refreshing the patch, but it's deep inside your for-chris branch so I'll
rather send patch if there aren't objections voiced.
thanks,
david
^ permalink raw reply
* [folded] lib-stringc-introduce-memchr_inv-fix-kernel-doc-for-memchr_inv.patch removed from -mm tree
From: akpm @ 2011-10-31 23:42 UTC (permalink / raw)
To: akinobu.mita, cl, geert, mm-commits
The patch titled
Subject: lib-stringc-introduce-memchr_inv-fix-kernel-doc-for-memchr_inv
has been removed from the -mm tree. Its filename was
lib-stringc-introduce-memchr_inv-fix-kernel-doc-for-memchr_inv.patch
This patch was dropped because it was folded into lib-stringc-introduce-memchr_inv.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Akinobu Mita <akinobu.mita@gmail.com>
Subject: lib-stringc-introduce-memchr_inv-fix-kernel-doc-for-memchr_inv
This fixes kernel-doc for memchr_inv() which is introduced by
lib-stringc-introduce-memchr_inv.patch in mmotm 2011-08-24-14-08
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/string.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff -puN lib/string.c~lib-stringc-introduce-memchr_inv-fix-kernel-doc-for-memchr_inv lib/string.c
--- a/lib/string.c~lib-stringc-introduce-memchr_inv-fix-kernel-doc-for-memchr_inv
+++ a/lib/string.c
@@ -769,10 +769,10 @@ static void *check_bytes8(const u8 *star
}
/**
- * memchr_inv - Find a character in an area of memory.
- * @s: The memory area
- * @c: The byte to search for
- * @n: The size of the area.
+ * memchr_inv - Find an unmatching character in an area of memory.
+ * @start: The memory area
+ * @c: Find a character other than c
+ * @bytes: The size of the area.
*
* returns the address of the first character other than @c, or %NULL
* if the whole buffer contains just @c.
_
Patches currently in -mm which might be from akinobu.mita@gmail.com are
origin.patch
mm-debug-pageallocc-use-plain-__ratelimit-instead-of-printk_ratelimit.patch
lib-stringc-introduce-memchr_inv.patch
mm-debug-pageallocc-use-memchr_inv.patch
debug-pagealloc-add-support-for-highmem-pages.patch
debug-pagealloc-add-support-for-highmem-pages-fix.patch
spinlock_debug-print-owner-on-spinlock-lockup.patch
^ permalink raw reply
* Question on CDROM access
From: sahlot arvind @ 2011-10-31 23:42 UTC (permalink / raw)
To: kernelnewbies
Hi,
I am running Ubuntu 11.10 and my CDROM drive's LED keeps blinking. I want
to know which process is accessing CDROM for no reasons. There is no media
in the drive, I believe OS seems to access it for media change events, but
I am more interested in which process or deamon is actually doing it.
I tried the followings and nothing gave anything:
'lsof | grep -in 'cdrom'
'lsof | grep -in 'sr0'
'lsof | grep -in 'sg0'
What tools could I use to track down the process, which is accessing my CD
drive?
Thanks in advance.
Asahlot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111031/f67e3442/attachment.html
^ permalink raw reply
* [folded] mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback-update.patch removed from -mm tree
From: akpm @ 2011-10-31 23:42 UTC (permalink / raw)
To: mgorman, mm-commits
The patch titled
Subject: mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback-update
has been removed from the -mm tree. Its filename was
mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback-update.patch
This patch was dropped because it was folded into mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Mel Gorman <mgorman@suse.de>
Subject: mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback-update
This patch expands on a comment on how we throttle from reclaim context.
It should be merged with
mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback.patch
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/vmscan.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff -puN mm/vmscan.c~mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback-update mm/vmscan.c
--- a/mm/vmscan.c~mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback-update
+++ a/mm/vmscan.c
@@ -1538,11 +1538,27 @@ shrink_inactive_list(unsigned long nr_to
putback_lru_pages(zone, sc, nr_anon, nr_file, &page_list);
/*
- * If we have encountered a high number of dirty pages under writeback
- * then we are reaching the end of the LRU too quickly and global
- * limits are not enough to throttle processes due to the page
- * distribution throughout zones. Scale the number of dirty pages that
- * must be under writeback before being throttled to priority.
+ * If reclaim is isolating dirty pages under writeback, it implies
+ * that the long-lived page allocation rate is exceeding the page
+ * laundering rate. Either the global limits are not being effective
+ * at throttling processes due to the page distribution throughout
+ * zones or there is heavy usage of a slow backing device. The
+ * only option is to throttle from reclaim context which is not ideal
+ * as there is no guarantee the dirtying process is throttled in the
+ * same way balance_dirty_pages() manages.
+ *
+ * This scales the number of dirty pages that must be under writeback
+ * before throttling depending on priority. It is a simple backoff
+ * function that has the most effect in the range DEF_PRIORITY to
+ * DEF_PRIORITY-2 which is the priority reclaim is considered to be
+ * in trouble and reclaim is considered to be in trouble.
+ *
+ * DEF_PRIORITY 100% isolated pages must be PageWriteback to throttle
+ * DEF_PRIORITY-1 50% must be PageWriteback
+ * DEF_PRIORITY-2 25% must be PageWriteback, kswapd in trouble
+ * ...
+ * DEF_PRIORITY-6 For SWAP_CLUSTER_MAX isolated pages, throttle if any
+ * isolated page is PageWriteback
*/
if (nr_writeback && nr_writeback >= (nr_taken >> (DEF_PRIORITY-priority)))
wait_iff_congested(zone, BLK_RW_ASYNC, HZ/10);
_
Patches currently in -mm which might be from mgorman@suse.de are
origin.patch
mm-compaction-trivial-clean-up-in-acct_isolated.patch
mm-change-isolate-mode-from-define-to-bitwise-type.patch
mm-compaction-make-isolate_lru_page-filter-aware.patch
mm-zone_reclaim-make-isolate_lru_page-filter-aware.patch
mm-migration-clean-up-unmap_and_move.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-direct-reclaim.patch
mm-vmscan-remove-dead-code-related-to-lumpy-reclaim-waiting-on-pages-under-writeback.patch
xfs-warn-if-direct-reclaim-tries-to-writeback-pages.patch
ext4-warn-if-direct-reclaim-tries-to-writeback-pages.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-kswapd-except-in-high-priority.patch
mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback.patch
mm-vmscan-immediately-reclaim-end-of-lru-dirty-pages-when-writeback-completes.patch
vmscan-count-pages-into-balanced-for-zone-with-good-watermark.patch
mremap-check-for-overflow-using-deltas.patch
mremap-avoid-sending-one-ipi-per-page.patch
thp-mremap-support-and-tlb-optimization.patch
thp-mremap-support-and-tlb-optimization-fix.patch
thp-mremap-support-and-tlb-optimization-fix-fix.patch
kswapd-avoid-unnecessary-rebalance-after-an-unsuccessful-balancing.patch
kswapd-assign-new_order-and-new_classzone_idx-after-wakeup-in-sleeping.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations-fix.patch
vmscan-abort-reclaim-compaction-if-compaction-can-proceed.patch
^ permalink raw reply
* [folded] mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:41 UTC (permalink / raw)
To: minchan.kim, aarcange, hannes, kamezawa.hiroyu, kosaki.motohiro,
mgorman, mhocko, riel, mm-co
The patch titled
Subject: mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix
has been removed from the -mm tree. Its filename was
mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix.patch
This patch was dropped because it was folded into mm-zone_reclaim-make-isolate_lru_page-filter-aware.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Minchan Kim <minchan.kim@gmail.com>
Subject: mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/mmzone.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN include/linux/mmzone.h~mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix include/linux/mmzone.h
--- a/include/linux/mmzone.h~mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix
+++ a/include/linux/mmzone.h
@@ -171,7 +171,7 @@ static inline int is_unevictable_lru(enu
/* Isolate clean file */
#define ISOLATE_CLEAN ((__force isolate_mode_t)0x4)
/* Isolate unmapped file */
-#define ISOLATE_UNMAPPED ((__force fmode_t)0x8)
+#define ISOLATE_UNMAPPED ((__force isolate_mode_t)0x8)
/* LRU Isolation modes. */
typedef unsigned __bitwise__ isolate_mode_t;
_
Patches currently in -mm which might be from minchan.kim@gmail.com are
mm-compaction-trivial-clean-up-in-acct_isolated.patch
mm-change-isolate-mode-from-define-to-bitwise-type.patch
mm-compaction-make-isolate_lru_page-filter-aware.patch
mm-zone_reclaim-make-isolate_lru_page-filter-aware.patch
mm-migration-clean-up-unmap_and_move.patch
vmscan-add-block-plug-for-page-reclaim.patch
mm-vmscan-drop-nr_force_scan-from-get_scan_count.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-direct-reclaim.patch
mm-vmscan-remove-dead-code-related-to-lumpy-reclaim-waiting-on-pages-under-writeback.patch
xfs-warn-if-direct-reclaim-tries-to-writeback-pages.patch
ext4-warn-if-direct-reclaim-tries-to-writeback-pages.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-kswapd-except-in-high-priority.patch
mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback.patch
mm-vmscan-immediately-reclaim-end-of-lru-dirty-pages-when-writeback-completes.patch
vmscan-count-pages-into-balanced-for-zone-with-good-watermark.patch
kswapd-assign-new_order-and-new_classzone_idx-after-wakeup-in-sleeping.patch
mm-compaction-make-compact_zone_order-static.patch
mm-disable-user-interface-to-manually-rescue-unevictable-pages.patch
vmscan-add-barrier-to-prevent-evictable-page-in-unevictable-list.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations-fix.patch
vmscan-abort-reclaim-compaction-if-compaction-can-proceed.patch
mm-do-not-drain-pagevecs-for-mlockallmcl_future.patch
^ permalink raw reply
* [folded] mm-compaction-make-isolate_lru_page-filter-aware-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:40 UTC (permalink / raw)
To: minchan.kim, aarcange, hannes, kamezawa.hiroyu, kosaki.motohiro,
mgorman, mhocko, riel, mm-co
The patch titled
Subject: mm-compaction-make-isolate_lru_page-filter-aware-fix
has been removed from the -mm tree. Its filename was
mm-compaction-make-isolate_lru_page-filter-aware-fix.patch
This patch was dropped because it was folded into mm-compaction-make-isolate_lru_page-filter-aware.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Minchan Kim <minchan.kim@gmail.com>
Subject: mm-compaction-make-isolate_lru_page-filter-aware-fix
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/mmzone.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN include/linux/mmzone.h~mm-compaction-make-isolate_lru_page-filter-aware-fix include/linux/mmzone.h
--- a/include/linux/mmzone.h~mm-compaction-make-isolate_lru_page-filter-aware-fix
+++ a/include/linux/mmzone.h
@@ -169,7 +169,7 @@ static inline int is_unevictable_lru(enu
/* Isolate active pages */
#define ISOLATE_ACTIVE ((__force isolate_mode_t)0x2)
/* Isolate clean file */
-#define ISOLATE_CLEAN ((__force fmode_t)0x4)
+#define ISOLATE_CLEAN ((__force isolate_mode_t)0x4)
/* LRU Isolation modes. */
typedef unsigned __bitwise__ isolate_mode_t;
_
Patches currently in -mm which might be from minchan.kim@gmail.com are
mm-compaction-trivial-clean-up-in-acct_isolated.patch
mm-change-isolate-mode-from-define-to-bitwise-type.patch
mm-compaction-make-isolate_lru_page-filter-aware.patch
mm-zone_reclaim-make-isolate_lru_page-filter-aware.patch
mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix.patch
mm-migration-clean-up-unmap_and_move.patch
vmscan-add-block-plug-for-page-reclaim.patch
mm-vmscan-drop-nr_force_scan-from-get_scan_count.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-direct-reclaim.patch
mm-vmscan-remove-dead-code-related-to-lumpy-reclaim-waiting-on-pages-under-writeback.patch
xfs-warn-if-direct-reclaim-tries-to-writeback-pages.patch
ext4-warn-if-direct-reclaim-tries-to-writeback-pages.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-kswapd-except-in-high-priority.patch
mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback.patch
mm-vmscan-immediately-reclaim-end-of-lru-dirty-pages-when-writeback-completes.patch
vmscan-count-pages-into-balanced-for-zone-with-good-watermark.patch
kswapd-assign-new_order-and-new_classzone_idx-after-wakeup-in-sleeping.patch
mm-compaction-make-compact_zone_order-static.patch
mm-disable-user-interface-to-manually-rescue-unevictable-pages.patch
vmscan-add-barrier-to-prevent-evictable-page-in-unevictable-list.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations-fix.patch
vmscan-abort-reclaim-compaction-if-compaction-can-proceed.patch
mm-do-not-drain-pagevecs-for-mlockallmcl_future.patch
^ permalink raw reply
* [folded] mm-add-comments-to-explain-mm_struct-fields-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:41 UTC (permalink / raw)
To: akpm, cl, mm-commits
The patch titled
Subject: mm-add-comments-to-explain-mm_struct-fields-fix
has been removed from the -mm tree. Its filename was
mm-add-comments-to-explain-mm_struct-fields-fix.patch
This patch was dropped because it was folded into mm-add-comments-to-explain-mm_struct-fields.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm-add-comments-to-explain-mm_struct-fields-fix
add missing ;
Cc: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/mm_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN include/linux/mm_types.h~mm-add-comments-to-explain-mm_struct-fields-fix include/linux/mm_types.h
--- a/include/linux/mm_types.h~mm-add-comments-to-explain-mm_struct-fields-fix
+++ a/include/linux/mm_types.h
@@ -294,7 +294,7 @@ struct mm_struct {
unsigned long hiwater_vm; /* High-water virtual memory usage */
unsigned long total_vm; /* Total pages mapped */
- unsigned long locked_vm /* Pages that have PG_mlocked set */
+ unsigned long locked_vm; /* Pages that have PG_mlocked set */
unsigned long pinned_vm; /* Refcount permanently increased */
unsigned long shared_vm; /* Shared pages (files) */
unsigned long exec_vm; /* VM_EXEC & ~VM_WRITE */
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
origin.patch
dma-mapping-fix-sync_single_range_-dma-debugging.patch
include-linux-dmarh-forward-declare-struct-acpi_dmar_header.patch
proc-self-numa_maps-restore-huge-tag-for-hugetlb-vmas.patch
mm-add-comments-to-explain-mm_struct-fields.patch
mm-avoid-null-pointer-access-in-vm_struct-via-proc-vmallocinfo.patch
thp-mremap-support-and-tlb-optimization-fix.patch
thp-mremap-support-and-tlb-optimization-fix-fix.patch
mm-neaten-warn_alloc_failed-fix.patch
debug-pagealloc-add-support-for-highmem-pages-fix.patch
mm-add-comment-explaining-task-state-setting-in-bdi_forker_thread-fix.patch
mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix.patch
mm-munlock-use-mapcount-to-avoid-terrible-overhead-fix.patch
kernel-sysctlc-add-cap_last_cap-to-proc-sys-kernel-fix.patch
drivers-leds-leds-lp5521c-check-if-reset-is-successful-fix.patch
lib-bitmapc-quiet-sparse-noise-about-address-space-fix.patch
llist-return-whether-list-is-empty-before-adding-in-llist_add-fix.patch
checkpatch-add-a-strict-check-for-utf-8-in-commit-logs.patch
^ permalink raw reply
* Re: [bisected] i915 dpms does not switch back light on
From: Alex Davis @ 2011-10-31 23:41 UTC (permalink / raw)
To: Wouter M. Koolen; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <4EAEA93A.9010100@science.uva.nl>
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
>> index 6f56676..a9e0c7b 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -262,6 +262,8 @@ void intel_panel_disable_backlight(struct drm_device *dev)
>> dev_priv->backlight_level = intel_panel_get_backlight(dev);
>> dev_priv->backlight_enabled = false;
>> }
>> +
>> + intel_panel_set_backlight(dev, 0);
>> }
>> void intel_panel_enable_backlight(struct drm_device *dev)
>Hi Alex,
>
>That indeed solves the problem here.
>
>Thanks for your swift response.
>
>Wouter
Actually, I sent you the wrong patch: the patch was supposed to remove those lines, not add them.
^ permalink raw reply
* [folded] mm-change-isolate-mode-from-define-to-bitwise-type-fix.patch removed from -mm tree
From: akpm @ 2011-10-31 23:40 UTC (permalink / raw)
To: minchan.kim, jweiner, mgorman, riel, mm-commits
The patch titled
Subject: mm-change-isolate-mode-from-define-to-bitwise-type-fix
has been removed from the -mm tree. Its filename was
mm-change-isolate-mode-from-define-to-bitwise-type-fix.patch
This patch was dropped because it was folded into mm-change-isolate-mode-from-define-to-bitwise-type.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Minchan Kim <minchan.kim@gmail.com>
Subject: mm-change-isolate-mode-from-define-to-bitwise-type-fix
[c1e8b0ae8, mm-change-isolate-mode-from-define-to-bitwise-type]
made a mistake on the bitwise type.
This patch corrects it.
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <jweiner@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/mmzone.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN include/linux/mmzone.h~mm-change-isolate-mode-from-define-to-bitwise-type-fix include/linux/mmzone.h
--- a/include/linux/mmzone.h~mm-change-isolate-mode-from-define-to-bitwise-type-fix
+++ a/include/linux/mmzone.h
@@ -165,9 +165,9 @@ static inline int is_unevictable_lru(enu
#define LRU_ALL ((1 << NR_LRU_LISTS) - 1)
/* Isolate inactive pages */
-#define ISOLATE_INACTIVE ((__force fmode_t)0x1)
+#define ISOLATE_INACTIVE ((__force isolate_mode_t)0x1)
/* Isolate active pages */
-#define ISOLATE_ACTIVE ((__force fmode_t)0x2)
+#define ISOLATE_ACTIVE ((__force isolate_mode_t)0x2)
/* LRU Isolation modes. */
typedef unsigned __bitwise__ isolate_mode_t;
_
Patches currently in -mm which might be from minchan.kim@gmail.com are
mm-compaction-trivial-clean-up-in-acct_isolated.patch
mm-change-isolate-mode-from-define-to-bitwise-type.patch
mm-compaction-make-isolate_lru_page-filter-aware.patch
mm-compaction-make-isolate_lru_page-filter-aware-fix.patch
mm-zone_reclaim-make-isolate_lru_page-filter-aware.patch
mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix.patch
mm-migration-clean-up-unmap_and_move.patch
vmscan-add-block-plug-for-page-reclaim.patch
mm-vmscan-drop-nr_force_scan-from-get_scan_count.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-direct-reclaim.patch
mm-vmscan-remove-dead-code-related-to-lumpy-reclaim-waiting-on-pages-under-writeback.patch
xfs-warn-if-direct-reclaim-tries-to-writeback-pages.patch
ext4-warn-if-direct-reclaim-tries-to-writeback-pages.patch
mm-vmscan-do-not-writeback-filesystem-pages-in-kswapd-except-in-high-priority.patch
mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback.patch
mm-vmscan-immediately-reclaim-end-of-lru-dirty-pages-when-writeback-completes.patch
vmscan-count-pages-into-balanced-for-zone-with-good-watermark.patch
kswapd-assign-new_order-and-new_classzone_idx-after-wakeup-in-sleeping.patch
mm-compaction-make-compact_zone_order-static.patch
mm-disable-user-interface-to-manually-rescue-unevictable-pages.patch
vmscan-add-barrier-to-prevent-evictable-page-in-unevictable-list.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations.patch
vmscan-limit-direct-reclaim-for-higher-order-allocations-fix.patch
vmscan-abort-reclaim-compaction-if-compaction-can-proceed.patch
mm-do-not-drain-pagevecs-for-mlockallmcl_future.patch
^ permalink raw reply
* [folded] cross-memory-attach-v4.patch removed from -mm tree
From: akpm @ 2011-10-31 23:39 UTC (permalink / raw)
To: cyeoh, arnd, benh, dhowells, hpa, jmorris, linux-arch, linux-man,
mingo
The patch titled
Subject: cross-memory-attach-v4
has been removed from the -mm tree. Its filename was
cross-memory-attach-v4.patch
This patch was dropped because it was folded into cross-memory-attach-v3.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Christopher Yeoh <cyeoh@au1.ibm.com>
Subject: cross-memory-attach-v4
> You might get some speed benefit by optimising for the small copies
> here. Define a local on-stack array of N page*'s and point
> process_pages at that if the number of pages is <= N. Saves a
> malloc/free and is more cache-friendly. But only if the result is
> measurable!
I have done some benchmarking on this, and it gains about 5-7% on a
microbenchmark with 4kb size copies and about a 1% gain with a more
realistic (but modified for smaller copies) hpcc benchmark. The
performance gain disappears into the noise by about 64kb sized copies.
No measurable overhead for larger copies. So I think its worth including
Included below is the patch (based on v4) - for ease of review the first diff
is just against the latest version of CMA which has been posted here previously.
The second is the entire CMA patch.
Signed-off-by: Chris Yeoh <cyeoh@au1.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: <linux-man@vger.kernel.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/process_vm_access.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff -puN mm/process_vm_access.c~cross-memory-attach-v4 mm/process_vm_access.c
--- a/mm/process_vm_access.c~cross-memory-attach-v4
+++ a/mm/process_vm_access.c
@@ -221,6 +221,10 @@ static int process_vm_rw_single_vec(unsi
return rc;
}
+/* Maximum number of entries for process pages array
+ which lives on stack */
+#define PVM_MAX_PP_ARRAY_COUNT 16
+
/**
* process_vm_rw_core - core of reading/writing pages from task specified
* @pid: PID of process to read/write from/to
@@ -241,7 +245,8 @@ static ssize_t process_vm_rw_core(pid_t
unsigned long flags, int vm_write)
{
struct task_struct *task;
- struct page **process_pages = NULL;
+ struct page *pp_stack[PVM_MAX_PP_ARRAY_COUNT];
+ struct page **process_pages = pp_stack;
struct mm_struct *mm;
unsigned long i;
ssize_t rc = 0;
@@ -271,13 +276,16 @@ static ssize_t process_vm_rw_core(pid_t
if (nr_pages == 0)
return 0;
- /* For reliability don't try to kmalloc more than 2 pages worth */
- process_pages = kmalloc(min_t(size_t, PVM_MAX_KMALLOC_PAGES,
- sizeof(struct pages *)*nr_pages),
- GFP_KERNEL);
+ if (nr_pages > PVM_MAX_PP_ARRAY_COUNT) {
+ /* For reliability don't try to kmalloc more than
+ 2 pages worth */
+ process_pages = kmalloc(min_t(size_t, PVM_MAX_KMALLOC_PAGES,
+ sizeof(struct pages *)*nr_pages),
+ GFP_KERNEL);
- if (!process_pages)
- return -ENOMEM;
+ if (!process_pages)
+ return -ENOMEM;
+ }
/* Get process information */
rcu_read_lock();
@@ -331,7 +339,8 @@ put_task_struct:
put_task_struct(task);
free_proc_pages:
- kfree(process_pages);
+ if (process_pages != pp_stack)
+ kfree(process_pages);
return rc;
}
_
Patches currently in -mm which might be from cyeoh@au1.ibm.com are
cross-memory-attach-v3.patch
^ permalink raw reply
* [folded] cross-memory-attach-v4.patch removed from -mm tree
From: akpm @ 2011-10-31 23:39 UTC (permalink / raw)
To: cyeoh, arnd, benh, dhowells, hpa, jmorris, linux-arch, linux-man,
mingo, paulus, tglx, mm-commits
The patch titled
Subject: cross-memory-attach-v4
has been removed from the -mm tree. Its filename was
cross-memory-attach-v4.patch
This patch was dropped because it was folded into cross-memory-attach-v3.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Christopher Yeoh <cyeoh@au1.ibm.com>
Subject: cross-memory-attach-v4
> You might get some speed benefit by optimising for the small copies
> here. Define a local on-stack array of N page*'s and point
> process_pages at that if the number of pages is <= N. Saves a
> malloc/free and is more cache-friendly. But only if the result is
> measurable!
I have done some benchmarking on this, and it gains about 5-7% on a
microbenchmark with 4kb size copies and about a 1% gain with a more
realistic (but modified for smaller copies) hpcc benchmark. The
performance gain disappears into the noise by about 64kb sized copies.
No measurable overhead for larger copies. So I think its worth including
Included below is the patch (based on v4) - for ease of review the first diff
is just against the latest version of CMA which has been posted here previously.
The second is the entire CMA patch.
Signed-off-by: Chris Yeoh <cyeoh@au1.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: <linux-man@vger.kernel.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/process_vm_access.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff -puN mm/process_vm_access.c~cross-memory-attach-v4 mm/process_vm_access.c
--- a/mm/process_vm_access.c~cross-memory-attach-v4
+++ a/mm/process_vm_access.c
@@ -221,6 +221,10 @@ static int process_vm_rw_single_vec(unsi
return rc;
}
+/* Maximum number of entries for process pages array
+ which lives on stack */
+#define PVM_MAX_PP_ARRAY_COUNT 16
+
/**
* process_vm_rw_core - core of reading/writing pages from task specified
* @pid: PID of process to read/write from/to
@@ -241,7 +245,8 @@ static ssize_t process_vm_rw_core(pid_t
unsigned long flags, int vm_write)
{
struct task_struct *task;
- struct page **process_pages = NULL;
+ struct page *pp_stack[PVM_MAX_PP_ARRAY_COUNT];
+ struct page **process_pages = pp_stack;
struct mm_struct *mm;
unsigned long i;
ssize_t rc = 0;
@@ -271,13 +276,16 @@ static ssize_t process_vm_rw_core(pid_t
if (nr_pages == 0)
return 0;
- /* For reliability don't try to kmalloc more than 2 pages worth */
- process_pages = kmalloc(min_t(size_t, PVM_MAX_KMALLOC_PAGES,
- sizeof(struct pages *)*nr_pages),
- GFP_KERNEL);
+ if (nr_pages > PVM_MAX_PP_ARRAY_COUNT) {
+ /* For reliability don't try to kmalloc more than
+ 2 pages worth */
+ process_pages = kmalloc(min_t(size_t, PVM_MAX_KMALLOC_PAGES,
+ sizeof(struct pages *)*nr_pages),
+ GFP_KERNEL);
- if (!process_pages)
- return -ENOMEM;
+ if (!process_pages)
+ return -ENOMEM;
+ }
/* Get process information */
rcu_read_lock();
@@ -331,7 +339,8 @@ put_task_struct:
put_task_struct(task);
free_proc_pages:
- kfree(process_pages);
+ if (process_pages != pp_stack)
+ kfree(process_pages);
return rc;
}
_
Patches currently in -mm which might be from cyeoh@au1.ibm.com are
cross-memory-attach-v3.patch
^ permalink raw reply
* [folded] cross-memory-attach-update.patch removed from -mm tree
From: akpm @ 2011-10-31 23:39 UTC (permalink / raw)
To: cyeoh, hpa, mingo, rdunlap, tglx, mm-commits
The patch titled
Subject: cross-memory-attach-update
has been removed from the -mm tree. Its filename was
cross-memory-attach-update.patch
This patch was dropped because it was folded into cross-memory-attach-v3.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Christopher Yeoh <cyeoh@au1.ibm.com>
Subject: cross-memory-attach-update
- Add x86_64 specific wire up
- Change behaviour so process_vm_readv and process_vm_writev return
the number of bytes successfully read or written even if an error
occurs
- Add more kernel doc interface comments
- rename some internal functions (process_vm_rw_check_iovecs,
process_vm_rw) so they make more sense.
- Add licence message
- Fix kernel-doc comment format
Still need to do benchmarking to see if the optimisation for small copies
using a local on-stack array in process_vm_rw_core is worth it.
Signed-off-by: Chris Yeoh <cyeoh@au1.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/ia32/ia32entry.S | 2
arch/x86/include/asm/unistd_64.h | 4
kernel/sys_ni.c | 4
mm/process_vm_access.c | 203 +++++++++++++++++------------
4 files changed, 132 insertions(+), 81 deletions(-)
diff -puN arch/x86/ia32/ia32entry.S~cross-memory-attach-update arch/x86/ia32/ia32entry.S
--- a/arch/x86/ia32/ia32entry.S~cross-memory-attach-update
+++ a/arch/x86/ia32/ia32entry.S
@@ -850,4 +850,6 @@ ia32_sys_call_table:
.quad sys_syncfs
.quad compat_sys_sendmmsg /* 345 */
.quad sys_setns
+ .quad compat_sys_process_vm_readv
+ .quad compat_sys_process_vm_writev
ia32_syscall_end:
diff -puN arch/x86/include/asm/unistd_64.h~cross-memory-attach-update arch/x86/include/asm/unistd_64.h
--- a/arch/x86/include/asm/unistd_64.h~cross-memory-attach-update
+++ a/arch/x86/include/asm/unistd_64.h
@@ -682,6 +682,10 @@ __SYSCALL(__NR_sendmmsg, sys_sendmmsg)
__SYSCALL(__NR_setns, sys_setns)
#define __NR_getcpu 309
__SYSCALL(__NR_getcpu, sys_getcpu)
+#define __NR_process_vm_readv 310
+__SYSCALL(__NR_process_vm_readv, sys_process_vm_readv)
+#define __NR_process_vm_writev 311
+__SYSCALL(__NR_process_vm_writev, sys_process_vm_writev)
#ifndef __NO_STUBS
#define __ARCH_WANT_OLD_READDIR
diff -puN kernel/sys_ni.c~cross-memory-attach-update kernel/sys_ni.c
--- a/kernel/sys_ni.c~cross-memory-attach-update
+++ a/kernel/sys_ni.c
@@ -145,6 +145,10 @@ cond_syscall(sys_io_submit);
cond_syscall(sys_io_cancel);
cond_syscall(sys_io_getevents);
cond_syscall(sys_syslog);
+cond_syscall(sys_process_vm_readv);
+cond_syscall(sys_process_vm_writev);
+cond_syscall(compat_sys_process_vm_readv);
+cond_syscall(compat_sys_process_vm_writev);
/* arch-specific weak syscall entries */
cond_syscall(sys_pciconfig_read);
diff -puN mm/process_vm_access.c~cross-memory-attach-update mm/process_vm_access.c
--- a/mm/process_vm_access.c~cross-memory-attach-update
+++ a/mm/process_vm_access.c
@@ -1,7 +1,12 @@
/*
- * linux/mm/process_vm_access.c
+ * linux/mm/process_vm_access.c
*
- * Copyright (C) 2010-2011 Christopher Yeoh <cyeoh@au1.ibm.com>, IBM Corp.
+ * Copyright (C) 2010-2011 Christopher Yeoh <cyeoh@au1.ibm.com>, IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
*/
#include <linux/mm.h>
@@ -16,7 +21,7 @@
#include <linux/compat.h>
#endif
-/*
+/**
* process_vm_rw_pages - read/write pages from task specified
* @task: task to read/write from
* @mm: mm for task
@@ -31,19 +36,22 @@
* @lvec_offset: offset in bytes from current iovec iov_base we are up to
* @vm_write: 0 means copy from, 1 means copy to
* @nr_pages_to_copy: number of pages to copy
+ * @bytes_copied: returns number of bytes successfully copied
+ * Returns 0 on success, error code otherwise
*/
-static ssize_t process_vm_rw_pages(struct task_struct *task,
- struct mm_struct *mm,
- struct page **process_pages,
- unsigned long pa,
- unsigned long start_offset,
- unsigned long len,
- const struct iovec *lvec,
- unsigned long lvec_cnt,
- unsigned long *lvec_current,
- size_t *lvec_offset,
- int vm_write,
- unsigned int nr_pages_to_copy)
+static int process_vm_rw_pages(struct task_struct *task,
+ struct mm_struct *mm,
+ struct page **process_pages,
+ unsigned long pa,
+ unsigned long start_offset,
+ unsigned long len,
+ const struct iovec *lvec,
+ unsigned long lvec_cnt,
+ unsigned long *lvec_current,
+ size_t *lvec_offset,
+ int vm_write,
+ unsigned int nr_pages_to_copy,
+ ssize_t *bytes_copied)
{
int pages_pinned;
void *target_kaddr;
@@ -51,8 +59,9 @@ static ssize_t process_vm_rw_pages(struc
int j;
int ret;
ssize_t bytes_to_copy;
- ssize_t bytes_copied = 0;
- ssize_t rc = -EFAULT;
+ ssize_t rc = 0;
+
+ *bytes_copied = 0;
/* Get the pages we're interested in */
down_read(&mm->mmap_sem);
@@ -61,8 +70,10 @@ static ssize_t process_vm_rw_pages(struc
vm_write, 0, process_pages, NULL);
up_read(&mm->mmap_sem);
- if (pages_pinned != nr_pages_to_copy)
+ if (pages_pinned != nr_pages_to_copy) {
+ rc = -EFAULT;
goto end;
+ }
/* Do the copy for each page */
for (pgs_copied = 0;
@@ -81,7 +92,7 @@ static ssize_t process_vm_rw_pages(struc
* - bytes remaining in destination iovec
*/
bytes_to_copy = min_t(ssize_t, PAGE_SIZE - start_offset,
- len - bytes_copied);
+ len - *bytes_copied);
bytes_to_copy = min_t(ssize_t, bytes_to_copy,
lvec[*lvec_current].iov_len
- *lvec_offset);
@@ -99,10 +110,12 @@ static ssize_t process_vm_rw_pages(struc
target_kaddr, bytes_to_copy);
kunmap(process_pages[pgs_copied]);
if (ret) {
+ *bytes_copied += bytes_to_copy - ret;
pgs_copied++;
+ rc = -EFAULT;
goto end;
}
- bytes_copied += bytes_to_copy;
+ *bytes_copied += bytes_to_copy;
*lvec_offset += bytes_to_copy;
if (*lvec_offset == lvec[*lvec_current].iov_len) {
/*
@@ -120,8 +133,6 @@ static ssize_t process_vm_rw_pages(struc
}
}
- rc = bytes_copied;
-
end:
if (vm_write) {
for (j = 0; j < pages_pinned; j++) {
@@ -140,7 +151,7 @@ end:
/* Maximum number of pages kmalloc'd to hold struct page's during copy */
#define PVM_MAX_KMALLOC_PAGES (PAGE_SIZE * 2)
-/*
+/**
* process_vm_rw_single_vec - read/write pages from task specified
* @addr: start memory address of target process
* @len: size of area to copy to/from
@@ -153,35 +164,38 @@ end:
* @mm: mm for task
* @task: task to read/write from
* @vm_write: 0 means copy from, 1 means copy to
+ * @bytes_copied: returns number of bytes successfully copied
+ * Returns 0 on success or on failure error code
*/
-static ssize_t process_vm_rw_single_vec(unsigned long addr,
- unsigned long len,
- const struct iovec *lvec,
- unsigned long lvec_cnt,
- unsigned long *lvec_current,
- size_t *lvec_offset,
- struct page **process_pages,
- struct mm_struct *mm,
- struct task_struct *task,
- int vm_write)
+static int process_vm_rw_single_vec(unsigned long addr,
+ unsigned long len,
+ const struct iovec *lvec,
+ unsigned long lvec_cnt,
+ unsigned long *lvec_current,
+ size_t *lvec_offset,
+ struct page **process_pages,
+ struct mm_struct *mm,
+ struct task_struct *task,
+ int vm_write,
+ ssize_t *bytes_copied)
{
unsigned long pa = addr & PAGE_MASK;
unsigned long start_offset = addr - pa;
unsigned long nr_pages;
- ssize_t bytes_copied = 0;
- ssize_t rc;
+ ssize_t bytes_copied_loop;
+ ssize_t rc = 0;
unsigned long nr_pages_copied = 0;
unsigned long nr_pages_to_copy;
unsigned long max_pages_per_loop = PVM_MAX_KMALLOC_PAGES
/ sizeof(struct pages *);
+ *bytes_copied = 0;
/* Work out address and page range required */
if (len == 0)
return 0;
nr_pages = (addr + len - 1) / PAGE_SIZE - addr / PAGE_SIZE + 1;
-
while ((nr_pages_copied < nr_pages) && (*lvec_current < lvec_cnt)) {
nr_pages_to_copy = min(nr_pages - nr_pages_copied,
max_pages_per_loop);
@@ -190,35 +204,49 @@ static ssize_t process_vm_rw_single_vec(
start_offset, len,
lvec, lvec_cnt,
lvec_current, lvec_offset,
- vm_write, nr_pages_to_copy);
+ vm_write, nr_pages_to_copy,
+ &bytes_copied_loop);
start_offset = 0;
+ *bytes_copied += bytes_copied_loop;
- if (rc < 0)
+ if (rc < 0) {
return rc;
- else {
- bytes_copied += rc;
- len -= rc;
+ } else {
+ len -= bytes_copied_loop;
nr_pages_copied += nr_pages_to_copy;
pa += nr_pages_to_copy * PAGE_SIZE;
}
}
- rc = bytes_copied;
return rc;
}
-static ssize_t process_vm_rw(pid_t pid, const struct iovec *lvec,
- unsigned long liovcnt,
- const struct iovec *rvec,
- unsigned long riovcnt,
- unsigned long flags, int vm_write)
+/**
+ * process_vm_rw_core - core of reading/writing pages from task specified
+ * @pid: PID of process to read/write from/to
+ * @lvec: iovec array specifying where to copy to/from locally
+ * @liovcnt: size of lvec array
+ * @rvec: iovec array specifying where to copy to/from in the other process
+ * @riovcnt: size of rvec array
+ * @flags: currently unused
+ * @vm_write: 0 if reading from other process, 1 if writing to other process
+ * Returns the number of bytes read/written or error code. May
+ * return less bytes than expected if an error occurs during the copying
+ * process.
+ */
+static ssize_t process_vm_rw_core(pid_t pid, const struct iovec *lvec,
+ unsigned long liovcnt,
+ const struct iovec *rvec,
+ unsigned long riovcnt,
+ unsigned long flags, int vm_write)
{
struct task_struct *task;
struct page **process_pages = NULL;
struct mm_struct *mm;
unsigned long i;
- ssize_t rc;
- ssize_t bytes_copied;
+ ssize_t rc = 0;
+ ssize_t bytes_copied_loop;
+ ssize_t bytes_copied = 0;
unsigned long nr_pages = 0;
unsigned long nr_pages_iov;
unsigned long iov_l_curr_idx = 0;
@@ -279,38 +307,53 @@ static ssize_t process_vm_rw(pid_t pid,
atomic_inc(&mm->mm_users);
task_unlock(task);
- rc = 0;
for (i = 0; i < riovcnt && iov_l_curr_idx < liovcnt; i++) {
- bytes_copied = process_vm_rw_single_vec(
+ rc = process_vm_rw_single_vec(
(unsigned long)rvec[i].iov_base, rvec[i].iov_len,
lvec, liovcnt, &iov_l_curr_idx, &iov_l_curr_offset,
- process_pages, mm, task, vm_write);
- if (bytes_copied < 0) {
- rc = bytes_copied;
+ process_pages, mm, task, vm_write, &bytes_copied_loop);
+ bytes_copied += bytes_copied_loop;
+ if (rc != 0) {
+ /* If we have managed to copy any data at all then
+ we return the number of bytes copied. Otherwise
+ we return the error code */
+ if (bytes_copied)
+ rc = bytes_copied;
goto put_mm;
- } else {
- rc += bytes_copied;
}
}
+ rc = bytes_copied;
put_mm:
mmput(mm);
put_task_struct:
put_task_struct(task);
-
free_proc_pages:
kfree(process_pages);
return rc;
}
-static ssize_t process_vm_rw_check_iovecs(pid_t pid,
- const struct iovec __user *lvec,
- unsigned long liovcnt,
- const struct iovec __user *rvec,
- unsigned long riovcnt,
- unsigned long flags, int vm_write)
+/**
+ * process_vm_rw - check iovecs before calling core routine
+ * @pid: PID of process to read/write from/to
+ * @lvec: iovec array specifying where to copy to/from locally
+ * @liovcnt: size of lvec array
+ * @rvec: iovec array specifying where to copy to/from in the other process
+ * @riovcnt: size of rvec array
+ * @flags: currently unused
+ * @vm_write: 0 if reading from other process, 1 if writing to other process
+ * Returns the number of bytes read/written or error code. May
+ * return less bytes than expected if an error occurs during the copying
+ * process.
+ */
+static ssize_t process_vm_rw(pid_t pid,
+ const struct iovec __user *lvec,
+ unsigned long liovcnt,
+ const struct iovec __user *rvec,
+ unsigned long riovcnt,
+ unsigned long flags, int vm_write)
{
struct iovec iovstack_l[UIO_FASTIOV];
struct iovec iovstack_r[UIO_FASTIOV];
@@ -336,8 +379,8 @@ static ssize_t process_vm_rw_check_iovec
if (rc <= 0)
goto free_iovecs;
- rc = process_vm_rw(pid, iov_l, liovcnt, iov_r, riovcnt, flags,
- vm_write);
+ rc = process_vm_rw_core(pid, iov_l, liovcnt, iov_r, riovcnt, flags,
+ vm_write);
free_iovecs:
if (iov_r != iovstack_r)
@@ -352,8 +395,7 @@ SYSCALL_DEFINE6(process_vm_readv, pid_t,
unsigned long, liovcnt, const struct iovec __user *, rvec,
unsigned long, riovcnt, unsigned long, flags)
{
- return process_vm_rw_check_iovecs(pid, lvec, liovcnt, rvec, riovcnt,
- flags, 0);
+ return process_vm_rw(pid, lvec, liovcnt, rvec, riovcnt, flags, 0);
}
SYSCALL_DEFINE6(process_vm_writev, pid_t, pid,
@@ -361,19 +403,18 @@ SYSCALL_DEFINE6(process_vm_writev, pid_t
unsigned long, liovcnt, const struct iovec __user *, rvec,
unsigned long, riovcnt, unsigned long, flags)
{
- return process_vm_rw_check_iovecs(pid, lvec, liovcnt, rvec, riovcnt,
- flags, 1);
+ return process_vm_rw(pid, lvec, liovcnt, rvec, riovcnt, flags, 1);
}
#ifdef CONFIG_COMPAT
asmlinkage ssize_t
-compat_process_vm_rw_check_iovecs(compat_pid_t pid,
- const struct compat_iovec __user *lvec,
- unsigned long liovcnt,
- const struct compat_iovec __user *rvec,
- unsigned long riovcnt,
- unsigned long flags, int vm_write)
+compat_process_vm_rw(compat_pid_t pid,
+ const struct compat_iovec __user *lvec,
+ unsigned long liovcnt,
+ const struct compat_iovec __user *rvec,
+ unsigned long riovcnt,
+ unsigned long flags, int vm_write)
{
struct iovec iovstack_l[UIO_FASTIOV];
struct iovec iovstack_r[UIO_FASTIOV];
@@ -406,8 +447,8 @@ compat_process_vm_rw_check_iovecs(compat
if (rc <= 0)
goto free_iovecs;
- rc = process_vm_rw(pid, iov_l, liovcnt, iov_r, riovcnt, flags,
- vm_write);
+ rc = process_vm_rw_core(pid, iov_l, liovcnt, iov_r, riovcnt, flags,
+ vm_write);
free_iovecs:
if (iov_r != iovstack_r)
@@ -427,8 +468,8 @@ compat_sys_process_vm_readv(compat_pid_t
unsigned long riovcnt,
unsigned long flags)
{
- return compat_process_vm_rw_check_iovecs(pid, lvec, liovcnt, rvec,
- riovcnt, flags, 0);
+ return compat_process_vm_rw(pid, lvec, liovcnt, rvec,
+ riovcnt, flags, 0);
}
asmlinkage ssize_t
@@ -439,8 +480,8 @@ compat_sys_process_vm_writev(compat_pid_
unsigned long riovcnt,
unsigned long flags)
{
- return compat_process_vm_rw_check_iovecs(pid, lvec, liovcnt, rvec,
- riovcnt, flags, 1);
+ return compat_process_vm_rw(pid, lvec, liovcnt, rvec,
+ riovcnt, flags, 1);
}
#endif
_
Patches currently in -mm which might be from cyeoh@au1.ibm.com are
cross-memory-attach-v3.patch
cross-memory-attach-v4.patch
^ permalink raw reply
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.