1. 10 11月, 2012 1 次提交
    • D
      PCI: SRIOV control and status via sysfs · 1789382a
      Donald Dutile 提交于
      Provide files under sysfs to determine the maximum number of VFs
      an SR-IOV-capable PCIe device supports, and methods to enable and
      disable the VFs on a per-device basis.
      
      Currently, VF enablement by SR-IOV-capable PCIe devices is done
      via driver-specific module parameters.  If not setup in modprobe files,
      it requires admin to unload & reload PF drivers with number of desired
      VFs to enable.  Additionally, the enablement is system wide: all
      devices controlled by the same driver have the same number of VFs
      enabled.  Although the latter is probably desired, there are PCI
      configurations setup by system BIOS that may not enable that to occur.
      
      Two files are created for the PF of PCIe devices with SR-IOV support:
      
          sriov_totalvfs	Contains the maximum number of VFs the device
      			could support as reported by the TotalVFs register
      			in the SR-IOV extended capability.
      
          sriov_numvfs	Contains the number of VFs currently enabled on
      			this device as reported by the NumVFs register in
      			the SR-IOV extended capability.
      
      			Writing zero to this file disables all VFs.
      
      			Writing a positive number to this file enables that
      			number of VFs.
      
      These files are readable for all SR-IOV PF devices.  Writes to the
      sriov_numvfs file are effective only if a driver that supports the
      sriov_configure() method is attached.
      Signed-off-by: NDonald Dutile <ddutile@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      1789382a
  2. 29 10月, 2012 2 次提交
  3. 26 10月, 2012 1 次提交
  4. 25 10月, 2012 2 次提交
  5. 24 10月, 2012 2 次提交
  6. 23 10月, 2012 2 次提交
  7. 22 10月, 2012 1 次提交
  8. 20 10月, 2012 2 次提交
    • C
      pidns: remove recursion from free_pid_ns() · bbc2e3ef
      Cyrill Gorcunov 提交于
      free_pid_ns() operates in a recursive fashion:
      
      free_pid_ns(parent)
        put_pid_ns(parent)
          kref_put(&ns->kref, free_pid_ns);
            free_pid_ns
      
      thus if there was a huge nesting of namespaces the userspace may trigger
      avalanche calling of free_pid_ns leading to kernel stack exhausting and a
      panic eventually.
      
      This patch turns the recursion into an iterative loop.
      
      Based on a patch by Andrew Vagin.
      
      [akpm@linux-foundation.org: export put_pid_ns() to modules]
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: Andrew Vagin <avagin@openvz.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bbc2e3ef
    • R
      linux/coredump.h needs asm/siginfo.h · 1d46e232
      Richard Weinberger 提交于
      Commit 5ab1c309 ("coredump: pass siginfo_t* to do_coredump() and
      below, not merely signr") added siginfo_t to linux/coredump.h but forgot
      to include asm/siginfo.h.  This breaks the build for UML/i386.  (And any
      other arch where asm/siginfo.h is not magically preincluded...)
      
        In file included from arch/x86/um/elfcore.c:2:0: include/linux/coredump.h:15:25: error: unknown type name 'siginfo_t'
        make[1]: *** [arch/x86/um/elfcore.o] Error 1
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      Cc: Denys Vlasenko <vda.linux@googlemail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Amerigo Wang <amwang@redhat.com>
      Cc: "Jonathan M. Foote" <jmfoote@cert.org>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Pedro Alves <palves@redhat.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d46e232
  9. 19 10月, 2012 1 次提交
  10. 18 10月, 2012 4 次提交
    • K
      of/irq: sparse fixes · d2e41518
      Kim Phillips 提交于
      drivers/of/irq.c:195:57: warning: restricted __be32 degrades to integer
      drivers/of/irq.c:196:51: warning: restricted __be32 degrades to integer
      drivers/of/irq.c:199:57: warning: restricted __be32 degrades to integer
      drivers/of/irq.c:201:58: warning: restricted __be32 degrades to integer
      drivers/of/irq.c:470:37: warning: incorrect type in assignment (different modifiers)
      drivers/of/irq.c:470:37:    expected int ( *[usertype] irq_init_cb )( ... )
      drivers/of/irq.c:470:37:    got void const *const data
      drivers/of/irq.c:96:5: error: symbol 'of_irq_map_raw' redeclared with different type (originally declared at include/linux/of_irq.h:61) - incompatible argument 2 (different base types)
      
      drivers/of/of_pci_irq.c:91:40: warning: incorrect type in argument 2 (different base types)
      drivers/of/of_pci_irq.c:91:40:    expected unsigned int const [usertype] *intspec
      drivers/of/of_pci_irq.c:91:40:    got restricted __be32 *<noident>
      drivers/of/of_pci_irq.c:91:53: warning: incorrect type in argument 4 (different base types)
      drivers/of/of_pci_irq.c:91:53:    expected unsigned int const [usertype] *addr
      drivers/of/of_pci_irq.c:91:53:    got restricted __be32 *<noident>
      Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      d2e41518
    • K
      of/address: sparse fixes · 47b1e689
      Kim Phillips 提交于
      drivers/of/address.c:66:29: warning: incorrect type in argument 1 (different base types)
      drivers/of/address.c:66:29:    expected restricted __be32 const [usertype] *cell
      drivers/of/address.c:66:29:    got unsigned int [usertype] *addr
      drivers/of/address.c:87:32: warning: incorrect type in argument 1 (different base types)
      drivers/of/address.c:87:32:    expected restricted __be32 const [usertype] *cell
      drivers/of/address.c:87:32:    got unsigned int [usertype] *addr
      drivers/of/address.c:91:30: warning: incorrect type in assignment (different base types)
      drivers/of/address.c:91:30:    expected unsigned int [unsigned] [usertype] <noident>
      drivers/of/address.c:91:30:    got restricted __be32 [usertype] <noident>
      drivers/of/address.c:92:22: warning: incorrect type in assignment (different base types)
      drivers/of/address.c:92:22:    expected unsigned int [unsigned] [usertype] <noident>
      drivers/of/address.c:92:22:    got restricted __be32 [usertype] <noident>
      drivers/of/address.c:147:35: warning: incorrect type in argument 1 (different base types)
      drivers/of/address.c:147:35:    expected restricted __be32 const [usertype] *addr
      drivers/of/address.c:147:35:    got unsigned int [usertype] *addr
      drivers/of/address.c:157:34: warning: incorrect type in argument 1 (different base types)
      drivers/of/address.c:157:34:    expected restricted __be32 const [usertype] *cell
      drivers/of/address.c:157:34:    got unsigned int [usertype] *
      drivers/of/address.c:256:29: warning: restricted __be32 degrades to integer
      drivers/of/address.c:256:36: warning: restricted __be32 degrades to integer
      drivers/of/address.c:262:34: warning: incorrect type in argument 1 (different base types)
      drivers/of/address.c:262:34:    expected restricted __be32 const [usertype] *cell
      drivers/of/address.c:262:34:    got unsigned int [usertype] *
      drivers/of/address.c:372:41: warning: incorrect type in argument 1 (different base types)
      drivers/of/address.c:372:41:    expected restricted __be32 const [usertype] *cell
      drivers/of/address.c:372:41:    got unsigned int [usertype] *addr
      drivers/of/address.c:395:53: warning: incorrect type in argument 2 (different base types)
      drivers/of/address.c:395:53:    expected restricted __be32 const [usertype] *addr
      drivers/of/address.c:395:53:    got unsigned int [usertype] *addr
      drivers/of/address.c:443:50: warning: incorrect type in argument 2 (different base types)
      drivers/of/address.c:443:50:    expected restricted __be32 const [usertype] *addr
      drivers/of/address.c:443:50:    got unsigned int *<noident>
      drivers/of/address.c:455:49: warning: incorrect type in argument 1 (different base types)
      drivers/of/address.c:455:49:    expected restricted __be32 const [usertype] *cell
      drivers/of/address.c:455:49:    got unsigned int *<noident>
      drivers/of/address.c:480:60: warning: incorrect type in argument 2 (different base types)
      drivers/of/address.c:480:60:    expected restricted __be32 const [usertype] *addr
      drivers/of/address.c:480:60:    got unsigned int *<noident>
      drivers/of/address.c:412:5: warning: symbol '__of_translate_address' was not declared. Should it be static?
      drivers/of/address.c:520:14: error: symbol 'of_get_address' redeclared with different type (originally declared at include/linux/of_address.h:22) - different base types
      Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      47b1e689
    • O
      of: add stub of_get_child_by_name for non-OF builds · 25c040c9
      Olof Johansson 提交于
      Fixes build error on s3c6400_defconfig, introduced by commit
      06455bbc, "dt/s3c64xx/spi: Use
      of_get_child_by_name to get a named child".
      
      drivers/spi/spi-s3c64xx.c: In function 's3c64xx_get_slave_ctrldata':
      drivers/spi/spi-s3c64xx.c:838:2: error: implicit declaration of function
          'of_get_child_by_name' [-Werror=implicit-function-declaration]
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      25c040c9
    • G
      USB: usb.h: remove dbg() macro · 2c78040c
      Greg Kroah-Hartman 提交于
      There are no users of this macro anymore in the kernel tree, so finally
      delete it.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c78040c
  11. 17 10月, 2012 7 次提交
  12. 13 10月, 2012 10 次提交
  13. 12 10月, 2012 5 次提交
    • A
      tty/console: fix warnings in drivers/tty/serial/kgdboc.c · f2f0945e
      Arnd Bergmann 提交于
      The con_debug_leave/con_debug_enter functions are stubbed out
      by defining them to (0), which causes harmless build warnings.
      Using proper inline functions is the normal way to deal with
      this.
      
      Without this patch, building the ARM bcm2835_defconfig results in:
      
      drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
      drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
      drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
      drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      f2f0945e
    • J
      vfs: allocate page instead of names_cache buffer in mount_block_root · a608ca21
      Jeff Layton 提交于
      First, it's incorrect to call putname() after __getname_gfp() since the
      bare __getname_gfp() call skips the auditing code, while putname()
      doesn't.
      
      mount_block_root allocates a PATH_MAX buffer via __getname_gfp, and then
      calls get_fs_names to fill the buffer. That function can call
      get_filesystem_list which assumes that that buffer is a full page in
      size. On arches where PAGE_SIZE != 4k, then this could potentially
      overrun.
      
      In practice, it's hard to imagine the list of filesystem names even
      approaching 4k, but it's best to be safe. Just allocate a page for this
      purpose instead.
      
      With this, we can also remove the __getname_gfp() definition since there
      are no more callers.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      a608ca21
    • J
      audit: overhaul __audit_inode_child to accomodate retrying · 4fa6b5ec
      Jeff Layton 提交于
      In order to accomodate retrying path-based syscalls, we need to add a
      new "type" argument to audit_inode_child. This will tell us whether
      we're looking for a child entry that represents a create or a delete.
      
      If we find a parent, don't automatically assume that we need to create a
      new entry. Instead, use the information we have to try to find an
      existing entry first. Update it if one is found and create a new one if
      not.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      4fa6b5ec
    • J
      audit: set the name_len in audit_inode for parent lookups · bfcec708
      Jeff Layton 提交于
      Currently, this gets set mostly by happenstance when we call into
      audit_inode_child. While that might be a little more efficient, it seems
      wrong. If the syscall ends up failing before audit_inode_child ever gets
      called, then you'll have an audit_names record that shows the full path
      but has the parent inode info attached.
      
      Fix this by passing in a parent flag when we call audit_inode that gets
      set to the value of LOOKUP_PARENT. We can then fix up the pathname for
      the audit entry correctly from the get-go.
      
      While we're at it, clean up the no-op macro for audit_inode in the
      !CONFIG_AUDITSYSCALL case.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bfcec708
    • J
      audit: add a new "type" field to audit_names struct · 78e2e802
      Jeff Layton 提交于
      For now, we just have two possibilities:
      
      UNKNOWN: for a new audit_names record that we don't know anything about yet
      NORMAL: for everything else
      
      In later patches, we'll add other types so we can distinguish and update
      records created under different circumstances.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      78e2e802