1. 01 5月, 2013 6 次提交
  2. 17 4月, 2013 1 次提交
    • E
      audit: allow checking the type of audit message in the user filter · 62062cf8
      Eric Paris 提交于
      When userspace sends messages to the audit system it includes a type.
      We want to be able to filter messages based on that type without have to
      do the all or nothing option currently available on the
      AUDIT_FILTER_TYPE filter list.  Instead we should be able to use the
      AUDIT_FILTER_USER filter list and just use the message type as one part
      of the matching decision.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      62062cf8
  3. 11 4月, 2013 2 次提交
  4. 09 2月, 2013 1 次提交
    • H
      unbreak automounter support on 64-bit kernel with 32-bit userspace (v2) · 4f4ffc3a
      Helge Deller 提交于
      automount-support is broken on the parisc architecture, because the existing
      #if list does not include a check for defined(__hppa__). The HPPA (parisc)
      architecture is similiar to other 64bit Linux targets where we have to define
      autofs_wqt_t (which is passed back and forth to user space) as int type which
      has a size of 32bit across 32 and 64bit kernels.
      
      During the discussion on the mailing list, H. Peter Anvin suggested to invert
      the #if list since only specific platforms (specifically those who do not have
      a 32bit userspace, like IA64 and Alpha) should have autofs_wqt_t as unsigned
      long type.
      
      This suggestion is probably the best way to go, since Arm64 (and maybe others?)
      seems to have a non-working automounter. So in the long run even for other new
      upcoming architectures this inverted check seem to be the best solution, since
      it will not require them to change this #if again (unless they are 64bit only).
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Acked-by: NIan Kent <raven@themaw.net>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      CC: James Bottomley <James.Bottomley@HansenPartnership.com>
      CC: Rolf Eike Beer <eike-kernel@sf-tec.de>
      4f4ffc3a
  5. 08 2月, 2013 1 次提交
  6. 05 2月, 2013 2 次提交
  7. 01 2月, 2013 1 次提交
  8. 31 1月, 2013 2 次提交
    • B
      net: usbnet: prevent buggy devices from killing us · 70c37bf9
      Bjørn Mork 提交于
      A device sending 0 length frames as fast as it can has been
      observed killing the host system due to the resulting memory
      pressure.
      
      Temporarily disable RX skb allocation and URB submission when
      the current error ratio is high, preventing us from trying to
      allocate an infinite number of skbs.  Reenable as soon as we
      are finished processing the done queue, allowing the device
      to continue working after short error bursts.
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Acked-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      70c37bf9
    • M
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming 提交于
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  9. 27 1月, 2013 3 次提交
  10. 26 1月, 2013 1 次提交
    • A
      USB: add usb_hcd_{start,end}_port_resume · da0aa716
      Alan Stern 提交于
      This patch (as1649) adds a mechanism for host controller drivers to
      inform usbcore when they have begun or ended resume signalling on a
      particular root-hub port.  The core will then make sure that the root
      hub does not get runtime-suspended while the port resume is going on.
      
      Since commit 596d789a (USB: set hub's
      default autosuspend delay as 0), the system tries to suspend hubs
      whenever they aren't in use.  While a root-hub port is being resumed,
      the root hub does not appear to be in use.  Attempted runtime suspends
      fail because of the ongoing port resume, but the PM core just keeps on
      trying over and over again.  We want to prevent this wasteful effort.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da0aa716
  11. 25 1月, 2013 1 次提交
    • L
      usb: Using correct way to clear usb3.0 device's remote wakeup feature. · 54a3ac0c
      Lan Tianyu 提交于
      Usb3.0 device defines function remote wakeup which is only for interface
      recipient rather than device recipient. This is different with usb2.0 device's
      remote wakeup feature which is defined for device recipient. According usb3.0
      spec 9.4.5, the function remote wakeup can be modified by the SetFeature()
      requests using the FUNCTION_SUSPEND feature selector. This patch is to use
      correct way to disable usb3.0 device's function remote wakeup after suspend
      error and resuming.
      
      This should be backported to kernels as old as 3.4, that contain the
      commit 623bef9e "USB/xhci: Enable remote
      wakeup for USB3 devices."
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      54a3ac0c
  12. 23 1月, 2013 2 次提交
    • O
      ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up() · 910ffdb1
      Oleg Nesterov 提交于
      Cleanup and preparation for the next change.
      
      signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
      actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
      necessary mask.
      
      Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
      signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
      which adds __TASK_TRACED.
      
      This way ptrace_signal_wake_up() can work "inside" ptrace_request()
      even if the tracee doesn't have the TASK_WAKEKILL bit set.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      910ffdb1
    • L
      mfd: Fix compile errors and warnings when !CONFIG_AB8500_BM · 00441b5e
      Lee Jones 提交于
      drivers/mfd/ab8500-core.c:1015:21: error: ‘ab8500_bm_data’ undeclared here
      
      include/linux/mfd/abx500/ab8500-bm.h:445:13: warning: ‘ab8500_fg_reinit’ defined but not used
      include/linux/mfd/abx500/ab8500-bm.h:448:13: warning: ‘ab8500_charger_usb_state_changed’ defined but not used
      include/linux/mfd/abx500/ab8500-bm.h:451:29: warning: ‘ab8500_btemp_get’ defined but not used
      include/linux/mfd/abx500/ab8500-bm.h:455:12: warning: ‘ab8500_btemp_get_batctrl_temp’ defined but not used
      include/linux/mfd/abx500/ab8500-bm.h:463:12: warning: ‘ab8500_fg_inst_curr_blocking’ defined but not used
      include/linux/mfd/abx500/ab8500-bm.h:442:12: warning: ‘ab8500_fg_inst_curr_done’ defined but not used
      include/linux/mfd/abx500/ab8500-bm.h:447:26: warning: ‘ab8500_fg_get’ defined but not used
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      00441b5e
  13. 22 1月, 2013 2 次提交
  14. 21 1月, 2013 1 次提交
  15. 19 1月, 2013 1 次提交
  16. 18 1月, 2013 1 次提交
  17. 17 1月, 2013 2 次提交
  18. 15 1月, 2013 3 次提交
    • D
      cpuidle: remove the power_specified field in the driver · 8aef33a7
      Daniel Lezcano 提交于
      We realized that the power usage field is never filled and when it
      is filled for tegra, the power_specified flag is not set causing all
      of these values to be reset when the driver is initialized with
      set_power_state().
      
      However, the power_specified flag can be simply removed under the
      assumption that the states are always backward sorted, which is the
      case with the current code.
      
      This change allows the menu governor select function and the
      cpuidle_play_dead() to be simplified.  Moreover, the
      set_power_states() function can removed as it does not make sense
      any more.
      
      Drop the power_specified flag from struct cpuidle_driver and make
      the related changes as described above.
      
      As a consequence, this also fixes the bug where on the dynamic
      C-states system, the power fields are not initialized.
      
      [rjw: Changelog]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=42870
      References: https://bugzilla.kernel.org/show_bug.cgi?id=43349
      References: https://lkml.org/lkml/2012/10/16/518Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8aef33a7
    • P
      tun: fix LSM/SELinux labeling of tun/tap devices · 5dbbaf2d
      Paul Moore 提交于
      This patch corrects some problems with LSM/SELinux that were introduced
      with the multiqueue patchset.  The problem stems from the fact that the
      multiqueue work changed the relationship between the tun device and its
      associated socket; before the socket persisted for the life of the
      device, however after the multiqueue changes the socket only persisted
      for the life of the userspace connection (fd open).  For non-persistent
      devices this is not an issue, but for persistent devices this can cause
      the tun device to lose its SELinux label.
      
      We correct this problem by adding an opaque LSM security blob to the
      tun device struct which allows us to have the LSM security state, e.g.
      SELinux labeling information, persist for the lifetime of the tun
      device.  In the process we tweak the LSM hooks to work with this new
      approach to TUN device/socket labeling and introduce a new LSM hook,
      security_tun_dev_attach_queue(), to approve requests to attach to a
      TUN queue via TUNSETQUEUE.
      
      The SELinux code has been adjusted to match the new LSM hooks, the
      other LSMs do not make use of the LSM TUN controls.  This patch makes
      use of the recently added "tun_socket:attach_queue" permission to
      restrict access to the TUNSETQUEUE operation.  On older SELinux
      policies which do not define the "tun_socket:attach_queue" permission
      the access control decision for TUNSETQUEUE will be handled according
      to the SELinux policy's unknown permission setting.
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Acked-by: NEric Paris <eparis@parisplace.org>
      Tested-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5dbbaf2d
    • S
      [libata] replace sata_settings with devslp_timing · 803739d2
      Shane Huang 提交于
      NCQ capability was used to check availability of SATA Settings page
      from Identify Device Data Log, which contains DevSlp timing variables.
      It does not work on some HDDs and leads to error messages.
      
      IDENTIFY word 78 bit 5(Hardware Feature Control) can't work either
      because it is only the sufficient condition of Identify Device data
      log, not the necessary condition.
      
      This patch replaced ata_device->sata_settings with ->devslp_timing
      to only save DevSlp timing variables(8 bytes), instead of the whole
      SATA Settings page(512 bytes).
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=51881Reported-by: NBorislav Petkov <bp@alien8.de>
      Signed-off-by: NShane Huang <shane.huang@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      803739d2
  19. 12 1月, 2013 7 次提交