| Age | Commit message (Collapse) | Author |
|---|
|
Used for smu power logging.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Used for smu power logging.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
used for notify SMU the allocated buffer address.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
New messages for smu power logging.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Setting the function pointer to the get the temperature on CZ.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Satyajit Sahu <satyajit.sahu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Don't leak implementation details about how each priority behaves to
usermode. This allows greater flexibility in the future.
Squash into c2636dc53abd8269a0930bccd564f2f195dba729
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This ioctl will allow us to purge inactive userspace buffers when the
system is running out of contiguous memory.
For now, the purge logic is rather dumb in that it does not try to
release only the amount of BO needed to meet the last CMA alloc request
but instead purges all objects placed in the purgeable pool as soon as
we experience a CMA allocation failure.
Note that the in-kernel BO cache is always purged before the purgeable
cache because those objects are known to be unused while objects marked
as purgeable by a userspace application/library might have to be
restored when they are marked back as unpurgeable, which can be
expensive.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019125748.3152-1-boris.brezillon@free-electrons.com
|
|
The transport may need to flush transport connect and receive tasks
that are running on rpciod. In order to do so safely, we need to
ensure that the caller of cancel_work_sync() etc is not itself
running on rpciod.
Do so by running the destroy task from the system workqueue.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
Pull "Renesas ARM Based SoC Fixes for v4.14" from Simon Horman:
Add 12V regulator to backlight allowing the power supply
for the backlight to be found.
* tag 'renesas-fixes-for-v4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
arm64: dts: salvator-common: add 12V regulator to backlight
|
|
The commit afece3ab9a36 ("PM / Domains: Add time accounting to various
genpd states") causes a boot regression for ux500.
The problem occurs when the ux500 machine code calls pm_genpd_init(), which
since the above change triggers a call to ktime_get(). More precisely,
because ux500 initializes PM domains in the init_IRQ() phase of the boot,
timekeeping has not yet been initialized.
Fix the problem by moving the initialization of the PM domains to after
timekeeping has been initialized.
Fixes: afece3ab9a36 ("PM / Domains: Add time accounting to various genpd..")
Cc: Thara Gopinath <thara.gopinath@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
These platforms provide a clock to their watchdog, in each
case this is the peripheral clock (PCLK), so explicitly
name the clock in the device tree.
Take this opportunity to add the "faraday,ftwdt010"
compatible as fallback to the watchdog IP blocks.
Cc: Jonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
into fixes
Pull "Reset controller fixes for v4.14" from Philipp Zabel:
Fix SoCFPGA reset controller for 64-bit systems. This patch removes the
assumption that BITS_PER_LONG is 32, which is not the case on Stratix10.
* tag 'reset-fixes-for-4.14-2' of git://git.pengutronix.de/git/pza/linux:
reset: socfpga: fix for 64-bit compilation
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes
Pull "Rockchip dts64 Fixes for 4.14 part 2" from Heiko Stübner:
The vqmmc voltages on rk3399 pose a risk for the chip if they
exceed 3.0V, so they got fixed to not be at 3.3V
And Arnd found a typo in the recently added iommu nodes.
* tag 'v4.14-rockchip-dts64fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: fix typo in iommu nodes
arm64: dts: rockchip: correct vqmmc voltage for rk3399 platforms
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes
Pull "i.MX fixes for 4.14" from Shawn Guo:
- Fix the legacy PCI interrupt numbers for i.MX7. The numbers were
wrongly coded in an inverted order than what Reference Manual tells.
It causes problem for PCI devices using legacy interrupt.
* tag 'imx-fixes-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: imx7d: Invert legacy PCI irq mapping
|
|
Pull "mvebu fixes for 4.14 (part 2)" from Gregory CLEMENT
Two device tree related fixes:
- One on Armada 38x using a other compatible string for I2C in order
to cover an errata.
- One for Armada 7K/8K fixing a typo on interrupt-map property for
PCIe leading to fail PME and AER root port service initialization
And the last one for the mbus fixing the window size calculation when
it exceed 32bits
* tag 'mvebu-fixes-4.14-2' of git://git.infradead.org/linux-mvebu:
bus: mbus: fix window size calculation for 4GB windows
ARM: dts: Fix I2C repeated start issue on Armada-38x
arm64: dts: marvell: fix interrupt-map property for Armada CP110 PCIe controller
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91 into fixes
Fixes: second batch for 4.14:
- one DT phy address fix for the new sama5d27 som1 ek
- two DT ADC patches that were forgotten while moving to
hardware triggers for sama5d2 (iio changes already applied)
* tag 'at91-fixes2' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91:
ARM: dts: at91: sama5d2: add ADC hw trigger edge type
ARM: dts: at91: sama5d2_xplained: enable ADTRG pin
ARM: dts: at91: at91-sama5d27_som1: fix PHY ID
|
|
http://github.com/Broadcom/stblinux into fixes
Pull "Broadcom devicetree fixes for 4.14" from Florian Fainelli:
This pull request contains Broadcom ARM-based SoC Device Tree fixes for 4.14,
please pull the following:
- Loic fixes the console path on the Raspberry Pi 3 which was not correctly set
and would cause all sorts of confusion between the Bluetooth controller and the
kernel console
* tag 'arm-soc/for-4.14/devicetree-fixes' of http://github.com/Broadcom/stblinux:
ARM: dts: bcm283x: Fix console path on RPi3
|
|
We should make sure to escelate allocation failures to prevent a
use-after-free in nvmf_create_ctrl.
Fixes: b28a308ee777 ("nvme-rdma: move tagset allocation to a dedicated routine")
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
The fact that we free the async event buffer in
nvme_rdma_destroy_admin_queue can cause us to free it
more than once because this happens in every reconnect
attempt since commit 31fdf1840170. we rely on the queue
state flags DELETING to avoid this for other resources.
A more complete fix is to not destroy the admin/io queues
unconditionally on every reconnect attempt, but its a bit
more extensive and will go in the next release.
Fixes: 31fdf1840170 ("nvme-rdma: reuse configure/destroy_admin_queue")
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
The error code is missing here so it means we return ERR_PTR(0) or NULL.
The other error paths all return an error code so this probably should
as well.
Fixes: 02b69b284cd7 ("ovl: lookup redirects")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
|
|
This was detected by fault injection test
Signed-off-by: Hirofumi Nakagawa <nklabs@gmail.com>
Fixes: 13cf199d0088 ("ovl: allocate an ovl_inode struct")
Cc: <stable@vger.kernel.org> # v4.13
|
|
If the device is in runtime suspend, resuming takes time and reduces our
powersaving. If this was for a small write into an object, that resume
will take longer than any savings in using the indirect GGTT access to
avoid the cpu cache.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019063733.31620-1-chris@chris-wilson.co.uk
|
|
Only the DDI hook has some actual content.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017140313.20937-1-jani.nikula@intel.com
|
|
They're unused and unsupported. Leave the reduced_clock pointers in
place still, should they prove useful later on.
v2: go from nuking DDI lowfreq_avail to nuking it entirely (Ville)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017140234.20677-1-jani.nikula@intel.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
Fix potential host oops and hangs.
|
|
A bunch of functions are now exclusively used for HDMI, so naming the
variables with hdmi prefix/suffix is redundant. Also use int rather
than u32 for the translation level consistently.
v2: Rebase due to hdmi_level=-1 avoidance
Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171018181958.4423-1-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
|
|
Handle missing buf trans tables, or out of bounds buf trans levels
the same way everywhere. These should never be hit under normal
conditions, but let's play it safe for now.
v2: Avoid the hdmi_level=-1 case (James)
Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171018181934.4229-1-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
|
|
SKL DDI B/C/D only have 9 usable buf trans registers for DP/eDP. That
matches the normal DP buf trans tables, but the low vswing eDP tables
have 10 entries. Thus the eDP tables can only be used safely with DDI A
and E.
We try to catch cases where DDI B/C/D gets used with the wrong number of
entires in some parts of the code, but not everywhere. Let's move the
code to deal with that deeper into intel_ddi_get_buf_trans_edp(). And
for sake of symmetry do the same in intel_ddi_get_buf_trans_dp(). That
would also avoid explosions in the rather unlikely case that the DP
tables would get revised to 10 entries as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-9-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
|
|
default_index contained in the BXT buf_trans tables is actually useless.
For DP we should always have a valid level selected (otherwise the link
training logic would be buggy), and for HDMI we can just do what the
other platforms do and pick the correct entry in intel_ddi_hdmi_level().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-8-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
|
|
encoder->type is unreliable for DP/HDMI, so pass it in explicity into
cnl_ddi_vswing_sequence(). This matches what we do for BXT.
v2: Pass intel_encoder down to cnl_ddi_vswing_program(), and
clean up the argument types while at it
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-7-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
|
|
Make BXT less special by following the CNL approach and handling
it in intel_ddi_dp_voltage_max() alognside every other DDI platform.
v2: Clean up the argument types to bxt_ddi_vswing_sequence() while at it
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-6-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
|
|
The caller of intel_prepare_hdmi_ddi_buffers() alreday figured out the
level, so let's just pass it in instead if figuring it out again.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-5-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
|
|
encoder->type isn't reliable for DP/HDMI encoders, so pass the type
explicity to skl_set_iboost(). Also take the opportunity to streamline
the code.
v2: Clean up the argument types to skl_ddi_set_iboost() while at it
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-4-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
|
|
Introduce intel_ddi_get_buf_trans_hdmi() and start using it where we
can.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-3-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
|
We'll want to use the intel_ddi_get_buf_trans_*() functions a bit
earlier in the file, so move them up. While at it start using them
in the iboost setup to get rid of the platform checks there.
v2: Rebase due to BDW FDI buf trans fix
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-2-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
|
|
Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.
As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.
This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:
socket$inet6_sctp()
bind$inet6()
sendto$inet6()
unshare(0x40000000)
getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.
Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually
different.
Reported-by: ChunYu Wang <chunwang@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Daniel Borkmann says:
====================
bpf: Fix for BPF devmap percpu allocation splat
The set fixes a splat in devmap percpu allocation when we alloc
the flush bitmap. Patch 1 is a prerequisite for the fix in patch 2,
patch 1 is rather small, so if this could be routed via -net, for
example, with Tejun's Ack that would be good. Patch 3 gets rid of
remaining PCPU_MIN_UNIT_SIZE checks, which are percpu allocator
internals and should not be used.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
PCPU_MIN_UNIT_SIZE is an implementation detail of the percpu
allocator. Given we support __GFP_NOWARN now, lets just let
the allocation request fail naturally instead. The two call
sites from BPF mistakenly assumed __GFP_NOWARN would work, so
no changes needed to their actual __alloc_percpu_gfp() calls
which use the flag already.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
It was reported that syzkaller was able to trigger a splat on
devmap percpu allocation due to illegal/unsupported allocation
request size passed to __alloc_percpu():
[ 70.094249] illegal size (32776) or align (8) for percpu allocation
[ 70.094256] ------------[ cut here ]------------
[ 70.094259] WARNING: CPU: 3 PID: 3451 at mm/percpu.c:1365 pcpu_alloc+0x96/0x630
[...]
[ 70.094325] Call Trace:
[ 70.094328] __alloc_percpu_gfp+0x12/0x20
[ 70.094330] dev_map_alloc+0x134/0x1e0
[ 70.094331] SyS_bpf+0x9bc/0x1610
[ 70.094333] ? selinux_task_setrlimit+0x5a/0x60
[ 70.094334] ? security_task_setrlimit+0x43/0x60
[ 70.094336] entry_SYSCALL_64_fastpath+0x1a/0xa5
This was due to too large max_entries for the map such that we
surpassed the upper limit of PCPU_MIN_UNIT_SIZE. It's fine to
fail naturally here, so switch to __alloc_percpu_gfp() and pass
__GFP_NOWARN instead.
Fixes: 11393cc9b9be ("xdp: Add batching support to redirect map")
Reported-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Shankara Pailoor <sp3485@columbia.edu>
Reported-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add an option for pcpu_alloc() to support __GFP_NOWARN flag.
Currently, we always throw a warning when size or alignment
is unsupported (and also dump stack on failed allocation
requests). The warning itself is harmless since we return
NULL anyway for any failed request, which callers are
required to handle anyway. However, it becomes harmful when
panic_on_warn is set.
The rationale for the WARN() in pcpu_alloc() is that it can
be tracked when larger than supported allocation requests are
made such that allocations limits can be tweaked if warranted.
This makes sense for in-kernel users, however, there are users
of pcpu allocator where allocation size is derived from user
space requests, e.g. when creating BPF maps. In these cases,
the requests should fail gracefully without throwing a splat.
The current work-around was to check allocation size against
the upper limit of PCPU_MIN_UNIT_SIZE from call-sites for
bailing out prior to a call to pcpu_alloc() in order to
avoid throwing the WARN(). This is bad in multiple ways since
PCPU_MIN_UNIT_SIZE is an implementation detail, and having
the checks on call-sites only complicates the code for no
good reason. Thus, lets fix it generically by supporting the
__GFP_NOWARN flag that users can then use with calling the
__alloc_percpu_gfp() helper instead.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Tejun Heo <tj@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Netanel Belgazal says:
====================
ENA ethernet driver bug fixes
Some fixes for ENA ethernet driver
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
ethtool ena_get_channels() expose the max number of queues as the max
number of queues ENA supports (128 queues) and not the actual number
of created queues.
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This failure is rare and only found on testing where deliberately fail
devm_ioremap()
[ 451.170464] ena 0000:04:00.0: failed to remap regs bar
451.170549] Workqueue: pciehp-1 pciehp_power_thread
[ 451.170551] task: ffff88085a5f2d00 task.stack: ffffc9000756c000
[ 451.170552] RIP: 0010:devm_iounmap+0x2d/0x40
[ 451.170553] RSP: 0018:ffffc9000756fac0 EFLAGS: 00010282
[ 451.170554] RAX: 00000000fffffffe RBX: 0000000000000000 RCX:
0000000000000000
[ 451.170555] RDX: ffffffff813a7e00 RSI: 0000000000000282 RDI:
0000000000000282
[ 451.170556] RBP: ffffc9000756fac8 R08: 00000000fffffffe R09:
00000000000009b7
[ 451.170557] R10: 0000000000000005 R11: 00000000000009b6 R12:
ffff880856c9d0a0
[ 451.170558] R13: ffffc9000f5c90c0 R14: ffff880856c9d0a0 R15:
0000000000000028
[ 451.170559] FS: 0000000000000000(0000) GS:ffff88085f400000(0000)
knlGS:0000000000000000
[ 451.170560] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 451.170561] CR2: 00007f169038b000 CR3: 0000000001c09000 CR4:
00000000003406f0
[ 451.170562] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 451.170562] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ 451.170563] Call Trace:
[ 451.170572] ena_release_bars.isra.48+0x34/0x60 [ena]
[ 451.170574] ena_probe+0x144/0xd90 [ena]
[ 451.170579] ? ida_simple_get+0x98/0x100
[ 451.170585] ? kernfs_next_descendant_post+0x40/0x50
[ 451.170591] local_pci_probe+0x45/0xa0
[ 451.170592] pci_device_probe+0x157/0x180
[ 451.170599] driver_probe_device+0x2a8/0x460
[ 451.170600] __device_attach_driver+0x7e/0xe0
[ 451.170602] ? driver_allows_async_probing+0x30/0x30
[ 451.170603] bus_for_each_drv+0x68/0xb0
[ 451.170605] __device_attach+0xdd/0x160
[ 451.170607] device_attach+0x10/0x20
[ 451.170610] pci_bus_add_device+0x4f/0xa0
[ 451.170611] pci_bus_add_devices+0x39/0x70
[ 451.170613] pciehp_configure_device+0x96/0x120
[ 451.170614] pciehp_enable_slot+0x1b3/0x290
[ 451.170616] pciehp_power_thread+0x3b/0xb0
[ 451.170622] process_one_work+0x149/0x360
[ 451.170623] worker_thread+0x4d/0x3c0
[ 451.170626] kthread+0x109/0x140
[ 451.170627] ? rescuer_thread+0x380/0x380
[ 451.170628] ? kthread_park+0x60/0x60
[ 451.170632] ret_from_fork+0x25/0x30
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Decrease log level of checksum errors as these messages can be
triggered remotely by bad packets.
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If sending messages with no cable connected, it quickly happens that
there is no more TX context available. Then "gs_can_start_xmit()"
returns with "NETDEV_TX_BUSY" and the upper layer does retry
immediately keeping the CPU busy. To fix that issue, I moved
"atomic_dec(&dev->active_tx_urbs)" from "gs_usb_xmit_callback()" to
the TX done handling in "gs_usb_receive_bulk_callback()". Renaming
"active_tx_urbs" to "active_tx_contexts" and moving it into
"gs_[alloc|free]_tx_context()" would also make sense.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
The dlc member of the struct rx_msg contains also the ESD_RTR flag to
mark received RTR frames. Without the fix the can_dlc value for received
RTR frames would always be set to 8 by get_can_dlc() instead of the
received value.
Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device")
Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
returning NULL
This patch adds the missing check and error handling for out-of-memory
situations, when kzalloc cannot allocate memory.
Fixes: cb5635a36776 ("can: complete initial namespace support")
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
"proto_tab" is a RCU protected array, when directly accessing the array,
sparse throws these warnings:
CHECK /srv/work/frogger/socketcan/linux/net/can/af_can.c
net/can/af_can.c:115:14: error: incompatible types in comparison expression (different address spaces)
net/can/af_can.c:795:17: error: incompatible types in comparison expression (different address spaces)
net/can/af_can.c:816:9: error: incompatible types in comparison expression (different address spaces)
This patch fixes the problem by using rcu_access_pointer() and
annotating "proto_tab" array as __rcu.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
The assignment of net via call sock_net will dereference sk. This
is performed before a sanity null check on sk, so there could be
a potential null dereference on the sock_net call if sk is null.
Fix this by assigning net after the sk null check. Also replace
the sk == NULL with the more usual !sk idiom.
Detected by CoverityScan CID#1431862 ("Dereference before null check")
Fixes: 384317ef4187 ("can: network namespace support for CAN_BCM protocol")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
