1. 25 4月, 2007 1 次提交
  2. 24 4月, 2007 1 次提交
    • B
      Taskstats fix the structure members alignment issue · 7e40f2ab
      Balbir Singh 提交于
      We broke the the alignment of members of taskstats to the 8 byte boundary
      with the CSA patches.  In the current kernel, the taskstats structure is
      not suitable for use by 32 bit applications in a 64 bit kernel.
      
      On x86_64
      
      Offsets of taskstats' members (64 bit kernel, 64 bit application)
      
      @taskstats'offsetof[@taskstats'indices] = (
              0,      # version
              4,      # ac_exitcode
              8,      # ac_flag
              9,      # ac_nice
              16,     # cpu_count
              24,     # cpu_delay_total
              32,     # blkio_count
              40,     # blkio_delay_total
              48,     # swapin_count
              56,     # swapin_delay_total
              64,     # cpu_run_real_total
              72,     # cpu_run_virtual_total
              80,     # ac_comm
              112,    # ac_sched
              113,    # ac_pad
              116,    # ac_uid
              120,    # ac_gid
              124,    # ac_pid
              128,    # ac_ppid
              132,    # ac_btime
              136,    # ac_etime
              144,    # ac_utime
              152,    # ac_stime
              160,    # ac_minflt
              168,    # ac_majflt
              176,    # coremem
              184,    # virtmem
              192,    # hiwater_rss
              200,    # hiwater_vm
              208,    # read_char
              216,    # write_char
              224,    # read_syscalls
              232,    # write_syscalls
              240,    # read_bytes
              248,    # write_bytes
              256,    # cancelled_write_bytes
          );
      
      Offsets of taskstats' members (64 bit kernel, 32 bit application)
      
      @taskstats'offsetof[@taskstats'indices] = (
              0,      # version
              4,      # ac_exitcode
              8,      # ac_flag
              9,      # ac_nice
              12,     # cpu_count
              20,     # cpu_delay_total
              28,     # blkio_count
              36,     # blkio_delay_total
              44,     # swapin_count
              52,     # swapin_delay_total
              60,     # cpu_run_real_total
              68,     # cpu_run_virtual_total
              76,     # ac_comm
              108,    # ac_sched
              109,    # ac_pad
              112,    # ac_uid
              116,    # ac_gid
              120,    # ac_pid
              124,    # ac_ppid
              128,    # ac_btime
              132,    # ac_etime
              140,    # ac_utime
              148,    # ac_stime
              156,    # ac_minflt
              164,    # ac_majflt
              172,    # coremem
              180,    # virtmem
              188,    # hiwater_rss
              196,    # hiwater_vm
              204,    # read_char
              212,    # write_char
              220,    # read_syscalls
              228,    # write_syscalls
              236,    # read_bytes
              244,    # write_bytes
              252,    # cancelled_write_bytes
          );
      
      This is one way to solve the problem without re-arranging structure members
      is to pack the structure.  The patch adds an __attribute__((aligned(8))) to
      the taskstats structure members so that 32 bit applications using taskstats
      can work with a 64 bit kernel.
      
      Using __attribute__((packed)) would break the 64 bit alignment of members.
      
      The fix was tested on x86_64. After the fix, we got
      
      Offsets of taskstats' members (64 bit kernel, 64 bit application)
      
      @taskstats'offsetof[@taskstats'indices] = (
              0,      # version
              4,      # ac_exitcode
              8,      # ac_flag
              9,      # ac_nice
              16,     # cpu_count
              24,     # cpu_delay_total
              32,     # blkio_count
              40,     # blkio_delay_total
              48,     # swapin_count
              56,     # swapin_delay_total
              64,     # cpu_run_real_total
              72,     # cpu_run_virtual_total
              80,     # ac_comm
              112,    # ac_sched
              113,    # ac_pad
              120,    # ac_uid
              124,    # ac_gid
              128,    # ac_pid
              132,    # ac_ppid
              136,    # ac_btime
              144,    # ac_etime
              152,    # ac_utime
              160,    # ac_stime
              168,    # ac_minflt
              176,    # ac_majflt
              184,    # coremem
              192,    # virtmem
              200,    # hiwater_rss
              208,    # hiwater_vm
              216,    # read_char
              224,    # write_char
              232,    # read_syscalls
              240,    # write_syscalls
              248,    # read_bytes
              256,    # write_bytes
              264,    # cancelled_write_bytes
          );
      
      Offsets of taskstats' members (64 bit kernel, 32 bit application)
      
      @taskstats'offsetof[@taskstats'indices] = (
              0,      # version
              4,      # ac_exitcode
              8,      # ac_flag
              9,      # ac_nice
              16,     # cpu_count
              24,     # cpu_delay_total
              32,     # blkio_count
              40,     # blkio_delay_total
              48,     # swapin_count
              56,     # swapin_delay_total
              64,     # cpu_run_real_total
              72,     # cpu_run_virtual_total
              80,     # ac_comm
              112,    # ac_sched
              113,    # ac_pad
              120,    # ac_uid
              124,    # ac_gid
              128,    # ac_pid
              132,    # ac_ppid
              136,    # ac_btime
              144,    # ac_etime
              152,    # ac_utime
              160,    # ac_stime
              168,    # ac_minflt
              176,    # ac_majflt
              184,    # coremem
              192,    # virtmem
              200,    # hiwater_rss
              208,    # hiwater_vm
              216,    # read_char
              224,    # write_char
              232,    # read_syscalls
              240,    # write_syscalls
              248,    # read_bytes
              256,    # write_bytes
              264,    # cancelled_write_bytes
          );
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Jay Lan <jlan@engr.sgi.com>
      Cc: Shailabh Nagar <nagar@watson.ibm.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7e40f2ab
  3. 21 4月, 2007 1 次提交
  4. 20 4月, 2007 5 次提交
  5. 18 4月, 2007 7 次提交
  6. 15 4月, 2007 1 次提交
  7. 11 4月, 2007 1 次提交
    • S
      ide: correctly prevent IDE timer expiry function to run if request was already handled · 23450319
      Suleiman Souhlal 提交于
      It is possible for the timer expiry function to run even though the
      request has already been handled: ide_timer_expiry() only checks that
      the handler is not NULL, but it is possible that we have handled a
      request (thus clearing the handler) and then started a new request
      (thus starting the timer again, and setting a handler). 
      
      A simple way to exhibit this is to set the DMA timeout to 1 jiffy and
      run dd: The kernel will panic after a few minutes because
      ide_timer_expiry() tries to add a timer when it's already active.
      
      To fix this, we simply add a request generation count that gets
      incremented at every interrupt, and check in ide_timer_expiry() that
      we have not already handled a new interrupt before running the expiry
      function.
      Signed-off-by: NSuleiman Souhlal <suleiman@google.com>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      23450319
  8. 09 4月, 2007 1 次提交
  9. 08 4月, 2007 1 次提交
    • I
      [PATCH] high-res timers: resume fix · 995f054f
      Ingo Molnar 提交于
      Soeren Sonnenburg reported that upon resume he is getting
      this backtrace:
      
       [<c0119637>] smp_apic_timer_interrupt+0x57/0x90
       [<c0142d30>] retrigger_next_event+0x0/0xb0
       [<c0104d30>] apic_timer_interrupt+0x28/0x30
       [<c0142d30>] retrigger_next_event+0x0/0xb0
       [<c0140068>] __kfifo_put+0x8/0x90
       [<c0130fe5>] on_each_cpu+0x35/0x60
       [<c0143538>] clock_was_set+0x18/0x20
       [<c0135cdc>] timekeeping_resume+0x7c/0xa0
       [<c02aabe1>] __sysdev_resume+0x11/0x80
       [<c02ab0c7>] sysdev_resume+0x47/0x80
       [<c02b0b05>] device_power_up+0x5/0x10
      
      it turns out that on resume we mistakenly re-enable interrupts too
      early.  Do the timer retrigger only on the current CPU.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NSoeren Sonnenburg <kernel@nn7.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      995f054f
  10. 07 4月, 2007 1 次提交
  11. 05 4月, 2007 3 次提交
  12. 04 4月, 2007 3 次提交
  13. 03 4月, 2007 4 次提交
  14. 02 4月, 2007 3 次提交
  15. 31 3月, 2007 1 次提交
  16. 30 3月, 2007 5 次提交
  17. 29 3月, 2007 1 次提交