1. 29 8月, 2015 4 次提交
  2. 22 8月, 2015 1 次提交
    • M
      mm: make page pfmemalloc check more robust · 2f064f34
      Michal Hocko 提交于
      Commit c48a11c7 ("netvm: propagate page->pfmemalloc to skb") added
      checks for page->pfmemalloc to __skb_fill_page_desc():
      
              if (page->pfmemalloc && !page->mapping)
                      skb->pfmemalloc = true;
      
      It assumes page->mapping == NULL implies that page->pfmemalloc can be
      trusted.  However, __delete_from_page_cache() can set set page->mapping
      to NULL and leave page->index value alone.  Due to being in union, a
      non-zero page->index will be interpreted as true page->pfmemalloc.
      
      So the assumption is invalid if the networking code can see such a page.
      And it seems it can.  We have encountered this with a NFS over loopback
      setup when such a page is attached to a new skbuf.  There is no copying
      going on in this case so the page confuses __skb_fill_page_desc which
      interprets the index as pfmemalloc flag and the network stack drops
      packets that have been allocated using the reserves unless they are to
      be queued on sockets handling the swapping which is the case here and
      that leads to hangs when the nfs client waits for a response from the
      server which has been dropped and thus never arrive.
      
      The struct page is already heavily packed so rather than finding another
      hole to put it in, let's do a trick instead.  We can reuse the index
      again but define it to an impossible value (-1UL).  This is the page
      index so it should never see the value that large.  Replace all direct
      users of page->pfmemalloc by page_is_pfmemalloc which will hide this
      nastiness from unspoiled eyes.
      
      The information will get lost if somebody wants to use page->index
      obviously but that was the case before and the original code expected
      that the information should be persisted somewhere else if that is
      really needed (e.g.  what SLAB and SLUB do).
      
      [akpm@linux-foundation.org: fix blooper in slub]
      Fixes: c48a11c7 ("netvm: propagate page->pfmemalloc to skb")
      Signed-off-by: NMichal Hocko <mhocko@suse.com>
      Debugged-by: NVlastimil Babka <vbabka@suse.com>
      Debugged-by: NJiri Bohac <jbohac@suse.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Cc: <stable@vger.kernel.org>	[3.6+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f064f34
  3. 21 8月, 2015 3 次提交
    • D
      drm/radeon: fix hotplug race at startup · 7f98ca45
      Dave Airlie 提交于
      We apparantly get a hotplug irq before we've initialised
      modesetting,
      
      [drm] Loading R100 Microcode
      BUG: unable to handle kernel NULL pointer dereference at   (null)
      IP: [<c125f56f>] __mutex_lock_slowpath+0x23/0x91
      *pde = 00000000
      Oops: 0002 [#1]
      Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
      CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf674028 #111
      Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
      Workqueue: events radeon_hotplug_work_func [radeon]
      task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
      EIP: 0060:[<c125f56f>] EFLAGS: 00010282 CPU: 0
      EIP is at __mutex_lock_slowpath+0x23/0x91
      EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
      ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
       DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
      Stack:
       f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
       f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
       c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
      Call Trace:
       [<c103c4c1>] ? dequeue_task_fair+0xa4/0xb7
       [<c125f162>] ? mutex_lock+0x9/0xa
       [<f8b0faca>] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
       [<c1034741>] ? process_one_work+0xfc/0x194
       [<c1034b58>] ? worker_thread+0x18d/0x218
       [<c10349cb>] ? rescuer_thread+0x1d5/0x1d5
       [<c103742a>] ? kthread+0x7b/0x80
       [<c12601c0>] ? ret_from_kernel_thread+0x20/0x30
       [<c10373af>] ? init_completion+0x18/0x18
      Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63
      Reported-and-Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7f98ca45
    • B
      PCI: Don't use 64-bit bus addresses on PA-RISC · 45ea2a5f
      Bjorn Helgaas 提交于
      Meelis and Helge reported that 3a9ad0b4 ("PCI: Add pci_bus_addr_t")
      caused HPMCs on A500 and hangs on rp5470.
      
      PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
      prior to 3a9ad0b4, we always used 32-bit PCI addresses.  After
      3a9ad0b4, we do use 64-bit PCI addresses in 64-bit kernels, and
      apparently there's some PA-RISC problem related to them.
      
      Fixes: 3a9ad0b4 ("PCI: Add pci_bus_addr_t")
      Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.eeReported-by: NMeelis Roos <mroos@linux.ee>
      Reported-by: NHelge Deller <deller@gmx.de>
      Tested-by: NHelge Deller <deller@gmx.de>
      Based-on-idea-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      CC: stable@vger.kernel.org	# v3.19+
      45ea2a5f
    • V
      Input: gpio_keys_polled - request GPIO pin as input. · 1ae5ddb6
      Vincent Pelletier 提交于
      GPIOF_IN flag was lost in:
      Commit 633a21d8("input: gpio_keys_polled: Add support for GPIO
      descriptors").
      
      Without this flag, legacy code path (for non-descriptor GPIO declarations)
      would configure GPIO as output (0 meaning GPIOF_DIR_OUT | GPIOF_INIT_LOW).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      1ae5ddb6
  4. 20 8月, 2015 5 次提交
    • G
      clocksource/imx: Fix boot with non-DT systems · be3b0f9b
      Guenter Roeck 提交于
      Commit 6dd74782 ("ARM: imx: move timer resources into a structure")
      moved initialization parameters into a data structure, but neglected to set
      the irq field in that data structure for non-DT boots. This causes the system
      to hang if a non-DT boot is attempted.
      
      Fixes: 6dd74782 ("ARM: imx: move timer resources into a structure")
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Link: http://lkml.kernel.org/r/1440066441-13930-1-git-send-email-linux@roeck-us.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      be3b0f9b
    • G
      irqchip/crossbar: Restore set_wake functionality · 8200fe43
      Grygorii Strashko 提交于
      The TI crossbar irqchip doesn't provides any facility to configure the
      wakeup sources, but the conversion to hierarchical irqdomains set the
      irq_set_wake callback to irq_chip_set_wake_parent. The parent chip
      (OMAP wakeupgen) has no irq_set_wake function either so the call will
      fail with -ENOSYS. As a result the irq_set_wake() call in the resume
      path will trigger an 'Unbalanced wake disable' warning.
      
      Before the conversion the GIC irqchip was the top level irqchip and
      correctly flagged with IRQCHIP_SKIP_SET_WAKE.
      
      Restore the correct behaviour by removing the irq_set_type callback
      from the crossbar irqchip and set the IRQCHIP_SKIP_SET_WAKE flag which
      lets the irq_set_irq_wake() call from the driver succeed.
      
      [ tglx: Massaged changelog ]
      
      Fixes: 783d3186 ('irqchip: crossbar: Convert dra7 crossbar...')
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: <linux@arm.linux.org.uk>
      Cc: <nsekhar@ti.com>
      Cc: <jason@lakedaemon.net>
      Cc: <balbi@ti.com>
      Cc: <linux-arm-kernel@lists.infradead.org>
      Cc: <tony@atomide.com>
      Cc: <marc.zyngier@arm.com>
      Cc: stable@vger.kernel.org # 4.1
      Link: http://lkml.kernel.org/r/1439554830-19502-7-git-send-email-grygorii.strashko@ti.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      8200fe43
    • G
      irqchip/crossbar: Restore the mask on suspend behaviour · 4fd8f47e
      Grygorii Strashko 提交于
      The ARM GIC requires that all interrupts which are not used as a
      wakeup source have to be masked during suspend.
      
      The conversion of the crossbar irqchip to hierarchical irq domains
      failed to mark the crossbar irqchip with the IRQCHIP_MASK_ON_SUSPEND
      flag and therefor broke the suspend requirement of the GIC.
      
      Before the conversion the flags were visible because the GIC was the
      top level irqchip. After the conversion the crossbar irqchip is the
      top level irq chip whose flags are evaluated in suspend_device_irq().
      As the flag is not set the masking of the non-wakeup irqs is not
      invoked which breaks suspend.
      
      Add the IRQCHIP_MASK_ON_SUSPEND flag to the crossbar irqchip, so the
      GIC interrupts get masked properly.
      
      [ tglx: Massaged changelog ]
      
      Fixes: 783d3186 ('irqchip: crossbar: Convert dra7 crossbar...')
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: <linux@arm.linux.org.uk>
      Cc: <nsekhar@ti.com>
      Cc: <jason@lakedaemon.net>
      Cc: <balbi@ti.com>
      Cc: <linux-arm-kernel@lists.infradead.org>
      Cc: <tony@atomide.com>
      Cc: <marc.zyngier@arm.com>
      Cc: stable@vger.kernel.org # 4.1
      Link: http://lkml.kernel.org/r/1439554830-19502-6-git-send-email-grygorii.strashko@ti.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      4fd8f47e
    • G
      irqchip/crossbar: Restore the irq_set_type() mechanism · e269ec42
      Grygorii Strashko 提交于
      The conversion of the crossbar irqchip to hierarchical irq domains
      failed to provide a mechanism to properly set the trigger type of an
      interrupt.
      
      The crossbar irq chip itself has no mechanism and therefor no
      irq_set_type() callback. The code before the conversion relayed the
      trigger configuration directly to the underlying GIC.
      
      Restore the correct behaviour by setting the crossbar irq_set_type
      callback to irq_chip_set_type_parent(). This propagates the
      set_trigger() call to the underlying GIC irqchip.
      
      [ tglx: Massaged changelog ]
      
      Fixes: 783d3186 ('irqchip: crossbar: Convert dra7 crossbar...')
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: <linux@arm.linux.org.uk>
      Cc: <nsekhar@ti.com>
      Cc: <jason@lakedaemon.net>
      Cc: <balbi@ti.com>
      Cc: <linux-arm-kernel@lists.infradead.org>
      Cc: <tony@atomide.com>
      Cc: <marc.zyngier@arm.com>
      Cc: stable@vger.kernel.org # 4.1
      Link: http://lkml.kernel.org/r/1439554830-19502-4-git-send-email-grygorii.strashko@ti.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      e269ec42
    • Y
      PCI: Tolerate hierarchies with no Root Port · b35b1df5
      Yijing Wang 提交于
      We should not assume any particular hardware topology.  Commit d0751b98
      ("PCI: Add dev->has_secondary_link to track downstream PCIe links") relied
      on the assumption that every PCIe hierarchy is rooted at a Root Port.  But
      we can't rely on any assumption about what hardware we will find; we just
      have to deal with the world as it is.
      
      On some platforms, PCIe devices (endpoints, switch upstream ports, etc.)
      appear directly on the root bus, and there is no Root Port in the PCI bus
      hierarchy.  For example, Meelis observed these top-level devices on a
      Sparc V245:
      
        0000:02:00.0 PCI bridge to [bus 03-0d]    Switch Upstream Port
        0001:02:00.0 PCI bridge to [bus 03]       PCIe to PCI/PCI-X Bridge
      
      These devices *look* like they have links going upstream, but there really
      are no upstream devices.
      
      In set_pcie_port_type(), we used the parent device to figure out which side
      of a switch port has a link, so if the parent device did not exist, we
      dereferenced a NULL parent pointer.
      
      Check whether the parent device exists before dereferencing it.
      
      Meelis observed this oops on Sparc V245 and T2000.  Ben Herrenschmidt says
      this is also possible on IBM PowerVM guests on PowerPC.
      
      [bhelgaas: changelog, comment]
      Link: http://lkml.kernel.org/r/alpine.LRH.2.20.1508122118210.18637@math.ut.eeReported-by: NMeelis Roos <mroos@linux.ee>
      Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      b35b1df5
  5. 19 8月, 2015 14 次提交
  6. 18 8月, 2015 11 次提交
    • A
      SCSI: Fix NULL pointer dereference in runtime PM · 49718f0f
      Alan Stern 提交于
      The routines in scsi_rpm.c assume that if a runtime-PM callback is
      invoked for a SCSI device, it can only mean that the device's driver
      has asked the block layer to handle the runtime power management (by
      calling blk_pm_runtime_init(), which among other things sets q->dev).
      
      However, this assumption turns out to be wrong for things like the ses
      driver.  Normally ses devices are not allowed to do runtime PM, but
      userspace can override this setting.  If this happens, the kernel gets
      a NULL pointer dereference when blk_post_runtime_resume() tries to use
      the uninitialized q->dev pointer.
      
      This patch fixes the problem by calling the block layer's runtime-PM
      routines only if the device's driver really does have a runtime-PM
      callback routine.  Since ses doesn't define any such callbacks, the
      crash won't occur.
      
      This fixes Bugzilla #101371.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NStanisław Pitucha <viraptor@gmail.com>
      Reported-by: NIlan Cohen <ilanco@gmail.com>
      Tested-by: NIlan Cohen <ilanco@gmail.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      49718f0f
    • H
      fnic: Use the local variable instead of I/O flag to acquire io_req_lock in... · db196935
      Hiral Shah 提交于
      fnic: Use the local variable instead of I/O flag to acquire io_req_lock in fnic_queuecommand() to avoid deadloack
      
      We added changes in fnic driver patch 1.6.0.16 to acquire
      io_req_lock in fnic_queuecommand() before issuing I/O so that io completion
      is serialized. But when releasing the lock we check for the I/O flag and
      this could be modified if IO abort occurs before I/O completion. In this case
      we wont release the lock and causes deadlock in some scenerios. Using the
      local variable to check the IO lock status will resolve the problem.
      
      Fixes: 41df7b02Signed-off-by: NHiral Shah <hishah@cisco.com>
      Signed-off-by: NSesidhar Baddela <sebaddel@cisco.com>
      Signed-off-by: NAnil Chintalapati <achintal@cisco.com>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      db196935
    • T
      drm/atmel-hlcdc: Compile suspend/resume for PM_SLEEP only · dbb3df2d
      Thierry Reding 提交于
      If PM is enabled but PM_SLEEP is disabled, the suspend/resume functions
      are still unused and produce a compiler warning.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Cc: <stable@vger.kernel.org> # 4.1+
      dbb3df2d
    • K
      net: phy: fix semicolon.cocci warnings · ff94c742
      kbuild test robot 提交于
      drivers/net/phy/smsc.c:127:3-4: Unneeded semicolon
      
       Remove unneeded semicolon.
      
      Generated by: scripts/coccinelle/misc/semicolon.cocci
      
      CC: Igor Plyatov <plyatov@gmail.com>
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff94c742
    • D
      a8079092
    • I
      be2net: avoid vxlan offloading on multichannel configs · af19e686
      Ivan Vecera 提交于
      VxLAN offloading is not functional if the NIC is running in multichannel
      mode (UMC, FLEX-10, VNIC...). Enabling this additionally kills whole
      connectivity through the NIC and the device needs to be down and up to
      restore it. The firmware should take care about it and does not allow
      the conversion of interface to tunnel type (be_cmd_manage_iface) or should
      support VxLAN offloading if multichannel config is enabled.
      I have tested this on the latest available firmware (10.6.144.21).
      
      Result:
      [root@sm-04 ~]# ip link set enp5s0f0 up[root@sm-04 ~]# ip addr add 172.30.10.50/24 dev enp5s0f0
      [root@sm-04 ~]# ping -c 3 172.30.10.254PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
      64 bytes from 172.30.10.254: icmp_seq=1 ttl=64 time=0.317 ms
      64 bytes from 172.30.10.254: icmp_seq=2 ttl=64 time=0.187 ms
      64 bytes from 172.30.10.254: icmp_seq=3 ttl=64 time=0.188 ms
      
       --- 172.30.10.254 ping statistics ---
      3 packets transmitted, 3 received, 0% packet loss, time 2000ms
      rtt min/avg/max/mdev = 0.187/0.230/0.317/0.063 ms
      [root@sm-04 ~]# ip link add link enp5s0f0 vxlan10 type vxlan id 10 remote 172.30.10.60 dstport 4789
      [root@sm-04 ~]# ip link set vxlan10 up
      [ 7900.442811] be2net 0000:05:00.0: Enabled VxLAN offloads for UDP port 4789
      [ 7900.455722] be2net 0000:05:00.1: Enabled VxLAN offloads for UDP port 4789
      [ 7900.468635] be2net 0000:05:00.2: Enabled VxLAN offloads for UDP port 4789
      [ 7900.481553] be2net 0000:05:00.3: Enabled VxLAN offloads for UDP port 4789
      [root@sm-04 ~]# ping -c 3 172.30.10.254
      PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
      
       --- 172.30.10.254 ping statistics ---
      3 packets transmitted, 0 received, 100% packet loss, time 1999ms
      
      [root@sm-04 ~]# ip link set vxlan10 down
      [ 7959.434093] be2net 0000:05:00.0: Disabled VxLAN offloads for UDP port 4789
      [ 7959.444792] be2net 0000:05:00.1: Disabled VxLAN offloads for UDP port 4789
      [ 7959.455592] be2net 0000:05:00.2: Disabled VxLAN offloads for UDP port 4789
      [ 7959.466416] be2net 0000:05:00.3: Disabled VxLAN offloads for UDP port 4789
      [root@sm-04 ~]# ip link del vxlan10
      [root@sm-04 ~]# ping -c 3 172.30.10.254
      PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
      
       --- 172.30.10.254 ping statistics ---
      3 packets transmitted, 0 received, 100% packet loss, time 1999ms
      
      [root@sm-04 ~]# ip link set enp5s0f0 down
      [root@sm-04 ~]# ip link set enp5s0f0 up
      [ 8071.019003] be2net 0000:05:00.0 enp5s0f0: Link is Up
      [root@sm-04 ~]# ping -c 3 172.30.10.254
      PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
      64 bytes from 172.30.10.254: icmp_seq=1 ttl=64 time=0.318 ms
      64 bytes from 172.30.10.254: icmp_seq=2 ttl=64 time=0.196 ms
      64 bytes from 172.30.10.254: icmp_seq=3 ttl=64 time=0.194 ms
      
       --- 172.30.10.254 ping statistics ---
      3 packets transmitted, 3 received, 0% packet loss, time 2000ms
      rtt min/avg/max/mdev = 0.194/0.236/0.318/0.057 ms
      
      Cc: Sathya Perla <sathya.perla@avagotech.com>
      Cc: Ajit Khaparde <ajit.khaparde@avagotech.com>
      Cc: Padmanabh Ratnakar <padmanabh.ratnakar@avagotech.com>
      Cc: Sriharsha Basavapatna <sriharsha.basavapatna@avagotech.com>
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Acked-by: NAjit Khaparde <ajit.khaparde@avagotech.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af19e686
    • I
      net: phy: workaround for buggy cable detection by LAN8700 after cable plugging · 776829de
      Igor Plyatov 提交于
      * Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
        Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
        set, the ENERGYON bit does not asserted sometimes). This is a common bug of
        LAN87xx family of PHY chips.
      * The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
        algorythm still not reliable on 100 % and sometimes skip cable plugging.
      Signed-off-by: NIgor Plyatov <plyatov@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      776829de
    • D
      net: ethernet: micrel: fix an error code · 2902bc66
      Dan Carpenter 提交于
      The dma_mapping_error() function returns true or false.  We should
      return -ENOMEM if it there is a dma mapping error.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2902bc66
    • G
      ppp: fix device unregistration upon netns deletion · 8cb775bc
      Guillaume Nault 提交于
      PPP devices may get automatically unregistered when their network
      namespace is getting removed. This happens if the ppp control plane
      daemon (e.g. pppd) exits while it is the last user of this namespace.
      
      This leads to several races:
      
        * ppp_exit_net() may destroy the per namespace idr (pn->units_idr)
          before all file descriptors were released. Successive ppp_release()
          calls may then cleanup PPP devices with ppp_shutdown_interface() and
          try to use the already destroyed idr.
      
        * Automatic device unregistration may also happen before the
          ppp_release() call for that device gets executed. Once called on
          the file owning the device, ppp_release() will then clean it up and
          try to unregister it a second time.
      
      To fix these issues, operations defined in ppp_shutdown_interface() are
      moved to the PPP device's ndo_uninit() callback. This allows PPP
      devices to be properly cleaned up by unregister_netdev() and friends.
      So checking for ppp->owner is now an accurate test to decide if a PPP
      device should be unregistered.
      
      Setting ppp->owner is done in ppp_create_interface(), before device
      registration, in order to avoid unprotected modification of this field.
      
      Finally, ppp_exit_net() now starts by unregistering all remaining PPP
      devices to ensure that none will get unregistered after the call to
      idr_destroy().
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8cb775bc
    • S
      net: phy: fix PHY_RUNNING in phy_state_machine · 11e122cb
      Shaohui Xie 提交于
      Currently, if phy state is PHY_RUNNING, we always register a CHANGE
      when phy works in polling or interrupt ignored, this will make the
      adjust_link being called even the phy link did Not changed.
      
      checking the phy link to make sure the link did changed before we
      register a CHANGE, if link did not changed, we do nothing.
      Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11e122cb
    • R
      dmaengine: fix balance of privatecnt inc/dec operations · 05aa1a77
      Robert Baldyga 提交于
      This patch increments privatecnt value and set DMA_PRIVATE in device
      caps in dma_request_slave_channel() function. This is needed to keep
      privatecnt increment/decrement balance.
      
      As function dma_release_channel() decrements privatecnt counter, we need
      to increment it when channel is requested. Otherwise privatecnt drops
      into negatives after few dma_release_channel() calls.
      Reported-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      05aa1a77
  7. 17 8月, 2015 1 次提交
  8. 15 8月, 2015 1 次提交
新手
引导
客服 返回
顶部