- 23 Jun, 2015 20 commits
-
-
WANG Cong authored
[ Upstream commit 86e363dc ] For mq qdisc, we add per tx queue qdisc to root qdisc for display purpose, however, that happens too early, before the new dev->qdisc is finally set, this causes q->list points to an old root qdisc which is going to be freed right before assigning with a new one. Fix this by moving ->attach() after setting dev->qdisc. For the record, this fixes the following crash: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 975 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98() list_del corruption. prev->next should be ffff8800d1998ae8, but was 6b6b6b6b6b6b6b6b CPU: 1 PID: 975 Comm: tc Not tainted 4.1.0-rc4+ #1019 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000009 ffff8800d73fb928 ffffffff81a44e7f 0000000047574756 ffff8800d73fb978 ffff8800d73fb968 ffffffff810790da ffff8800cfc4cd20 ffffffff814e725b ffff8800d1998ae8 ffffffff82381250 0000000000000000 Call Trace: [<ffffffff81a44e7f>] dump_stack+0x4c/0x65 [<ffffffff810790da>] warn_slowpath_common+0x9c/0xb6 [<ffffffff814e725b>] ? __list_del_entry+0x5a/0x98 [<ffffffff81079162>] warn_slowpath_fmt+0x46/0x48 [<ffffffff81820eb0>] ? dev_graft_qdisc+0x5e/0x6a [<ffffffff814e725b>] __list_del_entry+0x5a/0x98 [<ffffffff814e72a7>] list_del+0xe/0x2d [<ffffffff81822f05>] qdisc_list_del+0x1e/0x20 [<ffffffff81820cd1>] qdisc_destroy+0x30/0xd6 [<ffffffff81822676>] qdisc_graft+0x11d/0x243 [<ffffffff818233c1>] tc_get_qdisc+0x1a6/0x1d4 [<ffffffff810b5eaf>] ? mark_lock+0x2e/0x226 [<ffffffff817ff8f5>] rtnetlink_rcv_msg+0x181/0x194 [<ffffffff817ff72e>] ? rtnl_lock+0x17/0x19 [<ffffffff817ff72e>] ? rtnl_lock+0x17/0x19 [<ffffffff817ff774>] ? __rtnl_unlock+0x17/0x17 [<ffffffff81855dc6>] netlink_rcv_skb+0x4d/0x93 [<ffffffff817ff756>] rtnetlink_rcv+0x26/0x2d [<ffffffff818544b2>] netlink_unicast+0xcb/0x150 [<ffffffff81161db9>] ? might_fault+0x59/0xa9 [<ffffffff81854f78>] netlink_sendmsg+0x4fa/0x51c [<ffffffff817d6e09>] sock_sendmsg_nosec+0x12/0x1d [<ffffffff817d8967>] sock_sendmsg+0x29/0x2e [<ffffffff817d8cf3>] ___sys_sendmsg+0x1b4/0x23a [<ffffffff8100a1b8>] ? native_sched_clock+0x35/0x37 [<ffffffff810a1d83>] ? sched_clock_local+0x12/0x72 [<ffffffff810a1fd4>] ? sched_clock_cpu+0x9e/0xb7 [<ffffffff810def2a>] ? current_kernel_time+0xe/0x32 [<ffffffff810b4bc5>] ? lock_release_holdtime.part.29+0x71/0x7f [<ffffffff810ddebf>] ? read_seqcount_begin.constprop.27+0x5f/0x76 [<ffffffff810b6292>] ? trace_hardirqs_on_caller+0x17d/0x199 [<ffffffff811b14d5>] ? __fget_light+0x50/0x78 [<ffffffff817d9808>] __sys_sendmsg+0x42/0x60 [<ffffffff817d9838>] SyS_sendmsg+0x12/0x1c [<ffffffff81a50e97>] system_call_fastpath+0x12/0x6f ---[ end trace ef29d3fb28e97ae7 ]--- For long term, we probably need to clean up the qdisc_graft() code in case it hides other bugs like this. Fixes: 95dc1929 ("pkt_sched: give visibility to mq slave qdiscs") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ross Lagerwall authored
[ Upstream commit ce0e5c52 ] Commit e9ce7cb6 ("xen-netback: Factor queue-specific data into queue struct") introduced a regression when moving queue-specific data into the queue struct by failing to set the credit_bytes field. This prevented bandwidth limiting from working. Initialize the field as it was done before multiqueue support was added. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
-
Mark Salyzyn authored
[ Upstream commit b48732e4 ] got a rare NULL pointer dereference in clear_bit Signed-off-by:
Mark Salyzyn <salyzyn@android.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> ---- v2: switch to sock_flag(sk, SOCK_DEAD) and added net/caif/caif_socket.c v3: return -ECONNRESET in upstream caller of wait function for SOCK_DEAD Signed-off-by:
-
Richard Cochran authored
[ Upstream commit adbe088f ] A pair of nested spin locks was introduced in commit 63502b8d "dp83640: Fix receive timestamp race condition". Unfortunately the 'flags' parameter was reused for the inner lock, clobbering the originally saved IRQ state. This patch fixes the issue by changing the inner lock to plain spin_lock without irqsave. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Richard Cochran authored
[ Upstream commit a935865c ] Callers of the ext_write function are supposed to hold a mutex that protects the state of the dialed page, but one caller was missing the lock from the very start, and over time the code has been changed without following the rule. This patch cleans up the call sites in violation of the rule. Signed-off-by:
-
Richard Cochran authored
[ Upstream commit 397a253a ] Currently, the calibration function that corrects the initial offsets among multiple devices only works the first time. If the function is called more than once, the calibration fails and bogus offsets will be programmed into the devices. In a well hidden spot, the device documentation tells that trigger indexes 0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work. This patch fixes the issue by using one of the special triggers during the recalibration method. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
[ Upstream commit 47cc84ce ] When more than a multicast address is present in a MLDv2 report, all but the first address is ignored, because the code breaks out of the loop if there has not been an error adding that address. This has caused failures when two guests connected through the bridge tried to communicate using IPv6. Neighbor discoveries would not be transmitted to the other guest when both used a link-local address and a static address. This only happens when there is a MLDv2 querier in the network. The fix will only break out of the loop when there is a failure adding a multicast address. The mdb before the patch: dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp dev ovirtmgmt port bond0.86 grp ff02::2 temp After the patch: dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp dev ovirtmgmt port bond0.86 grp ff02::fb temp dev ovirtmgmt port bond0.86 grp ff02::2 temp dev ovirtmgmt port bond0.86 grp ff02::d temp dev ovirtmgmt port vnet0 grp ff02::1:ff00:76 temp dev ovirtmgmt port bond0.86 grp ff02::16 temp dev ovirtmgmt port vnet1 grp ff02::1:ff00:77 temp dev ovirtmgmt port bond0.86 grp ff02::1:ff00:def temp dev ovirtmgmt port bond0.86 grp ff02::1:ffa1:40bf temp Fixes: 08b202b6 ("bridge br_multicast: IPv6 MLD support.") Reported-by:
Rik Theys <Rik.Theys@esat.kuleuven.be> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@redhat.com> Tested-by:
-
Bjørn Mork authored
[ Upstream commit 44f6731d ] The tx_curr_frame_payload field is u32. When we try to calculate a small negative delta based on it, we end up with a positive integer close to 2^32 instead. So the tx_bytes pointer increases by about 2^32 for every transmitted frame. Fix by calculating the delta as a signed long. Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Reported-by:
Florian Bruhin <me@the-compiler.org> Fixes: 7a1e890e ("usbnet: Fix tx_bytes statistic running backward in cdc_ncm") Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit 381c759d ] ip_error does not check if in_dev is NULL before dereferencing it. IThe following sequence of calls is possible: CPU A CPU B ip_rcv_finish ip_route_input_noref() ip_route_input_slow() inetdev_destroy() dst_input() With the result that a network device can be destroyed while processing an input packet. A crash was triggered with only unicast packets in flight, and forwarding enabled on the only network device. The error condition was created by the removal of the network device. As such it is likely the that error code was -EHOSTUNREACH, and the action taken by ip_error (if in_dev had been accessible) would have been to not increment any counters and to have tried and likely failed to send an icmp error as the network device is going away. Therefore handle this weird case by just dropping the packet if !in_dev. It will result in dropping the packet sooner, and will not result in an actual change of behavior. Fixes: 251da413 ("ipv4: Cache ip_error() routes even when not forwarding.") Reported-by:
Vittorio Gambaletta <linuxbugs@vittgam.net> Tested-by:
"Eric W. Biederman" <ebiederm@xmission.com> Acked-by:
-
Daniel Borkmann authored
[ Upstream commit c78e1746 ] Vijay reported that a loop as simple as ... while true; do tc qdisc add dev foo root handle 1: prio tc filter add dev foo parent 1: u32 match u32 0 0 flowid 1 tc qdisc del dev foo root rmmod cls_u32 done ... will panic the kernel. Moreover, he bisected the change apparently introducing it to 78fd1d0a ("netlink: Re-add locking to netlink_lookup() and seq walker"). The removal of synchronize_net() from the netlink socket triggering the qdisc to be removed, seems to have uncovered an RCU resp. module reference count race from the tc API. Given that RCU conversion was done after e341694e ("netlink: Convert netlink_lookup() to use RCU protected hash table") which added the synchronize_net() originally, occasion of hitting the bug was less likely (not impossible though): When qdiscs that i) support attaching classifiers and, ii) have at least one of them attached, get deleted, they invoke tcf_destroy_chain(), and thus call into ->destroy() handler from a classifier module. After RCU conversion, all classifier that have an internal prio list, unlink them and initiate freeing via call_rcu() deferral. Meanhile, tcf_destroy() releases already reference to the tp->ops->owner module before the queued RCU callback handler has been invoked. Subsequent rmmod on the classifier module is then not prevented since all module references are already dropped. By the time, the kernel invokes the RCU callback handler from the module, that function address is then invalid. One way to fix it would be to add an rcu_barrier() to unregister_tcf_proto_ops() to wait for all pending call_rcu()s to complete. synchronize_rcu() is not appropriate as under heavy RCU callback load, registered call_rcu()s could be deferred longer than a grace period. In case we don't have any pending call_rcu()s, the barrier is allowed to return immediately. Since we came here via unregister_tcf_proto_ops(), there are no users of a given classifier anymore. Further nested call_rcu()s pointing into the module space are not being done anywhere. Only cls_bpf_delete_prog() may schedule a work item, to unlock pages eventually, but that is not in the range/context of cls_bpf anymore. Fixes: 25d8c0d5 ("net: rcu-ify tcf_proto") Fixes: 9888faef ("net: sched: cls_basic use RCU") Reported-by:
Vijay Subramanian <subramanian.vijay@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: John Fastabend <john.r.fastabend@intel.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Thomas Graf <tgraf@suug.ch> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Alexei Starovoitov <ast@plumgrid.com> Tested-by:
Alexei Starovoitov <ast@plumgrid.com> Acked-by:
-
Henning Rogge authored
[ Upstream commit 33b4b015 ] Commit <5cf3d461> ("udp: Simplify__udp*_lib_mcast_deliver") simplified the filter for incoming IPv6 multicast but removed the check of the local socket address and the UDP destination address. This patch restores the filter to prevent sockets bound to a IPv6 multicast IP to receive other UDP traffic link unicast. Signed-off-by:
Henning Rogge <hrogge@gmail.com> Fixes: 5cf3d461 ("udp: Simplify__udp*_lib_mcast_deliver") Cc: "David S. Miller" <davem@davemloft.net> Acked-by:
-
Florent Fourcot authored
[ Upstream commit 21858cd0 ] commit 1d13a96c ("ipv6: tcp: fix flowlabel value in ACK messages send from TIME_WAIT") added the flow label in the last TCP packets. Unfortunately, it was not casted properly. This patch replace the buggy shift with be32_to_cpu/cpu_to_be32. Fixes: 1d13a96c ("ipv6: tcp: fix flowlabel value in ACK messages") Reported-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Florent Fourcot <florent.fourcot@enst-bretagne.fr> Acked-by:
-
Nicolas Dichtel authored
[ Upstream commit ed2a80ab ] Before the patch, the command 'ip link add bond2 type bond mode 802.3ad' causes the kernel to send a rtnl message for the bond2 interface, with an ifindex 0. 'ip monitor' shows: 0: bond2: <BROADCAST,MULTICAST,MASTER> mtu 1500 state DOWN group default link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 9: bond2@NONE: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default link/ether ea:3e:1f:53:92:7b brd ff:ff:ff:ff:ff:ff [snip] The patch fixes the spotted bug by checking in bond driver if the interface is registered before calling the notifier chain. It also adds a check in rtmsg_ifinfo() to prevent this kind of bug in the future. Fixes: d4261e56 ("bonding: create netlink event when bonding option is changed") CC: Jiri Pirko <jiri@resnulli.us> Reported-by:
Julien Meunier <julien.meunier@6wind.com> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
Herbert Xu authored
[ Upstream commit c0bb07df ] The commit c5adde94 ("netlink: eliminate nl_sk_hash_lock") breaks the autobind retry mechanism because it doesn't reset portid after a failed netlink_insert. This means that should autobind fail the first time around, then the socket will be stuck in limbo as it can never be bound again since it already has a non-zero portid. Fixes: c5adde94 ("netlink: eliminate nl_sk_hash_lock") Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 7e140696 ] RGMII interfaces come in multiple flavors: RGMII with transmit or receive internal delay, no delays at all, or delays in both direction. This change extends the initial check for PHY_INTERFACE_MODE_RGMII to cover all of these variants since EEE should be allowed for any of these modes, since it is a property of the RGMII, hence Gigabit PHY capability more than the RGMII electrical interface and its delays. Fixes: a59a4d19 ("phy: add the EEE support and the way to access to the MMD registers") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Alexei Starovoitov authored
[ Upstream commit 3f7352bf ] x86 has variable length encoding. x86 JIT compiler is trying to pick the shortest encoding for given bpf instruction. While doing so the jump targets are changing, so JIT is doing multiple passes over the program. Typical program needs 3 passes. Some very short programs converge with 2 passes. Large programs may need 4 or 5. But specially crafted bpf programs may hit the pass limit and if the program converges on the last iteration the JIT compiler will be producing an image full of 'int 3' insns. Fix this corner case by doing final iteration over bpf program. Fixes: 0a14842f ("net: filter: Just In Time compiler for x86-64") Reported-by:
-
Alexei Starovoitov authored
[ Upstream commit 343f845b ] FROM_BE16: 'ror %reg, 8' doesn't clear upper bits of the register, so use additional 'movzwl' insn to zero extend 16 bits into 64 FROM_LE16: should zero extend lower 16 bits into 64 bit FROM_LE32: should zero extend lower 32 bits into 64 bit Fixes: 89aa0758 ("net: sock: allow eBPF programs to be attached to sockets") Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit d66bf7dd ] The code in __netdev_upper_dev_link() has an over-stringent loop detection logic that actually prevents valid configurations from working correctly. In particular, the logic returns an error if an upper device is already in the list of all upper devices for a given dev. This particular check seems to be a overzealous as it disallows perfectly valid configurations. For example: # ip l a link eth0 name eth0.10 type vlan id 10 # ip l a dev br0 typ bridge # ip l s eth0.10 master br0 # ip l s eth0 master br0 <--- Will fail If you switch the last two commands (add eth0 first), then both will succeed. If after that, you remove eth0 and try to re-add it, it will fail! It appears to be enough to simply check adj_list to keeps things safe. I've tried stacking multiple devices multiple times in all different combinations, and either rx_handler registration prevented the stacking of the device linking cought the error. Signed-off-by:
Vladislav Yasevich <vyasevic@redhat.com> Acked-by:
Jiri Pirko <jiri@resnulli.us> Acked-by:
Veaceslav Falico <vfalico@gmail.com> Signed-off-by:
-
Jens Axboe authored
commit dc48e56d upstream. exit_aio() currently serializes killing io contexts. Each context killing ends up having to do percpu_ref_kill(), which in turns has to wait for an RCU grace period. This can take a long time, depending on the number of contexts. And there's no point in doing them serially, when we could be waiting for all of them in one fell swoop. This patches makes my fio thread offload test case exit 0.2s instead of almost 6s. Reviewed-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Ilya Dryomov authored
commit 45002267 upstream. Crush temporary buffers are allocated as per replica size configured by the user. When there are more final osds (to be selected as per rule) than the replicas, buffer overlaps and it causes crash. Now, it ensures that at most num-rep osds are selected even if more number of osds are allowed by the rule. Reflects ceph.git commits 6b4d1aa99718e3b367496326c1e64551330fabc0, 234b066ba04976783d15ff2abc3e81b6cc06fb10. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
- 06 Jun, 2015 20 commits
-
-
Greg Kroah-Hartman authored
-
Andrew Morton authored
commit 2b1d3ae9 upstream. load_elf_binary() returns `retval', not `error'. Fixes: a87938b2 ("fs/binfmt_elf.c: fix bug in loading of PIE binaries") Reported-by:
James Hogan <james.hogan@imgtec.com> Cc: Michael Davidson <md@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
NeilBrown authored
commit 56ccc112 upstream. A recent change removed the need for locking around writing to "sync_action" (and various other places), but introduced a subtle race. When e.g. setting 'reshape' on a 'frozen' array, the 'frozen' flag is cleared before 'reshape' is set, so the md thread can get in and start trying recovery - which isn't wanted. So instead of clearing MD_RECOVERY_FROZEN for any command except 'frozen', only clear it when each specific command is parsed. This allows the handling of 'reshape' to clear the bit while a lock is held. Also remove some places where we set MD_RECOVERY_NEEDED, as it is always set on non-error exit of the function. Signed-off-by:
NeilBrown <neilb@suse.de> Fixes: 6791875e ("md: make reconfig_mutex optional for writes to md sysfs files.") Signed-off-by:
-
Naidu Tellapati authored
commit 1e70897d upstream. The PWM hardware on Pistachio platform has a maximum timebase steps value to 255. To fix it, let's introduce a compatible-specific data structure to contain the SoC-specific details and use it to specify a maximum timebase. Also, let's limit the minimum timebase to 16 steps, to allow a sane range of duty cycle steps. Fixes: 277bb6a2 ("pwm: Imagination Technologies PWM DAC driver") Signed-off-by:
Naidu Tellapati <naidu.tellapati@imgtec.com> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@imgtec.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Kevin Cernekee authored
commit 98fb1ffd upstream. Block drivers are responsible for calling flush_dcache_page() on each BIO request. This operation keeps the I$ coherent with the D$ on architectures that don't have hardware coherency support. Without this flush, random crashes are seen when executing user programs from an ext4 filesystem backed by a ubiblock device. This patch is based on the change implemented in commit 2d4dc890 ("block: add helpers to run flush_dcache_page() against a bio and a request's pages"). Fixes: 9d54c8a3 ("UBI: R/O block driver on top of UBI volumes") Signed-off-by:
Kevin Cernekee <cernekee@chromium.org> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Vineet Gupta authored
commit daaf40e5 upstream. Fixes: f7d11e93 locking,arch,arc: Fold atomic_ops Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Wei Yongjun authored
commit 932df430 upstream. In case of error, the function devm_ioremap() returns NULL not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: ecfe64d8 ("power: reset: Add AT91 reset driver") Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Sasha Levin authored
commit 161f873b upstream. We used to read file_handle twice. Once to get the amount of extra bytes, and once to fetch the entire structure. This may be problematic since we do size verifications only after the first read, so if the number of extra bytes changes in userspace between the first and second calls, we'll have an incoherent view of file_handle. Instead, read the constant size once, and copy that over to the final structure without having to re-read it again. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Oded Gabbay authored
commit 42e08c78 upstream. This patch sets the local memory size that is reported to userspace to 0. This is done to make sure that userspace won't try to allocate local memory for HSA. As long as amdkfd doesn't support allocating local memory for HSA, we need this patch. Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com> Cc: stable@vger.kernel.org Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Junichi Nomura authored
commit 15b94a69 upstream. dm-multipath accepts 0 path mapping. # echo '0 2097152 multipath 0 0 0 0' | dmsetup create newdev Such a mapping can be used to release underlying devices while still holding requests in its queue until working paths come back. However, once the multipath device is created over blk-mq devices, it rejects reloading of 0 path mapping: # echo '0 2097152 multipath 0 0 1 1 queue-length 0 1 1 /dev/sda 1' \ | dmsetup create mpath1 # echo '0 2097152 multipath 0 0 0 0' | dmsetup load mpath1 device-mapper: reload ioctl on mpath1 failed: Invalid argument Command failed With following kernel message: device-mapper: ioctl: can't change device type after initial table load. DM tries to inherit the current table type using dm_table_set_type() but it doesn't work as expected because of unnecessary check about whether the target type is hybrid or not. Hybrid type is for targets that work as either request-based or bio-based and not required for blk-mq or non blk-mq checking. Fixes: 65803c20 ("dm table: train hybrid target type detection to select blk-mq if appropriate") Signed-off-by:
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Joe Thornber authored
commit 1c220c69 upstream. dm_merge_bvec() was originally added in f6fccb ("dm: introduce merge_bvec_fn"). In that commit a value in sectors is converted to bytes using << 9, and then assigned to an int. This code made assumptions about the value of BIO_MAX_SECTORS. A later commit 148e51 ("dm: improve documentation and code clarity in dm_merge_bvec") was meant to have no functional change but it removed the use of BIO_MAX_SECTORS in favor of using queue_max_sectors(). At this point the cast from sector_t to int resulted in a zero value. The fallout being dm_merge_bvec() would only allow a single page to be added to a bio. This interim fix is minimal for the benefit of stable@ because the more comprehensive cleanup of passing a sector_t to all DM targets' merge function will impact quite a few DM targets. Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
-
Christian König authored
commit 7c0411d2 upstream. We have that bug for years and some users report side effects when fixing it on older hardware. So revert it for VM_CONTEXT0_PAGE_TABLE_END_ADDR, but keep it for VM 1-15. Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 2d1c18bb upstream. This breaks too many things. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=99041 https://bugs.freedesktop.org/show_bug.cgi?id=90681 This reverts commit 0f55db36. Signed-off-by:
-
Alex Deucher authored
commit fbfd3bc7 upstream. Avoids a crash when a monitor is hotplugged and the encoder and connector are not linked yet. bug: https://bugs.freedesktop.org/show_bug.cgi?id=90681Signed-off-by:
-
Alex Deucher authored
commit a10f0df0 upstream. Enabling audio may enable different pll dividers. Don't share plls if the monitors differ in audio support. bug: https://bugzilla.kernel.org/show_bug.cgi?id=98751Signed-off-by:
-
Daniel Vetter authored
commit 2e7f43c4 upstream. In commit f02ad907 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jan 22 16:36:23 2015 +0100 drm/atomic-helpers: Recover full cursor plane behaviour we've added a hack to atomic helpers to never to vblank waits for cursor updates through the legacy apis since that's what X expects. Unfortunately we've (again) forgotten to adjust the transitional helpers. Do this now. This fixes regressions for drivers only partially converted over to atomic (like i915). Reported-by:
Pekka Paalanen <ppaalanen@gmail.com> Cc: Pekka Paalanen <ppaalanen@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-and-tested-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Alex Deucher authored
commit 0f28d128 upstream. Retry the dpcd fetch several times. Some eDP panels fail several times before the fetch is successful. bug: https://bugs.freedesktop.org/show_bug.cgi?id=73530Signed-off-by:
-
Christian König authored
commit 607d4806 upstream. The mapping range is inclusive between starting and ending addresses. Signed-off-by:
-
Alex Deucher authored
commit fcf3b542 upstream. Signed-off-by:
-
Liad Kaufman authored
commit 553452e5 upstream. In the case of a DMA mapping error on the last iteration of the loop of the allocation of memory of the FW monitor we indeed free the pages, but don't NULL out the page variable thus allowing for the possibility of setting the FW monitor variables with invalid data to use. Fixes: c2d20201 ("iwlwifi: pcie: add firmware monitor capabilities") Signed-off-by:
Liad Kaufman <liad.kaufman@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
