1. 30 6月, 2008 2 次提交
    • T
      ptrace GET/SET FPXREGS broken · 11dbc963
      TAKADA Yoshihito 提交于
      When I update kernel 2.6.25 from 2.6.24, gdb does not work.
      On 2.6.25, ptrace(PTRACE_GETFPXREGS, ...) returns ENODEV.
      
      But 2.6.24 kernel's ptrace() returns EIO.
      It is issue of compatibility.
      
      I attached test program as pt.c and patch for fix it.
      
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <signal.h>
      #include <errno.h>
      #include <sys/ptrace.h>
      #include <sys/types.h>
      
      struct user_fxsr_struct {
      	unsigned short	cwd;
      	unsigned short	swd;
      	unsigned short	twd;
      	unsigned short	fop;
      	long	fip;
      	long	fcs;
      	long	foo;
      	long	fos;
      	long	mxcsr;
      	long	reserved;
      	long	st_space[32];	/* 8*16 bytes for each FP-reg = 128 bytes */
      	long	xmm_space[32];	/* 8*16 bytes for each XMM-reg = 128 bytes */
      	long	padding[56];
      };
      
      int main(void)
      {
        pid_t pid;
      
        pid = fork();
      
        switch(pid){
        case -1:/*  error */
          break;
        case 0:/*  child */
          child();
          break;
        default:
          parent(pid);
          break;
        }
        return 0;
      }
      
      int child(void)
      {
        ptrace(PTRACE_TRACEME);
        kill(getpid(), SIGSTOP);
        sleep(10);
        return 0;
      }
      int parent(pid_t pid)
      {
        int ret;
        struct user_fxsr_struct fpxregs;
      
        ret = ptrace(PTRACE_GETFPXREGS, pid, 0, &fpxregs);
        if(ret < 0){
          printf("%d: %s.\n", errno, strerror(errno));
        }
        kill(pid, SIGCONT);
        wait(pid);
        return 0;
      }
      
      /* in the kerel, at kernel/i387.c get_fpxregs() */
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      11dbc963
    • Z
      x86: fix cpu hotplug crash · fcb43042
      Zhang, Yanmin 提交于
      Vegard Nossum reported crashes during cpu hotplug tests:
      
        http://marc.info/?l=linux-kernel&m=121413950227884&w=4
      
      In function _cpu_up, the panic happens when calling
      __raw_notifier_call_chain at the second time. Kernel doesn't panic when
      calling it at the first time. If just say because of nr_cpu_ids, that's
      not right.
      
      By checking the source code, I found that function do_boot_cpu is the culprit.
      Consider below call chain:
       _cpu_up=>__cpu_up=>smp_ops.cpu_up=>native_cpu_up=>do_boot_cpu.
      
      So do_boot_cpu is called in the end. In do_boot_cpu, if
      boot_error==true, cpu_clear(cpu, cpu_possible_map) is executed. So later
      on, when _cpu_up calls __raw_notifier_call_chain at the second time to
      report CPU_UP_CANCELED, because this cpu is already cleared from
      cpu_possible_map, get_cpu_sysdev returns NULL.
      
      Many resources are related to cpu_possible_map, so it's better not to
      change it.
      
      Below patch against 2.6.26-rc7 fixes it by removing the bit clearing in
      cpu_possible_map.
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Tested-by: NVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fcb43042
  2. 26 6月, 2008 2 次提交
  3. 24 6月, 2008 1 次提交
  4. 20 6月, 2008 4 次提交
    • J
      xen: don't drop NX bit · ebb9cfe2
      Jeremy Fitzhardinge 提交于
      Because NX is now enforced properly, we must put the hypercall page
      into the .text segment so that it is executable.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stable Kernel <stable@kernel.org>
      Cc: the arch/x86 maintainers <x86@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ebb9cfe2
    • J
      xen: mask unwanted pte bits in __supported_pte_mask · 05345b0f
      Jeremy Fitzhardinge 提交于
      [ Stable: this isn't a bugfix in itself, but it's a pre-requiste
        for "xen: don't drop NX bit" ]
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stable Kernel <stable@kernel.org>
      Cc: the arch/x86 maintainers <x86@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      05345b0f
    • I
      xen: Use wmb instead of rmb in xen_evtchn_do_upcall(). · 46539383
      Isaku Yamahata 提交于
      This patch is ported one from 534:77db69c38249 of linux-2.6.18-xen.hg.
      Use wmb instead of rmb to enforce ordering between
      evtchn_upcall_pending and evtchn_pending_sel stores
      in xen_evtchn_do_upcall().
      
      Cc: Samuel Thibault <samuel.thibault@eu.citrix.com>
      Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: the arch/x86 maintainers <x86@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      46539383
    • S
      x86: fix NULL pointer deref in __switch_to · 54481cf8
      Suresh Siddha 提交于
      I am able to reproduce the oops reported by Simon in __switch_to() with
      lguest.
      
      My debug showed that there is at least one lguest specific
      issue (which should be present in 2.6.25 and before aswell) and it got
      exposed with a kernel oops with the recent fpu dynamic allocation patches.
      
      In addition to the previous possible scenario (with fpu_counter), in the
      presence of lguest, it is possible that the cpu's TS bit it still set and the
      lguest launcher task's thread_info has TS_USEDFPU still set.
      
      This is because of the way the lguest launcher handling the guest's TS bit.
      (look at lguest_set_ts() in lguest_arch_run_guest()). This can result
      in a DNA fault while doing unlazy_fpu() in __switch_to(). This will
      end up causing a DNA fault in the context of new process thats
      getting context switched in (as opossed to handling DNA fault in the context
      of lguest launcher/helper process).
      
      This is wrong in both pre and post 2.6.25 kernels. In the recent
      2.6.26-rc series, this is showing up as NULL pointer dereferences or
      sleeping function called from atomic context(__switch_to()), as
      we free and dynamically allocate the FPU context for the newly
      created threads. Older kernels might show some FPU corruption for processes
      running inside of lguest.
      
      With the appended patch, my test system is running for more than 50 mins
      now. So atleast some of your oops (hopefully all!) should get fixed.
      Please give it a try. I will spend more time with this fix tomorrow.
      Reported-by: NSimon Holm Thøgersen <odie@cs.aau.dk>
      Reported-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      54481cf8
  5. 19 6月, 2008 22 次提交
  6. 18 6月, 2008 9 次提交
    • P
      [POWERPC] Clear sub-page HPTE present bits when demoting page size · 65ba6cdc
      Paul Mackerras 提交于
      When we demote a slice from 64k to 4k, and we are about to insert an
      HPTE for a 4k subpage and we notice that there is an existing 64k
      HPTE, we first invalidate that HPTE before inserting the new 4k
      subpage HPTE.  Since the bits that encode which hash bucket the old
      HPTE was in overlap with the bits that encode which of the 16 subpages
      have HPTEs, we need to clear out the subpage HPTE-present bits before
      starting to insert HPTEs for the 4k subpages.  If we don't do that, we
      can erroneously think that a subpage already has an HPTE when it
      doesn't.
      
      That in itself wouldn't be such a problem except that when we go to
      update the HPTE that we think is present on machines with a
      hypervisor, the hypervisor can tell us that the HPTE we think is there
      is actually there even though it isn't, which can lead to a process
      getting stuck in a loop, continually faulting.  The reason for the
      confusion is that the AVPN (abbreviated virtual page number) we are
      looking for in the HPTE for a 4k subpage can actually match the AVPN
      in a stale HPTE for another 64k page.  For example, the HPTE for
      the 4k subpage at 0x84000f000 will be in the same hash bucket and have
      the same AVPN as the HPTE for the 64k page at 0x8400f0000.
      
      This fixes the code to clear out the subpage HPTE-present bits.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      65ba6cdc
    • J
      [POWERPC] 4xx: Clear new TLB cache attribute bits in Data Storage vector · b17879f7
      Josh Boyer 提交于
      A recent commit added support for the new 440x6 and 464 cores that have the
      added WL1, IL1I, IL1D, IL2I, and ILD2 bits for the caching attributes in the
      TLBs.  The new bits were cleared in the finish_tlb_load function, however a
      similar bit of code was missed in the DataStorage interrupt vector.
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b17879f7
    • P
      netlink: genl: fix circular locking · 6d1a3fb5
      Patrick McHardy 提交于
      genetlink has a circular locking dependency when dumping the registered
      families:
      
      - dump start:
      genl_rcv()            : take genl_mutex
      genl_rcv_msg()        : call netlink_dump_start() while holding genl_mutex
      netlink_dump_start(),
      netlink_dump()        : take nlk->cb_mutex
      ctrl_dumpfamily()     : try to detect this case and not take genl_mutex a
                              second time
      
      - dump continuance:
      netlink_rcv()         : call netlink_dump
      netlink_dump          : take nlk->cb_mutex
      ctrl_dumpfamily()     : take genl_mutex
      
      Register genl_lock as callback mutex with netlink to fix this. This slightly
      widens an already existing module unload race, the genl ops used during the
      dump might go away when the module is unloaded. Thomas Graf is working on a
      seperate fix for this.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d1a3fb5
    • D
      Revert "mac80211: Use skb_header_cloned() on TX path." · 3a5be7d4
      David S. Miller 提交于
      This reverts commit 608961a5.
      
      The problem is that the mac80211 stack not only needs to be able to
      muck with the link-level headers, it also might need to mangle all of
      the packet data if doing sw wireless encryption.
      
      This fixes kernel bugzilla #10903.  Thanks to Didier Raboud (for the
      bugzilla report), Andrew Prince (for bisecting), Johannes Berg (for
      bringing this bisection analysis to my attention), and Ilpo (for
      trying to analyze this purely from the TCP side).
      
      In 2.6.27 we can take another stab at this, by using something like
      skb_cow_data() when the TX path of mac80211 ends up with a non-NULL
      tx->key.  The ESP protocol code in the IPSEC stack can be used as a
      model for implementation.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a5be7d4
    • R
      af_unix: fix 'poll for write'/ connected DGRAM sockets · 3c73419c
      Rainer Weikusat 提交于
      The unix_dgram_sendmsg routine implements a (somewhat crude)
      form of receiver-imposed flow control by comparing the length of the
      receive queue of the 'peer socket' with the max_ack_backlog value
      stored in the corresponding sock structure, either blocking
      the thread which caused the send-routine to be called or returning
      EAGAIN. This routine is used by both SOCK_DGRAM and SOCK_SEQPACKET
      sockets. The poll-implementation for these socket types is
      datagram_poll from core/datagram.c. A socket is deemed to be writeable
      by this routine when the memory presently consumed by datagrams
      owned by it is less than the configured socket send buffer size. This
      is always wrong for connected PF_UNIX non-stream sockets when the
      abovementioned receive queue is currently considered to be full.
      'poll' will then return, indicating that the socket is writeable, but
      a subsequent write result in EAGAIN, effectively causing an
      (usual) application to 'poll for writeability by repeated send request
      with O_NONBLOCK set' until it has consumed its time quantum.
      
      The change below uses a suitably modified variant of the datagram_poll
      routines for both type of PF_UNIX sockets, which tests if the
      recv-queue of the peer a socket is connected to is presently
      considered to be 'full' as part of the 'is this socket
      writeable'-checking code. The socket being polled is additionally
      put onto the peer_wait wait queue associated with its peer, because the
      unix_dgram_sendmsg routine does a wake up on this queue after a
      datagram was received and the 'other wakeup call' is done implicitly
      as part of skb destruction, meaning, a process blocked in poll
      because of a full peer receive queue could otherwise sleep forever
      if no datagram owned by its socket was already sitting on this queue.
      Among this change is a small (inline) helper routine named
      'unix_recvq_full', which consolidates the actual testing code (in three
      different places) into a single location.
      Signed-off-by: NRainer Weikusat <rweikusat@mssgmbh.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c73419c
    • D
    • A
      tun: Proper handling of IPv6 header in tun driver when TUN_NO_PI is set · f09f7ee2
      Ang Way Chuang 提交于
      By default, tun.c running in TUN_TUN_DEV mode will set the protocol of
      packet to IPv4 if TUN_NO_PI is set. My program failed to work when I
      assumed that the driver will check the first nibble of packet,
      determine IP version and set the appropriate protocol.
      Signed-off-by: NAng Way Chuang <wcang@nav6.org>
      Acked-by: NMax Krasnyansky <maxk@qualcomm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f09f7ee2
    • R
      atl1: relax eeprom mac address error check · 58c7821c
      Radu Cristescu 提交于
      The atl1 driver tries to determine the MAC address thusly:
      
      	- If an EEPROM exists, read the MAC address from EEPROM and
      	  validate it.
      	- If an EEPROM doesn't exist, try to read a MAC address from
      	  SPI flash.
      	- If that fails, try to read a MAC address directly from the
      	  MAC Station Address register.
      	- If that fails, assign a random MAC address provided by the
      	  kernel.
      
      We now have a report of a system fitted with an EEPROM containing all
      zeros where we expect the MAC address to be, and we currently handle
      this as an error condition.  Turns out, on this system the BIOS writes
      a valid MAC address to the NIC's MAC Station Address register, but we
      never try to read it because we return an error when we find the all-
      zeros address in EEPROM.
      
      This patch relaxes the error check and continues looking for a MAC
      address even if it finds an illegal one in EEPROM.
      Signed-off-by: NRadu Cristescu <advantis@gmx.net>
      Signed-off-by: NJay Cliburn <jacliburn@bellsouth.net>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      58c7821c
    • D
      net/enc28j60: low power mode · 7dac6f8d
      David Brownell 提交于
      Keep enc28j60 chips in low-power mode when they're not in use.
      At typically 120 mA, these chips run hot even when idle; this
      low power mode cuts that power usage by a factor of around 100.
      
      This version provides a generic routine to poll a register until
      its masked value equals some value ... e.g. bit set or cleared.
      It's basically what the previous wait_phy_ready() did, but this
      version is generalized to support the handshaking needed to
      enter and exit low power mode.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NClaudio Lanconelli <lanconelli.claudio@eptar.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      7dac6f8d