1. 14 Dec, 2007 20 commits
  2. 26 Nov, 2007 20 commits
    • Greg Kroah-Hartman's avatar
      Linux 2.6.23.9 · 8996d0af
      Greg Kroah-Hartman authored
      8996d0af
    • Dan Williams's avatar
      ipw2200: batch non-user-requested scan result notifications · 6bb559a3
      Dan Williams authored
      patch 0b531676 in mainline.
      
      ipw2200 makes extensive use of background scanning when unassociated or
      down.  Unfortunately, the firmware sends scan completed events many
      times per second, which the driver pushes directly up to userspace.
      This needlessly wakes up processes listening for wireless events many
      times per second.  Batch together scan completed events for
      non-user-requested scans and send them up to userspace every 4 seconds.
      Scan completed events resulting from an SIOCSIWSCAN call are pushed up
      without delay.
      Signed-off-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Cc: Tobias Powalowski <t.powa@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6bb559a3
    • Ortwin Glück's avatar
      USB: Nikon D40X unusual_devs entry · 590ca6cb
      Ortwin Glück authored
      patch d466a919 in mainline.
      
      Not surprisingly the Nikon D40X DSC needs the same quirks as the D40,
      but it has a separate ID.
      See http://bugs.gentoo.org/show_bug.cgi?id=191431
      
      From: Ortwin Glück <odi@odi.ch>
      Cc: Tobias Powalowski <t.powa@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      590ca6cb
    • Phil Dibowitz's avatar
      USB: unusual_devs modification for Nikon D200 · 1ed8fc8e
      Phil Dibowitz authored
      patch 16eb345f in mainline.
      
      Upgrade the unusual_devs.h file to support the Nikon D200
      Signed-off-by: default avatarMike Pagano <mpagano-kernel@mpagano.com>
      Signed-off-by: default avatarPhil Dibowitz <phil@ipom.com>
      Cc: Tobias Powalowski <t.powa@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1ed8fc8e
    • Ingo Molnar's avatar
      softlockup: use cpu_clock() instead of sched_clock() · fd5ec14e
      Ingo Molnar authored
      patch a3b13c23 in mainline.
      
      sched_clock() is not a reliable time-source, use cpu_clock() instead.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fd5ec14e
    • Ingo Molnar's avatar
      softlockup watchdog fixes and cleanups · 00aceb50
      Ingo Molnar authored
      This is a merge of commits a5f2ce3c and
      43581a10 in mainline to fix a warning in
      the 2.6.23.3 kernel release.
      
      softlockup watchdog: style cleanups
      
      kernel/softirq.c grew a few style uncleanlinesses in the past few
      months, clean that up. No functional changes:
      
      text    data     bss     dec     hex filename
      1126      76       4    1206     4b6 softlockup.o.before
      1129      76       4    1209     4b9 softlockup.o.after
      
      ( the 3 bytes .text increase is due to the "<1>" appended to one of
      the printk messages. )
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      
      
      softlockup: improve debug output
      
      Improve the debuggability of kernel lockups by enhancing the debug
      output of the softlockup detector: print the task that causes the lockup
      and try to print a more intelligent backtrace.
      
      The old format was:
      
      BUG: soft lockup detected on CPU#1!
      [<c0105e4a>] show_trace_log_lvl+0x19/0x2e
      [<c0105f43>] show_trace+0x12/0x14
      [<c0105f59>] dump_stack+0x14/0x16
      [<c015f6bc>] softlockup_tick+0xbe/0xd0
      [<c013457d>] run_local_timers+0x12/0x14
      [<c01346b8>] update_process_times+0x3e/0x63
      [<c0145fb8>] tick_sched_timer+0x7c/0xc0
      [<c0140a75>] hrtimer_interrupt+0x135/0x1ba
      [<c011bde7>] smp_apic_timer_interrupt+0x6e/0x80
      [<c0105aa3>] apic_timer_interrupt+0x33/0x38
      [<c0104f8a>] syscall_call+0x7/0xb
      =======================
      
      The new format is:
      
      BUG: soft lockup detected on CPU#1! [prctl:2363]
      
      Pid: 2363, comm:                prctl
      EIP: 0060:[<c013915f>] CPU: 1
      EIP is at sys_prctl+0x24/0x18c
      EFLAGS: 00000213    Not tainted  (2.6.22-cfs-v20 #26)
      EAX: 00000001 EBX: 000003e7 ECX: 00000001 EDX: f6df0000
      ESI: 000003e7 EDI: 000003e7 EBP: f6df0fb0 DS: 007b ES: 007b FS: 00d8
      CR0: 8005003b CR2: 4d8c3340 CR3: 3731d000 CR4: 000006d0
      [<c0105e4a>] show_trace_log_lvl+0x19/0x2e
      [<c0105f43>] show_trace+0x12/0x14
      [<c01040be>] show_regs+0x1ab/0x1b3
      [<c015f807>] softlockup_tick+0xef/0x108
      [<c013457d>] run_local_timers+0x12/0x14
      [<c01346b8>] update_process_times+0x3e/0x63
      [<c0145fcc>] tick_sched_timer+0x7c/0xc0
      [<c0140a89>] hrtimer_interrupt+0x135/0x1ba
      [<c011bde7>] smp_apic_timer_interrupt+0x6e/0x80
      [<c0105aa3>] apic_timer_interrupt+0x33/0x38
      [<c0104f8a>] syscall_call+0x7/0xb
      =======================
      
      Note that in the old format we only knew that some system call locked
      up, we didnt know _which_. With the new format we know that it's at a
      specific place in sys_prctl(). [which was where i created an artificial
      kernel lockup to test the new format.]
      
      This is also useful if the lockup happens in user-space - the user-space
      EIP (and other registers) will be printed too. (such a lockup would
      either suggest that the task was running at SCHED_FIFO:99 and looping
      for more than 10 seconds, or that the softlockup detector has a
      false-positive.)
      
      The task name is printed too first, just in case we dont manage to print
      a useful backtrace.
      
      [satyam@infradead.org: fix warning]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarSatyam Sharma <satyam@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
      00aceb50
    • David P. Reed's avatar
      x86: fix freeze in x86_64 RTC update code in time_64.c · 653e60e2
      David P. Reed authored
      patch c399da0d in mainline.
      
      x86: fix freeze in x86_64 RTC update code in time_64.c
      
      Fix hard freeze on x86_64 when the ntpd service calls
      update_persistent_clock()
      
      A repeatable but randomly timed freeze has been happening in Fedora 6
      and 7 for the last year, whenever I run the ntpd service on my AMD64x2
      HP Pavilion dv9000z laptop.  This freeze is due to the use of
      spin_lock(&rtc_lock) under the assumption (per a bad comment) that
      set_rtc_mmss is called only with interrupts disabled.  The call from
      ntp.c to update_persistent_clock is made with interrupts enabled.
      
      [ tglx@linutronix.de: ported to 2.6.23.stable ]
      Signed-off-by: default avatarDavid P. Reed <dpreed@reed.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      653e60e2
    • David P. Reed's avatar
      ntp: fix typo that makes sync_cmos_clock erratic · 2d429c89
      David P. Reed authored
      patch fa6a1a55 in mainline.
      
      ntp: fix typo that makes sync_cmos_clock erratic
      
      Fix a typo in ntp.c that has caused updating of the persistent (RTC)
      clock when synced to NTP to behave erratically.
      
      When debugging a freeze that arises on my AMD64 machines when I
      run the ntpd service, I added a number of printk's to monitor the
      sync_cmos_clock procedure.  I discovered that it was not syncing to
      cmos RTC every 11 minutes as documented, but instead would keep trying
      every second for hours at a time.  The reason turned out to be a typo
      in sync_cmos_clock, where it attempts to ensure that
      update_persistent_clock is called very close to 500 msec. after a 1
      second boundary (required by the PC RTC's spec). That typo referred to
      "xtime" in one spot, rather than "now", which is derived from "xtime"
      but not equal to it.  This makes the test erratic, creating a
      "coin-flip" that decides when update_persistent_clock is called - when
      it is called, which is rarely, it may be at any time during the one
      second period, rather than close to 500 msec, so the value written is
      needlessly incorrect, too.
      Signed-off-by: default avatarDavid P. Reed <dpreed@reed.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2d429c89
    • Andrey Mirkin's avatar
      x86: return correct error code from child_rip in x86_64 entry.S · 26b880d6
      Andrey Mirkin authored
      patch 1c5b5cfd in mainline.
      
      x86: return correct error code from child_rip in x86_64 entry.S
      
      Right now register edi is just cleared before calling do_exit.
      That is wrong because correct return value will be ignored.
      Value from rax should be copied to rdi instead of clearing edi.
      
      AK: changed to 32bit move because it's strictly an int
      
      [ tglx: arch/x86 adaptation ]
      Signed-off-by: default avatarAndrey Mirkin <major@openvz.org>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      26b880d6
    • Huang, Ying's avatar
      x86: NX bit handling in change_page_attr() · 5b7e28db
      Huang, Ying authored
      patch 84e0fdb1 in mainline.
      
      x86: NX bit handling in change_page_attr()
      
      This patch fixes a bug of change_page_attr/change_page_attr_addr on
      Intel x86_64 CPUs.  After changing page attribute to be executable with
      these functions, the page remains un-executable on Intel x86_64 CPU.
      Because on Intel x86_64 CPU, only if the "NX" bits of all four level
      page tables are cleared, the corresponding page is executable (refer to
      section 4.13.2 of Intel 64 and IA-32 Architectures Software Developer's
      Manual).  So, the bug is fixed through clearing the "NX" bit of PMD when
      splitting the huge PMD.
      Signed-off-by: default avatarHuang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5b7e28db
    • Kirill Korotaev's avatar
      x86: mark read_crX() asm code as volatile · 420b463a
      Kirill Korotaev authored
      patch c1217a75 in mainline.
      
      x86: mark read_crX() asm code as volatile
      
      Some gcc versions (I checked at least 4.1.1 from RHEL5 & 4.1.2 from gentoo)
      can generate incorrect code with read_crX()/write_crX() functions mix up,
      due to cached results of read_crX().
      
      The small app for x8664 below compiled with -O2 demonstrates this
      (i686 does the same thing):
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      420b463a
    • Andrew Hastings's avatar
      x86: fix off-by-one in find_next_zero_string · 2e6792e3
      Andrew Hastings authored
      patch 801916c1 in mainline.
      
      x86: fix off-by-one in find_next_zero_string
      
      Fix an off-by-one error in find_next_zero_string which prevents
      allocating the last bit.
      
      [ tglx: arch/x86 adaptation ]
      Signed-off-by: default avatarAndrew Hastings <abh@cray.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2e6792e3
    • Jan Beulich's avatar
      i386: avoid temporarily inconsistent pte-s · df84bfba
      Jan Beulich authored
      patch aa506dc7 in mainline.
      
      i386: avoid temporarily inconsistent pte-s
      
      One more of these issues (which were considered fixed a few releases
      back): other than on x86-64, i386 allows set_fixmap() to replace
      already present mappings. Consequently, on PAE, care must be taken to
      not update the high half of a pte while the low half is still holding
      the old value.
      
       [tglx: arch/x86 adaptation]
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      df84bfba
    • Herbert Xu's avatar
      libcrc32c: keep intermediate crc state in cpu order · 332a20e3
      Herbert Xu authored
      It's upstream changeset ef19454b.
      
      [LIB] crc32c: Keep intermediate crc state in cpu order
      
      crypto/crc32.c:chksum_final() is computing the digest as
      *(__le32 *)out = ~cpu_to_le32(mctx->crc);
      so the low-level crc32c_le routines should just keep
      the crc in cpu order, otherwise it is getting swabbed
      one too many times on big-endian machines.
      Signed-off-by: default avatarBenny Halevy <bhalevy@fs1.bhalevy.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      332a20e3
    • Sebastian Siewior's avatar
      geode: Fix not inplace encryption · ca1b1e5c
      Sebastian Siewior authored
      patch 2e21630d in mainline.
      
      Currently the Geode AES module fails to encrypt or decrypt if
      the coherent bits are not set what is currently the case if the
      encryption does not occur inplace. However, the encryption works
      on my Geode machine _only_ if the coherent bits are always set.
      Signed-off-by: default avatarSebastian Siewior <sebastian@breakpoint.cc>
      Acked-by: default avatarJordan Crouse <jordan.crouse@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ca1b1e5c
    • Chuck Ebbert's avatar
      Fix divide-by-zero in the 2.6.23 scheduler code · 23a5e6a5
      Chuck Ebbert authored
      No patch in mainline as this logic has been removed from 2.6.24 so it is
      not necessary.
      
      
      https://bugzilla.redhat.com/show_bug.cgi?id=340161
      
      The problem code has been removed in 2.6.24. The below patch disables
      SCHED_FEAT_PRECISE_CPU_LOAD which causes the offending code to be skipped
      but does not prevent the user from enabling it.
      
      The divide-by-zero is here in kernel/sched.c:
      
      static void update_cpu_load(struct rq *this_rq)
      {
      	u64 fair_delta64, exec_delta64, idle_delta64, sample_interval64, tmp64;
      	unsigned long total_load = this_rq->ls.load.weight;
      	unsigned long this_load =  total_load;
      	struct load_stat *ls = &this_rq->ls;
      	int i, scale;
      
      	this_rq->nr_load_updates++;
      	if (unlikely(!(sysctl_sched_features & SCHED_FEAT_PRECISE_CPU_LOAD)))
      		goto do_avg;
      
      	/* Update delta_fair/delta_exec fields first */
      	update_curr_load(this_rq);
      
      	fair_delta64 = ls->delta_fair + 1;
      	ls->delta_fair = 0;
      
      	exec_delta64 = ls->delta_exec + 1;
      	ls->delta_exec = 0;
      
      	sample_interval64 = this_rq->clock - ls->load_update_last;
      	ls->load_update_last = this_rq->clock;
      
      	if ((s64)sample_interval64 < (s64)TICK_NSEC)
      		sample_interval64 = TICK_NSEC;
      
      	if (exec_delta64 > sample_interval64)
      		exec_delta64 = sample_interval64;
      
      	idle_delta64 = sample_interval64 - exec_delta64;
      
      ======>	tmp64 = div64_64(SCHED_LOAD_SCALE * exec_delta64, fair_delta64);
      	tmp64 = div64_64(tmp64 * exec_delta64, sample_interval64);
      
      	this_load = (unsigned long)tmp64;
      
      do_avg:
      
      	/* Update our load: */
      	for (i = 0, scale = 1; i < CPU_LOAD_IDX_MAX; i++, scale += scale) {
      		unsigned long old_load, new_load;
      
      		/* scale is effectively 1 << i now, and >> i divides by scale */
      
      		old_load = this_rq->cpu_load[i];
      		new_load = this_load;
      
      		this_rq->cpu_load[i] = (old_load*(scale-1) + new_load) >> i;
      	}
      }
      
      For stable only; the code has been removed in 2.6.24.
      Signed-off-by: default avatarChuck Ebbert <cebbert@redhat.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      23a5e6a5
    • Alexey Starikovskiy's avatar
      ACPI: VIDEO: Adjust current level to closest available one. · 77675886
      Alexey Starikovskiy authored
      patch 63f0edfc in mainline.
      
      ACPI: VIDEO: Adjust current level to closest available one.
      Signed-off-by: default avatarAlexey Starikovskiy <astarikovskiy@suse.de>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Cc: Tobias Powalowski <t.powa@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      77675886
    • Jeff Garzik's avatar
      libata: sata_sis: use correct S/G table size · 2fcce6c9
      Jeff Garzik authored
      patch 96af1547 in mainline.
      
      [libata] sata_sis: use correct S/G table size
      
      sata_sis has the same restrictions as other SFF controllers, and so must
      use LIBATA_MAX_PRD to denote that SCSI may only fill ATA_MAX_PRD/2
      entries, due to our need to handle IOMMU merging.
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Cc: Tobias Powalowski <t.powa@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2fcce6c9
    • Tejun Heo's avatar
      sata_sis: fix SCR read breakage · 458c3a1a
      Tejun Heo authored
      patch aaa092a1 in mainline.
      
      sata_sis: fix SCR read breakage
      
      SCR read for controllers which uses PCI configuration space for SCR
      access got broken while adding @val argument to SCR accessors.  Fix
      it.
      Signed-off-by: default avatarTejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      Cc: Tobias Powalowski <t.powa@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      458c3a1a
    • Fengguang Wu's avatar
      reiserfs: don't drop PG_dirty when releasing sub-page-sized dirty file · a47a72d3
      Fengguang Wu authored
      patch c06a018f in mainline.
      
      This is not a new problem in 2.6.23-git17.  2.6.22/2.6.23 is buggy in the
      same way.
      
      Reiserfs could accumulate dirty sub-page-size files until umount time. 
      They cannot be synced to disk by pdflush routines or explicit `sync'
      commands.  Only `umount' can do the trick.
      
      The direct cause is: the dirty page's PG_dirty is wrongly _cleared_.
      Call trace:
      	 [<ffffffff8027e920>] cancel_dirty_page+0xd0/0xf0
      	 [<ffffffff8816d470>] :reiserfs:reiserfs_cut_from_item+0x660/0x710
      	 [<ffffffff8816d791>] :reiserfs:reiserfs_do_truncate+0x271/0x530
      	 [<ffffffff8815872d>] :reiserfs:reiserfs_truncate_file+0xfd/0x3b0
      	 [<ffffffff8815d3d0>] :reiserfs:reiserfs_file_release+0x1e0/0x340
      	 [<ffffffff802a187c>] __fput+0xcc/0x1b0
      	 [<ffffffff802a1ba6>] fput+0x16/0x20
      	 [<ffffffff8029e676>] filp_close+0x56/0x90
      	 [<ffffffff8029fe0d>] sys_close+0xad/0x110
      	 [<ffffffff8020c41e>] system_call+0x7e/0x83
      
      Fix the bug by removing the cancel_dirty_page() call. Tests show that
      it causes no bad behaviors on various write sizes.
      
      === for the patient ===
      Here are more detailed demonstrations of the problem.
      
      1) the page has both PG_dirty(D)/PAGECACHE_TAG_DIRTY(d) after being written to;
         and then only PAGECACHE_TAG_DIRTY(d) remains after the file is closed.
      
      ------------------------------ screen 0 ------------------------------
      [T0] root /home/wfg# cat > /test/tiny
      [T1] hi
      [T2] root /home/wfg#
      
      ------------------------------ screen 1 ------------------------------
      [T1] root /home/wfg# echo /test/tiny > /proc/filecache
      [T1] root /home/wfg# cat /proc/filecache
           # file /test/tiny
           # flags R:referenced A:active M:mmap U:uptodate D:dirty W:writeback O:owner B:buffer d:dirty w:writeback
           # idx   len     state   refcnt
           0       1       ___UD__Bd_      2
      [T2] root /home/wfg# cat /proc/filecache
           # file /test/tiny
           # flags R:referenced A:active M:mmap U:uptodate D:dirty W:writeback O:owner B:buffer d:dirty w:writeback
           # idx   len     state   refcnt
           0       1       ___U___Bd_      2
      
      2) note the non-zero 'cancelled_write_bytes' after /tmp/hi is copied.
      
      ------------------------------ screen 0 ------------------------------
      [T0] root /home/wfg# echo hi > /tmp/hi
      [T1] root /home/wfg# cp /tmp/hi /dev/stdin /test
      [T2] hi
      [T3] root /home/wfg#
      
      ------------------------------ screen 1 ------------------------------
      [T1] root /proc/4397# cd /proc/`pidof cp`
      [T1] root /proc/4713# cat io
           rchar: 8396
           wchar: 3
           syscr: 20
           syscw: 1
           read_bytes: 0
           write_bytes: 20480
           cancelled_write_bytes: 4096
      [T2] root /proc/4713# cat io
           rchar: 8399
           wchar: 6
           syscr: 21
           syscw: 2
           read_bytes: 0
           write_bytes: 24576
           cancelled_write_bytes: 4096
      
      //Question: the 'write_bytes' is a bit more than expected ;-)
      Tested-by: default avatarMaxim Levitsky <maximlevitsky@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarFengguang Wu <wfg@mail.ustc.edu.cn>
      Reviewed-by: default avatarChris Mason <chris.mason@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a47a72d3