Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 30 10月, 2011 9 次提交
  3. 29 10月, 2011 2 次提交
  5. 28 10月, 2011 1 次提交
    • E
      compat: sync compat_stats with statfs. · 1448c721
      由 Eric W. Biederman 提交于 
      This was found by inspection while tracking a similar
bug in compat_statfs64, that has been fixed in mainline
since decemeber.

- This fixes a bug where not all of the f_spare fields
  were cleared on mips and s390.
- Add the f_flags field to struct compat_statfs
- Copy f_flags to userspace in case someone cares.
- Use __clear_user to copy the f_spare field to userspace
  to ensure that all of the elements of f_spare are cleared.
  On some architectures f_spare is has 5 ints and on some
  architectures f_spare only has 4 ints.  Which makes
  the previous technique of clearing each int individually
  broken.

I don't expect anyone actually uses the old statfs system
call anymore but if they do let them benefit from having
the compat and the native version working the same.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      1448c721
  7. 27 10月, 2011 7 次提交
  9. 26 10月, 2011 15 次提交
  11. 25 10月, 2011 5 次提交
    • J
      x86: Fix compilation bug in kprobes' twobyte_is_boostable · 315eb8a2
      由 Josh Stone 提交于 
      When compiling an i386_defconfig kernel with gcc-4.6.1-9.fc15.i686, I
noticed a warning about the asm operand for test_bit in kprobes'
can_boost.  I discovered that this caused only the first long of
twobyte_is_boostable[] to be output.

Jakub filed and fixed gcc PR50571 to correct the warning and this output
issue.  But to solve it for less current gcc, we can make kprobes'
twobyte_is_boostable[] non-const, and it won't be optimized out.

Before:

    CC      arch/x86/kernel/kprobes.o
  In file included from include/linux/bitops.h:22:0,
                   from include/linux/kernel.h:17,
                   from [...]/arch/x86/include/asm/percpu.h:44,
                   from [...]/arch/x86/include/asm/current.h:5,
                   from [...]/arch/x86/include/asm/processor.h:15,
                   from [...]/arch/x86/include/asm/atomic.h:6,
                   from include/linux/atomic.h:4,
                   from include/linux/mutex.h:18,
                   from include/linux/notifier.h:13,
                   from include/linux/kprobes.h:34,
                   from arch/x86/kernel/kprobes.c:43:
  [...]/arch/x86/include/asm/bitops.h: In function ‘can_boost.part.1’:
  [...]/arch/x86/include/asm/bitops.h:319:2: warning: use of memory input
        without lvalue in asm operand 1 is deprecated [enabled by default]

  $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
       551:	0f a3 05 00 00 00 00 	bt     %eax,0x0
                          554: R_386_32	.rodata.cst4

  $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o

  arch/x86/kernel/kprobes.o:     file format elf32-i386

  Contents of section .data:
   0000 48000000 00000000 00000000 00000000  H...............
  Contents of section .rodata.cst4:
   0000 4c030000                             L...

Only a single long of twobyte_is_boostable[] is in the object file.

After, without the const on twobyte_is_boostable:

  $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
       551:	0f a3 05 20 00 00 00 	bt     %eax,0x20
                          554: R_386_32	.data

  $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o

  arch/x86/kernel/kprobes.o:     file format elf32-i386

  Contents of section .data:
   0000 48000000 00000000 00000000 00000000  H...............
   0010 00000000 00000000 00000000 00000000  ................
   0020 4c030000 0f000200 ffff0000 ffcff0c0  L...............
   0030 0000ffff 3bbbfff8 03ff2ebb 26bb2e77  ....;.......&..w

Now all 32 bytes are output into .data instead.
Signed-off-by: NJosh Stone <jistone@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      315eb8a2
    • N
      ARM: 7139/1: fix compilation with CONFIG_ARM_ATAG_DTB_COMPAT and large TEXT_OFFSET · 531a6a94
      由 Nicolas Pitre 提交于 
      If TEXT_OFFSET is too large (e.g. like on MSM) the resulting immediate
argument gets wider than 8 bits.

Noticed by David Brown <davidb@codeaurora.org>
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      531a6a94
    • K
      m68k: Finally remove leftover markers sections · bc74ee97
      由 Kirill Tkhai 提交于 
      Markers have removed already twice:

1: fc537766
2: eb878b3b

But a little bit is still here.
Signed-off-by: NTkhai Kirill <tkhai@yandex.ru>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      bc74ee97
    • F
      m68k/mac: Fix mac_irq_pending() for PSC MACE and SCC · 8b223432
      由 Finn Thain 提交于 
      Add missing return statement. The docs say that the level 4 PSC IRQs
relate to MACE DMA and SCC. Since those drivers don't call
mac_irq_pending() this patch has no affect. But it should be fixed all the
same, since it can be useful for MACE debugging.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      8b223432
    • F
      m68k/mac: Fix compiler warning in via_read_time() · 75a23850
      由 Finn Thain 提交于 
      The algorithm described in the comment compares two reads from the RTC but
the code actually reads once and compares the result to an uninitialized
value. This causes the compiler to warn, "last_result maybe used
uninitialized". Make the code match the comment, fix the warning and
perhaps improve reliability. Tested on a Quadra 700.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      75a23850
  13. 24 10月, 2011 1 次提交
    • T
      x86: Fix S4 regression · 8548c84d
      由 Takashi Iwai 提交于 
      Commit 4b239f45 ("x86-64, mm: Put early page table high") causes a S4
regression since 2.6.39, namely the machine reboots occasionally at S4
resume.  It doesn't happen always, overall rate is about 1/20.  But,
like other bugs, once when this happens, it continues to happen.

This patch fixes the problem by essentially reverting the memory
assignment in the older way.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: <stable@kernel.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Yinghai Lu <yinghai.lu@oracle.com>
[ We'll hopefully find the real fix, but that's too late for 3.1 now ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8548c84d