| Age | Commit message (Collapse) | Author |
|---|
|
If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
a build error:
ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko] undefined!
ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko] undefined!
This changes the 'select' statement again, so we only try to enable
those symbols when the drivers will actually get built, and explicitly
test for QCOM_MDT_LOADER to be enabled before calling into it.
Fixes: 76724b30f222 ("[media] media: venus: enable building with COMPILE_TEST")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Without PM support, gcc warns about two unused functions:
platform/qcom/venus/core.c:146:13: error: 'venus_clks_disable' defined but not used [-Werror=unused-function]
platform/qcom/venus/core.c:126:12: error: 'venus_clks_enable' defined but not used [-Werror=unused-function]
The problem as usual are incorrect #ifdefs, so the easiest fix
is to do away with the #ifdef completely and mark the suspend/resume
handlers as __maybe_unused, which they are.
Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Allow calling cec_notifier_set_phys_addr and
cec_notifier_set_phys_addr_from_edid with a NULL notifier, in which
case these functions do nothing.
Add a cec_notifier_phys_addr_invalidate helper function (the notifier
equivalent of cec_phys_addr_invalidate).
These changes simplify drm CEC driver support.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The persistent_config option is used to make the CEC settings persistent by using
the eeprom inside the device to store this information. This was on by default, which
caused confusion since this device now behaves differently from other CEC devices
which all come up unconfigured.
Another reason for doing this now is that I hope a more standard way of selecting
persistent configuration will be created in the future. And for that to work all
CEC drivers should behave the same and come up unconfigured by default.
None of the open source CEC applications are using this CEC framework at the moment
so change this behavior before it is too late.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: <stable@vger.kernel.org> # for v4.10 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The switch in cec_transmit_attempt_done() should ignore the
CEC_TX_STATUS_MAX_RETRIES status bit.
Calling this function with e.g. CEC_TX_STATUS_NACK | CEC_TX_STATUS_MAX_RETRIES
is perfectly legal and should not trigger the WARN(1).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
I noticed an array underflow in ov5693_enum_frame_size(). The code
looks like this:
int index = fse->index;
if (index >= N_RES)
retur -EINVAL;
fse->index is a u32 that comes from the user. We want negative values
to be counted as -EINVAL but they aren't. There are several ways to fix
this but I feel like the best fix for future proofing is to change the
type of N_RES from int to unsigned long to make it the same as if we
were comparing against ARRAY_SIZE().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Since commit e8f4818895b3 ("[media] lirc: advertise
LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl
LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that
the hardware can detect. This breaks decoding in lirc because lircd
expects the answer in microseconds, but nanoseconds is returned.
Cc: <stable@vger.kernel.org> # v2.6.36+
Reported-by: Derek <user.vdr@gmail.com>
Tested-by: Derek <user.vdr@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Sending patches with SVG files via e-mail has a drawback: line
size could be bigger than 998, with is the limit given by
RFC 5322[1]. So, we need to enforce a lower limit, in order to
allow those patches to be properly reviewed.
[1] https://tools.ietf.org/html/rfc5322#section-2.1.1
So, use this small Perl script to limit columns size to ~900.
use Text::Wrap;
$Text::Wrap::columns = 900;
$t.=$_ while (<>);
print wrap("","",$t);
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Debian's ImageMagick is currently unable to decode those
images. Use scour to simplify the SVG, and provide only
one font type, in order to make it more palatable.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
This file is too big, with cause it to require a lot
of memory when parsed by texlive.
Optimize it, in order to avoid the need of touching at
main_memory at texmf.cnf.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The vimc platform drivers define a platform device ID table but these
are not set to the .id_table field in the platform driver structure.
So the platform device ID table is only used to fill the aliases in
the module but are not used for matching (works because the platform
subsystem fallbacks to the driver's name if no .id_table is set).
But this also means that the platform device ID table isn't used if
the driver is built-in, which leads to the following build warning:
This causes the following build warnings when the driver is built-in:
drivers/media/platform/vimc//vimc-capture.c:528:40: warning: ‘vimc_cap_driver_ids’ defined but not used [-Wunused-const-variable=]
static const struct platform_device_id vimc_cap_driver_ids[] = {
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/vimc//vimc-debayer.c:588:40: warning: ‘vimc_deb_driver_ids’ defined but not used [-Wunused-const-variable=]
static const struct platform_device_id vimc_deb_driver_ids[] = {
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/vimc//vimc-scaler.c:442:40: warning: ‘vimc_sca_driver_ids’ defined but not used [-Wunused-const-variable=]
static const struct platform_device_id vimc_sca_driver_ids[] = {
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/vimc//vimc-sensor.c:376:40: warning: ‘vimc_sen_driver_ids’ defined but not used [-Wunused-const-variable=]
static const struct platform_device_id vimc_sen_driver_ids[] = {
^~~~~~~~~~~~~~~~~~~
Reported-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Suggested-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Helen Koike <helen.koike@collabora.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
write_sysreg() may misparse the value argument because it is used
without parentheses to protect it.
This patch adds the ( ) in order to avoid any surprises.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
[will: same change to write_sysreg_s]
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
The check for column exclusion did not verify that the event being
checked was an L2 event, and not a software event.
Software events should not be checked for column exclusion.
This resulted in a group with both software and L2 events sometimes
incorrectly rejecting the L2 event for column exclusion and
not counting it.
Add a check for PMU type before applying column exclusion logic.
Fixes: 21bdbb7102edeaeb ("perf: add qcom l2 cache perf events driver")
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Neil Leeder <nleeder@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
In commit efe0160cfd40 ("powerpc/64: Linker on-demand sfpr functions
for modules"), we added an ld version check early in the powerpc
top-level Makefile.
Because the Makefile runs before the kernel config is setup, the
checks for CONFIG_CPU_LITTLE_ENDIAN etc. all take the default case. So
we end up configuring ld for 32-bit big endian.
That would be OK, except that for historical (or perhaps no) reason,
we use 'override LD' to add the endian flags to the LD variable
itself, rather than the normal approach of adding them to LDFLAGS.
The end result is that when we check the ld version we run it as:
$(CROSS_COMPILE)ld -EB -m elf32ppc --version
This often works, unless you are using a 64-bit only and/or little
endian only, toolchain. In which case you see something like:
$ make defconfig
powerpc64le-linux-ld: unrecognised emulation mode: elf32ppc
Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim
/bin/sh: 1: [: -ge: unexpected operator
The proper fix is to stop using 'override LD', but that will require a
fair bit of testing. Instead we can fix it for now just by reordering
the Makefile to do the version check earlier.
Fixes: efe0160cfd40 ("powerpc/64: Linker on-demand sfpr functions for modules")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
As for commit 68baf692c435 ("powerpc/pseries: Fix of_node_put()
underflow during DLPAR remove"), the call to of_node_put() must be
removed from pSeries_reconfig_remove_node().
dlpar_detach_node() and pSeries_reconfig_remove_node() both call
of_detach_node(), and thus the node should not be released in both
cases.
Fixes: 0829f6d1f69e ("of: device_node kobject lifecycle fixes")
Cc: stable@vger.kernel.org # v3.15+
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
There's a somewhat architectural issue with Radix MMU and KVM.
When coming out of a guest with AIL (Alternate Interrupt Location, ie,
MMU enabled), we start executing hypervisor code with the PID register
still containing whatever the guest has been using.
The problem is that the CPU can (and will) then start prefetching or
speculatively load from whatever host context has that same PID (if
any), thus bringing translations for that context into the TLB, which
Linux doesn't know about.
This can cause stale translations and subsequent crashes.
Fixing this in a way that is neither racy nor a huge performance
impact is difficult. We could just make the host invalidations always
use broadcast forms but that would hurt single threaded programs for
example.
We chose to fix it instead by partitioning the PID space between guest
and host. This is possible because today Linux only use 19 out of the
20 bits of PID space, so existing guests will work if we make the host
use the top half of the 20 bits space.
We additionally add support for a property to indicate to Linux the
size of the PID register which will be useful if we eventually have
processors with a larger PID space available.
There is still an issue with malicious guests purposefully setting the
PID register to a value in the hosts PID range. Hopefully future HW
can prevent that, but in the meantime, we handle it with a pair of
kludges:
- On the way out of a guest, before we clear the current VCPU in the
PACA, we check the PID and if it's outside of the permitted range
we flush the TLB for that PID.
- When context switching, if the mm is "new" on that CPU (the
corresponding bit was set for the first time in the mm cpumask), we
check if any sibling thread is in KVM (has a non-NULL VCPU pointer
in the PACA). If that is the case, we also flush the PID for that
CPU (core).
This second part is needed to handle the case where a process is
migrated (or starts a new pthread) on a sibling thread of the CPU
coming out of KVM, as there's a window where stale translations can
exist before we detect it and flush them out.
A future optimization could be added by keeping track of whether the
PID has ever been used and avoid doing that for completely fresh PIDs.
We could similarily mark PIDs that have been the subject of a global
invalidation as "fresh". But for now this will do.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[mpe: Rework the asm to build with CONFIG_PPC_RADIX_MMU=n, drop
unneeded include of kvm_book3s_asm.h]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Before commit bf8f6952a233 ("Add blurb about RGMII") it was unclear
whose responsibility it was to insert the required clock skew, and
in hindsight, some PHY drivers got it wrong. The solution forward
is to introduce a new property, explicitly requiring skew from the
node to which it is attached. In the interim, this driver will handle
all 4 RGMII modes identically (no skew).
Fixes: 52dfc8301248 ("net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller")
Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The logic for computing page buffer scatter does not take into
account the impact of compound pages. Therefore the optimization
to compute number of slots was incorrect and could cause stack
corruption a skb was sent with lots of fragments from huge pages.
This reverts commit 60b86665af0dfbeebda8aae43f0ba451cd2dcfe5.
Fixes: 60b86665af0d ("netvsc: optimize calculation of number of slots")
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The error paths set err, but it's not returned.
I wondered if we should fix all of the callers to check the returned
value, but Ben explains why the code is this way:
> Most call sites ignore it on purpose. There's nothing we can do if
> we fail to get a buffer at interrupt time, so we point the buffer to
> the scratch page so the HW doesn't DMA into lalaland and lose the
> packet.
>
> The one call site that tests and can fail is the one used when brining
> the interface up. If we fail to allocate at that point, we fail the
> ifup. But as you noticed, I do have a bug not returning the error.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
RFC 2465 defines ipv6IfStatsOutFragFails as:
"The number of IPv6 datagrams that have been discarded
because they needed to be fragmented at this output
interface but could not be."
The existing implementation, instead, would increase the counter
twice in case we fail to allocate room for single fragments:
once for the fragment, once for the datagram.
This didn't look intentional though. In one of the two affected
affected failure paths, the double increase was simply a result
of a new 'goto fail' statement, introduced to avoid a skb leak.
The other path appears to be affected since at least 2.6.12-rc2.
Reported-by: Sabrina Dubroca <sdubroca@redhat.com>
Fixes: 1d325d217c7f ("ipv6: ip6_fragment: fix headroom tests and skb leak")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Three small fixes.
The transfer size fixes are actually correcting some performance drops
on the hpsa and smartpqi cards. The cards actually have an internal
cache for request speed up but bypass it for transfers > 1MB. Since
4.3 the efficiency of our merges has rendered the cache mostly unused,
so limit transfers to under 1MB to recover the cache boost"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: sg: fix static checker warning in sg_is_valid_dxfer
scsi: smartpqi: limit transfer length to 1MB
scsi: hpsa: limit transfer length to 1MB
|
|
Pull uuid fixes from Christoph Hellwig:
- add a missing "!" in the uuid tests
- remove the last remaining user of the uuid_be type, and then the type
and its helpers
* tag 'uuid-for-4.13-2' of git://git.infradead.org/users/hch/uuid:
uuid: remove uuid_be
thunderbolt: use uuid_t instead of uuid_be
uuid: fix incorrect uuid_equal conversion in test_uuid_test
|
|
Pull dma mapping fixes from Christoph Hellwig:
"split the global dma coherent pool from the per-device pool.
This fixes a regression in the earlier 4.13 pull requests where the
global pool would override a per-device CMA pool (Vladimir Murzin)"
* tag 'dma-mapping-4.13-2' of git://git.infradead.org/users/hch/dma-mapping:
ARM: NOMMU: Wire-up default DMA interface
dma-coherent: introduce interface for default DMA pool
|
|
When PCCT is not available, kernel crashes as below when requests PCC
channel 0. This patch fixes this issue.
[ 0.920454] PCCT header not found.
...
[ 8.031309] Unable to handle kernel NULL pointer dereference at virtual address 00000010
[ 8.031310] [0000000000000010] user address but active_mm is swapper
[ 8.031312] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 8.031313] Modules linked in:
[ 8.031316] CPU: 31 PID: 1 Comm: swapper/0 Tainted: G W 4.13.0-rc1 #18
[ 8.031317] Hardware name: AppliedMicro(R) 07/20/2017
[ 8.031318] task: ffff809ef3b08000 task.stack: ffff809ef3b10000
[ 8.031322] PC is at pcc_mbox_request_channel+0x8c/0x160
[ 8.031325] LR is at xgene_slimpro_i2c_probe+0x1c0/0x378
[ 8.031326] pc : [<ffff000008899450>] lr : [<ffff000008819dac>] pstate: 00000045
[ 8.031327] sp : ffff809ef3b13bd0
[ 8.031327] x29: ffff809ef3b13bd0 x28: ffff000008ed90a0
[ 8.031329] x27: ffff000009091000 x26: ffff000008e50470
[ 8.031330] x25: ffff000008ed9100 x24: ffff809eefd9ac30
[ 8.031332] x23: 0000000000000000 x22: ffff0000090e3e10
[ 8.031333] x21: ffff0000090e3000 x20: 0000000000000000
[ 8.031335] x19: 0000000000000000 x18: 0000000000087ffc
[ 8.031336] x17: 2fe48d76a78303f0 x16: 0000000000087ffc
[ 8.031337] x15: ffff000000000000 x14: 0000000000000000
[ 8.031339] x13: 0000000000000000 x12: 0000000000000018
[ 8.031340] x11: 0000000000000018 x10: 0101010101010101
[ 8.031342] x9 : 0000000000000000 x8 : 7f7f7f7f7f7f7f7f
[ 8.031343] x7 : fefefefeff6b646d x6 : 0000008080808080
[ 8.031345] x5 : 0000000000000000 x4 : 0000000000000001
[ 8.031346] x3 : 0000000000000000 x2 : ffff000008819b64
[ 8.031348] x1 : 0000000000000000 x0 : 0000000000000000
...
[ 8.031393] Call trace:
[ 8.031394] Exception stack(0xffff809ef3b13a00 to 0xffff809ef3b13b30)
[ 8.031395] 3a00: 0000000000000000 0001000000000000 ffff809ef3b13bd0 ffff000008899450
[ 8.031397] 3a20: ffff809f7e1f9a10 ffff000008f60be0 0000000000000001 ffff809ef3b13b7c
[ 8.031398] 3a40: ffff809f7e1f9a10 0000000000000000 ffff000009091000 0000000000000003
[ 8.031399] 3a60: ffff000009091000 0000000000000003 ffff809ef3b13a80 ffff0000084e0794
[ 8.031400] 3a80: ffff809ef3b13a90 ffff00000850bb64 ffff809ef3b13ad0 ffff00000850bf34
[ 8.031402] 3aa0: 0000000000000000 0000000000000000 ffff000008819b64 0000000000000000
[ 8.031403] 3ac0: 0000000000000001 0000000000000000 0000008080808080 fefefefeff6b646d
[ 8.031404] 3ae0: 7f7f7f7f7f7f7f7f 0000000000000000 0101010101010101 0000000000000018
[ 8.031405] 3b00: 0000000000000018 0000000000000000 0000000000000000 ffff000000000000
[ 8.031406] 3b20: 0000000000087ffc 2fe48d76a78303f0
[ 8.031409] [<ffff000008899450>] pcc_mbox_request_channel+0x8c/0x160
[ 8.031410] [<ffff000008819dac>] xgene_slimpro_i2c_probe+0x1c0/0x378
[ 8.031413] [<ffff0000085e84dc>] platform_drv_probe+0x50/0xbc
[ 8.031414] [<ffff0000085e68a4>] driver_probe_device+0x21c/0x2d0
[ 8.031416] [<ffff0000085e6a04>] __driver_attach+0xac/0xb0
[ 8.031417] [<ffff0000085e4a78>] bus_for_each_dev+0x58/0x98
[ 8.031418] [<ffff0000085e61e4>] driver_attach+0x20/0x28
[ 8.031419] [<ffff0000085e5e0c>] bus_add_driver+0x1c8/0x22c
[ 8.031421] [<ffff0000085e7324>] driver_register+0x60/0xf4
[ 8.031422] [<ffff0000085e8420>] __platform_driver_register+0x4c/0x54
[ 8.031425] [<ffff000008e96dd0>] xgene_slimpro_i2c_driver_init+0x18/0x20
[ 8.031426] [<ffff000008083144>] do_one_initcall+0x38/0x124
[ 8.031429] [<ffff000008e50d0c>] kernel_init_freeable+0x190/0x22c
[ 8.031431] [<ffff0000089eac30>] kernel_init+0x10/0xfc
[ 8.031432] [<ffff000008082ec0>] ret_from_fork+0x10/0x50
[ 8.031434] Code: cb030e63 8b030013 b140067f 54fffda8 (f9400a61)
[ 8.031448] ---[ end trace 14eb48a4e1e1f9fb ]---
Signed-off-by: Hoan Tran <hotran@apm.com>
Acked-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Partially overlapping regions cause platform device creation
to fail. The latter of two overlapping resources will fail to be
reserved. Fix this by merging overlapping resource ranges while
enumerating WDAT table entries.
Signed-off-by: Ryan Kennedy <ryan5544@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
spin_is_locked always returns 0 for UP case, so ignores it
Reported-by: Joshua Kinard <kumba@gentoo.org>
Signed-off-by: Shaohua Li <shli@fb.com>
|
|
It's always bothered me that we only disable preemption in
copy_user_page around the call to flush_dcache_page_asm.
This patch extends this to after the copy.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
equivalent aliases
Helge noticed that we flush the TLB page in flush_cache_page but not in
flush_cache_range or flush_cache_mm.
For a long time, we have had random segmentation faults building
packages on machines with PA8800/8900 processors. These machines only
support equivalent aliases. We don't see these faults on machines that
don't require strict coherency. So, it appears TLB speculation
sometimes leads to cache corruption on machines that require coherency.
This patch adds TLB flushes to flush_cache_range and flush_cache_mm when
coherency is required. We only flush the TLB in flush_cache_page when
coherency is required.
The patch also optimizes flush_cache_range. It turns out we always have
the right context to use flush_user_dcache_range_asm and
flush_user_icache_range_asm.
The patch has been tested for some time on rp3440, rp3410 and A500-44.
It's been boot tested on c8000. No random segmentation faults were
observed during testing.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen into for-linus
Pull xen-blkfront fixes from Konrad for 4.13.
|
|
Mic mute led does not work on HP ProBook 440 G4.
We can use CXT_FIXUP_MUTE_LED_GPIO fixup to support it.
BugLink: https://bugs.launchpad.net/bugs/1705586
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Copy the approach taken by gfx8, which simplifies the code, and set the
instance index properly. The latter is required for debugging, e.g. for
reading wave status by UMR.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
In RCU read-side critical sections, blocking or sleeping is prohibited.
v2: Unlock RCU for the code path where result==NULL. (David Zhou)
Update subject
Tested-by and reported by: Dave Airlie <airlied@redhat.com>
[ 141.965723] =============================
[ 141.965724] WARNING: suspicious RCU usage
[ 141.965726] 4.12.0-rc7 #221 Not tainted
[ 141.965727] -----------------------------
[ 141.965728] /home/airlied/devel/kernel/linux-2.6/include/linux/rcupdate.h:531
Illegal context switch in RCU read-side critical section!
[ 141.965730]
other info that might help us debug this:
[ 141.965731]
rcu_scheduler_active = 2, debug_locks = 0
[ 141.965732] 1 lock held by amdgpu_cs:0/1332:
[ 141.965733] #0: (rcu_read_lock){......}, at: [<ffffffffa01a0d07>]
amdgpu_bo_list_get+0x0/0x109 [amdgpu]
[ 141.965774]
stack backtrace:
[ 141.965776] CPU: 6 PID: 1332 Comm: amdgpu_cs:0 Not tainted 4.12.0-rc7 #221
[ 141.965777] Hardware name: To be filled by O.E.M. To be filled by
O.E.M./M5A97 R2.0, BIOS 2603 06/26/2015
[ 141.965778] Call Trace:
[ 141.965782] dump_stack+0x68/0x92
[ 141.965785] lockdep_rcu_suspicious+0xf7/0x100
[ 141.965788] ___might_sleep+0x56/0x1fc
[ 141.965790] __might_sleep+0x68/0x6f
[ 141.965793] __mutex_lock+0x4e/0x7b5
[ 141.965817] ? amdgpu_bo_list_get+0xa4/0x109 [amdgpu]
[ 141.965820] ? lock_acquire+0x125/0x1b9
[ 141.965844] ? amdgpu_bo_list_set+0x464/0x464 [amdgpu]
[ 141.965846] mutex_lock_nested+0x16/0x18
[ 141.965848] ? mutex_lock_nested+0x16/0x18
[ 141.965872] amdgpu_bo_list_get+0xa4/0x109 [amdgpu]
[ 141.965895] amdgpu_cs_ioctl+0x4a0/0x17dd [amdgpu]
[ 141.965898] ? radix_tree_node_alloc.constprop.11+0x77/0xab
[ 141.965916] drm_ioctl+0x264/0x393 [drm]
[ 141.965939] ? amdgpu_cs_find_mapping+0x83/0x83 [amdgpu]
[ 141.965942] ? trace_hardirqs_on_caller+0x16a/0x186
Signed-off-by: Alex Xie <AlexBin.Xie@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If our device loses its connection for longer than the dead timeout we
will set NBD_DISCONNECTED in order to quickly fail any pending IO's that
flood in after the IO's that were waiting during the dead timer.
However if we re-connect at some point in the future we'll still see
this DISCONNECTED flag set if we then lose our connection again after
that, which means we won't get notifications for our newly lost
connections. Fix this by just clearing the DISCONNECTED flag on
reconnect in order to make sure everything works as it's supposed to.
Reported-by: Dan Melnic <dmm@fb.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Some machines can't power off the machine, so disable the lockup detectors to
avoid this watchdog BUG to show up every few seconds:
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-shutdow:1]
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 4.9+
|
|
The Page Deallocation Table (PDT) holds the physical addresses of all broken
memory addresses. With the physical address we now are able to show which DIMM
slot (e.g. 1a, 3c) actually holds the broken memory module so that users are
able to replace it.
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
I forgot one spot when introducing struct test_obj_val.
Fixes: e859afe1ee0c5 ("lib: test_rhashtable: fix for large entry counts")
Reported by: kernel test robot <fengguang.wu@intel.com>
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit e5a03bfd873c2 ("phy: Add an mdio_device structure")
introduced a spurious trailing semicolon. Remove it.
Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The value REQ_OP_FLUSH is only used by the block code for
request-based devices.
Remove the tests for REQ_OP_FLUSH from the bio-based dm-zoned-target.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
Bumo dm-raid target version to 1.12.1 to reflect that commit cc27b0c78c
("md: fix deadlock between mddev_suspend() and md_write_start()") is
available.
This version change allows userspace to detect that MD fix is available.
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
Use runtime flag to ensure that an mddev gets suspended/resumed just once.
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
During growing reshapes (i.e. stripes being added to a raid set), the
new stripe images are not in-sync and not part of the raid set until
the reshape is started.
LVM2 has to request multiple table reloads involving superblock updates
in order to reflect proper size of SubLVs in the cluster. Before a stripe
adding reshape starts, validate_raid_redundancy() fails as a result of that
because it checks the total number of devices against the number of rebuild
ones rather than the actual ones in the raid set (as retrieved from the
superblock) thus resulting in failed raid4/5/6/10 redundancy checks.
E.g. convert 3 stripes -> 7 stripes raid5 (which only allows for maximum
1 device to fail) requesting +4 delta disks causing 4 devices to rebuild
during reshaping thus failing activation.
To fix this, move validate_raid_redundancy() to get access to the
current raid_set members.
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
ordered") automatically enabled ordered attribute for unbound
workqueues w/ max_active == 1. Because ordered workqueues reject
max_active and some attribute changes, this implicit ordered mode
broke cases where the user creates an unbound workqueue w/ max_active
== 1 and later explicitly changes the related attributes.
This patch distinguishes explicit and implicit ordered setting and
overrides from attribute changes if implict.
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
|
|
Add a firmware wrapper function, which asks PDC firmware for the DIMM slot of a
physical address. This is needed to show users which DIMM module needs
replacement in case a broken DIMM was encountered.
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Paul Moore reported a SELinux/IP_PASSSEC regression
caused by missing skb->sp at recvmsg() time. We need to
preserve the skb head state to process the IP_CMSG_PASSSEC
cmsg.
With this commit we avoid releasing the skb head state in the
BH even if a secpath is attached to the current skb, and stores
the skb status (with/without head states) in the scratch area,
so that we can access it at skb deallocation time, without
incurring in cache-miss penalties.
This also avoids misusing the skb CB for ipv6 packets,
as introduced by the commit 0ddf3fb2c43d ("udp: preserve
skb->dst if required for IP options processing").
Clean a bit the scratch area helpers implementation, to
reduce the code differences between 32 and 64 bits build.
Reported-by: Paul Moore <paul@paul-moore.com>
Fixes: 0a463c78d25b ("udp: avoid a cache miss on dequeue")
Fixes: 0ddf3fb2c43d ("udp: preserve skb->dst if required for IP options processing")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Tested-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit c9c2877d08d9 ("parisc: Add Page Deallocation Table (PDT) support")
introduced the pdc_pat_mem_read_pd_pdt() firmware helper function, which
crashed the system because it trashed the stack if the
pdc_pat_mem_read_pd_retinfo struct was located on the stack (and which is
in size less than the required 32 64-bit values).
Fix it by using the pdc_result struct instead when calling firmware and copy
the return values back into the result struct when finished sucessfully.
While debugging this code I noticed that the pdc_type wasn't set correctly
either, so let's fix that too.
Fixes: c9c2877d08d9 ("parisc: Add Page Deallocation Table (PDT) support")
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
It's possible the preferred HMB size may not be a multiple of the
chunk_size. This patch moves len to function scope and uses that in
the for loop increment so the last iteration doesn't cause the total
size to exceed the allocated HMB size.
Based on an earlier patch from Keith Busch.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Keith Busch <keith.busch@intel.com>
Fixes: 87ad72a59a38 ("nvme-pci: implement host memory buffer support")
|
|
The FC-NVME spec hasn't locked down on the format string for TRADDR.
Currently the spec is lobbying for "nn-<16hexdigits>:pn-<16hexdigits>"
where the wwn's are hex values but not prefixed by 0x.
Most implementations so far expect a string format of
"nn-0x<16hexdigits>:pn-0x<16hexdigits>" to be used. The transport
uses the match_u64 parser which requires a leading 0x prefix to set
the base properly. If it's not there, a match will either fail or return
a base 10 value.
The resolution in T11 is pushing out. Therefore, to fix things now and
to cover any eventuality and any implementations already in the field,
this patch adds support for both formats.
The change consists of replacing the token matching routine with a
routine that validates the fixed string format, and then builds
a local copy of the hex name with a 0x prefix before calling
the system parser.
Note: the same parser routine exists in both the initiator and target
transports. Given this is about the only "shared" item, we chose to
replicate rather than create an interdendency on some shared code.
Signed-off-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
There are cases where threads are in the process of submitting new
io when the LLDD calls in to remove the remote port. In some cases,
the next io actually goes to the LLDD, who knows the remoteport isn't
present and rejects it. To properly recovery/restart these i/o's we
don't want to hard fail them, we want to treat them as temporary
resource errors in which a delayed retry will work.
Add a couple more checks on remoteport connectivity and commonize the
busy response handling when it's seen.
Signed-off-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
