Age | Commit message (Collapse) | Author | Files | Lines |
|
It's duplicating (without using some of the helpers) drm_gem_mmap with
the addition that it can redirect to drm-buf mmap support. But prime
import/export was dropped in
commit 990ed2720717173bbdea4cfb2bad37cc7aa91495
Author: Rob Clark <robdclark@gmail.com>
Date: Thu May 21 11:58:30 2015 -0400
drm/vgem: drop DRIVER_PRIME (v2)
for now, so this is dead code. And since I want to rework the locking
for drm_gem_mmap it seems simpler to de-dupe this code for now and
then start over with the reworked one again, if we want to resurrect
this all indeed.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://mid.gmane.org/1444894601-5200-8-git-send-email-daniel.vetter@ffwll.ch
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
In its original version, drm_framebuffer_init() returned a negative int
if drm_mode_object_get() failed (f453ba046074, "DRM: add mode setting
support").
This was accidentally disabled by commit 4b096ac10da0 ("drm: revamp
locking around fb creation/destruction"). Thus, drm_framebuffer_init()
pretends success if drm_mode_object_get() failed.
Reinstate the original behaviour. Also fix erroneous kernel-doc of
drm_mode_object_get().
Fixes: 4b096ac10da0 ("drm: revamp locking around fb creation/
destruction")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Just a random thing I spotted while reading code - better safe than
sorry.
Link: http://mid.gmane.org/1444894601-5200-11-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Pretty soon only some drivers will need dev->struct_mutex in their
gem_free_object callbacks. Hence it's really important to make sure
everything still keeps getting this right.
v2: Don't check for locking before we check for non-NULL obj. Spotted
by Dan Carpenter.
Link: http://mid.gmane.org/1444894601-5200-10-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Since
commit 131e663bd6f1055caaff128f9aa5071d227eeb72
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jul 9 23:32:33 2015 +0200
drm/gem: rip out drm vma accounting for gem mmaps
there is no need for this any more.
v2: Fixup compile noise spotted by 0-day build.
Link: http://mid.gmane.org/1444894601-5200-9-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Fixes userspace compilation error:
error: array type has incomplete element type
struct drm_clip_rect boxes[I810_NR_SAREA_CLIPRECTS];
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Fixes compile error:
drm/r128_drm.h:156:23: error: array type has incomplete element type
struct drm_clip_rect boxes[R128_NR_SAREA_CLIPRECTS];
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Fixes compiler error:
drm/savage_drm.h:50:24: error: array type has incomplete element type
struct drm_tex_region texList[SAVAGE_NR_TEX_HEAPS][SAVAGE_NR_TEX_REGIONS +
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This snippet...
* Lock VMA manager for extended lookups. Only *_locked() VMA function calls
* are allowed while holding this lock. All other contexts are blocked from VMA
* until the lock is released via drm_vma_offset_unlock_lookup().
...causes markdown-enabled kernel-doc to barf:
debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3247: parser error : Opening and ending tag mismatch: emphasis line 3247 and function
*<function><emphasis>locked</function> VMA function calls are allowed while
^
/root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3249: parser error : Opening and ending tag mismatch: function line 3249 and emphasis
released via <function>drm</emphasis>vma_offset_unlock_lookup</function>.
^
unable to parse /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml
A quick workaround is to replace *_locked() by X_locked().
Cc: Danilo Cesar Lemes de Paula <danilo.cesar@collabora.co.uk>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
[danvet: Just drop the X_ too, the usual style is _unlocked, except
that _ seems to be what annoys markdown.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Requires Markdown support.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Following Daniel's renaming of the document.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
DRM is a lot more than a direct rendering manager nowadays, and there's
also a bunch of things worth documenting for gpu driver developers
outside of drivers/gpu/drm, like vgaarb, vga_switcheroo or the various
hardware buses like host1x and ipu-v3.
To avoid further confusion let's rename the top-level to reflect
reality.
And yes I'm already looking forward to when we need to replace the G
in GPU with a * ;-)
Inspired by a thread with Lukas since he refused to include the
vga_switcheroo docs into the drm docs because it's not drm.
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
[Lukas: Drop BUG() easter egg in i915_gem_execbuffer.c spotted by Jani
and fix typos in commit message.]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Drop unused drm_atomic and fix comment for drm_debug.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Add a new debug class for _verbose_ debug message from the vblank code.
That is message we spew out potentially for every vblank interrupt.
Thierry already got annoyed at the spew, and now I managed to lock up
my box with these debug prints (seems serial console + a few debug
prints every vblank aren't a good combination).
Or should I maybe call it DRM_DEBUG_IRQ?
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
String literals get concatenated just fine on their own,
no need to use '\'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Just one special case (since i915 lost its ums code, yay):
- radeon: Has slots for the old ums ioctls which don't have
DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
everywhere.
Every other kms driver just has DRM_UNLOCKED for all their ioctls, as
they should.
v2: admgpu happened, include that one too. And i915 lost its UMS
support which means we can change all the i915 ioctls too.
v3: Rebased on top of new vmwgfx DX interface extensions.
v4: Rebase on top of render-node support in exynos.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
With the prep patches for i915 all kms drivers either have
DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
with an invariant return value when in modeset mode. But that's only
the case for i915 and radeon. The drm core ioctls are unfortunately
too much a mess still to dare this.
Follow-up patches will remove DRM_UNLOCKED from all kms drivers to
prove that this is indeed the case.
Also update the documentation.
v2: Really only do this for driver ioctls, spotted by David Herrmann.
And drop spurious whitespace change.
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
With kms all the data getparam looks at is actually invariant, and
certainly not protected by the global kms mutex. With ums all the
setup code is already racy as hell, so this won't make things any
worse.
I've done this change so that all ioctl still used by kms drivers
are marked as DRM_UNLOCKED, besides that we obviously don't need
it any more in kms mode.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
drm_vblank_count() returns the software counter. We should not pretend
it's the hw counter since we use the hw counter to figuere out what the
software counter value should be. So instead provide a new function
drm_vblank_no_hw_counter() for drivers that don't have a real hw
counter. The new function simply returns 0, which is about the only
thing it can do.
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
[danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface
change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This continues the pattern started in commit cc1ef118fc09 ("drm/irq:
Make pipe unsigned and name consistent"). This is applied to the public
APIs and driver callbacks, so pretty much all drivers need to be updated
to match the new prototypes.
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jianwei Wang <jianwei.wang.chn@gmail.com>
Cc: Alison Wang <alison.wang@freescale.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Avoid magic numbers and use the introduced defines.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Makes it cleaner to separate the two from rotation variable.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The following functions iterate over the client list, invoke client
callbacks or invoke handler callbacks without locking anything at all:
- Introduced by c8e9cf7bb240 ("vga_switcheroo: Add a helper function to
get the client state"):
vga_switcheroo_get_client_state()
- Introduced by 0d69704ae348 ("gpu/vga_switcheroo: add driver control
power feature. (v3)"):
vga_switcheroo_set_dynamic_switch()
vga_switcheroo_runtime_suspend()
vga_switcheroo_runtime_resume()
vga_switcheroo_runtime_resume_hdmi_audio()
Refactor vga_switcheroo_runtime_resume_hdmi_audio() a bit to be able to
release vgasr_mutex immediately after iterating over the client list.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
If we couldn't get a high precisions vblank timestamp, we currently
store a zeroed timestamp instead and assume the next vblank irq to
get us something better. This makes sense when trying to update the
timestamp from eg. vblank enable. But if we do this from the vblank
irq we will never get a vblank timestamp unless we high precision
timestamps are available and succeeded. This break weston for instance
on drivers lacking high precision timestamps.
To fix this, zero the timestamp only when not called from vbl irq.
When called from the irq, we still want the timestamp, even if not
perfect.
This fixes a regression from
4dfd64862ff852df drm: Use vblank timestamps to guesstimate how many vblanks were missed
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reported-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Surprisingly kbuild can't cope with tristates in the
<module>-$(CONFIG_FOO) pattern. This patch hacks up a solution.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Michal Marek <mmarek@suse.com>
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
This was only used for the ums+gem combo, so ripe for removal now that
we only have kms code left.
v2: Drop fence_reg_start since it's now unused, noticed by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
They're only used in the drm ioctl table, and there they're excluded
when AGP support is disabled. So this is just dead code ripe for
removal.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
drm core enforces now for DRIVER_MODESET that all ioctls are unlocked.
And all the old nasty ones from drm core aren't allowed for modern
drivers any more. Hence this is no longer needed.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
As usual pull it into the drm docbook template, too. And again as
usual I've decided to only document stuff exported to drivers, so all
the old leftover markup from the shared drm repo days lost the magic
** signature.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
And use it in radeon to replace all the ioctls no longer valid in kms
mode. I plan to also use this later on when nuking the ums support for
i915.
Note that setting the function pointer in the ioctl table to NULL
would amount to the same, but that results in some debug output from
the drm_ioctl() function. I've figured it's cleaner to have a
special-purpose function.
Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We already express the drm/agp depencies correctly in Kconfig, so we
can rip this remnant from the shared drm core days.
Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
if ttm would provide dummy functions. I'm not going to volunteer for
that though.
v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville
v3: Polish from Ville's review.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v2)
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
->load is deprecated, bus functions are deprecated and everyone
should use drm_dev_alloc®ister.
So update the .tmpl (and pull a bunch of the overview docs into the
sourcecode to increase chances that it'll stay in sync in the future)
and add notes to functions which are deprecated. I didn't bother to
clean up and document the unload sequence similarly since that one is
still a bit a mess: drm_dev_unregister does way too much,
drm_unplug_dev does what _unregister should be doing but then has the
complication of promising something it doesn't actually do (it doesn't
unplug existing open fds for instance, only prevents new ones).
Motivated since I don't want to hunt every new driver for usage of
drm_platform_init any more ;-)
v2: Reword the deprecation note for ->load a bit, using Laurent's
suggestion as an example (but making the wording a bit stronger even).
Fix spelling in commit message.
v3: More spelling fixes from Laurent.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Acked-by: David Herrmann <dh.herrmann@gmail.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
|
|
Andrey reported a panic:
[ 7249.865507] BUG: unable to handle kernel pointer dereference at 000000b4
[ 7249.865559] IP: [<c16afeca>] icmp_route_lookup+0xaa/0x320
[ 7249.865598] *pdpt = 0000000030f7f001 *pde = 0000000000000000
[ 7249.865637] Oops: 0000 [#1]
...
[ 7249.866811] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.3.0-999-generic #201509220155
[ 7249.866876] Hardware name: MSI MS-7250/MS-7250, BIOS 080014 08/02/2006
[ 7249.866916] task: c1a5ab00 ti: c1a52000 task.ti: c1a52000
[ 7249.866949] EIP: 0060:[<c16afeca>] EFLAGS: 00210246 CPU: 0
[ 7249.866981] EIP is at icmp_route_lookup+0xaa/0x320
[ 7249.867012] EAX: 00000000 EBX: f483ba48 ECX: 00000000 EDX: f2e18a00
[ 7249.867045] ESI: 000000c0 EDI: f483ba70 EBP: f483b9ec ESP: f483b974
[ 7249.867077] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 7249.867108] CR0: 8005003b CR2: 000000b4 CR3: 36ee07c0 CR4: 000006f0
[ 7249.867141] Stack:
[ 7249.867165] 320310ee 00000000 00000042 320310ee 00000000 c1aeca00
f3920240 f0c69180
[ 7249.867268] f483ba04 f855058b a89b66cd f483ba44 f8962f4b 00000000
e659266c f483ba54
[ 7249.867361] 8004753c f483ba5c f8962f4b f2031140 000003c1 ffbd8fa0
c16b0e00 00000064
[ 7249.867448] Call Trace:
[ 7249.867494] [<f855058b>] ? e1000_xmit_frame+0x87b/0xdc0 [e1000e]
[ 7249.867534] [<f8962f4b>] ? tcp_in_window+0xeb/0xb10 [nf_conntrack]
[ 7249.867576] [<f8962f4b>] ? tcp_in_window+0xeb/0xb10 [nf_conntrack]
[ 7249.867615] [<c16b0e00>] ? icmp_send+0xa0/0x380
[ 7249.867648] [<c16b102f>] icmp_send+0x2cf/0x380
[ 7249.867681] [<f89c8126>] nf_send_unreach+0xa6/0xc0 [nf_reject_ipv4]
[ 7249.867714] [<f89cd0da>] reject_tg+0x7a/0x9f [ipt_REJECT]
[ 7249.867746] [<f88c29a7>] ipt_do_table+0x317/0x70c [ip_tables]
[ 7249.867780] [<f895e0a6>] ? __nf_conntrack_find_get+0x166/0x3b0
[nf_conntrack]
[ 7249.867838] [<f895eea8>] ? nf_conntrack_in+0x398/0x600 [nf_conntrack]
[ 7249.867889] [<f84c0035>] iptable_filter_hook+0x35/0x80 [iptable_filter]
[ 7249.867933] [<c16776a1>] nf_iterate+0x71/0x80
[ 7249.867970] [<c1677715>] nf_hook_slow+0x65/0xc0
[ 7249.868002] [<c1681811>] __ip_local_out_sk+0xc1/0xd0
[ 7249.868034] [<c1680f30>] ? ip_forward_options+0x1a0/0x1a0
[ 7249.868066] [<c1681836>] ip_local_out_sk+0x16/0x30
[ 7249.868097] [<c1684054>] ip_send_skb+0x14/0x80
[ 7249.868129] [<c16840f4>] ip_push_pending_frames+0x34/0x40
[ 7249.868163] [<c16844a2>] ip_send_unicast_reply+0x282/0x310
[ 7249.868196] [<c16a0863>] tcp_v4_send_reset+0x1b3/0x380
[ 7249.868227] [<c16a1b63>] tcp_v4_rcv+0x323/0x990
[ 7249.868257] [<c16776a1>] ? nf_iterate+0x71/0x80
[ 7249.868289] [<c167dc2b>] ip_local_deliver_finish+0x8b/0x230
[ 7249.868322] [<c167df4c>] ip_local_deliver+0x4c/0xa0
[ 7249.868353] [<c167dba0>] ? ip_rcv_finish+0x390/0x390
[ 7249.868384] [<c167d88c>] ip_rcv_finish+0x7c/0x390
[ 7249.868415] [<c167e280>] ip_rcv+0x2e0/0x420
...
Prior to the VRF change the oif was not set in the flow struct, so the
VRF support should really have only added the vrf_master_ifindex lookup.
Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX")
Cc: Andrey Melnikov <temnota.am@gmail.com>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Update the docbook comment for __mdiobus_register() to include the new
module owner argument. This resolves a warning found by the 0-day
builder.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Thomas can no longer work on the driver, so he asked me to mark the
MAINTAINER entry as "Orphan" with the hope that someone else would
someday pick it up.
Cc: Thomas Dahlmann <dahlmann.thomas@arcor.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
ppp_dev_uninit() locks all_ppp_mutex while under rtnl mutex protection.
ppp_create_interface() must then lock these mutexes in that same order
to avoid possible deadlock.
[ 120.880011] ======================================================
[ 120.880011] [ INFO: possible circular locking dependency detected ]
[ 120.880011] 4.2.0 #1 Not tainted
[ 120.880011] -------------------------------------------------------
[ 120.880011] ppp-apitest/15827 is trying to acquire lock:
[ 120.880011] (&pn->all_ppp_mutex){+.+.+.}, at: [<ffffffffa0145f56>] ppp_dev_uninit+0x64/0xb0 [ppp_generic]
[ 120.880011]
[ 120.880011] but task is already holding lock:
[ 120.880011] (rtnl_mutex){+.+.+.}, at: [<ffffffff812e4255>] rtnl_lock+0x12/0x14
[ 120.880011]
[ 120.880011] which lock already depends on the new lock.
[ 120.880011]
[ 120.880011]
[ 120.880011] the existing dependency chain (in reverse order) is:
[ 120.880011]
[ 120.880011] -> #1 (rtnl_mutex){+.+.+.}:
[ 120.880011] [<ffffffff81073a6f>] lock_acquire+0xcf/0x10e
[ 120.880011] [<ffffffff813ab18a>] mutex_lock_nested+0x56/0x341
[ 120.880011] [<ffffffff812e4255>] rtnl_lock+0x12/0x14
[ 120.880011] [<ffffffff812d9d94>] register_netdev+0x11/0x27
[ 120.880011] [<ffffffffa0147b17>] ppp_ioctl+0x289/0xc98 [ppp_generic]
[ 120.880011] [<ffffffff8113b367>] do_vfs_ioctl+0x4ea/0x532
[ 120.880011] [<ffffffff8113b3fd>] SyS_ioctl+0x4e/0x7d
[ 120.880011] [<ffffffff813ad7d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
[ 120.880011]
[ 120.880011] -> #0 (&pn->all_ppp_mutex){+.+.+.}:
[ 120.880011] [<ffffffff8107334e>] __lock_acquire+0xb07/0xe76
[ 120.880011] [<ffffffff81073a6f>] lock_acquire+0xcf/0x10e
[ 120.880011] [<ffffffff813ab18a>] mutex_lock_nested+0x56/0x341
[ 120.880011] [<ffffffffa0145f56>] ppp_dev_uninit+0x64/0xb0 [ppp_generic]
[ 120.880011] [<ffffffff812d5263>] rollback_registered_many+0x19e/0x252
[ 120.880011] [<ffffffff812d5381>] rollback_registered+0x29/0x38
[ 120.880011] [<ffffffff812d53fa>] unregister_netdevice_queue+0x6a/0x77
[ 120.880011] [<ffffffffa0146a94>] ppp_release+0x42/0x79 [ppp_generic]
[ 120.880011] [<ffffffff8112d9f6>] __fput+0xec/0x192
[ 120.880011] [<ffffffff8112dacc>] ____fput+0x9/0xb
[ 120.880011] [<ffffffff8105447a>] task_work_run+0x66/0x80
[ 120.880011] [<ffffffff81001801>] prepare_exit_to_usermode+0x8c/0xa7
[ 120.880011] [<ffffffff81001900>] syscall_return_slowpath+0xe4/0x104
[ 120.880011] [<ffffffff813ad931>] int_ret_from_sys_call+0x25/0x9f
[ 120.880011]
[ 120.880011] other info that might help us debug this:
[ 120.880011]
[ 120.880011] Possible unsafe locking scenario:
[ 120.880011]
[ 120.880011] CPU0 CPU1
[ 120.880011] ---- ----
[ 120.880011] lock(rtnl_mutex);
[ 120.880011] lock(&pn->all_ppp_mutex);
[ 120.880011] lock(rtnl_mutex);
[ 120.880011] lock(&pn->all_ppp_mutex);
[ 120.880011]
[ 120.880011] *** DEADLOCK ***
Fixes: 8cb775bc0a34 ("ppp: fix device unregistration upon netns deletion")
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The builds of allmodconfig of avr32 is failing with:
drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit declaration
of function 'pci_iomap' [-Werror=implicit-function-declaration]
drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit declaration
of function 'pci_iounmap' [-Werror=implicit-function-declaration]
The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI
is not defined and CONFIG_GENERIC_PCI_IOMAP is defined.
Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are
getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP both
are not defined.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Read the standard link partner advertisment registers and store it in
phydev->lp_advertising, so ethtool can report this information to
userspace via ethtool. Zero it as per genphy if autonegotiation is
disabled. Tested with a Marvell 88E1512 PHY.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We observed some performance degradation on s390x with dynamic
halt polling. Until we can provide a proper fix, let's enable
halt_poll_ns as default only for supported architectures.
Architectures are now free to set their own halt_poll_ns
default value.
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
29ecd6601904 ("KVM: x86: avoid uninitialized variable warning",
2015-09-06) introduced a not-so-subtle problem, which probably
escaped review because it was not part of the patch context.
Before the patch, leaf was always equal to iterator.level. After,
it is equal to iterator.level - 1 in the call to is_shadow_zero_bits_set,
and when is_shadow_zero_bits_set does another "-1" the check on
reserved bits becomes incorrect. Using "iterator.level" in the call
fixes this call trace:
WARNING: CPU: 2 PID: 17000 at arch/x86/kvm/mmu.c:3385 handle_mmio_page_fault.part.93+0x1a/0x20 [kvm]()
Modules linked in: tun sha256_ssse3 sha256_generic drbg binfmt_misc ipv6 vfat fat fuse dm_crypt dm_mod kvm_amd kvm crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd fam15h_power amd64_edac_mod k10temp edac_core amdkfd amd_iommu_v2 radeon acpi_cpufreq
[...]
Call Trace:
dump_stack+0x4e/0x84
warn_slowpath_common+0x95/0xe0
warn_slowpath_null+0x1a/0x20
handle_mmio_page_fault.part.93+0x1a/0x20 [kvm]
tdp_page_fault+0x231/0x290 [kvm]
? emulator_pio_in_out+0x6e/0xf0 [kvm]
kvm_mmu_page_fault+0x36/0x240 [kvm]
? svm_set_cr0+0x95/0xc0 [kvm_amd]
pf_interception+0xde/0x1d0 [kvm_amd]
handle_exit+0x181/0xa70 [kvm_amd]
? kvm_arch_vcpu_ioctl_run+0x68b/0x1730 [kvm]
kvm_arch_vcpu_ioctl_run+0x6f6/0x1730 [kvm]
? kvm_arch_vcpu_ioctl_run+0x68b/0x1730 [kvm]
? preempt_count_sub+0x9b/0xf0
? mutex_lock_killable_nested+0x26f/0x490
? preempt_count_sub+0x9b/0xf0
kvm_vcpu_ioctl+0x358/0x710 [kvm]
? __fget+0x5/0x210
? __fget+0x101/0x210
do_vfs_ioctl+0x2f4/0x560
? __fget_light+0x29/0x90
SyS_ioctl+0x4c/0x90
entry_SYSCALL_64_fastpath+0x16/0x73
---[ end trace 37901c8686d84de6 ]---
Reported-by: Borislav Petkov <bp@alien8.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Intel CPUID on AMD host or vice versa is a weird case, but it can
happen. Handle it by checking the host CPU vendor instead of the
guest's in reset_tdp_shadow_zero_bits_mask. For speed, the
check uses the fact that Intel EPT has an X (executable) bit while
AMD NPT has NX.
Reported-by: Borislav Petkov <bp@alien8.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
kvm_set_cr0 may want to call kvm_zap_gfn_range and thus access the
memslots array (SRCU protected). Using a mini SRCU critical section
is ugly, and adding it to kvm_arch_vcpu_create doesn't work because
the VMX vcpu_create callback calls synchronize_srcu.
Fixes this lockdep splat:
===============================
[ INFO: suspicious RCU usage. ]
4.3.0-rc1+ #1 Not tainted
-------------------------------
include/linux/kvm_host.h:488 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by qemu-system-i38/17000:
#0: (&(&kvm->mmu_lock)->rlock){+.+...}, at: kvm_zap_gfn_range+0x24/0x1a0 [kvm]
[...]
Call Trace:
dump_stack+0x4e/0x84
lockdep_rcu_suspicious+0xfd/0x130
kvm_zap_gfn_range+0x188/0x1a0 [kvm]
kvm_set_cr0+0xde/0x1e0 [kvm]
init_vmcb+0x760/0xad0 [kvm_amd]
svm_create_vcpu+0x197/0x250 [kvm_amd]
kvm_arch_vcpu_create+0x47/0x70 [kvm]
kvm_vm_ioctl+0x302/0x7e0 [kvm]
? __lock_is_held+0x51/0x70
? __fget+0x101/0x210
do_vfs_ioctl+0x2f4/0x560
? __fget_light+0x29/0x90
SyS_ioctl+0x4c/0x90
entry_SYSCALL_64_fastpath+0x16/0x73
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This patch fixes a v4.2+ regression introduced by commit c04a6091
that removed support for obsolete sync-and-steering markers usage
as originally defined in RFC-3720.
The regression would involve attempting to send OFMarker=No +
IFMarker=No keys during opertional negotiation login phase,
including when initiators did not actually propose these keys.
The result for MSFT iSCSI initiators would be random junk in
TCP stream after the last successful login request was been sent
signaling the move to full feature phase (FFP) operation.
To address this bug, go ahead and avoid negotiating these keys
by default unless the initiator explicitly proposes them, but
still respond to them with 'No' if they are proposed.
Reported-by: Dragan Milivojević <galileo@pkm-inc.com>
Bisected-by: Christophe Vu-Brugier <cvubrugier@fastmail.fm>
Tested-by: Christophe Vu-Brugier <cvubrugier@fastmail.fm>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
|
|
This patch changes transport_lookup_cmd_lun() to obtain
se_lun->lun_ref + se_cmd->se_device rcu_dereference during
TCM_WRITE_PROTECT -> CHECK_CONDITION failure status.
Do this to ensure the active control D_SENSE mode page bit
is being honored.
Reported-by: Sagi Grimberg <sagig@mellanox.com>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
|
|
This patch allows target_sense_desc_format() to be called without a
valid se_device pointer, which can occur during an early exception
ahead of transport_lookup_cmd_lun() setting up se_cmd->se_device.
This addresses a v4.3-rc1 specific NULL pointer dereference
regression introduced by commit 4e4937e8.
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
|