1. 25 8月, 2008 3 次提交
    • A
      KVM: fix userspace ABI breakage · 1327138e
      Adrian Bunk 提交于
      The following part of commit 9ef621d3
      (KVM: Support mixed endian machines) changed on the size of a struct
      that is exported to userspace:
      
      include/linux/kvm.h:
      
      @@ -318,14 +318,14 @@ struct kvm_trace_rec {
       	__u32 vcpu_id;
       	union {
       		struct {
      -			__u32 cycle_lo, cycle_hi;
      +			__u64 cycle_u64;
       			__u32 extra_u32[KVM_TRC_EXTRA_MAX];
       		} cycle;
       		struct {
       			__u32 extra_u32[KVM_TRC_EXTRA_MAX];
       		} nocycle;
       	} u;
      -};
      +} __attribute__((packed));
      
      Packing a struct was the correct idea, but it packed the wrong struct.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      1327138e
    • A
      KVM: MMU: Fix torn shadow pte · cd5998eb
      Avi Kivity 提交于
      The shadow code assigns a pte directly in one place, which is nonatomic on
      i386 can can cause random memory references.  Fix by using an atomic setter.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      cd5998eb
    • E
      KVM: Use .fixup instead of .text.fixup on __kvm_handle_fault_on_reboot · 18b13e54
      Eduardo Habkost 提交于
      vmlinux.lds expects the fixup code to be on a section named .fixup. The
      .text.fixup section is not mentioned on vmlinux.lds, and is included on
      the resulting vmlinux (just after .text) only because of ld heuristics on
      placing orphan sections.
      
      However, placing .text.fixup outside .text breaks the definition of
      _etext, making it exclude the .text.fixup contents. That makes .text.fixup
      be ignored by the kernel initialization code that needs to know about
      section locations, such as the code setting page protection bits.
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      18b13e54
  2. 24 8月, 2008 3 次提交
  3. 23 8月, 2008 2 次提交
    • S
      ipv6: protocol for address routes · f410a1fb
      Stephen Hemminger 提交于
      This fixes a problem spotted with zebra, but not sure if it is
      necessary a kernel problem.  With IPV6 when an address is added to an
      interface, Zebra creates a duplicate RIB entry, one as a connected
      route, and other as a kernel route.
      
      When an address is added to an interface the RTN_NEWADDR message
      causes Zebra to create a connected route. In IPV4 when an address is
      added to an interface a RTN_NEWROUTE message is set to user space with
      the protocol RTPROT_KERNEL. Zebra ignores these messages, because it
      already has the connected route.
      
      The problem is that route created in IPV6 has route protocol ==
      RTPROT_BOOT.  Was this a design decision or a bug? This fixes it. Same
      patch applies to both net-2.6 and stable.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f410a1fb
    • D
      icmp: icmp_sk() should not use smp_processor_id() in preemptible code · fdc0bde9
      Denis V. Lunev 提交于
      Pass namespace into icmp_xmit_lock, obtain socket inside and return
      it as a result for caller.
      
      Thanks Alexey Dobryan for this report:
      
      Steps to reproduce:
      
      	CONFIG_PREEMPT=y
      	CONFIG_DEBUG_PREEMPT=y
      	tracepath <something>
      
      BUG: using smp_processor_id() in preemptible [00000000] code: tracepath/3205
      caller is icmp_sk+0x15/0x30
      Pid: 3205, comm: tracepath Not tainted 2.6.27-rc4 #1
      
      Call Trace:
       [<ffffffff8031af14>] debug_smp_processor_id+0xe4/0xf0
       [<ffffffff80409405>] icmp_sk+0x15/0x30
       [<ffffffff8040a17b>] icmp_send+0x4b/0x3f0
       [<ffffffff8025a415>] ? trace_hardirqs_on_caller+0xd5/0x160
       [<ffffffff8025a4ad>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff8023a475>] ? local_bh_enable_ip+0x95/0x110
       [<ffffffff804285b9>] ? _spin_unlock_bh+0x39/0x40
       [<ffffffff8025a26c>] ? mark_held_locks+0x4c/0x90
       [<ffffffff8025a4ad>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff8025a415>] ? trace_hardirqs_on_caller+0xd5/0x160
       [<ffffffff803e91b4>] ip_fragment+0x8d4/0x900
       [<ffffffff803e7030>] ? ip_finish_output2+0x0/0x290
       [<ffffffff803e91e0>] ? ip_finish_output+0x0/0x60
       [<ffffffff803e6650>] ? dst_output+0x0/0x10
       [<ffffffff803e922c>] ip_finish_output+0x4c/0x60
       [<ffffffff803e92e3>] ip_output+0xa3/0xf0
       [<ffffffff803e68d0>] ip_local_out+0x20/0x30
       [<ffffffff803e753f>] ip_push_pending_frames+0x27f/0x400
       [<ffffffff80406313>] udp_push_pending_frames+0x233/0x3d0
       [<ffffffff804067d1>] udp_sendmsg+0x321/0x6f0
       [<ffffffff8040d155>] inet_sendmsg+0x45/0x80
       [<ffffffff803b967f>] sock_sendmsg+0xdf/0x110
       [<ffffffff8024a100>] ? autoremove_wake_function+0x0/0x40
       [<ffffffff80257ce5>] ? validate_chain+0x415/0x1010
       [<ffffffff8027dc10>] ? __do_fault+0x140/0x450
       [<ffffffff802597d0>] ? __lock_acquire+0x260/0x590
       [<ffffffff803b9e55>] ? sockfd_lookup_light+0x45/0x80
       [<ffffffff803ba50a>] sys_sendto+0xea/0x120
       [<ffffffff80428e42>] ? _spin_unlock_irqrestore+0x42/0x80
       [<ffffffff803134bc>] ? __up_read+0x4c/0xb0
       [<ffffffff8024e0c6>] ? up_read+0x26/0x30
       [<ffffffff8020b8bb>] system_call_fastpath+0x16/0x1b
      
      icmp6_sk() is similar.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fdc0bde9
  4. 22 8月, 2008 32 次提交