Fix regressions to runtime PM on OMAP and other minor fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJT/wC9AAoJEA5ceFyATYLZyZ4QAJ0q0XT9hpsx5TAUcM8azeYG
jRGm2SrkBQlxkCH8lS6PhJXGdbd8SR3H9l0ITPNed/Vwt0N5LBtBVmRWGDJNliGM
E9RoBTBqohPlBozyORDoM8cs2RIVqj14WAhXjJUvq+6DAxw6rQ5UMnKJXiNf8Ui7
MGh9i0/JQvKNYLVvGACzo5Jb38c0fSR7irYcAQJstI77QnnJQ6pSTdseCV64F45L
IFvLa+4gkqfi8vFHlVH5pSa6NRmq9x+q1fkDl/e+EcJjZ67xfAFuXGlvsM8m6B7F
YzyNNiqpGW9KvRRhOfQCWadI0olgtPZS2XXS9pRgIDDDh38V9bkyv0aQJLGQrZlz
ChQq2jnVifTo0MK93x4s28DUjETxhUQLZ0rtENiLaNHcpiFJRZxVdZ+q5ZTRN5JA
oaqbty6FEyWlSIv80jIe4s55RpBxWIGr0PRLNnVRl4+GWKxQOjCnnY2CLxLpz0dN
c/6TVJwIsZDQD6A895eBdjmTCF4oLdswtwHMn4P3g1vxNGjP0UwsJ3kGb59Zx7GO
dopEtLCutMC8tcLUl2YJwEiPUSqAJlfeDJ7h0SRdhwE3jqsdnuwFOT2BRFlfM6qq
P04SYd5W9r9MW9y5suUnuURddpqVYIe8wt405dSqY4+jP2pVzyjAMaBmuoVbOx4g
Ejjp9CDLmsozs1wfiOsd
=s/sJ
-----END PGP SIGNATURE-----
Merge tag 'for-3.17-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus
Kishon writes:
for_3.17-rc
Fix regressions to runtime PM on OMAP and other minor fixes.
The arm64 interrupt migration code on cpu offline calls
irqchip.irq_set_affinity() with the argument force=true. Originally
this argument had no effect because it was not used by any interrupt
chip driver and there was no semantics defined.
This changed with commit 01f8fa4f01 ("genirq: Allow forcing cpu
affinity of interrupts") which made the force argument useful to route
interrupts to not yet online cpus without checking the target cpu
against the cpu online mask. The following commit ffde1de640
("irqchip: gic: Support forced affinity setting") implemented this for
the GIC interrupt controller.
As a consequence the cpu offline irq migration fails if CPU0 is
offlined, because CPU0 is still set in the affinity mask and the
validation against cpu online mask is skipped to the force argument
being true. The following first_cpu(mask) selection always selects
CPU0 as the target.
Commit 601c942176d8("arm64: use cpu_online_mask when using forced
irq_set_affinity") intended to fix the above mentioned issue but
introduced another issue where affinity can be migrated to a wrong
CPU due to unconditional copy of cpu_online_mask.
As with for arm, solve the issue by calling irq_set_affinity() with
force=false from the CPU offline irq migration code so the GIC driver
validates the affinity mask against CPU online mask and therefore
removes CPU0 from the possible target candidates. Also revert the
changes done in the commit 601c942176 as it's no longer needed.
Tested on Juno platform.
Fixes: 601c942176d8("arm64: use cpu_online_mask when using forced
irq_set_affinity")
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org> # 3.10.x
Signed-off-by: Will Deacon <will.deacon@arm.com>
The current code just returns -EINVAL because mode can't be equal to
both 1 and 2.
Also this function is messy so I have cleaned it up:
1) Remove initializers like "int time = -1". Initializing variables to
garbage values turns off GCC's uninitialized variable warnings so it
can lead to bugs.
2) Use kstrtoint() instead of sscanf().
3) Use SCI_KBD_MODE_FNZ and SCI_KBD_MODE_AUTO instead of magic numbers 1
and 2.
4) Don't check for "mode == -1" because that can't happen.
5) Preserve the error code from toshiba_kbd_illum_status_set().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Pull f2fs bug fixes from Jaegeuk Kim:
"This series includes patches to:
- fix recovery routines
- fix bugs related to inline_data/xattr
- fix when casting the dentry names
- handle EIO or ENOMEM correctly
- fix memory leak
- fix lock coverage"
* tag 'for-f2fs-3.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs: (28 commits)
f2fs: reposition unlock_new_inode to prevent accessing invalid inode
f2fs: fix wrong casting for dentry name
f2fs: simplify by using a literal
f2fs: truncate stale block for inline_data
f2fs: use macro for code readability
f2fs: introduce need_do_checkpoint for readability
f2fs: fix incorrect calculation with total/free inode num
f2fs: remove rename and use rename2
f2fs: skip if inline_data was converted already
f2fs: remove rewrite_node_page
f2fs: avoid double lock in truncate_blocks
f2fs: prevent checkpoint during roll-forward
f2fs: add WARN_ON in f2fs_bug_on
f2fs: handle EIO not to break fs consistency
f2fs: check s_dirty under cp_mutex
f2fs: unlock_page when node page is redirtied out
f2fs: introduce f2fs_cp_error for readability
f2fs: give a chance to mount again when encountering errors
f2fs: trigger release_dirty_inode in f2fs_put_super
f2fs: don't skip checkpoint if there is no dirty node pages
...
Pull key subsystem fixes from James Morris:
"Fixes for the keys subsystem, one of which addresses a use-after-free
bug"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
PEFILE: Relax the check on the length of the PKCS#7 cert
KEYS: Fix use-after-free in assoc_array_gc()
KEYS: Fix public_key asymmetric key subtype name
KEYS: Increase root_maxkeys and root_maxbytes sizes
In blk-mq.c blk_mq_alloc_tag_set, if:
set->tags = kmalloc_node()
succeeds, but one of the blk_mq_init_rq_map() calls fails,
goto out_unwind;
needs to free set->tags so the caller is not obligated
to do so. None of the current callers (null_blk,
virtio_blk, virtio_blk, or the forthcoming scsi-mq)
do so.
set->tags needs to be set to NULL after doing so,
so other tag cleanup logic doesn't try to free
a stale pointer later. Also set it to NULL
in blk_mq_free_tag_set.
Tested with error injection on the forthcoming
scsi-mq + hpsa combination.
Signed-off-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Another handful of arm64 fixes here:
- A few fixes for real issues found by smatch (after Dan's talk at KS)
- Revert the /proc/cpuinfo changes merged during the merge window.
We've opened a can of worms here, so we need to find out where we
stand before we change this interface.
- Implement KSTK_ESP for compat tasks, otherwise 32-bit Android gets
confused wondering where its [stack] has gone
- Misc fixes (fpsimd context handling, crypto, ...)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCgAGBQJUBKj4AAoJEC379FI+VC/ZR7wP/jdJ+mK+lqMPg0K2vw8qiGsu
Npq/QBG+mrIcPJZQ/njPBx7Ex7o/8YrhlA4tzuT5sk3Q+P5xgcg6VCneOp4qYmNA
YUuNcWOx1Oufo8FxnmG8nylV9hlNKYiY83/UTlSw4ZdEH9C/CpBb3ihI5XnfJvtE
yRg2DnkW2p4kd0Xp/Ffc9zIEhvquv5ieYEmEXlC0//N/C2AZcbgVBLDBikfxtouM
q6htZZ/jJ4hYTgpY6pL0zl7g/Ct5S2BI07cDKYXg79Sr8GtgbGlAO5LbRb+Ll7LB
Uo3FSN0hhcoHGq+R8QjBKQ/FINSjpywSPIhU1kJESwfyRpLwPdpWM+dy1NNf+/gY
J1xES+jcilYhbb/jQM2E4xsSsID9KmWHEWJ4cDpaDx2DLj2eEX0vfv403ghZ7VSG
yUfTCUFdRLf8HadVlTgsNsS9ckNYRHsxhG+hgMjfM48dkNlkwNQB3wMi8DwUFLY2
BGNKiWbX8LK1qE1Cy81mlsl/P0WzEY8qzswbuOZ7DnN7Rhr1zMMnG5KHYcOyGNPD
BlIKj6DUMgZE49ouExx4sFyO1chmIDgC5R+acHAmEqNS6SvWFrK9eQBjdpob5nff
OBtusJGsSlLmoNQOrzE8funS3fyiuA4Dl/ZsTSyQbVq3IDRCZ1UrCw0+2Py7IMhZ
cWbL9Vbsb9drJbutXrgI
=ibHT
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull more arm64 fixes from Will Deacon:
"Another handful of arm64 fixes here. They address some issues found
by running smatch on the arch code (ignoring the false positives) and
also stop 32-bit Android from losing track of its stack.
There's one additional irq migration fix in the pipeline, but it came
in after I'd tagged and tested this set.
- a few fixes for real issues found by smatch (after Dan's talk at KS)
- revert the /proc/cpuinfo changes merged during the merge window.
We've opened a can of worms here, so we need to find out where we
stand before we change this interface.
- implement KSTK_ESP for compat tasks, otherwise 32-bit Android gets
confused wondering where its [stack] has gone
- misc fixes (fpsimd context handling, crypto, ...)"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
Revert "arm64: cpuinfo: print info for all CPUs"
arm64: fix bug for reloading FPSIMD state after cpu power off
arm64: report correct stack pointer in KSTK_ESP for compat tasks
arm64: Add brackets around user_stack_pointer()
arm64: perf: don't rely on layout of pt_regs when grabbing sp or pc
arm64: ptrace: fix compat reg getter/setter return values
arm64: ptrace: fix compat hardware watchpoint reporting
arm64: Remove unused variable in head.S
arm64/crypto: remove redundant update of data
Pull LED fix from Bryan Wu:
"Hugh, Jiri and many other people found a kernel oops due to a LED
change merged recently. Now the right fix might just revert it and
avoid the kernel oops"
* 'leds-fixes-for-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
Revert "leds: convert blink timer to workqueue"
A few more driver specific fixes on top of the currently pending fixes
(which are already in your tree but not Linus').
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUByMFAAoJELSic+t+oim9YfkP/27rmG+gA43D8EuPc+QvAY+b
fXyT6CgsacFEh867ubyVkxPHp7rtDvRFXrckPOpMEQiTUTbFkhVST6xXYlP4LZzA
97AiJqzSkPJiAlTxWTwlf8EkRw4n82uYSqOUx8ZlJbtUqt8VeaTVshm+L5emBPq1
Q9BvcJ233Co7OWtHr2DsDh1sn7oYBBkO+mX9Ewcn79shhNdcH52IrWfih/6MHKmJ
UtgThDokbvTXZlX7bxsfmEHloP9TJL5Et1pYDlQmQ1CqcJYG0YrQ8PylMeFE4SV9
Ej68ogbJqddZNWS/6wyDXBKxsl54l+OJaHPGizxruvIBlpowkpyMS1pj5Us10VCc
mqUuqGfXQbm2B7DJr9/P9+jI5QVcBJ0z8RZ+0dCgFZKU0+A1zTue75RKH7tO/M0C
KEPW/G3MevbXJNCU1QUVkjZnsyw22302irSxksmmuE/grUabILDqWTFzXIX/v0mk
1fE1dOGLpztHWLdnZ5eXd2xLRF48EoZbeIj8n6rXJOA4zMbZFbkAwt8BbljU2DCN
Pb/54HP/0+s+Ig6r4vU5J/IPGKBGUj8z2F4wbZzSbT37X05JF2BP8E6FIRPkYLbp
hUtLXTP0mNXE0L99CzkPnVJZa4cViHUNZ7Zde7jza3s0F8T49IDS8g3codFAqFtK
n2wJa9hB2fMKw7pgVfzv
=gYI8
-----END PGP SIGNATURE-----
Merge tag 'asoc-v3.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v3.17
A few more driver specific fixes on top of the currently pending fixes
(which are already in your tree but not Linus').
The PHY configuration is stored in an opaque "config" field, but when
allocating the structure, its proper size needs to be known. In the case
of UTMI, the proper structure is tegra_utmip_config of which a local
variable already exists, so we can use that to obtain the size from.
Fixes the following warning from the sparse checker:
drivers/usb/phy/phy-tegra-usb.c:882:17: warning: expression using sizeof(void)
Fixes: 81d5dfe6d8 (usb: phy: tegra: Read UTMIP parameters from device tree)
Cc: stable@vger.kernel.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Up to now, when endpoint addresses in descriptors were non-consecutive,
there were created redundant files, which could cause problems in kernel,
when user tried to read/write to them. It was result of fact that maximum
endpoint address was taken as total number of endpoints in function.
This patch adds endpoint descriptors counting and storing their addresses
in eps_addrmap to verify their cohesion in each speed.
Endpoint address map would be also useful for further features, just like
vitual endpoint address mapping.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch fixes the usb_pkt_pop(). If a gadget driver calls
usb_ep_dequeue(), this driver will call the usb_pkt_pop().
So, the usb_pkt_pop() should cancel the transaction.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch fixes the condition of is_done in usbhsf_dma_push_done().
This function will be called after a transmission finished by DMAC.
So, the function should check if the transmission packet is short packet
or not. Also the function should call try_run to send the zero packet
by the pio handler if the "*is_done" is not set. Otherwize, the
transaction will not finish if a gadget driver sets the "zero" flag
in a transmission.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch protects the mod->irq_bempsts and mod->irq_brdysts by
spin lock in the usbhs_status_get_each_irq() because other functions
will write them during spin lock. Otherwise, the driver will clears
the BRDYSTS and/or BEMPSTS wrongly, and then, the transaction will not
finish.
Also since the driver should use the INTSTS0 and BRDYSTS and BEMPSTS
as the same timing, the patch protects them.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Some gadget drivers will call usb_ep_queue() more than once before
the first queue doesn't finish. However, this driver didn't handle
it correctly. So, this patch fixes the behavior of some
usbhs_pkt_handle using the "running" flag. Otherwise, the oops below
happens if we use g_ncm driver and when the "iperf -u -c host -b 200M"
is running.
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 80000007 [#1] SMP ARM
Modules linked in: usb_f_ncm g_ncm libcomposite u_ether
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.17.0-rc1-00008-g8b2be8a-dirty #20
task: c051c7e0 ti: c0512000 task.ti: c0512000
PC is at 0x0
LR is at usbhsf_pkt_handler+0xa8/0x114
pc : [<00000000>] lr : [<c0278fb4>] psr: 60000193
sp : c0513ce8 ip : c0513c58 fp : c0513d24
r10: 00000001 r9 : 00000193 r8 : eebec4a0
r7 : eebec410 r6 : eebe0c6c r5 : 00000000 r4 : ee4a2774
r3 : 00000000 r2 : ee251e00 r1 : c0513cf4 r0 : ee4a2774
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Clearly this was meant to be an include guard, but a trailing
underscore was missing. It has been this way since the file was
introduced in 0fe6f1d1 ("usb: udc: add Faraday fusb300 driver").
Fixes: 0fe6f1d1 ("usb: udc: add Faraday fusb300 driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
CPPI TX does not transmit ZLP for TX transfers which
- transfer size is multiple of EP packet size,
- and URB_ZERO_PACKET is set in urb->transfer_flags.
The fix is transmitting the ZLP using PIO mode after the CPPI TX is
done.
Validated using the following usbtest write case in MUSB host mode.
# testusb -t1 -c1
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Thanks to Dan Carpenter for extending smatch to find bugs like this.
(This was found using a development version of smatch.)
Fixes: 36de928641
Reported-by: Dan Carpenter <dan.carpenter@oracle.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
The __percpu __iomem annotations on the rdist base are contradictory
and confuse static checkers such as sparse.
This patch fixes the anotations so that rdist is described as a __percpu
pointer to an __iomem pointer.
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1409062410-25891-9-git-send-email-will.deacon@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The internal irq domain ops for the GIC are not used directly anywhere
else, so make them static. This gets rid of a sparse warning on the
file.
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1409062410-25891-8-git-send-email-will.deacon@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The following compilation error occurs on 64-bit Exynos7 SoC:
drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’:
drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of function ‘set_irq_flags’ [-Werror=implicit-function-declaration]
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
^
drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared (first use in this function)
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
^
drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is reported only once for each function it appears in
drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared (first use in this function)
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
Fix the build error by including linux/interrupt.h.
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lkml.kernel.org/r/1409722329-18309-1-git-send-email-ch.naveen@samsung.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Pull an RCU fix from Paul E. McKenney:
"This series contains a single commit fixing an initialization bug
reported by Amit Shah and fixed by Pranith Kumar (and tested by Amit).
This bug results in a boot-time hang in callback-offloaded configurations
where callbacks were posted before the offloading ('rcuo') kthreads
were created."
Signed-off-by: Ingo Molnar <mingo@kernel.org>
fc95ca7284 introduces a memset in
kvmppc_alloc_hpt since the general CMA doesn't clear the memory it
allocates.
However, the size argument passed to memset is computed from a signed value
and its signed bit is extended by the cast the compiler is doing. This lead
to extremely large size value when dealing with order value >= 31, and
almost all the memory following the allocated space is cleaned. As a
consequence, the system is panicing and may even fail spawning the kdump
kernel.
This fix makes use of an unsigned value for the memset's size argument to
avoid sign extension. Among this fix, another shift operation which may
lead to signed extended value too is also fixed.
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The quite-recently-added analog-tv-connector bindings say that the
compatible string for composite video connector is
"composite-connector". That string is also used in the omap3-n900.dts
file. However, the connector driver uses "composite-video-connector", so
this has never worked.
While changing the driver's compatible string to "composite-connector"
would be safer, as published DT bindings should not be changed, I'd
rather fix the bindings in this case for two reasons:
* composite-connector is a bit too generic name, as it doesn't even hint
at video.
* it's clear that this has never worked, which means no one has used
those bindings, which should make it safe to change this.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Two vmwgfx fixes, marked for stable as well
* 'vmwgfx-fixes-3.17' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle
drm/vmwgfx: Fix an incorrect OOM return value
Relax the check on the length of the PKCS#7 cert as it appears that the PE
file wrapper size gets rounded up to the nearest 8.
The debugging output looks like this:
PEFILE: ==> verify_pefile_signature()
PEFILE: ==> pefile_parse_binary()
PEFILE: checksum @ 110
PEFILE: header size = 200
PEFILE: cert = 968 @547be0 [68 09 00 00 00 02 02 00 30 82 09 56 ]
PEFILE: sig wrapper = { 968, 200, 2 }
PEFILE: Signature data not PKCS#7
The wrapper is the first 8 bytes of the hex dump inside []. This indicates a
length of 0x968 bytes, including the wrapper header - so 0x960 bytes of
payload.
The ASN.1 wrapper begins [ ... 30 82 09 56 ]. That indicates an object of size
0x956 - a four byte discrepency, presumably just padding for alignment
purposes.
So we just check that the ASN.1 container is no bigger than the payload and
reduce the recorded size appropriately.
Whilst we're at it, allow shorter PKCS#7 objects that manage to squeeze within
127 or 255 bytes. It's just about conceivable if no X.509 certs are included
in the PKCS#7 message.
Reported-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
An edit script should be considered inaccessible by a function once it has
called assoc_array_apply_edit() or assoc_array_cancel_edit().
However, assoc_array_gc() is accessing the edit script just after the
gc_complete: label.
Reported-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
cc: shemming@brocade.com
cc: paulmck@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Signed-off-by: James Morris <james.l.morris@oracle.com>
The length of the name of an asymmetric key subtype must be stored in struct
asymmetric_key_subtype::name_len so that it can be matched by a search for
"<subkey_name>:<partial_fingerprint>". Fix the public_key subtype to have
name_len set.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Now that NFS client uses the kernel key ring facility to store the NFSv4
id/gid mappings, the defaults for root_maxkeys and root_maxbytes need to be
substantially increased.
These values have been soak tested:
https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c73
Signed-off-by: Steve Dickson <steved@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
While doing a ranged fsync, that is, one whose range doesn't cover the
whole possible file range (0 to LLONG_MAX), we can crash under certain
circumstances with a trace like the following:
[41074.641913] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
(...)
[41074.642692] CPU: 0 PID: 24580 Comm: fsx Not tainted 3.16.0-fdm-btrfs-next-45+ #1
(...)
[41074.643886] RIP: 0010:[<ffffffffa01ecc99>] [<ffffffffa01ecc99>] btrfs_ordered_update_i_size+0x279/0x2b0 [btrfs]
(...)
[41074.644919] Stack:
(...)
[41074.644919] Call Trace:
[41074.644919] [<ffffffffa01db531>] btrfs_truncate_inode_items+0x3f1/0xa10 [btrfs]
[41074.644919] [<ffffffffa01eb54f>] ? btrfs_get_logged_extents+0x4f/0x80 [btrfs]
[41074.644919] [<ffffffffa02137a9>] btrfs_log_inode+0x2f9/0x970 [btrfs]
[41074.644919] [<ffffffff81090875>] ? sched_clock_local+0x25/0xa0
[41074.644919] [<ffffffff8164a55e>] ? mutex_unlock+0xe/0x10
[41074.644919] [<ffffffff810af51d>] ? trace_hardirqs_on+0xd/0x10
[41074.644919] [<ffffffffa0214b4f>] btrfs_log_inode_parent+0x1ef/0x560 [btrfs]
[41074.644919] [<ffffffff811d0c55>] ? dget_parent+0x5/0x180
[41074.644919] [<ffffffffa0215d11>] btrfs_log_dentry_safe+0x51/0x80 [btrfs]
[41074.644919] [<ffffffffa01e2d1a>] btrfs_sync_file+0x1ba/0x3e0 [btrfs]
[41074.644919] [<ffffffff811eda6b>] vfs_fsync_range+0x1b/0x30
(...)
The necessary conditions that lead to such crash are:
* an incremental fsync (when the inode doesn't have the
BTRFS_INODE_NEEDS_FULL_SYNC flag set) happened for our file and it logged
a file extent item ending at offset X;
* the file got the flag BTRFS_INODE_NEEDS_FULL_SYNC set in its inode, due
to a file truncate operation that reduces the file to a size smaller
than X;
* a ranged fsync call happens (via an msync for example), with a range that
doesn't cover the whole file and the end of this range, lets call it Y, is
smaller than X;
* btrfs_log_inode, sees the flag BTRFS_INODE_NEEDS_FULL_SYNC set and
calls btrfs_truncate_inode_items() to remove all items from the log
tree that are associated with our file;
* btrfs_truncate_inode_items() removes all of the inode's items, and the lowest
file extent item it removed is the one ending at offset X, where X > 0 and
X > Y - before returning, it calls btrfs_ordered_update_i_size() with an offset
parameter set to X;
* btrfs_ordered_update_i_size() sees that X is greater then the current ordered
size (btrfs_inode's disk_i_size) and then it assumes there can't be any ongoing
ordered operation with a range covering the offset X, calling a BUG_ON() if
such ordered operation exists. This assumption is made because the disk_i_size
is only increased after the corresponding file extent item is added to the
btree (btrfs_finish_ordered_io);
* But because our fsync covers only a limited range, such an ordered extent might
exist, and our fsync callback (btrfs_sync_file) doesn't wait for such ordered
extent to finish when calling btrfs_wait_ordered_range();
And then by the time btrfs_ordered_update_i_size() is called, via:
btrfs_sync_file() ->
btrfs_log_dentry_safe() ->
btrfs_log_inode_parent() ->
btrfs_log_inode() ->
btrfs_truncate_inode_items() ->
btrfs_ordered_update_i_size()
We hit the BUG_ON(), which could never happen if the fsync range covered the whole
possible file range (0 to LLONG_MAX), as we would wait for all ordered extents to
finish before calling btrfs_truncate_inode_items().
So just don't call btrfs_ordered_update_i_size() if we're removing the inode's items
from a log tree, which isn't supposed to change the in memory inode's disk_i_size.
Issue found while running xfstests/generic/127 (happens very rarely for me), more
specifically via the fsx calls that use memory mapped IO (and issue msync calls).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
While writing to a file, in inode.c:cow_file_range() (and same applies to
submit_compressed_extents()), after reserving an extent for the file data,
we create a new extent map for the written range and insert it into the
extent map cache. After that, we create an ordered operation, but if it
fails (due to a transient/temporary-ENOMEM), we return without dropping
that extent map, which points to a reserved extent that is freed when we
return. A subsequent incremental fsync (when the btrfs inode doesn't have
the flag BTRFS_INODE_NEEDS_FULL_SYNC) considers this extent map valid and
logs a file extent item based on that extent map, which points to a disk
extent that doesn't contain valid data - it was freed by us earlier, at this
point it might contain any random/garbage data.
Therefore, if we reach an error condition when cowing a file range after
we added the new extent map to the cache, drop it from the cache before
returning.
Some sequence of steps that lead to this:
$ mkfs.btrfs -f /dev/sdd
$ mount -o commit=9999 /dev/sdd /mnt
$ cd /mnt
$ xfs_io -f -c "pwrite -S 0x01 -b 4096 0 4096" -c "fsync" foo
$ xfs_io -c "pwrite -S 0x02 -b 4096 4096 4096"
$ sync
$ od -t x1 foo
0000000 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
*
0010000 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
*
0020000
$ xfs_io -c "pwrite -S 0xa1 -b 4096 0 4096" foo
# Now this write + fsync fail with -ENOMEM, which was returned by
# btrfs_add_ordered_extent() in inode.c:cow_file_range().
$ xfs_io -c "pwrite -S 0xff -b 4096 4096 4096" foo
$ xfs_io -c "fsync" foo
fsync: Cannot allocate memory
# Now do a new write + fsync, which will succeed. Our previous
# -ENOMEM was a transient/temporary error.
$ xfs_io -c "pwrite -S 0xee -b 4096 16384 4096" foo
$ xfs_io -c "fsync" foo
# Our file content (in page cache) is now:
$ od -t x1 foo
0000000 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1
*
0010000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
*
0020000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0040000 ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee
*
0050000
# Now reboot the machine, and mount the fs, so that fsync log replay
# takes place.
# The file content is now weird, in particular the first 8Kb, which
# do not match our data before nor after the sync command above.
$ od -t x1 foo
0000000 ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee
*
0010000 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
*
0020000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0040000 ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee
*
0050000
# In fact these first 4Kb are a duplicate of the last 4kb block.
# The last write got an extent map/file extent item that points to
# the same disk extent that we got in the write+fsync that failed
# with the -ENOMEM error. btrfs-debug-tree and btrfsck allow us to
# verify that:
$ btrfs-debug-tree /dev/sdd
(...)
item 6 key (257 EXTENT_DATA 0) itemoff 15819 itemsize 53
extent data disk byte 12582912 nr 8192
extent data offset 0 nr 8192 ram 8192
item 7 key (257 EXTENT_DATA 8192) itemoff 15766 itemsize 53
extent data disk byte 0 nr 0
extent data offset 0 nr 8192 ram 8192
item 8 key (257 EXTENT_DATA 16384) itemoff 15713 itemsize 53
extent data disk byte 12582912 nr 4096
extent data offset 0 nr 4096 ram 4096
$ umount /dev/sdd
$ btrfsck /dev/sdd
Checking filesystem on /dev/sdd
UUID: db5e60e1-050d-41e6-8c7f-3d742dea5d8f
checking extents
extent item 12582912 has multiple extent items
ref mismatch on [12582912 4096] extent item 1, found 2
Backref bytes do not match extent backref, bytenr=12582912, ref bytes=4096, backref bytes=8192
backpointer mismatch on [12582912 4096]
Errors found in extent allocation tree or chunk allocation
checking free space cache
checking fs roots
root 5 inode 257 errors 1000, some csum missing
found 131074 bytes used err is 1
total csum bytes: 4
total tree bytes: 131072
total fs tree bytes: 32768
total extent tree bytes: 16384
btree space waste bytes: 123404
file data blocks allocated: 274432
referenced 274432
Btrfs v3.14.1-96-gcc7fd5a-dirty
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
It should have been removed with commit d1b6848590
("cpufreq / intel_pstate: Optimize intel_pstate_set_policy")
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Many CPUs do not support complete set of RAPL domains, as a
result this detection failed message is very misleading and
can be annoying.
[ 5.082632] intel_rapl: RAPL domain core detection failed
[ 5.088370] intel_rapl: RAPL domain uncore detection failed
So lower the warning message to info and only print out the RAPL
domains that are supported.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
I've confirmed that monitoring the package power usage as well as setting power
limits appear to be working as expected. Supports the package and dram domains.
Tested aginst cpu:
Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
Signed-off-by: Jason Baron <jbaron@akamai.com>
Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit d431cbc53c (PM / sleep: Simplify sleep states sysfs
interface code) the pm_states[] array is not populated initially,
which causes setup_test_suspend() to always fail and the suspend
testing during boot doesn't work any more.
Fix the problem by using pm_labels[] instead of pm_states[] in
setup_test_suspend() and storing a pointer to the label of the
sleep state to test rather than the number representing it,
because the connection between the state numbers and labels is
only established by suspend_set_ops().
Fixes: d431cbc53c (PM / sleep: Simplify sleep states sysfs interface code)
Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On the Toshiba Tecra Z40, after a suspend-to-disk, some FN hotkeys
driven by toshiba_acpi are not functional.
Calling the ACPI object ENAB on resume makes them back alive.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This is a follow-up patch to commit 49458e8308 ("ideapad-laptop:
Constify DMI table and other r/o variables") to do what its commit
message says. The actual commit differs from the patch posted at
https://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg05340.html
significantly, probably due to a bad merge conflict resolution. Fix up
the mess and constify the DMI table for real and fix the bogus
double-const of ideapad_rfk_data[].
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Ike Panhc <ike.pan@canonical.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Two of the blk-mq based drivers do not pass back the return value
from blk_mq_alloc_tag_set, instead just returning -ENOMEM.
blk_mq_alloc_tag_set returns -EINVAL if the number of queues or
queue depth is bad. -ENOMEM implies that retrying after freeing some
memory might be more successful, but that won't ever change
in the -EINVAL cases.
Change the null_blk and mtip32xx drivers to pass along
the return value.
Signed-off-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
During allocation and initialization of the network driver structures,
the wrong pointer is used to initialize a spin lock. Fix the spin lock
initialization by using the proper pointer.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The user_skb maybe be leaked if the operation on it failed and codes
skipped into the label "out:" without calling genlmsg_unicast.
Cc: Pravin Shelar <pshelar@nicira.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
make defconfig reports:
warning: (NETFILTER_XT_TARGET_LOG) selects NF_LOG_IPV6 which has unmet direct dependencies (NET && INET && IPV6 && NETFILTER && NETFILTER_ADVANCED)
Fixes: d79a61d netfilter: NETFILTER_XT_TARGET_LOG selects NF_LOG_*
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Greg Kroah-Hartman