Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 8月, 2011 5 次提交
    • A
      powerpc: Jump label misalignment causes oops at boot · c113a3ae
      由 Anton Blanchard 提交于 
      I hit an oops at boot on the first instruction of timer_cpu_notify:

NIP [c000000000722f88] .timer_cpu_notify+0x0/0x388

The code should look like:

c000000000722f78:       eb e9 00 30     ld      r31,48(r9)
c000000000722f7c:       2f bf 00 00     cmpdi   cr7,r31,0
c000000000722f80:       40 9e ff 44     bne+    cr7,c000000000722ec4
c000000000722f84:       4b ff ff 74     b       c000000000722ef8

c000000000722f88 <.timer_cpu_notify>:
c000000000722f88:       7c 08 02 a6     mflr    r0
c000000000722f8c:       2f a4 00 07     cmpdi   cr7,r4,7
c000000000722f90:       fb c1 ff f0     std     r30,-16(r1)
c000000000722f94:       fb 61 ff d8     std     r27,-40(r1)

But the oops output shows:

eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 7c0803a6 ebe1fff8 4e800020
00000000 ebe90030 c0000000 00ad0a28 00000000 2fa40007 fbc1fff0 fb61ffd8

So we scribbled over our instructions with c000000000ad0a28, which
is an address inside the jump_table ELF section.

It turns out the jump_table section is only aligned to 8 bytes but
we are aligning our entries within the section to 16 bytes. This
means our entries are offset from the table:

c000000000acd4a8 <__start___jump_table>:
        ...
c000000000ad0a10:       c0 00 00 00     lfs     f0,0(0)
c000000000ad0a14:       00 70 cd 5c     .long 0x70cd5c
c000000000ad0a18:       c0 00 00 00     lfs     f0,0(0)
c000000000ad0a1c:       00 70 cd 90     .long 0x70cd90
c000000000ad0a20:       c0 00 00 00     lfs     f0,0(0)
c000000000ad0a24:       00 ac a4 20     .long 0xaca420

And the jump table sort code gets very confused and writes into the
wrong spot. Remove the alignment, and also remove the padding since
we it saves some space and we shouldn't need it.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c113a3ae
    • A
      powerpc: Clean up some panic messages in prom_init · fbafd728
      由 Anton Blanchard 提交于 
      Add a newline to the panic messages in make_room. Also fix a
comment that suggested our chunk size is 4Mb. It's 1MB.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      fbafd728
    • A
      powerpc: Fix device tree claim code · 966728dd
      由 Anton Blanchard 提交于 
      I have a box that fails in OF during boot with:

DEFAULT CATCH!, exception-handler=fff00400
at   %SRR0: 49424d2c4c6f6768   %SRR1: 800000004000b002

ie "IBM,Logh". OF got corrupted with a device tree string.

Looking at make_room and alloc_up, we claim the first chunk (1 MB)
but we never claim any more. mem_end is always set to alloc_top
which is the top of our available address space, guaranteeing we will
never call alloc_up and claim more memory.

Also alloc_up wasn't setting alloc_bottom to the bottom of the
available address space.

This doesn't help the box to boot, but we at least fail with
an obvious error. We could relocate the device tree in a future
patch.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      966728dd
    • S
      powerpc: Return the_cpu_ spec from identify_cpu · 26ee9767
      由 Scott Wood 提交于 
      Commit af9eef3c caused cpu_setup to see
the_cpu_spec, rather than the source struct.  However, on 32-bit, the
return value of identify_cpu was being used for feature fixups, and
identify_cpu was returning the source struct.  So if cpu_setup patches
the feature bits, the update won't affect the fixups.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      26ee9767
    • S
      powerpc: mtspr/mtmsr should take an unsigned long · 326ed6a9
      由 Scott Wood 提交于 
      Add a cast in case the caller passes in a different type, as it would
if mtspr/mtmsr were functions.

Previously, if a 64-bit type was passed in on 32-bit, GCC would bind the
constraint to a pair of registers, and would substitute the first register
in the pair in the asm code.  This corresponds to the upper half of the
64-bit register, which is generally not the desired behavior.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      326ed6a9
  3. 03 8月, 2011 1 次提交
  5. 27 7月, 2011 5 次提交
  7. 26 7月, 2011 1 次提交
  9. 24 7月, 2011 1 次提交
  11. 23 7月, 2011 1 次提交
    • O
      virtio: expose for non-virtualization users too · e7254219
      由 Ohad Ben-Cohen 提交于 
      virtio has been so far used only in the context of virtualization,
and the virtio Kconfig was sourced directly by the relevant arch
Kconfigs when VIRTUALIZATION was selected.

Now that we start using virtio for inter-processor communications,
we need to source the virtio Kconfig outside of the virtualization
scope too.

Moreover, some architectures might use virtio for both virtualization
and inter-processor communications, so directly sourcing virtio
might yield unexpected results due to conflicting selections.

The simple solution offered by this patch is to always source virtio's
Kconfig in drivers/Kconfig, and remove it from the appropriate arch
Kconfigs. Additionally, a virtio menu entry has been added so virtio
drivers don't show up in the general drivers menu.

This way anyone can use virtio, though it's arguably less accessible
(and neat!) for virtualization users now.

Note: some architectures (mips and sh) seem to have a VIRTUALIZATION
menu merely for sourcing virtio's Kconfig, so that menu is removed too.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      e7254219
  13. 22 7月, 2011 5 次提交
  15. 21 7月, 2011 2 次提交
    • P
      treewide: fix potentially dangerous trailing ';' in #defined values/expressions · 497888cf
      由 Phil Carmody 提交于 
      All these are instances of
  #define NAME value;
or
  #define NAME(params_opt) value;

These of course fail to build when used in contexts like
  if(foo $OP NAME)
  while(bar $OP NAME)
and may silently generate the wrong code in contexts such as
  foo = NAME + 1;    /* foo = value; + 1; */
  bar = NAME - 1;    /* bar = value; - 1; */
  baz = NAME & quux; /* baz = value; & quux; */

Reported on comp.lang.c,
Message-ID: <ab0d55fe-25e5-482b-811e-c475aa6065c3@c29g2000yqd.googlegroups.com>
Initial analysis of the dangers provided by Keith Thompson in that thread.

There are many more instances of more complicated macros having unnecessary
trailing semicolons, but this pile seems to be all of the cases of simple
values suffering from the problem. (Thus things that are likely to be found
in one of the contexts above, more complicated ones aren't.)
Signed-off-by: NPhil Carmody <ext-phil.2.carmody@nokia.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      497888cf
    • J
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      由 Josef Bacik 提交于 
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
in fsync to make it less of a painful operation, so push down taking i_mutex and
the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
file systems can drop taking the i_mutex altogether it seems, like ext3 and
ocfs2.  For correctness sake I just pushed everything down in all cases to make
sure that we keep the current behavior the same for everybody, and then each
individual fs maintainer can make up their mind about what to do from there.
Thanks,
Acked-by: NJan Kara <jack@suse.cz>
Signed-off-by: NJosef Bacik <josef@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  17. 20 7月, 2011 1 次提交
  19. 19 7月, 2011 12 次提交
  21. 13 7月, 2011 2 次提交
  23. 12 7月, 2011 4 次提交