- 07 Oct, 2014 3 commits
-
-
Herbert Xu authored
As we may defragment the packet in IPv4 PRE_ROUTING and refragment it after POST_ROUTING we should save the value of frag_max_size. This is still very wrong as the bridge is supposed to leave the packets intact, meaning that the right thing to do is to use the original frag_list for fragmentation. Unfortunately we don't currently guarantee that the frag_list is left untouched throughout netfilter so until this changes this is the best we can do. There is also a spot in FORWARD where it appears that we can forward a packet without going through fragmentation, mark it so that we can fix it later. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sylvain "ythier" Hitier authored
In commit 6f2b6a30, # 3c59x: Add dma error checking and recovery the intent is to split out the mapping from the byte-swapping in order to insert a dma_mapping_error() check. Kinda this semantic patch: // See http://coccinelle.lip6.fr/ // // Beware, grouik-and-dirty! @@ expression DEV, X, Y, Z; @@ - cpu_to_le32(pci_map_single(DEV, X, Y, Z)) + dma_addr_t addr = pci_map_single(DEV, X, Y, Z); + if (dma_mapping_error(&DEV->dev, addr)) + /* snip */; + cpu_to_le32(addr) However, the #else part (of the #if DO_ZEROCOPY test) is changed this way: - cpu_to_le32(pci_map_single(DEV, X, Y, Z)) + dma_addr_t addr = cpu_to_le32(pci_map_single(DEV, X, Y, Z)); // ^^^^^^^^^^^ // That mismatches the 3 other changes! + if (dma_mapping_error(&DEV->dev, addr)) + /* snip */; + cpu_to_le32(addr) Let's remove the leftover cpu_to_le32() for coherency. v2: Better changelog. v3: Add Acked-by Fixes: 6f2b6a30 # 3c59x: Add dma error checking and recovery Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Sylvain "ythier" Hitier <sylvain.hitier@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ivan Vecera authored
When Tx VLAN offloading is disabled frames with size ~ MTU are not transmitted as the driver does not account 4 bytes of VLAN header added by stack. It should use VLAN_ETH_HLEN instead of ETH_HLEN. The second problem is with newer BNA chips (BNA 1860). These chips filter out any VLAN tagged frames in Tx path. This is a problem when Tx VLAN offloading is disabled and frames are tagged by stack. Older chips like 1010/1020 are not affected as they probably don't do such filtering. Cc: Rasesh Mody <rasesh.mody@qlogic.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 06 Oct, 2014 5 commits
-
-
Vlad Yasevich authored
Currently association restarts do not take into consideration the state of the socket. When a restart happens, the current assocation simply transitions into established state. This creates a condition where a remote system, through a the restart procedure, may create a local association that is no way reachable by user. The conditions to trigger this are as follows: 1) Remote does not acknoledge some data causing data to remain outstanding. 2) Local application calls close() on the socket. Since data is still outstanding, the association is placed in SHUTDOWN_PENDING state. However, the socket is closed. 3) The remote tries to create a new association, triggering a restart on the local system. The association moves from SHUTDOWN_PENDING to ESTABLISHED. At this point, it is no longer reachable by any socket on the local system. This patch addresses the above situation by moving the newly ESTABLISHED association into SHUTDOWN-SENT state and bundling a SHUTDOWN after the COOKIE-ACK chunk. This way, the restarted associate immidiately enters the shutdown procedure and forces the termination of the unreachable association. Reported-by: David Laight <David.Laight@aculab.com> Signed-off-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Antoine Tenart says: ==================== net: spider_net: fix possible bitops errors Dan reported a possible signedness issue on the pxa168_eth driver. While having a look at it, I came across a similar problem in the spider_net driver. Here is one proposal to fix it. The first patch rework the spider_net_set_mac() function by removing the spider_net_get_mac_address() call and using memcpy() to set netdev->dev_addr (which is what's done in lots of Ethernet drivers) and the second one fix the actual signedness issue. If for any reason you really want to keep a call to spider_net_get_mac_address() because the memcpy() is somehow not good enough here, we can also come up with a solution involving a temporary unsigned char variable. I couldn't test these changes, so please do. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Antoine Ténart authored
Signedness bugs may occur when using signed char for bitops, depending on if the highest bit is ever used. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Antoine Ténart authored
This patch removes the spider_net_get_mac_address() call at the end of the spider_net_set_mac() function. The dev->dev_addr is instead updated with a memcpy() from sa->sa_data. Since spider_net_get_mac_address() is not used anywhere else, this patch also removes the function. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
KY Srinivasan authored
After the packet is successfully sent, we should not touch the packet as it may have been freed. This patch is based on the work done by Long Li <longli@microsoft.com>. David, please queue this up for stable. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 05 Oct, 2014 4 commits
-
-
Joe Lawrence authored
When team_notify_peers and team_mcast_rejoin are called, they both reset their respective .count_pending atomic variable. Then when the actual worker function is executed, the variable is atomically decremented. This pattern introduces a potential race condition where the .count_pending rolls over and the worker function keeps rescheduling until .count_pending decrements to zero again: THREAD 1 THREAD 2 ======== ======== team_notify_peers(teamX) atomic_set count_pending = 1 schedule_delayed_work team_notify_peers(teamX) atomic_set count_pending = 1 team_notify_peers_work atomic_dec_and_test count_pending = 0 (return) schedule_delayed_work team_notify_peers_work atomic_dec_and_test count_pending = -1 schedule_delayed_work (repeat until count_pending = 0) Instead of assigning a new value to .count_pending, use atomic_add to tack-on the additional desired worker function invocations. Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com> Acked-by: Jiri Pirko <jiri@resnulli.us> Fixes: fc423ff0 ("team: add peer notification") Fixes: 492b200e ("team: add support for sending multicast rejoins") Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ignacy Gawędzki authored
The result of a negated container has to be inverted before checking for early ending. This fixes my previous attempt (17c9c823) to make inverted containers work correctly. Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Similar to commit bc23333b ("net: bcmgenet: fix bcmgenet_put_tx_csum()"), we need to return the skb pointer in case we had to reallocate the SKB headroom. Fixes: 80105bef ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nicolas Dichtel authored
In xmit path, we build a flowi6 which will be used for the output route lookup. We are sending a GRE packet, neither IPv4 nor IPv6 encapsulated packet, thus the protocol should be IPPROTO_GRE. Fixes: c12b395a ("gre: Support GRE over IPv6") Reported-by: Matthieu Ternisien d'Ouville <matthieu.tdo@6wind.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 03 Oct, 2014 11 commits
-
-
hayeswang authored
Resume the device before setting the MAC address. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michel Stam authored
I've noticed every time the interface is set to 'up,', the kernel reports that the link speed is set to 100 Mbps/Full Duplex, even when ethtool is used to set autonegotiation to 'off', half duplex, 10 Mbps. It can be tested by: ifconfig eth0 down ethtool -s eth0 autoneg off speed 10 duplex half ifconfig eth0 up Then checking 'dmesg' for the link speed. Signed-off-by: Michel Stam <m.stam@fugro.nl> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Herton R. Krzesinski says: ==================== Small fixes/changes for RDS I got a report of one issue within RDS (after investigation it was a double free), and I'm sending the fix (patch 3/3) which reporter said it works (no more WARNING triggered on a specially instrumented kernel). The report/test was done on a very old kernel (RHEL 5, 2.6.18 based with backports), but the problem the patch handles still exists and should not change. Besides that, while reviewing some of the code but being unable to reproduce with rds_tcp, I noticed two small improvements/fixes which are in patches 1 and 2. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herton R. Krzesinski authored
I got a report of a double free happening at RDS slab cache. One suspicion was that may be somewhere we were doing a sock_hold/sock_put on an already freed sock. Thus after providing a kernel with the following change: static inline void sock_hold(struct sock *sk) { - atomic_inc(&sk->sk_refcnt); + if (!atomic_inc_not_zero(&sk->sk_refcnt)) + WARN(1, "Trying to hold sock already gone: %p (family: %hd)\n", + sk, sk->sk_family); } The warning successfuly triggered: Trying to hold sock already gone: ffff81f6dda61280 (family: 21) WARNING: at include/net/sock.h:350 sock_hold() Call Trace: <IRQ> [<ffffffff8adac135>] :rds:rds_send_remove_from_sock+0xf0/0x21b [<ffffffff8adad35c>] :rds:rds_send_drop_acked+0xbf/0xcf [<ffffffff8addf546>] :rds_rdma:rds_ib_recv_tasklet_fn+0x256/0x2dc [<ffffffff8009899a>] tasklet_action+0x8f/0x12b [<ffffffff800125a2>] __do_softirq+0x89/0x133 [<ffffffff8005f30c>] call_softirq+0x1c/0x28 [<ffffffff8006e644>] do_softirq+0x2c/0x7d [<ffffffff8006e4d4>] do_IRQ+0xee/0xf7 [<ffffffff8005e625>] ret_from_intr+0x0/0xa <EOI> Looking at the call chain above, the only way I think this would be possible is if somewhere we already released the same socket->sock which is assigned to the rds_message at rds_send_remove_from_sock. Which seems only possible to happen after the tear down done on rds_release. rds_release properly calls rds_send_drop_to to drop the socket from any rds_message, and some proper synchronization is in place to avoid race with rds_send_drop_acked/rds_send_remove_from_sock. However, I still see a very narrow window where it may be possible we touch a sock already released: when rds_release races with rds_send_drop_acked, we check RDS_MSG_ON_CONN to avoid cleanup on the same rds_message, but in this specific case we don't clear rm->m_rs. In this case, it seems we could then go on at rds_send_drop_to and after it returns, the sock is freed by last sock_put on rds_release, with concurrently we being at rds_send_remove_from_sock; then at some point in the loop at rds_send_remove_from_sock we process an rds_message which didn't have rm->m_rs unset for a freed sock, and a possible sock_hold on an sock already gone at rds_release happens. This hopefully address the described condition above and avoids a double free on "second last" sock_put. In addition, I removed the comment about socket destruction on top of rds_send_drop_acked: we call rds_send_drop_to in rds_release and we should have things properly serialized there, thus I can't see the comment being accurate there. Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herton R. Krzesinski authored
I see two problems if we consider the sock->ops->connect attempt to fail in rds_tcp_conn_connect. The first issue is that for example we don't remove the previously added rds_tcp_connection item to rds_tcp_tc_list at rds_tcp_set_callbacks, which means that on a next reconnect attempt for the same rds_connection, when rds_tcp_conn_connect is called we can again call rds_tcp_set_callbacks, resulting in duplicated items on rds_tcp_tc_list, leading to list corruption: to avoid this just make sure we call properly rds_tcp_restore_callbacks before we exit. The second issue is that we should also release the sock properly, by setting sock = NULL only if we are returning without error. Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herton R. Krzesinski authored
Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://neil.brown.name/mdLinus Torvalds authored
Pull raid5 discard fix from Neil Brown: "One fix for raid5 discard issue" * tag 'md/3.17-final-fix' of git://neil.brown.name/md: md/raid5: disable 'DISCARD' by default due to safety concerns.
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Nothing too major or scary. One i915 regression fix, nouveau has a tmds regression fix, along with a regression fix for the runtime pm code for optimus laptops not restoring the display hw correctly" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/nouveau: make sure display hardware is reinitialised on runtime resume drm/nouveau: punt fbcon resume out to a workqueue drm/nouveau: fix regression on original nv50 board drm/nv50/disp: fix dpms regression on certain boards drm/i915: Flush the PTEs after updating them before suspend
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull ACPI and power management fixes from Rafael Wysocki: "These are three regression fixes (cpufreq core, pcc-cpufreq, i915 / ACPI) and one trivial fix for a callback return value mismatch in the cpufreq integrator driver. Specifics: - A recent cpufreq core fix went too far and introduced a regression in the system suspend code path. Fix from Viresh Kumar. - An ACPI-related commit in the i915 driver that fixed backlight problems for some Thinkpads inadvertently broke a Dell machine (in 3.16). Fix from Aaron Lu. - The pcc-cpufreq driver was broken during the 3.15 cycle by a commit that put wait_event() under a spinlock by mistake. Fix that (Rafael J Wysocki). - The return value type of integrator_cpufreq_remove() is void, but should be int. Fix from Arnd Bergmann" * tag 'pm+acpi-3.17-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: update 'cpufreq_suspended' after stopping governors ACPI / i915: Update the condition to ignore firmware backlight change request cpufreq: integrator: fix integrator_cpufreq_remove return type cpufreq: pcc-cpufreq: Fix wait_event() under spinlock
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
final regression fix for 3.17. * tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel: drm/i915: Flush the PTEs after updating them before suspend
-
Rafael J. Wysocki authored
* pm-cpufreq: cpufreq: update 'cpufreq_suspended' after stopping governors cpufreq: integrator: fix integrator_cpufreq_remove return type cpufreq: pcc-cpufreq: Fix wait_event() under spinlock * acpi-video: ACPI / i915: Update the condition to ignore firmware backlight change request
-
- 02 Oct, 2014 17 commits
-
-
Linus Torvalds authored
Merge fixes from Andrew Morton: "5 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: mm: page_alloc: fix zone allocation fairness on UP perf: fix perf bug in fork() MAINTAINERS: change git URL for mpc5xxx tree mm: memcontrol: do not iterate uninitialized memcgs ocfs2/dlm: should put mle when goto kill in dlm_assert_master_handler
-
Johannes Weiner authored
The zone allocation batches can easily underflow due to higher-order allocations or spills to remote nodes. On SMP that's fine, because underflows are expected from concurrency and dealt with by returning 0. But on UP, zone_page_state will just return a wrapped unsigned long, which will get past the <= 0 check and then consider the zone eligible until its watermarks are hit. Commit 3a025760 ("mm: page_alloc: spill to remote nodes before waking kswapd") already made the counter-resetting use atomic_long_read() to accomodate underflows from remote spills, but it didn't go all the way with it. Make it clear that these batches are expected to go negative regardless of concurrency, and use atomic_long_read() everywhere. Fixes: 81c0a2bb ("mm: page_alloc: fair zone allocator policy") Reported-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: Leon Romanovsky <leon@leon.nu> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Mel Gorman <mgorman@suse.de> Cc: <stable@vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Peter Zijlstra authored
Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by calling perf_event_free_task() when failing sched_fork() we will not yet have done the memset() on ->perf_event_ctxp[] and will therefore try and 'free' the inherited contexts, which are still in use by the parent process. This is bad.. Suggested-by: Oleg Nesterov <oleg@redhat.com> Reported-by: Oleg Nesterov <oleg@redhat.com> Reported-by: Sylvain 'ythier' Hitier <sylvain.hitier@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Anatolij Gustschin authored
The repository for mpc5xxx has been moved, update git URL to new location. Signed-off-by: Anatolij Gustschin <agust@denx.de> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Johannes Weiner authored
The cgroup iterators yield css objects that have not yet gone through css_online(), but they are not complete memcgs at this point and so the memcg iterators should not return them. Commit d8ad3055 ("mm/memcg: iteration skip memcgs not yet fully initialized") set out to implement exactly this, but it uses CSS_ONLINE, a cgroup-internal flag that does not meet the ordering requirements for memcg, and so the iterator may skip over initialized groups, or return partially initialized memcgs. The cgroup core can not reasonably provide a clear answer on whether the object around the css has been fully initialized, as that depends on controller-specific locking and lifetime rules. Thus, introduce a memcg-specific flag that is set after the memcg has been initialized in css_online(), and read before mem_cgroup_iter() callers access the memcg members. Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org> Acked-by: Michal Hocko <mhocko@suse.cz> Cc: Hugh Dickins <hughd@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: <stable@vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
alex chen authored
In dlm_assert_master_handler, the mle is get in dlm_find_mle, should be put when goto kill, otherwise, this mle will never be released. Signed-off-by: Alex Chen <alex.chen@huawei.com> Reviewed-by: Joseph Qi <joseph.qi@huawei.com> Reviewed-by: joyce.xue <xuejiufei@huawei.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-mediaLinus Torvalds authored
Pull media fix from Mauro Carvalho Chehab: "One last time regression fix at em28xx. The removal of .reset_resume broke suspend/resume on this driver for some devices. There are more fixes to be done for em28xx suspend/resume to be better handled, but I'm opting to let them to stay for a while at the media devel tree, in order to get more tests. So, for now, let's just revert this patch" * tag 'media/v3.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: Revert "[media] media: em28xx - remove reset_resume interface"
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull parisc fix from Helge Deller: "One late but trivial patch to fix the serial console on parisc machines which got broken during the 3.17 release cycle" * 'parisc-3.17-8' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix serial console for machines with serial port on superio chip
-
Linus Torvalds authored
Merge NUMA balancing related fixlets from Mel Gorman: "There were a few minor changes so am resending just the two patches that are mostly likely to affect the bug Dave and Sasha saw and marked them for stable. I'm less confident it will address Sasha's problem because while I have not kept up to date, I believe he's also seeing memory corruption issues in next from an unknown source. Still, it would be nice to see how they affect trinity testing. I'll send the MPOL_MF_LAZY patch separately because it's not urgent" * emailed patches from Mel Gorman <mgorman@suse.de>: mm: numa: Do not mark PTEs pte_numa when splitting huge pages mm: migrate: Close race between migration completion and mprotect
-
Mel Gorman authored
This patch reverts 1ba6e0b5 ("mm: numa: split_huge_page: transfer the NUMA type from the pmd to the pte"). If a huge page is being split due a protection change and the tail will be in a PROT_NONE vma then NUMA hinting PTEs are temporarily created in the protected VMA. VM_RW|VM_PROTNONE |-----------------| ^ split here In the specific case above, it should get fixed up by change_pte_range() but there is a window of opportunity for weirdness to happen. Similarly, if a huge page is shrunk and split during a protection update but before pmd_numa is cleared then a pte_numa can be left behind. Instead of adding complexity trying to deal with the case, this patch will not mark PTEs NUMA when splitting a huge page. NUMA hinting faults will not be triggered which is marginal in comparison to the complexity in dealing with the corner cases during THP split. Cc: stable@vger.kernel.org Signed-off-by: Mel Gorman <mgorman@suse.de> Acked-by: Rik van Riel <riel@redhat.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Mel Gorman authored
A migration entry is marked as write if pte_write was true at the time the entry was created. The VMA protections are not double checked when migration entries are being removed as mprotect marks write-migration-entries as read. It means that potentially we take a spurious fault to mark PTEs write again but it's straight-forward. However, there is a race between write migrations being marked read and migrations finishing. This potentially allows a PTE to be write that should have been read. Close this race by double checking the VMA permissions using maybe_mkwrite when migration completes. [torvalds@linux-foundation.org: use maybe_mkwrite] Cc: stable@vger.kernel.org Signed-off-by: Mel Gorman <mgorman@suse.de> Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds authored
Pull sound fixes from Takashi Iwai: "Just a few pending bits of random fixes in ASoC. Nothing exciting, but would be nice to be merged in 3.17, as most of them are also for stable kernels" * tag 'sound-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: ssm2602: do not hardcode type to SSM2602 ASoC: core: fix possible ZERO_SIZE_PTR pointer dereferencing error. MAINTAINERS: add atmel audio alsa driver maintainer entry ASoC: rt286: Fix sync function ASoC: rt286: Correct default value ASoC: soc-compress: fix double unlock of fe card mutex ASoC: fsl_ssi: fix kernel panic in probe function
-
git://anongit.freedesktop.org/git/nouveau/linux-2.6Dave Airlie authored
A few regression fixes, the runpm ones dating back to 3.15. Also a fairly severe TMDS regression that effected a lot of GF8/9/GT2xx users. * 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nouveau: make sure display hardware is reinitialised on runtime resume drm/nouveau: punt fbcon resume out to a workqueue drm/nouveau: fix regression on original nv50 board drm/nv50/disp: fix dpms regression on certain boards
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Don't halt the firmware in r8152 driver, from Hayes Wang. 2) Handle full sized 802.1ad frames in bnx2 and tg3 drivers properly, from Vlad Yasevich. 3) Don't sleep while holding tx_clean_lock in netxen driver, fix from Manish Chopra. 4) Certain kinds of ipv6 routes can end up endlessly failing the route validation test, causing it to be re-looked up over and over again. This particularly kills input route caching in TCP sockets. Fix from Hannes Frederic Sowa. 5) netvsc_start_xmit() has a use-after-free access to skb->len, fix from K Y Srinivasan. 6) Fix matching of inverted containers in ematch module, from Ignacy Gawędzki. 7) Aggregation of GRO frames via SKB ->frag_list for linear skbs isn't handled properly, regression fix from Eric Dumazet. 8) Don't test return value of ipv4_neigh_lookup(), which returns an error pointer, against NULL. From WANG Cong. 9) Fix an old regression where we mistakenly allow a double add of the same tunnel. Fixes from Steffen Klassert. 10) macvtap device delete and open can run in parallel and corrupt lists etc., fix from Vlad Yasevich. 11) Fix build error with IPV6=m NETFILTER_XT_TARGET_TPROXY=y, from Pablo Neira Ayuso. 12) rhashtable_destroy() triggers lockdep splats, fix also from Pablo. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (32 commits) bna: Update Maintainer Email r8152: disable power cut for RTL8153 r8152: remove clearing bp bnx2: Correctly receive full sized 802.1ad fragmes tg3: Allow for recieve of full-size 8021AD frames r8152: fix setting RTL8152_UNPLUG netxen: Fix bug in Tx completion path. netxen: Fix BUG "sleeping function called from invalid context" ipv6: remove rt6i_genid hyperv: Fix a bug in netvsc_start_xmit() net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected ematch: Fix matching of inverted containers. gro: fix aggregation for skb using frag_list neigh: check error pointer instead of NULL for ipv4_neigh_lookup() ip6_gre: Return an error when adding an existing tunnel. ip6_vti: Return an error when adding an existing tunnel. ip6_tunnel: Return an error when adding an existing tunnel. ip6gre: add a rtnl link alias for ip6gretap net/mlx4_core: Allow not to specify probe_vf in SRIOV IB mode r8152: fix the carrier off when autoresuming ...
-
NeilBrown authored
It has come to my attention (thanks Martin) that 'discard_zeroes_data' is only a hint. Some devices in some cases don't do what it says on the label. The use of DISCARD in RAID5 depends on reads from discarded regions being predictably zero. If a write to a previously discarded region performs a read-modify-write cycle it assumes that the parity block was consistent with the data blocks. If all were zero, this would be the case. If some are and some aren't this would not be the case. This could lead to data corruption after a device failure when data needs to be reconstructed from the parity. As we cannot trust 'discard_zeroes_data', ignore it by default and so disallow DISCARD on all raid4/5/6 arrays. As many devices are trustworthy, and as there are benefits to using DISCARD, add a module parameter to over-ride this caution and cause DISCARD to work if discard_zeroes_data is set. If a site want to enable DISCARD on some arrays but not on others they should select DISCARD support at the filesystem level, and set the raid456 module parameter. raid456.devices_handle_discard_safely=Y As this is a data-safety issue, I believe this patch is suitable for -stable. DISCARD support for RAID456 was added in 3.7 Cc: Shaohua Li <shli@kernel.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Heinz Mauelshagen <heinzm@redhat.com> Cc: stable@vger.kernel.org (3.7+) Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Acked-by: Mike Snitzer <snitzer@redhat.com> Fixes: 620125f2Signed-off-by: NeilBrown <neilb@suse.de>
-
Ben Skeggs authored
Linus commit 05c63c2f modified the runtime suspend/resume paths to skip over display-related tasks to avoid locking issues on resume. Unfortunately, this resulted in the display hardware being left in a partially initialised state, preventing subsequent modesets from completing. This commit unifies the (many) suspend/resume paths, bringing back display (and fbcon) handling in the runtime paths. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Preparation for some runtime pm fixes. Currently we skip over fbcon suspend/resume in the runtime path, which causes issues on resume if fbcon tries to write to the framebuffer before the BAR subdev has been resumed to restore the BAR1 VM setup. As we might be woken up via a sysfs connector, we are unable to call fb_set_suspend() in the resume path as it could make its way down to a modeset and cause all sorts of locking hilarity. To solve this, we'll just delay the fbcon resume to a workqueue. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-