On Sat, 16 Dec 2006, Martin Michlmayr wrote:
Debian recently applied a number of mm changes that went into 2.6.19
to their 2.6.18 kernel for LSB 3.1 compliance (msync() had problems
before). Since then, some filesystem corruption has been observed
which can be traced back to these mm
On Sat, 16 Dec 2006, Martin Michlmayr wrote:
* Hugh Dickins [EMAIL PROTECTED] [2006-12-16 18:20]:
Very disturbing. I'm not aware of any problem with them, and we
surely wouldn't have released 2.6.19 with any known-corrupting patches
in. There's some doubts about 2.6.19 itself in the links
On Sat, 16 Dec 2006, Peter Zijlstra wrote:
Moving the cleaning of the page out from under the private_lock opened
up a window where newly attached buffer might still see the page dirty
status and were thus marked (incorrectly) dirty themselves; resulting in
filesystem data corruption.
I'm not
On Wed, 20 Dec 2006, Peter Zijlstra wrote:
fix page_mkclean_one()
Congratulations on getting to the bottom of it, Peter (if you have:
I haven't digested enough of the thread to tell). I'm mostly offline at
present, no time for dialogue, I'll throw out a few remarks and run...
it had
On Thu, 11 Jan 2007, Robert Schwebel wrote:
Mounting tmpfs with gid=symbolic-group doesn't work on recent kernels
any more; the same with uid=symbolic-username works fine:
[EMAIL PROTECTED]:~$ mkdir troet
[EMAIL PROTECTED]:~$ sudo mount -t tmpfs -ogid=rsc none troet/
mount: wrong fs type,
On Thu, 11 Jan 2007, Jacky Malcles wrote:
is there a way, other than rebooting, to clean up /proc/swaps ?
I'm in this situation (due to testing errors),
# cat /proc/swaps
FilenameTypeSizeUsed
Priority
/dev/sdc1
MS_POSIXACL when ACLs are configured. We
could fix this at another level; but it seems most robust to avoid setting
the s_mount_opt flag in the first place (at the expense of more ifdefs).
Likewise don't set the XATTR_USER flag when built without XATTR support.
Signed-off-by: Hugh Dickins [EMAIL
On Thu, 18 Jan 2007, Nadia Derbey wrote:
Trying to mmap /dev/kmem with an offset I take from /boot/System.map,
I get an EIO error on a 2.6.20-rc4.
This is something that used to work on older kernels.
Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering whether
pfn is
On Fri, 19 Jan 2007, Nadia Derbey wrote:
Hugh Dickins wrote:
Sigh, you're right, 2.6.19 messed that up completely.
No, you never had to subtract PAGE_OFFSET from that address
in the past, and you shouldn't have to do so now.
Whoops, I should never have said never. Checking further back
On Fri, 19 Jan 2007, Franck Bui-Huu wrote:
Hugh Dickins wrote:
Please revert the offending patch below, and then maybe Franck
can come up with a patch which preserves the original behaviour
on architectures which used to work (e.g. i386), while fixing
it for those architectures (which
On Fri, 19 Jan 2007, Arjan van de Ven wrote:
On Fri, 2007-01-19 at 16:33 +, Hugh Dickins wrote:
Though I do wonder whether
it was safe to change its behaviour at that stage: more evidence that
few have actually been using mmap of /dev/kmem.
... and maybe we should just kill /dev
On Fri, 19 Jan 2007, Arjan van de Ven wrote:
On Fri, 2007-01-19 at 17:12 +, Hugh Dickins wrote:
Though so long as /dev/mem support remains, /dev/kmem might as well?
they're not the same; for a long time, /dev/mem on actual memory
returned zeros... so you couldn't use it for rootkits
On Fri, 19 Jan 2007, Alexey Dobriyan wrote:
From: Alexey Kuznetsov [EMAIL PROTECTED]
If read failed we cannot map not-uptodate page to user space.
Good point.
Actually, we are in serious troubles, we do not even know what
process to kill.
True, though we don't really want to kill
On Sat, 20 Jan 2007, Franck Bui-Huu wrote:
On 1/19/07, Hugh Dickins [EMAIL PROTECTED] wrote:
That said, it's really confusing to pass a virtual address as an
offset because:
(a) mmap() has always worked with offset not addresses;
mmap maps some offset down a backing object to some
to /dev/kmem - whereas his patch description seems to say that he
was correcting the offset on a few plaforms, there was no such problem
to correct, and his patch was in fact changing its API on all platforms.
Suggested-by: Hugh Dickins [EMAIL PROTECTED]
---
From: Franck Bui-Huu [EMAIL PROTECTED]
Date
ifdefs).
Likewise don't set the XATTR_USER flag when built without XATTR support.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/ext2/super.c |4
fs/ext3/super.c |4
fs/ext4/super.c |4
3 files changed, 12 insertions(+)
--- 2.6.20-rc5/fs/ext2/super.c 2007-01-13
ext2_new_blocks has a nice io_error label for setting -EIO,
so goto that in the one place that doesn't already use it.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/ext2/balloc.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006
rsv_end is the last block within the reservation,
so alloc_new_reservation should accept start_block == rsv_end as success.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/ext2/balloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006
for mainline ext2? No, because the size in its memscan
is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a
multiple of 8. Is this a problem for ext3 or ext4? No, because they have
an additional extN_test_allocatable test which rescues them from the error.
Signed-off-by: Hugh
ext2_new_blocks should reset the reservation window size to 0 when squeezing
the last blocks out of an almost full filesystem, so the retry doesn't skip
any groups with less than half that free, reporting ENOSPC too soon.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/ext2/balloc.c |1
grp_goal 0 is a genuine goal (unlike -1),
so ext2_try_to_allocate_with_rsv should treat it as such.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/ext2/balloc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18
The reservations tree is an rb_tree not a list, so it's less confusing to
use rb_entry() than list_entry() - though they're both just container_of().
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/ext2/balloc.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 2.6.19-rc6
agree with the compiler.
Suggest delete local variable.
You're right, thank you, here's a patch...
[PATCH] kill install_file_pte's pte_val
David Binderman and his Intel C compiler rightly observe that
install_file_pte no longer has any use for its pte_val.
Signed-off-by: Hugh Dickins [EMAIL
On Tue, 28 Nov 2006, Mingming Cao wrote:
On Tue, 2006-11-28 at 17:40 +, Hugh Dickins wrote:
After several days of testing ext2 with reservations, it got caught inside
ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding
on the window [12cff,12d0e
On Tue, 21 Nov 2006, Mingming Cao wrote:
On Mon, 2006-11-20 at 16:19 +, Hugh Dickins wrote:
After four days of running, the EM64T has at last reproduced the same
hang as it did in an hour before: stuck in
ext2_try_to_allocate_with_rsv,
repeatedly ext2_rsv_window_add
On Tue, 28 Nov 2006, Mingming Cao wrote:
Port a series ext2 balloc patches from Hugh to ext3/4. The first 6
patches are against ext3, and the rest are aginst ext4.
Thanks for all that, Mingming:
whichever is appropriate, all twelve
Acked-by: Hugh Dickins [EMAIL PROTECTED]
or
Signed-off
On Sun, 4 Sep 2005, Blaisorblade wrote:
On Friday 02 September 2005 23:02, Hugh Dickins wrote:
On Fri, 26 Aug 2005, Blaisorblade wrote:
* The first 2 patches modify the PTE encoding macros and start preparing
the VM for the new situation (i.e. VMA which have variable protections,
which
On Fri, 9 Sep 2005, Jan Beulich wrote:
But why would anyone want frame pointers on x86-64?
I'd put the question differently: Why should x86-64 not allow what
other architectures do?
But of course, I'm not insisting on this patch to get in, it just
seemed an obvious inconsistency...
I'm
On Fri, 9 Sep 2005, Andi Kleen wrote:
It won't give more accurate backtraces, not even on i386 because show_stack
doesn't have any code to follow frame pointers.
Ah, right. I'm using kdb with it. (And my recollection of when
show_stack did have a framepointer version, is that it was
On Fri, 9 Sep 2005, Andi Kleen wrote:
On Fri, Sep 09, 2005 at 12:14:38PM +0100, Hugh Dickins wrote:
Ah, right. I'm using kdb with it. (And my recollection of when
show_stack did have a framepointer version, is that it was hopelessly
broken on interrupt frames, and we're much better off
On Fri, 9 Sep 2005, Andi Kleen wrote:
On Friday 09 September 2005 13:31, Hugh Dickins wrote:
On Fri, 9 Sep 2005, Andi Kleen wrote:
But kdb should be using a dwarf2 unwinder instead. kgdb certainly
supports that, as does NLKD.
In an ideal and bloat-neutral world. I've always imagined
-off-by: Hugh Dickins [EMAIL PROTECTED]
---
arch/alpha/mm/remap.c |6
arch/arm/mm/consistent.c |6
arch/arm/mm/ioremap.c |4 --
arch/arm26/mm/memc.c |3 +-
arch/cris/mm/ioremap.c|4 --
arch/frv/mm/dma-alloc.c |5
On Thu, 16 Nov 2006, Andrew Morton wrote:
On Thu, 16 Nov 2006 00:49:20 -0800
Mingming Cao [EMAIL PROTECTED] wrote:
That does not explain the repeated reservation window add and remove
behavior Huge has reported.
I spent quite some time comparing with ext3. I'm a bit stumped and I'm
On Fri, 17 Nov 2006, Francis Moreau wrote:
On Fri, 2006-11-17 at 14:12 +, moreau francis wrote:
Peter Zijlstra wrote:
The new object is the one allocated using:
new = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
Of course but at this point the choice of the new VMA is already
On Sat, 18 Nov 2006, David Rientjes wrote:
The return value of free_pages_check() indicates if PG_reserved was set.
If so, the calling functions return immediately and no pages are freed so
there is no need to call bad_page().
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Nick Piggin [EMAIL
On Sat, 25 Nov 2006, Linus Torvalds wrote:
On Fri, 24 Nov 2006, Hugh Dickins wrote:
You need to add in something like the patch below (mutatis mutandis
for whichever approach you end up taking): tmpfs uses highmem pages
for its swap vector blocks, noting where on swap the data pages
Latest mmotm rarely boots if SLUB is enabled: earlyprintk=vga shows
it crashing with various backtraces. The memset has now been removed
from kmem_cache_open(), so kmem_cache_init() needs to zero its page.
This gets SLUB booting reliably again.
Signed-off-by: Hugh Dickins hu...@google.com
On Mon, 27 Aug 2012, Arvydas Sidorenko wrote:
On 08/27/2012 06:39 PM, Arvydas Sidorenko wrote:
Can you pastebin 'dmesg' and 'lspci'? Did this occur only once, or is
it reproducible?
Jeff
It does happen every time when booting into -next 20120824.
I don't know what went into
On Sun, Sep 9, 2012 at 1:28 PM, Jeff Garzik jgar...@pobox.com wrote:
I'll send Linus a patch to disable.
Thanks, but no, the change in question hasn't reached Linus yet, it's
just a linux-next or mmotm thing - isn't it?
I'll reply again later, but just about to rush out, and thought it
best to
On Sun, 9 Sep 2012, Jeff Garzik wrote:
On 09/09/2012 04:11 PM, Arvydas Sidorenko wrote:
I think you know your way around SCSI/libata much better than I do.
I just bisected linux-next, and it comes down to the commit below, which
introduces the regression for me, and I'm guessing for
On Mon, 17 Sep 2012, Andrew Morton wrote:
On Sat, 15 Sep 2012 15:50:07 +0200
Sasha Levin levinsasha...@gmail.com wrote:
Hi all,
While fuzzing with trinity within a KVM tools guest on a linux-next kernel,
I
got the lockdep warning at the bottom of this mail.
I've tried figuring
On Mon, 17 Sep 2012, Hugh Dickins wrote:
On Mon, 17 Sep 2012, Andrew Morton wrote:
On Sat, 15 Sep 2012 15:50:07 +0200
Sasha Levin levinsasha...@gmail.com wrote:
Hi all,
While fuzzing with trinity within a KVM tools guest on a linux-next
kernel, I
got the lockdep warning
is already
somewhat inconsistent, and no worse if clear_page_mlock() moved up.
Reported-by: Sasha Levin levinsasha...@gmail.com
Deciphered-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Hugh Dickins hu...@google.com
Cc: Mel Gorman m...@csn.ul.ie
Cc: Rik van Riel r...@redhat.com
Cc: Johannes
anonymous page, which has no mapping and cannot be mlocked yet.
Signed-off-by: Hugh Dickins hu...@google.com
Cc: Mel Gorman m...@csn.ul.ie
Cc: Rik van Riel r...@redhat.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michel Lespinasse wal...@google.com
Cc: Ying Han ying...@google.com
in userspace,
not a propertly of pagecache: an mlocked unmapped page is nonsensical.
Reported-by: Johannes Weiner han...@cmpxchg.org
Signed-off-by: Hugh Dickins hu...@google.com
Cc: Mel Gorman m...@csn.ul.ie
Cc: Rik van Riel r...@redhat.com
Cc: Michel Lespinasse wal...@google.com
Cc: Ying Han ying
UNEVICTABLE_MLOCKFREED and unevictable_pgs_mlockfreed always 0.
Signed-off-by: Hugh Dickins hu...@google.com
Cc: Mel Gorman m...@csn.ul.ie
Cc: Rik van Riel r...@redhat.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michel Lespinasse wal...@google.com
Cc: Ying Han ying...@google.com
---
include/linux
On Wed, 19 Sep 2012, Johannes Weiner wrote:
On Tue, Sep 18, 2012 at 08:55:21PM -0700, Hugh Dickins wrote:
We had thought that pages could no longer get freed while still marked
as mlocked; but Johannes Weiner posted this program to demonstrate that
truncating an mlocked private file mapping
On Wed, 18 Sep 2012, David Rientjes wrote:
When a transparent hugepage is mapped and it is included in an mlock()
range, follow_page() incorrectly avoids setting the page's mlock bit and
moving it to the unevictable lru.
This is evident if you try to mlock(), munlock(), and then mlock() a
On Fri, 21 Sep 2012, Fengguang Wu wrote:
On Sat, Sep 15, 2012 at 11:26:23AM +0200, Sasha Levin wrote:
On 09/15/2012 02:00 AM, Michel Lespinasse wrote:
All right. Hugh managed to reproduce the issue on his suse laptop, and
I came up with a fix.
The problem was that in mremap, the new
Simply remove UNEVICTABLE_MLOCKFREED and unevictable_pgs_mlockfreed
line from /proc/vmstat: Johannes and Mel point out that it was very
unlikely to have been used by any tool, and of course we can restore
it easily enough if that turns out to be wrong.
Signed-off-by: Hugh Dickins hu...@google.com
On Tue, 11 Sep 2012, David Rientjes wrote:
On Thu, 16 Aug 2012, a...@linux-foundation.org wrote:
This does revert 2.6.27's dfe195fb79e88 (mm: fix uninitialized variables
for find_vma_prepare callers), but it looks like gcc 4.3.0 was one of
those releases too eager to shout about
On Mon, 13 Aug 2012, Xiao Guangrong wrote:
They are used to abstract the difference between NUMA enabled and NUMA
disabled
to make the code more readable
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
mm/huge_memory.c | 166
On Tue, 11 Sep 2012, David Rientjes wrote:
On Tue, 11 Sep 2012, Hugh Dickins wrote:
This does revert 2.6.27's dfe195fb79e88 (mm: fix uninitialized
variables
for find_vma_prepare callers), but it looks like gcc 4.3.0 was one of
those releases too eager to shout about
On Wed, 12 Sep 2012, David Rientjes wrote:
On Wed, 12 Sep 2012, Hugh Dickins wrote:
that we can't fix it all up to use
uninitialized_var() so this is handled the proper way?
I do prefer to avoid it when we can, some reasons given below.
It's easily silenced with __maybe_unused
On Wed, 12 Sep 2012, Xiao Guangrong wrote:
On 09/12/2012 10:03 AM, Hugh Dickins wrote:
What brought me to look at it was hitting BUG at mm/huge_memory.c:1842!
running tmpfs kbuild swapping load (with memcg's memory.limit_in_bytes
forcing out to swap), while I happened to have CONFIG_NUMA
On Wed, 12 Sep 2012, Hugh Dickins wrote:
@@ -1825,6 +1825,7 @@ static bool khugepaged_prealloc_page(struct page
**hpage, bool *wait)
return false;
*wait = false;
+ *hpage = NULL;
khugepaged_alloc_sleep();
} else if (*hpage
...@cn.fujitsu.com
Signed-off-by: Hugh Dickins hu...@google.com
---
include/linux/mmzone.h |2 -
mm/memcontrol.c| 40 ---
mm/mmzone.c|6 -
mm/page_alloc.c|2 -
4 files changed, 36 insertions(+), 14 deletions(-)
--- 3.6-rc5
On Tue, 11 Sep 2012, Laura Abbott wrote:
When a buffer is added to the LRU list, a reference is taken which is
not dropped until the buffer is evicted from the LRU list. This is the
correct behavior, however this LRU reference will prevent the buffer
from being dropped. This means that the
On Sat, 15 Sep 2012, Jiri Slaby wrote:
On 09/15/2012 02:00 AM, Michel Lespinasse wrote:
All right. Hugh managed to reproduce the issue on his suse laptop, and
I came up with a fix.
The problem was that in mremap, the new vma's vm_{start,end,pgoff}
fields need to be updated before
the hotadd after hotremove issue.
Reported-by: Tang Chen tangc...@cn.fujitsu.com
Signed-off-by: Hugh Dickins hu...@google.com
---
include/linux/mmzone.h |2 -
mm/memcontrol.c| 46 +--
mm/mmzone.c|6 -
mm/page_alloc.c
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
I'm totally unclear whether the kernel ever gets built with these
'creative' compilers that you refer to. Is ACCESS_ONCE() a warning
of where some future compiler would
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
On Wed, Jul 25, 2012 at 01:26:43PM -0700, Hugh Dickins wrote:
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
I'm totally unclear whether the kernel ever gets built
On Thu, 26 Jul 2012, Rik van Riel wrote:
On 07/20/2012 09:49 AM, Mel Gorman wrote:
This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Larry and I were looking around the hugetlb code some
more, and found what looks like yet another race.
On Thu, 26 Jul 2012, Peter Zijlstra wrote:
On Tue, 2012-07-24 at 14:51 -0700, Hugh Dickins wrote:
I do love the status quo, but an audit would be welcome. When
it comes to patches, personally I tend to prefer ACCESS_ONCE() and
smp_read_barrier_depends() and accompanying comments
On Mon, 30 Jul 2012, Johannes Weiner wrote:
On Mon, Jul 30, 2012 at 12:28:35AM +0200, Sasha Levin wrote:
Hi all,
I was poking around /dev/kmem related code, and noticed the following in
mmap_kmem():
/* Turn a kernel-virtual address into a physical page frame */
On Fri, 27 Jul 2012, Hillf Danton wrote:
If swap entry is cleared, we can see the reason that copying pte is
interrupted. If due to page table lock held long enough, no need to
increase swap count.
I can't see a bug to be fixed here.
How would it break out of the loop above without freshly
On Tue, 24 Jul 2012, Meelis Roos wrote:
While testing Debian update on fresh 3.5 kernel on Sun Ultra 2
(sparc64), got the above BUG during generation of initramfs. The machine
last run 3.5-rc7 and some previous rc-s fine, as well as earlier 3.x
releases.
Rerunning this initramfs
-off-by: Hugh Dickins hu...@google.com
---
mm/mmap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- v3.5/mm/mmap.c 2012-07-21 13:58:29.0 -0700
+++ linux/mm/mmap.c 2012-07-30 19:38:41.977203670 -0700
@@ -2310,7 +2310,7 @@ void exit_mmap(struct mm_struct *mm
On Tue, 28 Aug 2012, Richard W.M. Jones wrote:
On Wed, Aug 22, 2012 at 09:56:12PM -0700, Hugh Dickins wrote:
[PATCH] block: replace __getblk_slow misfix by grow_dev_page fix
I noticed this (second version) went upstream already. Nevertheless I
tested it today and it doesn't cause
[ Cc'ing original mail to netdev as the problem may be recognized there ]
On Wed, 29 Aug 2012, David Madore wrote:
Dear all,
I hope this is the right place to send this sort of backtrace dump.
I'm getting the following sort of dumps (below) on a 3.2.27 kernel on
an arm/kirkwood (actually
On Fri, 10 Aug 2012, Hillf Danton wrote:
On Fri, Aug 10, 2012 at 9:26 AM, Hugh Dickins hu...@google.com wrote:
On Thu, 9 Aug 2012, Hillf Danton wrote:
After walking rb tree, if vma is determined, prev vma has to be determined
based on vma; and rb_prev should be considered only if no vma
On Thu, 9 Aug 2012, Ren, Qiaowei wrote:
On Wed, 8 Aug 2012, David Rientjes wrote:
On Wed, 8 Aug 2012, Qiaowei Ren wrote:
Add a shmaps entry to /proc/pid: show information about shared memory in
an address space.
People that use shared memory and want to perform an analyzing
On Thu, 9 Aug 2012, Hillf Danton wrote:
After walking rb tree, if vma is determined, prev vma has to be determined
based on vma; and rb_prev should be considered only if no vma determined.
Why? Because you think more code is better code? I disagree.
If you have seen a bug here, please tell
On Fri, 10 Aug 2012, Takashi Iwai wrote:
At Fri, 10 Aug 2012 14:35:13 +0200,
Daniel Vetter wrote:
On Fri, Aug 10, 2012 at 1:59 PM, Takashi Iwai ti...@suse.de wrote:
At Mon, 6 Aug 2012 11:25:30 -0700 (PDT),
Hugh Dickins wrote:
On Mon, 6 Aug 2012, Daniel Vetter wrote:
On Mon
On Tue, 21 Aug 2012, Tejun Heo wrote:
On Tue, Aug 21, 2012 at 11:43:44PM +0200, Lennart Poettering wrote:
I'm not against this but unsure whether using kmem is enough for the
suggested use case. Lennart, would this suit systemd? How much
metadata are we talking about?
Just small
-by: Hugh Dickins hu...@google.com
Cc: sta...@vger.kernel.org # 3.0 3.2 3.4 3.5
---
fs/buffer.c | 43 +--
1 file changed, 21 insertions(+), 22 deletions(-)
--- 3.6-rc2/fs/buffer.c 2012-08-04 09:19:20.644022328 -0700
+++ linux/fs/buffer.c 2012-08-21 08:49
On Wed, 22 Aug 2012, Xiao Guangrong wrote:
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
The KSM usage of it looks safe because it will only establish readonly
ptes with it.
Hmm, in KSM code, i found this code in replace_page:
set_pte_at_notify(mm, addr, ptep, mk_pte(kpage,
On Wed, 22 Aug 2012, Aristeu Rozanski wrote:
On Mon, Aug 20, 2012 at 09:47:15PM -0700, Hugh Dickins wrote:
On Mon, 20 Aug 2012, Aristeu Rozanski wrote:
On Mon, Aug 20, 2012 at 12:10:09AM -0700, Hugh Dickins wrote:
Yes, it looks nice to me. I might have preferred more as inlines
On Wed, 22 Aug 2012, Andi Kleen wrote:
Andrea Arcangeli aarca...@redhat.com writes:
+ /*
+* Take the lock with irqs disabled to avoid a lock
+* inversion with the lru_lock. The lru_lock is taken
+* before the autonuma_migrate_lock in
+
On Wed, 22 Aug 2012, Richard W.M. Jones wrote:
On Tue, Aug 21, 2012 at 06:33:45PM -0700, Hugh Dickins wrote:
Jeff,
Your commit 91f68c89d8f3 (block: fix infinite loop in __getblk_slow),
already gone into 3.* stable, is not good. Could you and your testers
please give this alternative
On Thu, 23 Aug 2012, Jeff Moyer wrote:
Hugh Dickins hu...@google.com writes:
[PATCH] block: replace __getblk_slow misfix by grow_dev_page fix
Commit 91f68c89d8f3 (block: fix infinite loop in __getblk_slow)
is not good: a successful call to grow_buffers() cannot guarantee
that the page
textdata bss dec hex filename
4658957 880729 5195032 10734718 a3cc7e vmlinux.o
v7:
- checkpatch warnings fixed
- Implement the changes requested by Hugh Dickins:
- make simple_xattrs_init and simple_xattrs_free inline
- get rid of locking and list
Sorry to report that with 3.6-rc1, closing and opening the lid on
this ThinkPad T420s leaves the screen blank, and I have to reboot.
I understand there's also an nVidia graphics device in here,
but I have that configured out, preferring to use the i915:
00:02.0 VGA compatible controller: Intel
On Sun, 5 Aug 2012, Takashi Iwai wrote:
At Sat, 4 Aug 2012 10:01:13 -0700 (PDT),
Hugh Dickins wrote:
Sorry to report that with 3.6-rc1, closing and opening the lid on
this ThinkPad T420s leaves the screen blank, and I have to reboot.
I understand there's also an nVidia graphics
On Mon, 6 Aug 2012, Daniel Vetter wrote:
On Mon, Aug 6, 2012 at 6:21 AM, Hugh Dickins hu...@google.com wrote:
On Sun, 5 Aug 2012, Takashi Iwai wrote:
At Sat, 4 Aug 2012 10:01:13 -0700 (PDT),
Hugh Dickins wrote:
Sorry to report that with 3.6-rc1, closing and opening the lid
On Mon, 6 Aug 2012, Hillf Danton wrote:
Both find_vma and find_vma_prev have code for walking rb tree, and we can
walk less.
To cut the walk in find_vma_prev off, find_vma is changed to take care of
vm_prev while walking rb tree, and we end up wrapping find_vma_prev with
find_vma.
No
(), reinitialize the list
- use simple_xattr_* prefix
- introduce simple_xattr_add() to prevent direct list usage
Cc: Li Zefan lize...@huawei.com
Cc: Tejun Heo t...@kernel.org
Cc: Hugh Dickins hu...@google.com
Hugh, can you please review and ack this one?
Yes, it looks nice to me. I
On Fri, 17 Aug 2012, Rik van Riel wrote:
On 08/17/2012 08:03 PM, Daniel Forrest wrote:
Based on your comments, I came up with the following patch. It boots
and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
if I've overlooked something. I'm not a kernel hacker.
On Mon, 20 Aug 2012, Aristeu Rozanski wrote:
On Mon, Aug 20, 2012 at 12:10:09AM -0700, Hugh Dickins wrote:
Yes, it looks nice to me. I might have preferred more as inlines in
the header file to lower the slight init/evict overhead, and I don't
see why __simple_xattr_set() isn't using
On Mon, 4 Feb 2008, Andrew Morton wrote:
Takashi found a bug in it:
Bless him.
---
a/lib/vsprintf.c~add-new-string-functions-strict_strto-and-convert-kernel-params-to-use-them-fix-2
+++ a/lib/vsprintf.c
@@ -234,7 +234,7 @@ int strict_strto##type(const char *cp, u
if (ret
Please chuck out:
add-new-string-functions-strict_strto-and-convert-kernel-params-to-use-them.patch
(along with Randy's perfectly reasonable -fix.patch).
So predictable that it would just disable loading modules with params:
Feb 4 13:17:02 blonde kernel: thinkpad_acpi: `1' invalid for parameter
with randomized brk start. The proper way is to check whether
the address is not below the start_brk address.
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
Acked-by: Hugh Dickins [EMAIL PROTECTED]
diff --git a/mm/mmap.c b/mm/mmap.c
index 8295577..1c3b48f 100644
--- a/mm/mmap.c
+++ b/mm
When change_page_attr splits a large page on x86_32 (without PAE), it is
currently corrupting every process's page directory: fix that by removing
the thinko which passes down a physical instead of a virtual address.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.24-git/arch/x86/mm
When change_page_attr splits a large page on x86_32 (without PAE), it is
currently corrupting every process's page directory: fix that by removing
the thinko which passes down a physical instead of a virtual address -
this version of the patch being the hotfix for 2.6.24-mm1.
Signed-off-by: Hugh
On Wed, 6 Feb 2008, Tomasz Chmielewski wrote:
Hello Kernel Users,
is there a size limit for tmpfs for the /dev/shm filesystem?
There shouldn't be any artificial size limit on the /dev/shm filesystem,
it's an internal mount, and those are unlimited by default. Which is
not to say that you
On Wed, 6 Feb 2008, H. Peter Anvin wrote:
Hugh Dickins wrote:
Don't forget that tmpfs overflows into swap, so you could save money
by adding adding more swap and cutting down on the RAM: though of
course that will perform very poorly once it's actually using the
swap, probably
On Sun, 3 Feb 2008, Oleg Nesterov wrote:
So I have to try to find another bug ;) Suppose that -load_binary() does
a series of do_mmap(MAP_EXECUTABLE). It is possible that mmap_region() can
merge 2 vmas. In that case we leak -num_exe_file_vmas. Unless I missed
something, mmap_region() should
On Wed, 6 Feb 2008, H. Peter Anvin wrote:
That sounds like a problem in our overall swap handling, not specifically in
tmpfs. Now, I can't say anything concrete about heavy swap conditions, but in
light swap conditions I have measured a 20x performance improvement(!) over
ext3 on real
On Wed, 6 Feb 2008, H. Peter Anvin wrote:
The specific application was this:
- extract a kernel tarball
- make distclean
- cp -al the resulting tree
- apply a patch to each tree
- do a diff between the trees
- delete all files
... repeat something like 20,000 times.
Right, thanks.
On Wed, 6 Feb 2008, Matt Helsley wrote:
On Wed, 2008-02-06 at 20:33 +, Hugh Dickins wrote:
Sorry, Matt, I don't like your patch at all. It seems to add a fair
amount of ugliness and unmaintainablity, all for a peculiar MVFS case
I thought that getting rid of the separate versions
701 - 800 of 4042 matches
Mail list logo
