1. 19 10月, 2006 5 次提交
    • G
      PCI Hotplug: move pci_hotplug.h to include/linux/ · 7a54f25c
      Greg Kroah-Hartman 提交于
      This makes it possible to build pci hotplug drivers outside of the main
      kernel tree, and Sam keeps telling me to move local header files to
      their proper places...
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7a54f25c
    • M
      PCI: optionally sort device lists breadth-first · 6b4b78fe
      Matt Domsch 提交于
      Problem:
      New Dell PowerEdge servers have 2 embedded ethernet ports, which are
      labeled NIC1 and NIC2 on the chassis, in the BIOS setup screens, and
      in the printed documentation.  Assuming no other add-in ethernet ports
      in the system, Linux 2.4 kernels name these eth0 and eth1
      respectively.  Many people have come to expect this naming.  Linux 2.6
      kernels name these eth1 and eth0 respectively (backwards from
      expectations).  I also have reports that various Sun and HP servers
      have similar behavior.
      
      
      Root cause:
      Linux 2.4 kernels walk the pci_devices list, which happens to be
      sorted in breadth-first order (or pcbios_find_device order on i386,
      which most often is breadth-first also).  2.6 kernels have both the
      pci_devices list and the pci_bus_type.klist_devices list, the latter
      is what is walked at driver load time to match the pci_id tables; this
      klist happens to be in depth-first order.
      
      On systems where, for physical routing reasons, NIC1 appears on a
      lower bus number than NIC2, but NIC2's bridge is discovered first in
      the depth-first ordering, NIC2 will be discovered before NIC1.  If the
      list were sorted breadth-first, NIC1 would be discovered before NIC2.
      
      A PowerEdge 1955 system has the following topology which easily
      exhibits the difference between depth-first and breadth-first device
      lists.
      
      -[0000:00]-+-00.0  Intel Corporation 5000P Chipset Memory Controller Hub
                 +-02.0-[0000:03-08]--+-00.0-[0000:04-07]--+-00.0-[0000:05-06]----00.0-[0000:06]----00.0  Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC2, 2.4 kernel name eth1, 2.6 kernel name eth0)
                 +-1c.0-[0000:01-02]----00.0-[0000:02]----00.0  Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC1, 2.4 kernel name eth0, 2.6 kernel name eth1)
      
      
      Other factors, such as device driver load order and the presence of
      PCI slots at various points in the bus hierarchy further complicate
      this problem; I'm not trying to solve those here, just restore the
      device order, and thus basic behavior, that 2.4 kernels had.
      
      
      Solution:
      
      The solution can come in multiple steps.
      
      Suggested fix #1: kernel
      Patch below optionally sorts the two device lists into breadth-first
      ordering to maintain compatibility with 2.4 kernels.  It adds two new
      command line options:
        pci=bfsort
        pci=nobfsort
      to force the sort order, or not, as you wish.  It also adds DMI checks
      for the specific Dell systems which exhibit "backwards" ordering, to
      make them "right".
      
      
      Suggested fix #2: udev rules from userland
      Many people also have the expectation that embedded NICs are always
      discovered before add-in NICs (which this patch does not try to do).
      Using the PCI IRQ Routing Table provided by system BIOS, it's easy to
      determine which PCI devices are embedded, or if add-in, which PCI slot
      they're in.  I'm working on a tool that would allow udev to name
      ethernet devices in ascending embedded, slot 1 .. slot N order,
      subsort by PCI bus/dev/fn breadth-first.  It'll be possible to use it
      independent of udev as well for those distributions that don't use
      udev in their installers.
      
      Suggested fix #3: system board routing rules
      One can constrain the system board layout to put NIC1 ahead of NIC2
      regardless of breadth-first or depth-first discovery order.  This adds
      a significant level of complexity to board routing, and may not be
      possible in all instances (witness the above systems from several
      major manufacturers).  I don't want to encourage this particular train
      of thought too far, at the expense of not doing #1 or #2 above.
      
      
      Feedback appreciated.  Patch tested on a Dell PowerEdge 1955 blade
      with 2.6.18.
      
      You'll also note I took some liberty and temporarily break the klist
      abstraction to simplify and speed up the sort algorithm.  I think
      that's both safe and appropriate in this instance.
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      6b4b78fe
    • A
      pci: Additional search functions · 29f3eb64
      Alan Cox 提交于
      In order to finish converting to pci_get_* interfaces we need to add a couple
      of bits of missing functionaility
      
      pci_get_bus_and_slot() provides the equivalent to pci_find_slot()
      (pci_get_slot is already taken as a name for something similar but not the
      same)
      
      pci_get_device_reverse() is the equivalent of pci_find_device_reverse but
      refcounting
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      29f3eb64
    • M
      [S390] Fix pte type checking. · 83377484
      Martin Schwidefsky 提交于
      handle_pte_fault uses pte_present, pte_none and pte_file to find out
      the type of a pte. That is done without holding the page table lock.
      This clashes with the way how ptep_clear_flush removes active page
      table entries from the system. First the ipte instruction is used
      to invalidate the pte and remove all plt entries for the page. The
      ipte sets the hardware invalid bit without changing any other bit.
      After the ipte finished the pte is cleared. A concurrent fault can
      observe the the previously valid pte with the invalid bit set. With
      the current encoding of the different pte types an invalidated
      read-only pte can be misinterpreted as a swap-pte.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      83377484
    • H
      [S390] Wire up epoll_pwait syscall. · f5956f84
      Heiko Carstens 提交于
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      f5956f84
  2. 18 10月, 2006 3 次提交
  3. 17 10月, 2006 5 次提交
  4. 16 10月, 2006 5 次提交
  5. 14 10月, 2006 5 次提交
  6. 13 10月, 2006 3 次提交
  7. 12 10月, 2006 14 次提交
    • J
      [PATCH] ide-cd: fix breakage with internally queued commands · cea2885a
      Jens Axboe 提交于
      We still need to maintain a private PC style command, since it
      isn't completely unified with REQ_TYPE_BLOCK_PC yet.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      cea2885a
    • J
      [PATCH] elevator: elevator_type member not used · 2b1191af
      Jens Axboe 提交于
      elevator_type field in elevator_type structure is useless:
      it isn't used anywhere in kernel sources.
      Signed-off-by: NVasily Tarasov <vtaras@openvz.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      2b1191af
    • Y
    • V
      [SCTP]: Fix receive buffer accounting. · 331c4ee7
      Vlad Yasevich 提交于
      When doing receiver buffer accounting, we always used skb->truesize.
      This is problematic when processing bundled DATA chunks because for
      every DATA chunk that could be small part of one large skb, we would
      charge the size of the entire skb.  The new approach is to store the
      size of the DATA chunk we are accounting for in the sctp_ulpevent
      structure and use that stored value for accounting.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      331c4ee7
    • V
      IPsec: correct semantics for SELinux policy matching · 5b368e61
      Venkat Yekkirala 提交于
      Currently when an IPSec policy rule doesn't specify a security
      context, it is assumed to be "unlabeled" by SELinux, and so
      the IPSec policy rule fails to match to a flow that it would
      otherwise match to, unless one has explicitly added an SELinux
      policy rule allowing the flow to "polmatch" to the "unlabeled"
      IPSec policy rules. In the absence of such an explicitly added
      SELinux policy rule, the IPSec policy rule fails to match and
      so the packet(s) flow in clear text without the otherwise applicable
      xfrm(s) applied.
      
      The above SELinux behavior violates the SELinux security notion of
      "deny by default" which should actually translate to "encrypt by
      default" in the above case.
      
      This was first reported by Evgeniy Polyakov and the way James Morris
      was seeing the problem was when connecting via IPsec to a
      confined service on an SELinux box (vsftpd), which did not have the
      appropriate SELinux policy permissions to send packets via IPsec.
      
      With this patch applied, SELinux "polmatching" of flows Vs. IPSec
      policy rules will only come into play when there's a explicit context
      specified for the IPSec policy rule (which also means there's corresponding
      SELinux policy allowing appropriate domains/flows to polmatch to this context).
      
      Secondly, when a security module is loaded (in this case, SELinux), the
      security_xfrm_policy_lookup() hook can return errors other than access denied,
      such as -EINVAL.  We were not handling that correctly, and in fact
      inverting the return logic and propagating a false "ok" back up to
      xfrm_lookup(), which then allowed packets to pass as if they were not
      associated with an xfrm policy.
      
      The solution for this is to first ensure that errno values are
      correctly propagated all the way back up through the various call chains
      from security_xfrm_policy_lookup(), and handled correctly.
      
      Then, flow_cache_lookup() is modified, so that if the policy resolver
      fails (typically a permission denied via the security module), the flow
      cache entry is killed rather than having a null policy assigned (which
      indicates that the packet can pass freely).  This also forces any future
      lookups for the same flow to consult the security module (e.g. SELinux)
      for current security policy (rather than, say, caching the error on the
      flow cache entry).
      
      This patch: Fix the selinux side of things.
      
      This makes sure SELinux polmatching of flow contexts to IPSec policy
      rules comes into play only when an explicit context is associated
      with the IPSec policy rule.
      
      Also, this no longer defaults the context of a socket policy to
      the context of the socket since the "no explicit context" case
      is now handled properly.
      Signed-off-by: NVenkat Yekkirala <vyekkirala@TrustedCS.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      5b368e61
    • J
      IPsec: propagate security module errors up from flow_cache_lookup · 134b0fc5
      James Morris 提交于
      When a security module is loaded (in this case, SELinux), the
      security_xfrm_policy_lookup() hook can return an access denied permission
      (or other error).  We were not handling that correctly, and in fact
      inverting the return logic and propagating a false "ok" back up to
      xfrm_lookup(), which then allowed packets to pass as if they were not
      associated with an xfrm policy.
      
      The way I was seeing the problem was when connecting via IPsec to a
      confined service on an SELinux box (vsftpd), which did not have the
      appropriate SELinux policy permissions to send packets via IPsec.
      
      The first SYNACK would be blocked, because of an uncached lookup via
      flow_cache_lookup(), which would fail to resolve an xfrm policy because
      the SELinux policy is checked at that point via the resolver.
      
      However, retransmitted SYNACKs would then find a cached flow entry when
      calling into flow_cache_lookup() with a null xfrm policy, which is
      interpreted by xfrm_lookup() as the packet not having any associated
      policy and similarly to the first case, allowing it to pass without
      transformation.
      
      The solution presented here is to first ensure that errno values are
      correctly propagated all the way back up through the various call chains
      from security_xfrm_policy_lookup(), and handled correctly.
      
      Then, flow_cache_lookup() is modified, so that if the policy resolver
      fails (typically a permission denied via the security module), the flow
      cache entry is killed rather than having a null policy assigned (which
      indicates that the packet can pass freely).  This also forces any future
      lookups for the same flow to consult the security module (e.g. SELinux)
      for current security policy (rather than, say, caching the error on the
      flow cache entry).
      Signed-off-by: NJames Morris <jmorris@namei.org>
      134b0fc5
    • P
      NetLabel: fix a cache race condition · ffb733c6
      paul.moore@hp.com 提交于
      Testing revealed a problem with the NetLabel cache where a cached entry could
      be freed while in use by the LSM layer causing an oops and other problems.
      This patch fixes that problem by introducing a reference counter to the cache
      entry so that it is only freed when it is no longer in use.
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      ffb733c6
    • A
      Lockdep: fix compile error in drivers/input/serio/serio.c · 07646e21
      Andrew Morton 提交于
      lockdep_set_subclass() was missing in !LOCKDEP case
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      07646e21
    • R
      sh: SH-4A UBC support · 8ae91b9a
      Ryusuke Sakato 提交于
      A simple patch to enable the UBC on SH-4A.
      Signed-off-by: NRyusuke Sakato <sakato@hsdv.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      8ae91b9a
    • R
      04d4d7d5
    • A
      [MIPS] Optimize and cleanup get_saved_sp, set_saved_sp · 9b95e629
      Atsushi Nemoto 提交于
      If CONFIG_BUILD_ELF64 was not selected and gcc had -msym32 option
      (i.e. 4.0 or newer), there is no point to use %highest, %higher for
      kernel symbols.
      
      This patch also fixes 64-bit SMTC version of get_saved_sp() which is
      broken but harmless since there is no such CPUs for now.
      
      A bonus is set_saved_sp() and SMP version of get_saved_sp() are more
      readable now.
      Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9b95e629
    • A
      dff9262e
    • A
      [PATCH] m68k uaccess __user annotations · b971018b
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b971018b
    • A
      [PATCH] arm-versatile iomem annotations · 399ad77b
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      399ad77b