1. 01 3月, 2015 4 次提交
    • A
      rtc: ds1685: fix ds1685_rtc_alarm_irq_enable build error · 682354d4
      Arnd Bergmann 提交于
      The newly added ds1685 driver causes a build error when enabled without
      CONFIG_RTC_INTF_DEV:
      
        drivers/rtc/rtc-ds1685.c:919:22: error: 'ds1685_rtc_alarm_irq_enable' undeclared here (not in a function)
          .alarm_irq_enable = ds1685_rtc_alarm_irq_enable,
      
      Apparently the driver was incorrectly changed to reflect the interface
      change from 16380c15 ("RTC: Convert rtc drivers to use the
      alarm_irq_enable method"), which removed the respective #ifdef from all
      other rtc drivers.
      
      This does the same change that was merged for the other drivers before and
      removes the #ifdef, allowing the interrupts to be enabled through the
      in-kernel rtc interface independent of the existence of /dev/rtc.
      
      Fixes: aaaf5fbf ("rtc: add driver for DS1685 family of real time clocks")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NJoshua Kinard <kumba@gentoo.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      682354d4
    • M
      memcg: fix low limit calculation · 4e54dede
      Michal Hocko 提交于
      A memcg is considered low limited even when the current usage is equal to
      the low limit.  This leads to interesting side effects e.g.
      groups/hierarchies with no memory accounted are considered protected and
      so the reclaim will emit MEMCG_LOW event when encountering them.
      
      Another and much bigger issue was reported by Joonsoo Kim.  He has hit a
      NULL ptr dereference with the legacy cgroup API which even doesn't have
      low limit exposed.  The limit is 0 by default but the initial check fails
      for memcg with 0 consumption and parent_mem_cgroup() would return NULL if
      use_hierarchy is 0 and so page_counter_read would try to dereference NULL.
      
      I suppose that the current implementation is just an overlook because the
      documentation in Documentation/cgroups/unified-hierarchy.txt says:
      
        "The memory.low boundary on the other hand is a top-down allocated
        reserve.  A cgroup enjoys reclaim protection when it and all its
        ancestors are below their low boundaries"
      
      Fix the usage and the low limit comparision in mem_cgroup_low accordingly.
      
      Fixes: 241994ed (mm: memcontrol: default hierarchy interface for memory)
      Reported-by: NJoonsoo Kim <js1304@gmail.com>
      Signed-off-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4e54dede
    • J
      mm/nommu: fix memory leak · da616534
      Joonsoo Kim 提交于
      Maxime reported the following memory leak regression due to commit
      dbc8358c ("mm/nommu: use alloc_pages_exact() rather than its own
      implementation").
      
      On v3.19, I am facing a memory leak.  Each time I run a command one page
      is lost.  Here an example with busybox's free command:
      
        / # free
                     total       used       free     shared    buffers     cached
        Mem:          7928       1972       5956          0          0        492
        -/+ buffers/cache:       1480       6448
        / # free
                     total       used       free     shared    buffers     cached
        Mem:          7928       1976       5952          0          0        492
        -/+ buffers/cache:       1484       6444
        / # free
                     total       used       free     shared    buffers     cached
        Mem:          7928       1980       5948          0          0        492
        -/+ buffers/cache:       1488       6440
        / # free
                     total       used       free     shared    buffers     cached
        Mem:          7928       1984       5944          0          0        492
        -/+ buffers/cache:       1492       6436
        / # free
                     total       used       free     shared    buffers     cached
        Mem:          7928       1988       5940          0          0        492
        -/+ buffers/cache:       1496       6432
      
      At some point, the system fails to sastisfy 256KB allocations:
      
        free: page allocation failure: order:6, mode:0xd0
        CPU: 0 PID: 67 Comm: free Not tainted 3.19.0-05389-gacf2cf1-dirty #64
        Hardware name: STM32 (Device Tree Support)
          show_stack+0xb/0xc
          warn_alloc_failed+0x97/0xbc
          __alloc_pages_nodemask+0x295/0x35c
          __get_free_pages+0xb/0x24
          alloc_pages_exact+0x19/0x24
          do_mmap_pgoff+0x423/0x658
          vm_mmap_pgoff+0x3f/0x4e
          load_flat_file+0x20d/0x4f8
          load_flat_binary+0x3f/0x26c
          search_binary_handler+0x51/0xe4
          do_execveat_common+0x271/0x35c
          do_execve+0x19/0x1c
          ret_fast_syscall+0x1/0x4a
        Mem-info:
        Normal per-cpu:
        CPU    0: hi:    0, btch:   1 usd:   0
        active_anon:0 inactive_anon:0 isolated_anon:0
         active_file:0 inactive_file:0 isolated_file:0
         unevictable:123 dirty:0 writeback:0 unstable:0
         free:1515 slab_reclaimable:17 slab_unreclaimable:139
         mapped:0 shmem:0 pagetables:0 bounce:0
         free_cma:0
        Normal free:6060kB min:352kB low:440kB high:528kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:492kB isolated(anon):0ks
        lowmem_reserve[]: 0 0
        Normal: 23*4kB (U) 22*8kB (U) 24*16kB (U) 23*32kB (U) 23*64kB (U) 23*128kB (U) 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6060kB
        123 total pagecache pages
        2048 pages of RAM
        1538 free pages
        66 reserved pages
        109 slab pages
        -46 pages shared
        0 pages swap cached
        nommu: Allocation of length 221184 from process 67 (free) failed
        Normal per-cpu:
        CPU    0: hi:    0, btch:   1 usd:   0
        active_anon:0 inactive_anon:0 isolated_anon:0
         active_file:0 inactive_file:0 isolated_file:0
         unevictable:123 dirty:0 writeback:0 unstable:0
         free:1515 slab_reclaimable:17 slab_unreclaimable:139
         mapped:0 shmem:0 pagetables:0 bounce:0
         free_cma:0
        Normal free:6060kB min:352kB low:440kB high:528kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:492kB isolated(anon):0ks
        lowmem_reserve[]: 0 0
        Normal: 23*4kB (U) 22*8kB (U) 24*16kB (U) 23*32kB (U) 23*64kB (U) 23*128kB (U) 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6060kB
        123 total pagecache pages
        Unable to allocate RAM for process text/data, errno 12 SEGV
      
      This problem happens because we allocate ordered page through
      __get_free_pages() in do_mmap_private() in some cases and we try to free
      individual pages rather than ordered page in free_page_series().  In
      this case, freeing pages whose refcount is not 0 won't be freed to the
      page allocator so memory leak happens.
      
      To fix the problem, this patch changes __get_free_pages() to
      alloc_pages_exact() since alloc_pages_exact() returns
      physically-contiguous pages but each pages are refcounted.
      
      Fixes: dbc8358c ("mm/nommu: use alloc_pages_exact() rather than its own implementation").
      Reported-by: NMaxime Coquelin <mcoquelin.stm32@gmail.com>
      Tested-by: NMaxime Coquelin <mcoquelin.stm32@gmail.com>
      Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: <stable@vger.kernel.org>	[3.19]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      da616534
    • M
      ocfs2: update web page + git tree in documentation · 01945fa2
      Mark Fasheh 提交于
      We (the Ocfs2 project) recently moved the location of our ocfs2-tools
      git tree and project web page.  The pertinent discussion can be seen
      here:
      
        https://oss.oracle.com/pipermail/ocfs2-devel/2015-February/010579.html
      
      The following patch updates the Ocfs2 documentation in MAINTAINERS,
      ocfs2.txt, and dlmfs.txt.  I added our new official web page, changed
      the location of our tools git tree and removed the link to Joel's
      ancient kernel git tree - Andrew has handled our patches for a while
      now.
      Signed-off-by: NMark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      01945fa2
  2. 27 2月, 2015 3 次提交
  3. 25 2月, 2015 5 次提交
  4. 24 2月, 2015 5 次提交
  5. 23 2月, 2015 23 次提交