{"head":"005ee65cafcb1f868cbc56221807c4f848fb4072","size":27,"push_id":46027760,"shas":[["a74e53b29b52d42b0fa14a8948f1abab72d500f0","ac3103168222bc871c4c4626b935581739d3d72b@google.com","vmscan: change shrinker API by passing shrink_control struct\n\nChange each shrinker's API by consolidating the existing parameters into\nshrink_control struct.  This will simplify any further features added w/o\ntouching each file of shrinker.\n\n[akpm@linux-foundation.org: fix build]\n[akpm@linux-foundation.org: fix warning]\n[kosaki.motohiro@jp.fujitsu.com: fix up new shrinker API]\n[akpm@linux-foundation.org: fix xfs warning]\n[akpm@linux-foundation.org: update gfs2]\nSigned-off-by: Ying Han <yinghan@google.com>\nCc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nCc: Minchan Kim <minchan.kim@gmail.com>\nAcked-by: Pavel Emelyanov <xemul@openvz.org>\nCc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nCc: Mel Gorman <mel@csn.ul.ie>\nAcked-by: Rik van Riel <riel@redhat.com>\nCc: Johannes Weiner <hannes@cmpxchg.org>\nCc: Hugh Dickins <hughd@google.com>\nCc: Dave Hansen <dave@linux.vnet.ibm.com>\nCc: Steven Whitehouse <swhiteho@redhat.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","Ying Han"],["89bcbd6625d8ef11e3bcc777b5703419928ff293","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","mm: prevent concurrent unmap_mapping_range() on the same inode\n\nMichael Leun reported that running parallel opens on a fuse filesystem\ncan trigger a \"kernel BUG at mm/truncate.c:475\"\n\nGurudas Pai reported the same bug on NFS.\n\nThe reason is, unmap_mapping_range() is not prepared for more than\none concurrent invocation per inode.  For example:\n\n  thread1: going through a big range, stops in the middle of a vma and\n     stores the restart address in vm_truncate_count.\n\n  thread2: comes in with a small (e.g. single page) unmap request on\n     the same vma, somewhere before restart_address, finds that the\n     vma was already unmapped up to the restart address and happily\n     returns without doing anything.\n\nAnother scenario would be two big unmap requests, both having to\nrestart the unmapping and each one setting vm_truncate_count to its\nown value.  This could go on forever without any of them being able to\nfinish.\n\nTruncate and hole punching already serialize with i_mutex.  Other\ncallers of unmap_mapping_range() do not, and it's difficult to get\ni_mutex protection for all callers.  In particular ->d_revalidate(),\nwhich calls invalidate_inode_pages2_range() in fuse, may be called\nwith or without i_mutex.\n\nThis patch adds a new mutex to 'struct address_space' to prevent\nrunning multiple concurrent unmap_mapping_range() on the same mapping.\n\n[ We'll hopefully get rid of all this with the upcoming mm\n  preemptibility series by Peter Zijlstra, the \"mm: Remove i_mmap_mutex\n  lockbreak\" patch in particular.  But that is for 2.6.39 ]\n\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\nReported-by: Michael Leun <lkml20101129@newton.leun.net>\nReported-by: Gurudas Pai <gurudas.pai@oracle.com>\nTested-by: Gurudas Pai <gurudas.pai@oracle.com>\nAcked-by: Hugh Dickins <hughd@google.com>\nCc: stable@kernel.org\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\n\tfs/nilfs2/btnode.c\n\tfs/nilfs2/mdt.c","Renaud Allard"],["eef52cac5d82a66ab06bc2a1587fb6d74d3beb32","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/djm/tmem\n\n* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/djm/tmem:\n  xen: cleancache shim to Xen Transcendent Memory\n  ocfs2: add cleancache support\n  ext4: add cleancache support\n  btrfs: add cleancache support\n  ext3: add cleancache support\n  mm/fs: add hooks to support cleancache\n  mm: cleancache core ops functions and config\n  fs: add field to superblock to support cleancache\n  mm/fs: cleancache documentation\n\nFix up trivial conflict in fs/btrfs/extent_io.c due to includes\n\nConflicts:\n\n\tfs/btrfs/extent_io.c","Renaud Allard"],["cd0c4ef90ae961473b71527b1a1d6912b0d51507","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","Sync configs","Renaud Allard"],["4019887480b65229b01941959375ad244aea0461","69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","vfs: reorganize 'struct inode' layout a bit\n\nThis tries to make the 'struct inode' accesses denser in the data cache\nby moving a commonly accessed field (i_security) closer to other fields\nthat are accessed often.\n\nIt also makes 'i_state' just an 'unsigned int' rather than 'unsigned\nlong', since we only use a few bits of that field, and moves it next to\nthe existing 'i_flags' so that we potentially get better structure\nlayout (although depending on config options, i_flags may already have\npacked in the same word as i_lock, so this improves packing only for the\ncase of spinlock debugging)\n\nOut 'struct inode' is still way too big, and we should probably move\nsome other fields around too (the acl fields in particular) for better\ndata cache access density.  Other fields (like the inode hash) are\nlikely to be entirely irrelevant under most loads.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","Linus Torvalds"],["c9fb5cf25d87cc04acc580dafdc89d04f908e053","69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","vfs: i_state needs to be 'unsigned long' for now\n\nCommit 13e12d14e2dc (\"vfs: reorganize 'struct inode' layout a bit\")\nmoved things around a bit changed i_state to be unsigned int instead of\nunsigned long.  That was to help structure layout for the 64-bit case,\nand shrink 'struct inode' a bit (admittedly that only happened when\nspinlock debugging was on and i_flags didn't pack with i_lock).\n\nHowever, Meelis Roos reports that this results in unaligned exceptions\non sprc, and it turns out that the bit-locking primitives that we use\nfor the I_NEW bit want to use the bitops.  Which want 'unsigned long',\nnot 'unsigned int'.\n\nWe really should fix the bit locking code to not have that kind of\nrequirement, but that's a much bigger change.  So for now, revert that\nfield back to 'unsigned long' (but keep the other re-ordering changes\nfrom the commit that caused this).\n\nAndi points out that we have played games with this in 'struct page', so\nit's solvable with other hacks too, but since right now the struct inode\nsize advantage only happens with some rare config options, it's not\nworth fighting.\n\nIt _would_ be worth fixing the bitlocking code, though.  Especially\nsince there is no type safety in the bitlocking code (this never caused\nany warnings, and worked fine on x86-64, because the bitlocks take a\n'void *' and x86-64 doesn't care that deeply about alignment).  So it's\ncurrently a very easy problem to trigger by mistake and never notice.\n\nReported-by: Meelis Roos <mroos@linux.ee>\nCc: Andi Kleen <andi@firstfloor.org>\nCc: David Miller <davem@davemloft.net>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","Linus Torvalds"],["144339fc9135445d2f704813df421132e6672d9d","c65a040f7f664378353fb65fc3553df208a14f68@canonical.com","ulimit: raise default hard ulimit on number of files to 4096\n\nApps are increasingly using more than 1024 file descriptors.  See\ndiscussion in several distro bug trackers, e.g.  BugLink:\nhttp://bugs.launchpad.net/bugs/663090\nhttps://issues.rpath.com/browse/RPL-2054\n\nYou don't want to raise the default soft limit, since that might break\napps that use select(), but it's safe to raise the default hard limit;\nthat way, apps that know they need lots of file descriptors can raise\ntheir soft limit without needing root, and without user intervention.\n\nUbuntu is doing this with a kernel change because they have a policy of\nnot changing kernel defaults in userland.\n\nWhile 4096 might not be enough for *all* apps, it seems to be plenty for\nthe apps I've seen lately that are unhappy with 1024.\n\nSigned-off-by: Tim Gardner <tim.gardner@canonical.com>\nCc: Dan Kegel <dank@kegel.com>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nCc: Christoph Hellwig <hch@lst.de>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","Tim Gardner"],["26edf12d350eda7034b767988733787dae69d1ac","f6aa0246ff943bfa8602cdf60d40c481b38ed232@arm.linux.org.uk","ARM: tlb: delay page freeing for SMP and ARMv7 CPUs\n\nWe need to delay freeing any mapped page on SMP and ARMv7 systems to\nensure that the data is not accessed by other CPUs, or is used for\nspeculative prefetch with ARMv7.  This includes not only mapped pages\nbut also pages used for the page tables themselves.\n\nThis avoids races with the MMU/other CPUs accessing pages after they've\nbeen freed but before we've invalidated the TLB.\n\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","Russell King"],["1b90f26cd0e6bd092be967b876d197ab42f2e977","f6aa0246ff943bfa8602cdf60d40c481b38ed232@arm.linux.org.uk","ARM: tlb: move noMMU tlb_flush() to asm/tlb.h\n\nThere's no need to noMMU to put tlb_flush() in asm/tlbflush.h - it's\npart of the tlb shootdown interface.  Move it to asm/tlb.h instead, as\nper x86.\n\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","Russell King"],["45506bacb44024e17be0a4a81529307609d352bd","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","CHange includes to allow 2 former commits to compile","Renaud Allard"],["7a4bf6f66de81550db0b777a09dd95110e8ad943","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","Put kernels in experimental by default, don't update CM7 tree","Renaud Allard"],["016212c1490bdcf81fbc4f6ca4c1c7159f40037e","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","Add most crypto algorithms and methods","Renaud Allard"],["f497064e07e2c8a49187af2c203d04c29e541a44","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","Import security from 3.0","Renaud Allard"],["9dc05b143c69def7b8ce1aafc97da30b0483ee39","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","Import block from 3.0","Renaud Allard"],["58e0cd9ec0c3713c4a77c3d3145df6e61e760f36","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","Import IPC from 3.0","Renaud Allard"],["c0924b1b74babcb21926c90385ec253ec139a7da","db9c790829dcb458d3bf76afc103e85be10d8afc@gmail.com","ARM: S5PV210: Fix security engine interrupt names\n\nThis change is intended to correct security subsystem interrupt names\nfor Samsung S5PV210 and S5PC110 SoCs.\n\nSigned-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com>\nSigned-off-by: Kukjin Kim <kgene.kim@samsung.com>","Vladimir Zapolskiy"],["c5131cb7aaffd2c917d05ac5798136c7ec2635e6","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","ARM: simplify early machine init hooks\n\nRather than storing each machine init hook separately, store a\npointer to the machine description record and dereference this\ninstead.  This pointer is only available while the init sections\nare present, which is not a problem as we only use it from init\ncode.\n\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\n\nConflicts:\n\n\tarch/arm/include/asm/mach/irq.h\n\tarch/arm/kernel/irq.c\n\tarch/arm/kernel/setup.c","Renaud Allard"],["2ee6c3ad29959102ce7dda23615bc99ea55f88a6","380081620a7947c89c11153c5513f34019caa923@android.com","ARM: common: fiq_debugger: Fix build for 2.6.39 irq changes\n\nSigned-off-by: Colin Cross <ccross@android.com>\nChange-Id: I68147c0a17f9cd1b7693826754edc55b1bb09592","Colin Cross"],["b39b62fc642dce28d0597bc2a7d81c32b1ffbbce","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","Revert \"ARM: common: fiq_debugger: Fix build for 2.6.39 irq changes\"\n\nThis reverts commit 2ee6c3ad29959102ce7dda23615bc99ea55f88a6.","Renaud Allard"],["8b006f37332cef8c4567821a7d9ab3d70d3ac445","81ef2ef7cd3a859923573a7bb84652871c617f7d@allard.it","Import drivers/block from 3.0","Renaud Allard"]],"ref":"refs/heads/FuguMod"}