Commit bd8b2441742b ("NFS: Store the raw NFS access mask in the inode's
access cache") changed how the access results are stored after an
access() call. An NFS v4 OPEN might have access bits returned with the
opendata, so we should use the NFS4_ACCESS values when determining the
return value in nfs4_opendata_access().
Fixes: bd8b2441742b ("NFS: Store the raw NFS access mask in the inode's
access cache")
Reported-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Commit de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring")
moves link status commitment into bond_mii_monitor(), but it still relies
on the return value of bond_miimon_inspect() as the hint. We need to return
non-zero as long as we propose a link status change.
Fixes: de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring")
Reported-by: Benjamin Gilbert <benjamin.gilbert@coreos.com>
Tested-by: Benjamin Gilbert <benjamin.gilbert@coreos.com>
Cc: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Device lock bites again; if a device .remove() callback races a user
calling ioctl(VFIO_GROUP_GET_DEVICE_FD), the unbind request will hold
the device lock, but the user ioctl may have already taken a vfio_device
reference. In the case of a PCI device, the initial open will attempt
to reset the device, which again attempts to get the device lock,
resulting in deadlock. Use the trylock PCI reset interface and return
error on the open path if reset fails due to lock contention.
Link: https://lkml.org/lkml/2017/7/25/381
Reported-by: Wen Congyang <wencongyang2@huawei.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Currently dm_dax_flush() is not being called, even if underlying dax
device supports write cache, because DAXDEV_WRITE_CACHE is not being
propagated up to the DM dax device.
If the underlying dax device supports write cache, set
DAXDEV_WRITE_CACHE on the DM dax device. This will cause dm_dax_flush()
to be called.
Fixes: abebfbe2f7 ("dm: add ->flush() dax operation support")
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
mempool_alloc() cannot fail for GFP_NOIO allocation, so there is no
point testing for failure.
One place the code tested for failure was passing "0" as the GFP
flags. This is most unusual and is probably meant to be GFP_NOIO,
so that is changed.
Also, allocation from ->extra_pool and ->prealloc_pool are repeated
before releasing the previous allocation. This can deadlock if the code
is servicing a write under high memory pressure. To avoid deadlocks,
change these to use GFP_NOWAIT and leave the error handling in place.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Use GFP_NOIO for memory allocations in the I/O path. Other memory
allocations in the initialization path can use GFP_KERNEL.
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
When CONFIG_EEH=y and CONFIG_VFIO_SPAPR_EEH=n, build fails with the
following:
drivers/vfio/pci/vfio_pci.o: In function `.vfio_pci_release':
vfio_pci.c:(.text+0xa98): undefined reference to `.vfio_spapr_pci_eeh_release'
drivers/vfio/pci/vfio_pci.o: In function `.vfio_pci_open':
vfio_pci.c:(.text+0x1420): undefined reference to `.vfio_spapr_pci_eeh_open'
In this case, vfio_pci.c should use the empty definitions of
vfio_spapr_pci_eeh_open and vfio_spapr_pci_eeh_release functions.
This patch fixes it by guarding these function definitions with
CONFIG_VFIO_SPAPR_EEH, the symbol that controls whether vfio_spapr_eeh.c is
built, which is where the non-empty versions of these functions are. We need to
make use of IS_ENABLED() macro because CONFIG_VFIO_SPAPR_EEH is a tristate
option.
This issue was found during a randconfig build. Logs are here:
http://kisskb.ellerman.id.au/kisskb/buildresult/12982362/
Signed-off-by: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Fixes some minor issues all over the codebase.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJZd0o3AAoJECgfDbjSjVRpgK0IAKsLivWrL60y/o83bFH/59K0
m7XGZ8OMGyl94PTubidM3QqJtYCt2fv+mzkuUZXzxklJ2v4csrJeF0KKQzYlI+/k
fJv9D1SX96L1yOSHVv91YI8wNNi6NqqLCg8xKd5V7xo/IwufPRmWEEppx7zi1Cb1
Ne3rRZOox4QdRUL6hQaN9MlCxQUvIL6zRM68UXtGOImLmb0O/vsic+DNjk7gItRz
/iO3WE4Ig8sbrFjntgJ/+iotJO4/0qbKMxFVQOUOluiOiOhJgGlq+qmMdM45JBzM
btED8OnuNcAWdDhtsux4ivC1Kl10cEGzXM3NzS2rV4/7A6rCRJvcFH0bUQGHdlk=
=4J1q
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio fixes and cleanups from Michael Tsirkin:
"Fixes some minor issues all over the codebase"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
virtio-net: fix module unloading
virtio-balloon: coding format cleanup
virtio-balloon: deflate via a page list
virtio_blk: Use sysfs_match_string() helper
Using variables instead of hard paths makes the requirements information
more accurate.
Signed-off-by: Lin Ma <lma@suse.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We need to hold the srcu lock when accessing memory slots
during migration
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iQIcBAABAgAGBQJZd0O1AAoJEBF7vIC1phx8WOIQAKLLmnqmKfD5sy3hIxkRUHG7
WlN33M9tNCjDa1gL6iurBqKbOHt7phBhZdp/Kzuy/UxwPtM5vMaajQv1mLKl7b2y
1GKEt2aTMJ3e/ql3Z3kVOASNguU2NHjVuzu+BObLhfzBXmNYp4hkyrMSkegb4Q2v
j6Kfhpz/ltrzCYhL1/WYquKwG/aAV0fDefbfSrZZ0yx1TCnbtAEfbqBO6LXfys2t
M3LW2OQwavV0YYrrwF4o7Seg0YfpQVYVH1j1/0dLd/Mb1w1D5/CB+gTr6zYhZ6z2
MzZAa5ADRJ1y+YEoB6aB8T95/4i9Aw3fYhPYfw4ijUJcHUwSbzllSt2brIUSkEZo
rajClCRjAMaMfeg2q5SZ6Mbg/wt5uo9O0hRG9weqZQR+NCnYkcrfgTe2kYSrorAs
Msp6CUSfP9cOL9JETD+f3hEWl4uqA1P21n6Ga/v5ERPDxqIrqU49mlgjxBKRcPK4
wHKaBrA4h53yOjNQ5U/Bdr130W2dQnRHmYAQXuUM9OjbBOliTbtgf8ND0U15S9TY
HZomb3kEkL1o8J5rH6NBxxntoU48SEtuppBDSIAYBnp9h02F+RvNPqMr4orFHfD/
OJe0zJHYobK44kz59DGmN5ed5wZl+Vzvdf7KAa62MotKmDMykbkWbcb9j+gcUFHf
Yal+Mk51xCKPUcadGD/e
=PjH2
-----END PGP SIGNATURE-----
Merge tag 'kvm-s390-master-4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD
KVM: s390: fixup missing srcu lock
We need to hold the srcu lock when accessing memory slots
during migration
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Run kvm-unit-tests/eventinj.flat in L1 w/ ept=0 on both L0 and L1:
Before NMI IRET test
Sending NMI to self
NMI isr running stack 0x461000
Sending nested NMI to self
After nested NMI to self
Nested NMI isr running rip=40038e
After iret
After NMI to self
FAIL: NMI
Commit 4c4a6f790ee862 (KVM: nVMX: track NMI blocking state separately
for each VMCS) tracks NMI blocking state separately for vmcs01 and
vmcs02. However it is not enough:
- The L2 (kvm-unit-tests/eventinj.flat) generates NMI that will fault
on IRET, so the L2 can generate #PF which can be intercepted by L0.
- L0 walks L1's guest page table and sees the mapping is invalid, it
resumes the L1 guest and injects the #PF into L1. At this point the
vmcs02 has nmi_known_unmasked=true.
- L1 sets set bit 3 (blocking by NMI) in the interruptibility-state field
of vmcs12 (and fixes the shadow page table) before resuming L2 guest.
- L1 executes VMRESUME to resume L2, causing a vmexit to L0
- during VMRESUME emulation, prepare_vmcs02 sets bit 3 in the
interruptibility-state field of vmcs02, but nmi_known_unmasked is
still true.
- L2 immediately exits to L0 with another page fault, because L0 still has
not updated the NGVA->HPA page tables. However, nmi_known_unmasked is
true so vmx_recover_nmi_blocking does not do anything.
The fix is to update nmi_known_unmasked when preparing vmcs02 from vmcs12.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The PI vector for L0 and L1 must be different. If dest vcpu0
is in guest mode while vcpu1 is delivering a non-nested PI to
vcpu0, there wont't be any vmexit so that the non-nested interrupt
will be delayed.
Signed-off-by: Wincy Van <fanwenyi0529@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We are using the same vector for nested/non-nested posted
interrupts delivery, this may cause interrupts latency in
L1 since we can't kick the L2 vcpu out of vmx-nonroot mode.
This patch introduces a new vector which is only for nested
posted interrupts to solve the problems above.
Signed-off-by: Wincy Van <fanwenyi0529@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This reverts the change of commit f85c758dbee54cc3612a6e873ef7cecdb66ebee5,
as the behavior it modified was intended.
The VM is running in 32-bit PAE mode, and Table 4-7 of the Intel manual
says:
Table 4-7. Use of CR3 with PAE Paging
Bit Position(s) Contents
4:0 Ignored
31:5 Physical address of the 32-Byte aligned
page-directory-pointer table used for linear-address
translation
63:32 Ignored (these bits exist only on processors supporting
the Intel-64 architecture)
To placate the static checker, write the mask explicitly as an
unsigned long constant instead of using a 32-bit unsigned constant.
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: f85c758dbee54cc3612a6e873ef7cecdb66ebee5
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Simplify and improve the code so that the PID is always available in
the uevent even when debugfs is not available.
This adds a userspace_pid field to struct kvm, as per Radim's
suggestion, so that the PID can be retrieved on destruction too.
Acked-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Fixes: 286de8f6ac9202 ("KVM: trigger uevents when creating or destroying a VM")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We must use pre-processor conditional block or suitable accessors to
manipulate skb->sp elsewhere builds lacking the CONFIG_XFRM will break.
Fixes: dce4551cb2ad ("udp: preserve head state for IP_CMSG_PASSSEC")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The wrong bit is assigned to DIG_CLK_CTL_RXD3_CLK_EN, change it for the
correct one.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Just like in the allocator we must avoid touching multiple AGs out of
order when freeing blocks, as freeing still locks the AGF and can cause
the same AB-BA deadlocks as in the allocation path.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Nikolay Borisov <n.borisov.lkml@gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
The register_syscore_ops() function takes a mutex and might
sleep. In the IOMMU initialization code it is invoked during
irq-remapping setup already, where irqs are disabled.
This causes a schedule-while-atomic bug:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: swapper/0
no locks held by swapper/0/1.
irq event stamp: 304
hardirqs last enabled at (303): [<ffffffff818a87b6>] _raw_spin_unlock_irqrestore+0x36/0x60
hardirqs last disabled at (304): [<ffffffff8235d440>] enable_IR_x2apic+0x79/0x196
softirqs last enabled at (36): [<ffffffff818ae75f>] __do_softirq+0x35f/0x4ec
softirqs last disabled at (31): [<ffffffff810c1955>] irq_exit+0x105/0x120
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2.1.el7a.test.x86_64.debug #1
Hardware name: PowerEdge C6145 /040N24, BIOS 3.5.0 10/28/2014
Call Trace:
dump_stack+0x85/0xca
___might_sleep+0x22a/0x260
__might_sleep+0x4a/0x80
__mutex_lock+0x58/0x960
? iommu_completion_wait.part.17+0xb5/0x160
? register_syscore_ops+0x1d/0x70
? iommu_flush_all_caches+0x120/0x150
mutex_lock_nested+0x1b/0x20
register_syscore_ops+0x1d/0x70
state_next+0x119/0x910
iommu_go_to_state+0x29/0x30
amd_iommu_enable+0x13/0x23
Fix it by moving the register_syscore_ops() call to the next
initialization step, which runs with irqs enabled.
Reported-by: Artem Savkov <asavkov@redhat.com>
Tested-by: Artem Savkov <asavkov@redhat.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Fixes: 2c0ae1720c09 ('iommu/amd: Convert iommu initialization to state machine')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The code looks in imx_enum_frame_size() looks like this:
2066 int index = fse->index;
2067 struct imx_device *dev = to_imx_sensor(sd);
2068
2069 mutex_lock(&dev->input_lock);
2070 if (index >= dev->entries_curr_table) {
2071 mutex_unlock(&dev->input_lock);
2072 return -EINVAL;
2073 }
2074
2075 fse->min_width = dev->curr_res_table[index].width;
"fse->index" is a u32 that comes from the user. We want negative values
of "index" to be -EINVAL so we don't read before the start of the
dev->curr_res_table[] array. I've made "entries_curr_table" unsigned
long to fix this. I thought about making it unsigned int, but because
of struct alignment, it doesn't use more memory either way.
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
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>
The problem is this code from ap1302_enum_frame_size():
738 int index = fse->index;
739
740 mutex_lock(&dev->input_lock);
741 context = ap1302_get_context(sd);
742 if (index >= dev->cntx_res[context].res_num) {
743 mutex_unlock(&dev->input_lock);
744 return -EINVAL;
745 }
746
747 res_table = dev->cntx_res[context].res_table;
748 fse->min_width = res_table[index].width;
"fse->index" is a u32 that come from the user. We want negative values
of "index" to be treated as -EINVAL but they're not so we can read from
before the start of the res_table[] array.
I've fixed this by making "res_num" a u32. I made "cur_res" a u32 as
well, just for consistency.
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
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>
The problem here is this code from atomisp_enum_input():
581 int index = input->index;
582
583 if (index >= isp->input_cnt)
584 return -EINVAL;
585
586 if (!isp->inputs[index].camera)
587 return -EINVAL;
"input->index" is a u32 which comes from the ioctl. We want negative
values of "index" to be counted as -EINVAL but they aren't. I've fixed
this by changing the type of "isp->input_cnt" to unsigned int.
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
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>
Couple of instances of sst_acpi_mach were having missing sentinels
so add them up
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
drop VPFE_CMD_S_CCDC_RAW_PARAMS ioctl from dm355/dm644x following reasons:
- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
the user input over the kernel settings, and then compare them
for inequality.
- We then go on to use an address provided by user space as both the
__user pointer for input and pass it through phys_to_virt to come up
with a kernel pointer to copy the data to. This looks like a trivially
exploitable root hole.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works
for vpfe_capture driver with a minimal patch suitable for backporting.
- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
the user input over the kernel settings, and then compare them
for inequality.
- We then go on to use an address provided by user space as both the
__user pointer for input and pass it through phys_to_virt to come up
with a kernel pointer to copy the data to. This looks like a trivially
exploitable root hole.
Due to these reasons we make sure this ioctl now returns -EINVAL and backport
this patch as far as possible.
Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver")
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Cc: <stable@vger.kernel.org> # for v3.7 and up
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
In venus_boot(), we pass a pointer to a phys_addr_t
into dmam_alloc_coherent, which the compiler warns about:
platform/qcom/venus/firmware.c: In function 'venus_boot':
platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
To avoid the error refactor venus_boot function by discard
dma_alloc_coherent invocation because we don't want to map the
memory for the device. Something more, the usage of
DMA mapping API is actually wrong and the current
implementation relies on several bugs in DMA mapping code.
When these bugs are fixed that will break firmware loading,
so fix this now to avoid future troubles.
The meaning of venus_boot is to copy the content of the
firmware buffer into reserved (and memblock removed)
block of memory and pass that physical address to the
trusted zone for authentication and mapping through iommu
form the secure world. After iommu mapping is done the iova
is passed as ane entry point to the remote processor.
After this change memory-region property is parsed manually
and the physical address is memremap to CPU, call mdt_load to
load firmware segments into proper places and unmap
reserved memory.
Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Not entirely sure what triggers it, but with venus build as kernel
module and in initrd, we hit this crash:
Unable to handle kernel paging request at virtual address ffff80003c039000
pgd = ffff00000a14f000
[ffff80003c039000] *pgd=00000000bd9f7003, *pud=00000000bd9f6003, *pmd=00000000bd9f0003, *pte=0000000000000000
Internal error: Oops: 96000007 [#1] SMP
Modules linked in: qcom_wcnss_pil(E+) crc32_ce(E) qcom_common(E) venus_core(E+) remoteproc(E) snd_soc_msm8916_digital(E) virtio_ring(E) cdc_ether(E) snd_soc_lpass_apq8016(E) snd_soc_lpass_cpu(E) snd_soc_apq8016_sbc(E) snd_soc_lpass_platform(E) v4l2_mem2mem(E) virtio(E) snd_soc_core(E) ac97_bus(E) snd_pcm_dmaengine(E) snd_seq(E) leds_gpio(E) videobuf2_v4l2(E) videobuf2_core(E) snd_seq_device(E) snd_pcm(E) videodev(E) media(E) nvmem_qfprom(E) msm(E) snd_timer(E) snd(E) soundcore(E) spi_qup(E) mdt_loader(E) qcom_tsens(E) qcom_spmi_temp_alarm(E) nvmem_core(E) msm_rng(E) uas(E) usb_storage(E) dm9601(E) usbnet(E) mii(E) mmc_block(E) adv7511(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) qcom_spmi_vadc(E) qcom_vadc_common(PE) industrialio(E) pinctrl_spmi_mpp(E)
pinctrl_spmi_gpio(E) rtc_pm8xxx(E) clk_smd_rpm(E) sdhci_msm(E) sdhci_pltfm(E) qcom_smd_regulator(E) drm(E) smd_rpm(E) qcom_spmi_pmic(E) regmap_spmi(E) ci_hdrc_msm(E) ci_hdrc(E) usb3503(E) extcon_usb_gpio(E) phy_msm_usb(E) udc_core(E) qcom_hwspinlock(E) extcon_core(E) ehci_msm(E) i2c_qup(E) sdhci(E) mmc_core(E) spmi_pmic_arb(E) spmi(E) qcom_smd(E) smsm(E) rpmsg_core(E) smp2p(E) smem(E) hwspinlock_core(E) gpio_keys(E)
CPU: 2 PID: 551 Comm: irq/150-venus Tainted: P E 4.12.0+ #1625
Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc2-00144-ga97bdbdf72-dirty 07/08/2017
task: ffff800037338000 task.stack: ffff800038e00000
PC is at hfi_sys_init_done+0x64/0x140 [venus_core]
LR is at hfi_process_msg_packet+0xcc/0x1e8 [venus_core]
pc : [<ffff00000118b384>] lr : [<ffff00000118c11c>] pstate: 20400145
sp : ffff800038e03c60
x29: ffff800038e03c60 x28: 0000000000000000
x27: 00000000000df018 x26: ffff00000118f4d0
x25: 0000000000020003 x24: ffff80003a8d3010
x23: ffff00000118f760 x22: ffff800037b40028
x21: ffff8000382981f0 x20: ffff800037b40028
x19: ffff80003c039000 x18: 0000000000000020
x17: 0000000000000000 x16: ffff800037338000
x15: ffffffffffffffff x14: 0000001000000014
x13: 0000000100001007 x12: 0000000100000020
x11: 0000100e00000000 x10: 0000000000000001
x9 : 0000000200000000 x8 : 0000001400000001
x7 : 0000000000001010 x6 : 0000000000000148
x5 : 0000000000001009 x4 : ffff80003c039000
x3 : 00000000cd770abb x2 : 0000000000000042
x1 : 0000000000000788 x0 : 0000000000000002
Process irq/150-venus (pid: 551, stack limit = 0xffff800038e00000)
Call trace:
[<ffff00000118b384>] hfi_sys_init_done+0x64/0x140 [venus_core]
[<ffff00000118c11c>] hfi_process_msg_packet+0xcc/0x1e8 [venus_core]
[<ffff00000118a2b4>] venus_isr_thread+0x1b4/0x208 [venus_core]
[<ffff00000118e750>] hfi_isr_thread+0x28/0x38 [venus_core]
[<ffff000008161550>] irq_thread_fn+0x30/0x70
[<ffff0000081617fc>] irq_thread+0x14c/0x1c8
[<ffff000008105e68>] kthread+0x138/0x140
[<ffff000008083590>] ret_from_fork+0x10/0x40
Code: 52820125 52820207 7a431820 54000249 (b9400263)
---[ end trace c963460f20a984b6 ]---
The problem is that in the error case, we've incremented the data ptr
but not decremented rem_bytes, and keep reading (presumably garbage)
until eventually we go beyond the end of the buffer.
Instead, on first error, we should probably just bail out. Other
option is to increment read_bytes by sizeof(u32) before the switch,
rather than only accounting for the ptype header in the non-error
case. Note that in this case it is HFI_ERR_SYS_INVALID_PARAMETER,
ie. an unrecognized/unsupported parameter, so interpreting the next
word as a property type would be bogus. The other error cases are
due to truncated buffer, so there isn't likely to be anything valid
to interpret in the remainder of the buffer. So just bailing seems
like a reasonable solution.
Signed-off-by: Rob Clark <robdclark@gmail.com>
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>
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>
