06 Oct, 2014
40 commits
-
commit af438fec6cb99fc2e2faf8b16b865af26ce722e6 upstream.
Use the corresponding compatibles to identify the devices.
Signed-off-by: Rajendra Nayak
Signed-off-by: Lokesh Vutla
Acked-by: Nishanth Menon
Tested-by: Nishanth Menon
Signed-off-by: Paul Walmsley
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit f87dfcabc6f173cc811d185d33327f50a8c88399 upstream.
The mdp_lut_clk isn't a child of the mdp_clk. Instead it's the
child of the mdp_src clock. Fix it.Fixes: 6d00b56fe "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)"
Signed-off-by: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman -
commit ff20783f7b9f35b29e768d8ecc7076c1ca1a60ca upstream.
Clocks that don't have a pre-divider don't list any pre-divider
in their frequency tables, but their tables are initialized using
aggregate initializers. Use tagged initializers so we properly
assign the m and n values for each frequency. Furthermore, the
mmcc_pxo_pll8_pll2_pll3 array improperly mapped the second
element to pll2 instead of pll8, causing the clock driver to
recalculate the wrong rate for any clocks using this array along
with a rate that uses pll2. Plus the .num_parents field is 3
instead of 4 so you can't even switch the parent to pll3. Finally
I noticed that the jpegd clock improperly indicates that the
pre-divider width is only 2, when it's actually 4 bits wide.Fixes: 6d00b56fe "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)"
Tested-by: Rob Clark
Signed-off-by: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman -
commit 0bf22be0da8ea74bc7ccc5b07d7855830be16eca upstream.
The lustre virtual block device cannot handle 64K pages and fails at compile
time. To avoid running into this error, let's disable the Kconfig option
for this driver in cases it doesn't support.Reported-by: Dann Frazier
Signed-off-by: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman -
commit 6098b45b32e6baeacc04790773ced9340601d511 upstream.
It seems that exit_aio() also needs to wait for all iocbs to complete (like
io_destroy), but we missed the wait step in current implemention, so fix
it in the same way as we did in io_destroy.Signed-off-by: Gu Zheng
Signed-off-by: Benjamin LaHaise
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings -
commit 067bb1741c27c8d3b74ac98c0b8fc12b31e67005 upstream.
In some cases, clocks can switch their parent with clk_set_rate, for
example clk_mux can do this in some cases. Current implementation of
clk_change_rate uses un-safe list iteration on the clock children, which
will cause wrong clocks to be parsed in case any of the clock children
change their parents during the change rate operation. Fixed by using
the safe list iterator instead.The problem was detected due to some divide by zero errors generated
by clock init on dra7-evm board, see discussion under
http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details.Fixes: 71472c0c06cf ("clk: add support for clock reparent on set_rate")
Signed-off-by: Tero Kristo
Reported-by: Nishanth Menon
Signed-off-by: Mike Turquette
Signed-off-by: Greg Kroah-Hartman -
commit 24223657806a0ebd0ae5c9caaf7b021091889cf2 upstream.
CPUs which should support the RAPL counters according to
Family/Model/Stepping may still issue #GP when attempting to access
the RAPL MSRs. This may happen when Linux is running under KVM and
we are passing-through host F/M/S data, for example. Use rdmsrl_safe
to first access the RAPL_POWER_UNIT MSR; if this fails, do not
attempt to use this PMU.Signed-off-by: Venkatesh Srinivas
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/r/1394739386-22260-1-git-send-email-venkateshs@google.com
Cc: zheng.z.yan@intel.com
Cc: eranian@google.com
Cc: ak@linux.intel.com
Cc: linux-kernel@vger.kernel.org
[ The patch also silently fixes another bug: rapl_pmu_init() didn't handle the memory alloc failure case previously. ]
Signed-off-by: Ingo Molnar
[backport by whissi]
Cc: Thomas D
Signed-off-by: Greg Kroah-Hartman -
commit d97a86c170b4e432f76db072a827fe30b4d6f659 upstream.
The lvip[] array has "state->limit" elements so the condition here
should be >= instead of >.Fixes: 6ceea22bbbc8 ('partitions: add aix lvm partition support files')
Signed-off-by: Dan Carpenter
Acked-by: Philippe De Muyter
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit dd8ecfcac66b4485416b2d1df0ec4798b198d7d6 upstream.
Accordingly to discussion [1] and followed up documentation the DMA controller
driver shouldn't start any DMA operations when dmaengine_submit() is called.This patch fixes the workflow in dw_dmac driver to follow the documentation.
[1] http://www.spinics.net/lists/arm-kernel/msg125987.html
Signed-off-by: Andy Shevchenko
Signed-off-by: Vinod Koul
Cc: "Petallo, MauriceX R"
Signed-off-by: Greg Kroah-Hartman -
commit e7637c6c0382485f4d2e20715d058dae6f2b6a7c upstream.
We have a duplicate code which starts first descriptor in the queue. Let's make
this as a separate helper that can be used in future as well.Signed-off-by: Andy Shevchenko
Signed-off-by: Vinod Koul
Cc: "Petallo, MauriceX R"
Signed-off-by: Greg Kroah-Hartman -
commit d4089a332883ad969700aac5dd4dd5f1c4fee825 upstream.
Using dma_mapping_error() to make sure the mapping did not
fail.Signed-off-by: Heikki Krogerus
Cc: "Petallo, MauriceX R"
Signed-off-by: Greg Kroah-Hartman -
commit 43e8317b0bba1d6eb85f38a4a233d82d7c20d732 upstream.
Use the observation that, for platform-dependent sleep states
(PM_SUSPEND_STANDBY, PM_SUSPEND_MEM), a given state is either
always supported or always unsupported and store that information
in pm_states[] instead of calling valid_state() every time we
need to check it.Also do not use valid_state() for PM_SUSPEND_FREEZE, which is always
valid, and move the pm_test_level validity check for PM_SUSPEND_FREEZE
directly into enter_state().Signed-off-by: Rafael J. Wysocki
Cc: Brian Norris
Signed-off-by: Greg Kroah-Hartman -
commit 27ddcc6596e50cb8f03d2e83248897667811d8f6 upstream.
To allow sleep states corresponding to the "mem", "standby" and
"freeze" lables to be different from the pm_states[] indexes of
those strings, introduce struct pm_sleep_state, consisting of
a string label and a state number, and turn pm_states[] into an
array of objects of that type.This modification should not lead to any functional changes.
Signed-off-by: Rafael J. Wysocki
Cc: Brian Norris
Signed-off-by: Greg Kroah-Hartman -
commit eb90b0c734ad793d5f5bf230a9e9a4dcc48df8aa upstream.
commit fc604767613b6d2036cdc35b660bc39451040a47
("ipvs: changes for local real server") from 2.6.37
introduced DNAT support to local real server but the
IPv6 LOCAL_OUT handler ip_vs_local_reply6() is
registered incorrectly as IPv4 hook causing any outgoing
IPv4 traffic to be dropped depending on the IP header values.Chris tracked down the problem to CONFIG_IP_VS_IPV6=y
Bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768Reported-by: Chris J Arges
Tested-by: Chris J Arges
Signed-off-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman -
commit caa8ad94edf686d02b555c65a6162c0d1b434958 upstream.
There's actually no good reason why we cannot use cgroup id 0,
so lets just remove this artificial barrier.Reported-by: Alexey Perevalov
Signed-off-by: Daniel Borkmann
Tested-by: Alexey Perevalov
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit 76f084bc10004b3050b2cff9cfac29148f1f6088 upstream.
Previously, only the four high bits of the tclass were maintained in the
ipv6 case. This matches the behavior of ipv4, though whether or not we
should reflect ECN bits may be up for debate.Signed-off-by: Alex Gartrell
Acked-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman -
commit 7bd8490eef9776ced7632345df5133384b6be0fe upstream.
xt_hashlimit cannot be used with large hash tables, because garbage
collector is run from a timer. If table is really big, its possible
to hold cpu for more than 500 msec, which is unacceptable.Switch to a work queue, and use proper scheduling points to remove
latencies spikes.Later, we also could switch to a smoother garbage collection done
at lookup time, one bucket at a time...Signed-off-by: Eric Dumazet
Cc: Florian Westphal
Cc: Patrick McHardy
Reviewed-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit 2627b7e15c5064ddd5e578e4efd948d48d531a3f upstream.
commit 8f4e0a18682d91 ("IPVS netns exit causes crash in conntrack")
added second ip_vs_conn_drop_conntrack call instead of just adding
the needed check. As result, the first call still can cause
crash on netns exit. Remove it.Signed-off-by: Julian Anastasov
Signed-off-by: Hans Schillstrom
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman -
commit f0cc9a057151892b885be21a1d19b0185568281d upstream.
r1_bio->start_next_window is not initialised in the READ
case, so allow_barrier may incorrectly decrement
conf->current_window_requests
which can cause raise_barrier() to block forever.Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Reported-by: Brassow Jonathan
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit b8cb6b4c121e1bf1963c16ed69e7adcb1bc301cd upstream.
If a devices is being recovered it is not InSync and is not Faulty.
If a read error is experienced on that device, fix_read_error()
will be called, but it ignores non-InSync devices. So it will
neither fix the error nor fail the device.It is incorrect that fix_read_error() ignores non-InSync devices.
It should only ignore Faulty devices. So fix it.This became a bug when we allowed reading from a device that was being
recovered. It is suitable for any subsequent -stable kernel.Fixes: da8840a747c0dbf49506ec906757a6b87b9741e9
Reported-by: Alexander Lyakas
Tested-by: Alexander Lyakas
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 34e97f170149bfa14979581c4c748bc9b4b79d5b upstream.
Both normal IO and resync IO can be retried with reschedule_retry()
and so be counted into ->nr_queued, but only normal IO gets counted in
->nr_pending.Before the recent improvement to RAID1 resync there could only
possibly have been one or the other on the queue. When handling a
read failure it could only be normal IO. So when handle_read_error()
called freeze_array() the fact that freeze_array only compares
->nr_queued against ->nr_pending was safe.But now that these two types can interleave, we can have both normal
and resync IO requests queued, so we need to count them both in
nr_pending.This error can lead to freeze_array() hanging if there is a read
error, so it is suitable for -stable.Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Reported-by: Brassow Jonathan
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit c2fd4c94deedb89ac1746c4a53219be499372c06 upstream.
raise_barrier() uses next_resync as part of its calculations, so it
really should be updated first, instead of afterwards.next_resync is always used under resync_lock so update it under
resync lock to, just before it is used. That is safest.This could cause normal IO and resync IO to interact badly so
it suitable for -stable.Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 235549605eb7f1c5a37cef8b09d12e6d412c5cd6 upstream.
next_resync is (approximately) the location for the next resync request.
However it does *not* reliably determine the earliest location
at which resync might be happening.
This is because resync requests can complete out of order, and
we only limit the number of current requests, not the distance
from the earliest pending request to the latest.mddev->curr_resync_completed is a reliable indicator of the earliest
position at which resync could be happening. It is updated less
frequently, but is actually reliable which is more important.So use it to determine if a write request is before the region
being resynced and so safe from conflict.This error can allow resync IO to interfere with normal IO which
could lead to data corruption. Hence: stable.Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 2f73d3c55d09ce60647b96ad2a9b539c95a530ee upstream.
The resync/recovery process for raid1 was recently changed
so that writes could happen in parallel with resync providing
they were in different regions of the device.There is a problem though: While a write request will always
wait for conflicting resync to complete, a resync request
will *not* always wait for conflicting writes to complete.Two changes are needed to fix this:
1/ raise_barrier (which waits until it is safe to do resync)
must wait until current_window_requests is zero
2/ wait_battier (which waits at the start of a new write request)
must update current_window_requests if the request could
possible conflict with a concurrent resync.As concurrent writes and resync can lead to data loss,
this patch is suitable for -stable.Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Cc: majianpeng
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit c6d119cf1b5a778e9ed60a006e2a434fcc4471a2 upstream.
commit 79ef3a8aa1cb1523cc231c9a90a278333c21f761 made
it possible for reads to happen concurrently with resync.
This means that we need to be more careful where read_balancing
is allowed during resync - we can no longer be sure that any
resync that has already started will definitely finish.So keep read_balancing to before recovery_cp, which is conservative
but safe.This bug makes it possible to read from a device that doesn't
have up-to-date data, so it can cause data corruption.
So it is suitable for any kernel since 3.11.Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 669cc7ba77864e7b1ac39c9f2b2afb8730f341f4 upstream.
If there are outstanding writes when close_sync is called,
the change to ->start_next_window might cause them to
decrement the wrong counter when they complete. Fix this
by merging the two counters into the one that will be decremented.Having an incorrect value in a counter can cause raise_barrier()
to hangs, so this is suitable for -stable.Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 77639ff2b3404a913b8037d230a384798b854bae upstream.
The log_status function should show HDMI information, but the test checking for
an HDMI input was inverted. Fix this.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 6a03dc92cc2edfa2257502557b9f714893987383 upstream.
This was caused by an uninitialized setup.config field.
Based on a suggestion from Devin Heitmueller.
Signed-off-by: Hans Verkuil
Thanks-to: Devin Heitmueller
Reported-by: Scott Robinson
Tested-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit a04646c045cab08a9e62b9be8f01ecbb0632d24e upstream.
add the following IDs
USB_PID_PCTV_78E (0x025a) for PCTV 78e
USB_PID_PCTV_79E (0x0262) for PCTV 79eFor these it9135 devices.
Signed-off-by: Malcolm Priestley
Cc: Antti Palosaari
Signed-off-by: Antti Palosaari
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 7106e02baed4a72fb23de56b02ad4d31daa74d95 upstream.
While debugging a cpufreq-related hardware failure on a system I saw the
following lockdep warning:=========================
[ BUG: held lock freed! ] 3.17.0-rc4+ #1 Tainted: G E
-------------------------
insmod/2247 is freeing memory ffff88006e1b1400-ffff88006e1b17ff, with a lock still held there!
(&policy->rwsem){+.+...}, at: [] __cpufreq_add_dev.isra.21+0x47d/0xb80
3 locks held by insmod/2247:
#0: (subsys mutex#5){+.+.+.}, at: [] subsys_interface_register+0x69/0x120
#1: (cpufreq_rwsem){.+.+.+}, at: [] __cpufreq_add_dev.isra.21+0x73/0xb80
#2: (&policy->rwsem){+.+...}, at: [] __cpufreq_add_dev.isra.21+0x47d/0xb80stack backtrace:
CPU: 0 PID: 2247 Comm: insmod Tainted: G E 3.17.0-rc4+ #1
Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 08/24/2013
0000000000000000 000000008f3063c4 ffff88006f87bb30 ffffffff8171b358
ffff88006bcf3750 ffff88006f87bb68 ffffffff810e09e1 ffff88006e1b1400
ffffea0001b86c00 ffffffff8156d327 ffff880073003500 0000000000000246
Call Trace:
[] dump_stack+0x4d/0x66
[] debug_check_no_locks_freed+0x171/0x180
[] ? __cpufreq_add_dev.isra.21+0x427/0xb80
[] kfree+0xab/0x2b0
[] __cpufreq_add_dev.isra.21+0x427/0xb80
[] ? _raw_spin_unlock+0x27/0x40
[] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
[] cpufreq_add_dev+0xe/0x10
[] subsys_interface_register+0xc1/0x120
[] cpufreq_register_driver+0x112/0x340
[] ? kfree+0xda/0x2b0
[] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
[] pcc_cpufreq_init+0x4af/0xe81 [pcc_cpufreq]
[] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
[] do_one_initcall+0xd4/0x210
[] ? __vunmap+0xd2/0x120
[] load_module+0x1315/0x1b70
[] ? store_uevent+0x70/0x70
[] ? copy_module_from_fd.isra.44+0x129/0x180
[] SyS_finit_module+0xa6/0xd0
[] system_call_fastpath+0x16/0x1b
cpufreq: __cpufreq_add_dev: ->get() failed
insmod: ERROR: could not insert module pcc-cpufreq.ko: No such deviceThe warning occurs in the __cpufreq_add_dev() code which does
down_write(&policy->rwsem);
...
if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {
policy->cur = cpufreq_driver->get(policy->cpu);
if (!policy->cur) {
pr_err("%s: ->get() failed\n", __func__);
goto err_get_freq;
}If cpufreq_driver->get(policy->cpu) returns an error we execute the
code at err_get_freq, which does not up the policy->rwsem. This causes
the lockdep warning.Trivial patch to up the policy->rwsem in the error path.
After the patch has been applied, and an error occurs in the
cpufreq_driver->get(policy->cpu) call we will now seecpufreq: __cpufreq_add_dev: ->get() failed
cpufreq: __cpufreq_add_dev: ->get() failed
modprobe: ERROR: could not insert 'pcc_cpufreq': No such deviceFixes: 4e97b631f24c (cpufreq: Initialize governor for a new policy under policy->rwsem)
Signed-off-by: Prarit Bhargava
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit bd8c78e78d5011d8111bc2533ee73b13a3bd6c42 upstream.
In testmode and vendor command reply/event SKBs we use the
skb cb data to store nl80211 parameters between allocation
and sending. This causes the code for CONFIG_NETLINK_MMAP
to get confused, because it takes ownership of the skb cb
data when the SKB is handed off to netlink, and it doesn't
explicitly clear it.Clear the skb cb explicitly when we're done and before it
gets passed to netlink to avoid this issue.Reported-by: Assaf Azulay
Reported-by: David Spinadel
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman -
commit f2d5a94436cc7cc0221b9a81bba2276a25187dd3 upstream.
On 32-bit architectures, the legacy buffer_head functions are not always
handling the sector number with the proper 64-bit types, and will thus
fail on 4TB+ disks.Any code that uses __getblk() (and thus bread(), breadahead(),
sb_bread(), sb_breadahead(), sb_getblk()), and calls it using a 64-bit
block on a 32-bit arch (where "long" is 32-bit) causes an inifinite loop
in __getblk_slow() with an infinite stream of errors logged to dmesg
like this:__find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648
b_state=0x00000020, b_size=512
device sda1 blocksize: 512Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e. the
top 32-bits are missing (in this case the 0x1 at the top).This is because grow_dev_page() is broken and has a 32-bit overflow due
to shifting the page index value (a pgoff_t - which is just 32 bits on
32-bit architectures) left-shifted as the block number. But the top
bits to get lost as the pgoff_t is not type cast to sector_t / 64-bit
before the shift.This patch fixes this issue by type casting "index" to sector_t before
doing the left shift.Note this is not a theoretical bug but has been seen in the field on a
4TiB hard drive with logical sector size 512 bytes.This patch has been verified to fix the infinite loop problem on 3.17-rc5
kernel using a 4TB disk image mounted using "-o loop". Without this patch
doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop
100% reproducibly whilst with the patch it works fine as expected.Signed-off-by: Anton Altaparmakov
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 2e97140dd58cab8772bf77d73eabda213e45202d upstream.
Use the new vga_switcheroo_fini_domain_pm_ops function
to unregister the pm ops.Based on a patch from:
Pali Rohárbug:
https://bugzilla.kernel.org/show_bug.cgi?id=84431Reviewed-by: Ben Skeggs
Signed-off-by: Alex Deucher
Signed-off-by: Pali Rohár
Cc: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit 53beaa01e0fe8e4202f43485a03b32fcf5dfea74 upstream.
Use the new vga_switcheroo_fini_domain_pm_ops function
to unregister the pm ops.Based on a patch from:
Pali Rohárbug:
https://bugzilla.kernel.org/show_bug.cgi?id=84431Reviewed-by: Ben Skeggs
Signed-off-by: Alex Deucher
Cc: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit 766a53d059d1500c9755c8af017bd411bd8f1b20 upstream.
Drivers should call this on unload to unregister pmops.
Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=84431Reviewed-by: Ben Skeggs
Signed-off-by: Alex Deucher
Signed-off-by: Pali Rohár
Cc: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit 3577af70a2ce4853d58e57d832e687d739281479 upstream.
We saw a kernel soft lockup in perf_remove_from_context(),
it looks like the `perf` process, when exiting, could not go
out of the retry loop. Meanwhile, the target process was forking
a child. So either the target process should execute the smp
function call to deactive the event (if it was running) or it should
do a context switch which deactives the event.It seems we optimize out a context switch in perf_event_context_sched_out(),
and what's more important, we still test an obsolete task pointer when
retrying, so no one actually would deactive that event in this situation.
Fix it directly by reloading the task pointer in perf_remove_from_context().This should cure the above soft lockup.
Signed-off-by: Cong Wang
Signed-off-by: Cong Wang
Signed-off-by: Peter Zijlstra
Cc: Paul Mackerras
Cc: Arnaldo Carvalho de Melo
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1409696840-843-1-git-send-email-xiyou.wangcong@gmail.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit a59c5850f09b4c2d6ad2fc47e5e1be8d654529d6 upstream.
When marsheling a user path to the kernel struct ib_sa_path, need
to zero smac, dmac and set the vlan id to the "no vlan" value.Fixes: dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm structures")
Reported-by: Aleksey Senin
Signed-off-by: Matan Barak
Signed-off-by: Or Gerlitz
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit f5c4834d9328c4ed9fe5dcbec6128d6da16db69a upstream.
When reading the IPv6 addresses from the net-device, make sure to
avoid adding a duplicate entry to the GID table because of equality
between the default GID we generate and the default IPv6 link-local
address of the device.Fixes: acc4fccf4eff ("IB/mlx4: Make sure GID index 0 is always occupied")
Signed-off-by: Moni Shoua
Signed-off-by: Or Gerlitz
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit e381835cf1b8e3b2857277dbc3b77d8c5350f70a upstream.
When Ethernet netdev is not present for a port (e.g. when the link
layer type of the port is InfiniBand) it's possible to dereference a
null pointer when we do netdevice scanning.To fix that, we move a section of code that needs to run only when
netdev is present to a proper if () statement.Fixes: ad4885d279b6 ("IB/mlx4: Build the port IBoE GID table properly under bonding")
Reported-by: Dan Carpenter
Signed-off-by: Moni Shoua
Signed-off-by: Or Gerlitz
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman
