<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers, branch v4.14.4</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.14.4</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.14.4'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-12-05T10:26:38Z</updated>
<entry>
<title>drm/i915: Prevent zero length "index" write</title>
<updated>2017-12-05T10:26:38Z</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2017-11-23T19:41:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=88e1bb2a24125747d48b5e2d60bccdb247b86eb9'/>
<id>urn:sha1:88e1bb2a24125747d48b5e2d60bccdb247b86eb9</id>
<content type='text'>
commit 56350fb8978bbf4aafe08f21234e161dd128b417 upstream.

The hardware always writes one or two bytes in the index portion of
an indexed transfer. Make sure the message we send as the index
doesn't have a zero length.

Cc: Daniel Kurtz &lt;djkurtz@chromium.org&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Sean Paul &lt;seanpaul@chromium.org&gt;
Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
(cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Don't try indexed reads to alternate slave addresses</title>
<updated>2017-12-05T10:26:38Z</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2017-11-23T19:41:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e522b9247ce931a7319f1d7e9d0bdfa5817b9a4e'/>
<id>urn:sha1:e522b9247ce931a7319f1d7e9d0bdfa5817b9a4e</id>
<content type='text'>
commit ae5c631e605a452a5a0e73205a92810c01ed954b upstream.

We can only specify the one slave address to indexed reads/writes.
Make sure the messages we check are destined to the same slave
address before deciding to do an indexed transfer.

Cc: Daniel Kurtz &lt;djkurtz@chromium.org&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Sean Paul &lt;seanpaul@chromium.org&gt;
Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
(cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition</title>
<updated>2017-12-05T10:26:38Z</updated>
<author>
<name>Xiong Zhang</name>
<email>xiong.y.zhang@intel.com</email>
</author>
<published>2017-11-27T23:29:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6c0d3d1d5908f5cd5c838c99663238cac201953b'/>
<id>urn:sha1:6c0d3d1d5908f5cd5c838c99663238cac201953b</id>
<content type='text'>
commit b721b65af4eb46df6a1d9e34b14003225e403565 upstream.

For ADDR_4K_MASK, bit[45..12] should be 1, all other bits
should be 0. The current definition wrongly set bit[46] as 1
also. This path fixes this.

v2: Add commit message, fixes and cc stable.(Zhenyu)

Fixes: 2707e4446688("drm/i915/gvt: vGPU graphics memory virtualization")
Signed-off-by: Xiong Zhang &lt;xiong.y.zhang@intel.com&gt;
Signed-off-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915/fbdev: Serialise early hotplug events with async fbdev config</title>
<updated>2017-12-05T10:26:38Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2017-11-25T19:41:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7042c2b9a19e74972f5783ab3b7ef98ebdee293f'/>
<id>urn:sha1:7042c2b9a19e74972f5783ab3b7ef98ebdee293f</id>
<content type='text'>
commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643 upstream.

As both the hotplug event and fbdev configuration run asynchronously, it
is possible for them to run concurrently. If configuration fails, we were
freeing the fbdev causing a use-after-free in the hotplug event.

&lt;7&gt;[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration
&lt;7&gt;[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77
&lt;7&gt;[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0
&lt;7&gt;[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800
&lt;7&gt;[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config
&lt;7&gt;[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0)
&lt;7&gt;[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
&lt;4&gt;[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP
&lt;0&gt;[ 3069.977453] ---------------------------------
&lt;4&gt;[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915]
&lt;4&gt;[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G     U          4.14.0-CI-CI_DRM_3388+ #1
&lt;4&gt;[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
&lt;4&gt;[ 3069.977508] Workqueue: events output_poll_execute
&lt;4&gt;[ 3069.977512] task: ffff880177734e40 task.stack: ffffc90001fe4000
&lt;4&gt;[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60
&lt;4&gt;[ 3069.977523] RSP: 0018:ffffc90001fe7bb0 EFLAGS: 00010002
&lt;4&gt;[ 3069.977526] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000282 RCX: 0000000000000000
&lt;4&gt;[ 3069.977530] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880170d4efd0
&lt;4&gt;[ 3069.977534] RBP: ffffc90001fe7c70 R08: 0000000000000001 R09: 0000000000000000
&lt;4&gt;[ 3069.977538] R10: 0000000000000000 R11: ffffffff81899609 R12: ffff880170d4efd0
&lt;4&gt;[ 3069.977542] R13: ffff880177734e40 R14: 0000000000000001 R15: 0000000000000000
&lt;4&gt;[ 3069.977547] FS:  0000000000000000(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000
&lt;4&gt;[ 3069.977551] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&lt;4&gt;[ 3069.977555] CR2: 00007f7e8b7bcf04 CR3: 0000000003e0f000 CR4: 00000000003406e0
&lt;4&gt;[ 3069.977559] Call Trace:
&lt;4&gt;[ 3069.977565]  ? mark_held_locks+0x64/0x90
&lt;4&gt;[ 3069.977571]  ? _raw_spin_unlock_irq+0x24/0x50
&lt;4&gt;[ 3069.977575]  ? _raw_spin_unlock_irq+0x24/0x50
&lt;4&gt;[ 3069.977579]  ? trace_hardirqs_on_caller+0xde/0x1c0
&lt;4&gt;[ 3069.977583]  ? _raw_spin_unlock_irq+0x2f/0x50
&lt;4&gt;[ 3069.977588]  ? finish_task_switch+0xa5/0x210
&lt;4&gt;[ 3069.977592]  ? lock_acquire+0xaf/0x200
&lt;4&gt;[ 3069.977596]  lock_acquire+0xaf/0x200
&lt;4&gt;[ 3069.977600]  ? __mutex_lock+0x5e9/0x9b0
&lt;4&gt;[ 3069.977604]  _raw_spin_lock+0x2a/0x40
&lt;4&gt;[ 3069.977608]  ? __mutex_lock+0x5e9/0x9b0
&lt;4&gt;[ 3069.977612]  __mutex_lock+0x5e9/0x9b0
&lt;4&gt;[ 3069.977616]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
&lt;4&gt;[ 3069.977621]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
&lt;4&gt;[ 3069.977625]  drm_fb_helper_hotplug_event.part.19+0x16/0xa0
&lt;4&gt;[ 3069.977630]  output_poll_execute+0x8d/0x180
&lt;4&gt;[ 3069.977635]  process_one_work+0x22e/0x660
&lt;4&gt;[ 3069.977640]  worker_thread+0x48/0x3a0
&lt;4&gt;[ 3069.977644]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
&lt;4&gt;[ 3069.977649]  kthread+0x102/0x140
&lt;4&gt;[ 3069.977653]  ? process_one_work+0x660/0x660
&lt;4&gt;[ 3069.977657]  ? kthread_create_on_node+0x40/0x40
&lt;4&gt;[ 3069.977662]  ret_from_fork+0x27/0x40
&lt;4&gt;[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff &lt;f0&gt; ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85
&lt;1&gt;[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP: ffffc90001fe7bb0
&lt;4&gt;[ 3069.977712] ---[ end trace 4ad012eb3af62df7 ]---

In order to keep the dev_priv-&gt;ifbdev alive after failure, we have to
avoid the free and leave it empty until we unload the module (which is
less than ideal, but a necessary evil for simplicity). Then we can use
intel_fbdev_sync() to serialise the hotplug event with the configuration.
The serialisation between the two was removed in commit 934458c2c95d
("Revert "drm/i915: Fix races on fbdev""), but the use after free is much
older, commit 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization
fails")

Fixes: 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails")
Fixes: 934458c2c95d ("Revert "drm/i915: Fix races on fbdev"")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Lukas Wunner &lt;lukas@wunner.de&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Reviewed-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@chris-wilson.co.uk
(cherry picked from commit ad88d7fc6c032ddfb32b8d496a070ab71de3a64f)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Re-register PMIC bus access notifier on runtime resume</title>
<updated>2017-12-05T10:26:38Z</updated>
<author>
<name>Hans de Goede</name>
<email>j.w.r.degoede@gmail.com</email>
</author>
<published>2017-11-14T13:55:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=569e3d1de49f0896733de8e709fc1fd28034d7dc'/>
<id>urn:sha1:569e3d1de49f0896733de8e709fc1fd28034d7dc</id>
<content type='text'>
commit 294cf1af8cf2eb0d1eced377fdfb9a2d3f0e8b42 upstream.

intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.

intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier and call that on runtime resume.

Reported-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Imre Deak &lt;imre.deak@intel.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
(cherry picked from commit bedf4d79c3654921839b62246b0965ddb308b201)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2</title>
<updated>2017-12-05T10:26:38Z</updated>
<author>
<name>Hans de Goede</name>
<email>j.w.r.degoede@gmail.com</email>
</author>
<published>2017-11-10T15:03:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6613dc721fc232698aafd0f6e214137cfda61e35'/>
<id>urn:sha1:6613dc721fc232698aafd0f6e214137cfda61e35</id>
<content type='text'>
commit f4359cedfb43b934f38c50d1604db21333abe57b upstream.

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:

intel_runtime_pm_put does:

   atomic_dec(&amp;dev_priv-&gt;pm.wakeref_count);

   pm_runtime_mark_last_busy(kdev);
   pm_runtime_put_autosuspend(kdev);

And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).

This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.

Changes in v2:
-Reword comment explaining why disabling the wakeref asserts is
 ok and necessary

Reported-by: FKr &lt;bugs-freedesktop@ubermail.me&gt;
Reviewed-by: Imre Deak &lt;imre.deak@intel.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
(cherry picked from commit ce30560c80dead91e98a03d90fb8791e57a9b69d)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>md: forbid a RAID5 from having both a bitmap and a journal.</title>
<updated>2017-12-05T10:26:38Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.com</email>
</author>
<published>2017-10-17T03:24:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a67936842ba66eb229e6322856fefd2310e0b3fb'/>
<id>urn:sha1:a67936842ba66eb229e6322856fefd2310e0b3fb</id>
<content type='text'>
commit 230b55fa8d64007339319539f8f8e68114d08529 upstream.

Having both a bitmap and a journal is pointless.
Attempting to do so can corrupt the bitmap if the journal
replay happens before the bitmap is initialized.
Rather than try to avoid this corruption, simply
refuse to allow arrays with both a bitmap and a journal.
So:
 - if raid5_run sees both are present, fail.
 - if adding a bitmap finds a journal is present, fail
 - if adding a journal finds a bitmap is present, fail.

Signed-off-by: NeilBrown &lt;neilb@suse.com&gt;
Tested-by: Joshua Kinard &lt;kumba@gentoo.org&gt;
Acked-by: Joshua Kinard &lt;kumba@gentoo.org&gt;
Signed-off-by: Shaohua Li &lt;shli@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>e1000e: fix the use of magic numbers for buffer overrun issue</title>
<updated>2017-12-05T10:26:37Z</updated>
<author>
<name>Sasha Neftin</name>
<email>sasha.neftin@intel.com</email>
</author>
<published>2017-11-06T06:31:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=635526b896ca34fff5487d3ac00d04afbee7e1e4'/>
<id>urn:sha1:635526b896ca34fff5487d3ac00d04afbee7e1e4</id>
<content type='text'>
commit c0f4b163a03e73055dd734eaca64b9580e72e7fb upstream.

This is a follow on to commit b10effb92e27 ("fix buffer overrun while the
 I219 is processing DMA transactions") to address David Laights concerns
about the use of "magic" numbers.  So define masks as well as add
additional code comments to give a better understanding of what needs to
be done to avoid a buffer overrun.

Signed-off-by: Sasha Neftin &lt;sasha.neftin@intel.com&gt;
Reviewed-by: Alexander H Duyck &lt;alexander.h.duyck@intel.com&gt;
Reviewed-by: Dima Ruinskiy &lt;dima.ruinskiy@intel.com&gt;
Reviewed-by: Raanan Avargil &lt;raanan.avargil@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/hfi1: Do not warn on lid conversions for OPA</title>
<updated>2017-12-05T10:26:37Z</updated>
<author>
<name>Don Hiatt</name>
<email>don.hiatt@intel.com</email>
</author>
<published>2017-10-02T18:04:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c48f3c04984557e34cf2b7194eb4d7947edccc5e'/>
<id>urn:sha1:c48f3c04984557e34cf2b7194eb4d7947edccc5e</id>
<content type='text'>
commit 4988be5813ff2afdc0d8bfa315ef34a577d3efbf upstream.

On OPA devices opa_local_smp_check will receive 32Bit LIDs when the LID
is Extended. In such cases, it is okay to lose the upper 16 bits of the
LID as this information is obtained elsewhere. Do not issue a warning
when calling ib_lid_cpu16() in this case by masking out the upper 16Bits.

[75920.148985] ------------[ cut here ]------------
[75920.154651] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3788 hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
[75920.166192] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
[75920.246331] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G        W I E   4.13.0-rc7+ #1
[75920.255907] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
[75920.268158] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
[75920.274934] task: ffff88084a718000 task.stack: ffffc9000a424000
[75920.282123] RIP: 0010:hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
[75920.288881] RSP: 0018:ffffc9000a427c38 EFLAGS: 00010206
[75920.295265] RAX: 0000000000010001 RBX: ffff8808361420e8 RCX: ffff880837811d80
[75920.303784] RDX: 0000000000000002 RSI: 0000000000007fff RDI: ffff880837811d80
[75920.312302] RBP: ffffc9000a427d38 R08: 0000000000000000 R09: ffff8808361420e8
[75920.320819] R10: ffff88083841f0e8 R11: ffffc9000a427da8 R12: 0000000000000001
[75920.329335] R13: ffff880837810000 R14: 0000000000000000 R15: ffff88084f1a4800
[75920.337849] FS:  0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000
[75920.347450] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[75920.354405] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0
[75920.362947] Call Trace:
[75920.366257]  ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
[75920.372457]  ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
[75920.378652]  ? __kmalloc+0x1df/0x210
[75920.383229]  ib_mad_recv_done+0x305/0x9b0 [ib_core]
[75920.389270]  __ib_process_cq+0x5d/0xb0 [ib_core]
[75920.395032]  ib_cq_poll_work+0x20/0x60 [ib_core]
[75920.400777]  process_one_work+0x149/0x360
[75920.405836]  worker_thread+0x4d/0x3c0
[75920.410505]  kthread+0x109/0x140
[75920.414681]  ? rescuer_thread+0x380/0x380
[75920.419731]  ? kthread_park+0x60/0x60
[75920.424406]  ret_from_fork+0x25/0x30
[75920.428972] Code: 4c 89 9d 58 ff ff ff 49 89 45 00 66 b8 00 02 49 89 45 08 e8 44 27 89 e0 4c 8b 9d 58 ff ff ff e9 d8 f6 ff ff 0f ff e9 55 e7 ff ff &lt;0f&gt; ff e9 3b e5 ff ff 0f ff 0f 1f 84 00 00 00 00 00 e9 4b e9 ff
[75921.451269] ---[ end trace cf26df27c9597265 ]---

Fixes: 62ede7779904 ("Add OPA extended LID support")
Reviewed-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Don Hiatt &lt;don.hiatt@intel.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Reviewed-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/core: Do not warn on lid conversions for OPA</title>
<updated>2017-12-05T10:26:37Z</updated>
<author>
<name>Don Hiatt</name>
<email>don.hiatt@intel.com</email>
</author>
<published>2017-10-02T18:04:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2b24fdca153f0fd6c2d0f1f60c7606a53b6db575'/>
<id>urn:sha1:2b24fdca153f0fd6c2d0f1f60c7606a53b6db575</id>
<content type='text'>
commit 6588e412fe872ed81f3fb8d9b4561a66ecb763d0 upstream.

On OPA devices the user_mad recv_handler can receive 32Bit LIDs
(e.g. OPA_PERMISSIVE_LID) and it is okay to lose the upper 16 bits
of the LID as this information is obtained elsewhere. Do not issue
a warning when calling ib_lid_be16() in this case by masking out
the upper 16Bits.

[75667.310846] ------------[ cut here ]------------
[75667.316447] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3799 recv_handler+0x15a/0x170 [ib_umad]
[75667.327640] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
[75667.407704] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G        W I E   4.13.0-rc7+ #1
[75667.417310] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
[75667.429555] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
[75667.436360] task: ffff88084a718000 task.stack: ffffc9000a424000
[75667.443549] RIP: 0010:recv_handler+0x15a/0x170 [ib_umad]
[75667.450090] RSP: 0018:ffffc9000a427ce8 EFLAGS: 00010286
[75667.456508] RAX: 00000000ffffffff RBX: ffff88085159ce80 RCX: 0000000000000000
[75667.465094] RDX: ffff88085a47b068 RSI: 0000000000000000 RDI: ffff88085159cf00
[75667.473668] RBP: ffffc9000a427d38 R08: 000000000001efc0 R09: ffff88085159ce80
[75667.482228] R10: ffff88085f007480 R11: ffff88084acf20e8 R12: ffff88085a47b020
[75667.490824] R13: ffff881056842e10 R14: ffff881056840200 R15: ffff88104c8d0800
[75667.499390] FS:  0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000
[75667.509028] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[75667.516080] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0
[75667.524664] Call Trace:
[75667.528044]  ? find_mad_agent+0x7c/0x1b0 [ib_core]
[75667.534031]  ? ib_mark_mad_done+0x73/0xa0 [ib_core]
[75667.540142]  ib_mad_recv_done+0x423/0x9b0 [ib_core]
[75667.546215]  __ib_process_cq+0x5d/0xb0 [ib_core]
[75667.552007]  ib_cq_poll_work+0x20/0x60 [ib_core]
[75667.557766]  process_one_work+0x149/0x360
[75667.562844]  worker_thread+0x4d/0x3c0
[75667.567529]  kthread+0x109/0x140
[75667.571713]  ? rescuer_thread+0x380/0x380
[75667.576775]  ? kthread_park+0x60/0x60
[75667.581447]  ret_from_fork+0x25/0x30
[75667.586014] Code: 43 4a 0f b6 45 c6 88 43 4b 48 8b 45 b0 48 89 43 4c 48 8b 45 b8 48 89 43 54 8b 45 c0 0f c8 89 43 5c e9 79 ff ff ff e8 16 4e fa e0 &lt;0f&gt; ff e9 42 ff ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00
[75667.608323] ---[ end trace cf26df27c9597264 ]---

Fixes: 62ede7779904 ("Add OPA extended LID support")
Reviewed-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Don Hiatt &lt;don.hiatt@intel.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Reviewed-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
