We hard code cephx auth ticket buffer size to 256 bytes. This isn't
enough for any moderate setups and, in case tickets themselves are not
encrypted, leads to buffer overflows (ceph_x_decrypt() errors out, but
ceph_decode_copy() doesn't - it's just a memcpy() wrapper). Since the
buffer is allocated dynamically anyway, allocated it a bit later, at
the point where we know how much is going to be needed.
Fixes: http://tracker.ceph.com/issues/8979
Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Add a helper for processing individual cephx auth tickets. Needed for
the next commit, which deals with allocating ticket buffers. (Most of
the diff here is whitespace - view with git diff -b).
Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Sage Weil <sage@redhat.com>
We preallocate a few of the message types we get back from the mon. If we
get a larger message than we are expecting, fall back to trying to allocate
a new one instead of blindly using the one we have.
CC: stable@vger.kernel.org
Signed-off-by: Sage Weil <sage@redhat.com>
Reviewed-by: Ilya Dryomov <ilya.dryomov@inktank.com>
When a writeback or a promotion of a block is completed, the cell of
that block is removed from the prison, the block is marked as clean, and
the clear_dirty() callback of the cache policy is called.
Unfortunately, performing those actions in this order allows an incoming
new write bio for that block to come in before clearing the dirty status
is completed and therefore possibly causing one of these two scenarios:
Scenario A:
Thread 1 Thread 2
cell_defer() .
- cell removed from prison .
- detained bios queued .
. incoming write bio
. remapped to cache
. set_dirty() called,
. but block already dirty
. => it does nothing
clear_dirty() .
- block marked clean .
- policy clear_dirty() called .
Result: Block is marked clean even though it is actually dirty. No
writeback will occur.
Scenario B:
Thread 1 Thread 2
cell_defer() .
- cell removed from prison .
- detained bios queued .
clear_dirty() .
- block marked clean .
. incoming write bio
. remapped to cache
. set_dirty() called
. - block marked dirty
. - policy set_dirty() called
- policy clear_dirty() called .
Result: Block is properly marked as dirty, but policy thinks it is clean
and therefore never asks us to writeback it.
This case is visible in "dmsetup status" dirty block count (which
normally decreases to 0 on a quiet device).
Fix these issues by calling clear_dirty() before calling cell_defer().
Incoming bios for that block will then be detained in the cell and
released only after clear_dirty() has completed, so the race will not
occur.
Found by inspecting the code after noticing spurious dirty counts
(scenario B).
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
If we are running in a kdump environment, resources are scarce.
For some SCSI setups with a huge set of shared tags, we run out
of memory allocating what the drivers is asking for. So implement
a scale back logic to reduce the tag depth for those cases, allowing
the driver to successfully load.
We should extend this to detect low memory situations, and implement
a sane fallback for those (1 queue, 64 tags, or something like that).
Tested-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
When RANDOMIZE_BASE (KASLR) is enabled; or the sum of all loaded
modules exceeds 512 MiB, then loading modules fails with a warning
(and hence a vmalloc allocation failure) because the PTEs for the
newly-allocated vmalloc address space are not zero.
WARNING: CPU: 0 PID: 494 at linux/mm/vmalloc.c:128
vmap_page_range_noflush+0x2a1/0x360()
This is caused by xen_setup_kernel_pagetables() copying
level2_kernel_pgt into level2_fixmap_pgt, overwriting many non-present
entries.
Without KASLR, the normal kernel image size only covers the first half
of level2_kernel_pgt and module space starts after that.
L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[ 0..255]->kernel
[256..511]->module
[511]->level2_fixmap_pgt[ 0..505]->module
This allows 512 MiB of of module vmalloc space to be used before
having to use the corrupted level2_fixmap_pgt entries.
With KASLR enabled, the kernel image uses the full PUD range of 1G and
module space starts in the level2_fixmap_pgt. So basically:
L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[0..511]->kernel
[511]->level2_fixmap_pgt[0..505]->module
And now no module vmalloc space can be used without using the corrupt
level2_fixmap_pgt entries.
Fix this by properly converting the level2_fixmap_pgt entries to MFNs,
and setting level1_fixmap_pgt as read-only.
A number of comments were also using the the wrong L3 offset for
level2_kernel_pgt. These have been corrected.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: stable@vger.kernel.org
I am leaving Samsung, so my current e-mail address is not going to work
any longer. Replace it with my private one. In addition, Sylwester
Nawrocki is being added as co-maintainer for Samsung clock drivers to
take some of the responsibilities, as I will be doing my part in my spare
time.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
dpcm_path_get may return -ENOMEM when allocating memory for list
fails. We should not keep processing path or start up dpcm dai in
this case.
Signed-off-by: Qiao Zhou <zhouqiao@marvell.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
These of_node_get() were added to balance refcount decrements inside of
of_find_node_by_name().
See: commit c92f5dd2c4 ("regulator: Add missing of_node_put()")
However of_find_node_by_name() was then replaced by of_get_child_by_name(),
which doesn't call of_node_put() against its input parameter.
So, need to remove these unnecessary of_node_get() calls.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix to return -ENOMEM from the workqueue alloc error handling
case instead of 0, as done elsewhere in this function.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
drivers/block/rbd.c: In function ‘rbd_dev_device_setup’:
drivers/block/rbd.c:5090:19: warning: format not a string literal and no format arguments [-Wformat-security]
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Fix a missing __user annotation in a cast of a user space pointer (found by
checker).
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds missing space between "interface" and "by"
in bonding module parameter description.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linux manpage for recvmsg and sendmsg calls does not explicitly mention setting msg_namelen to 0 when
msg_name passed set as NULL. When developers don't set msg_namelen member in msghdr, it might contain garbage
value which will fail the validation check and sendmsg and recvmsg calls from kernel will return EINVAL. This will
break old binaries and any code for which there is no access to source code.
To fix this, we set msg_namelen to 0 when msg_name is passed as NULL from userland.
Signed-off-by: Ani Sinha <ani@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull cifs/smb3 fixes from Steve French:
"This includes various cifs and smb3 bug fixes including those for bugs
found with the recently updated xfstests.
Also I am working fixes for two additional cifs problems found by
xfstests which I plan to send later (when reviewed and run additional
tests)"
* 'for-next-3.17' of git://git.samba.org/sfrench/cifs-2.6:
Clarify Kconfig help text for CIFS and SMB2/SMB3
CIFS: Fix wrong filename length for SMB2
CIFS: Fix wrong restart readdir for SMB1
CIFS: Fix directory rename error
cifs: No need to send SIGKILL to demux_thread during umount
cifs: Allow directIO read/write during cache=strict
cifs: remove unneeded check of null checking in if condition
cifs: fix a possible use of uninit variable in SMB2_sess_setup
cifs: fix memory leak when password is supplied multiple times
cifs: fix a possible null pointer deref in decode_ascii_ssetup
Trivial whitespace fix
ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of
physical buttons, instead they generate primary button click when user
presses somewhat hard on the surface of the touchpad. Unfortunately they
also report primary button click whenever there are 2 or more contacts
on the pad, messing up all multi-finger gestures (2-finger scrolling,
multi-finger tapping, etc). To cope with this behavior we introduce a
delay (currently 50 msecs) in reporting primary press in case more
contacts appear.
Cc: stable@vger.kernel.org
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When trying to use the matrix-keypad driver with GPIO drivers that
require nested irq handlers (e.g. I2C GPIO adapters like PCA9554),
request_irq() fails because the GPIO driver requires a threaded
interrupt handler.
Use request_any_context_irq() to be able to use any GPIO driver as
keypad driver.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
In the case where the CHG/interrupt line mode is not configured correctly,
this warning is output to dmesg output for each interrupt. Downgrade the
message to debug.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Since commit 54196ccbe0 (of: consolidate linker section OF match table
declarations) which went into 3.16-rc1 the following compiler warning is
generated:
In file included from drivers/clk/clk-efm32gg.c:12:0: include/linux/of.h:772:20:
warning: comparison of distinct pointer types lacks a cast [enabled by default]
.data = (fn == (fn_type)NULL) ? fn : fn }
^
include/linux/of.h:785:3: note: in expansion of macro '_OF_DECLARE'
_OF_DECLARE(table, name, compat, fn, of_init_fn_1)
^
include/linux/clk-provider.h:545:42: note: in expansion of macro 'OF_DECLARE_1'
#define CLK_OF_DECLARE(name, compat, fn) OF_DECLARE_1(clk, name, compat, fn)
^
drivers/clk/clk-efm32gg.c:81:1: note: in expansion of macro 'CLK_OF_DECLARE'
CLK_OF_DECLARE(efm32ggcmu, "efm32gg,cmu", efm32gg_cmu_init);
^
Fix it by making efm32gg_cmu_init return void.
Cc: Rob Herring <robh@kernel.org>
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
In a couple of places the driver is missing a check to ensure there is a
secondary DAI before it de-references the pointer to it, causing a null
pointer de-reference. This patch adds a check to avoid this.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
Johannes Berg <johannes@sipsolutions.net> says:
"Two more fixes for mac80211 - one of them addresses a long-standing
issue that we only found when using vendor events more frequently;
the other addresses some bad information being reported in userspace
that people were starting to actually look at."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pull arch/microblaze fixes from Michal Simek:
- Kconfig menu structure fix
- fix number of syscalls
- fix compilation warnings from allmodconfig
* tag 'microblaze-3.17-rc5' of git://git.monstr.eu/linux-2.6-microblaze:
microblaze: Fix number of syscalls
microblaze: Rename Advance setup to Kernel features
microblaze: Add mm/Kconfig to advance menu
arch/microblaze/include/asm/uaccess.h: Use pr_devel() instead of pr_debug()
arch/microblaze/include/asm/entry.h: Include "linux/linkage.h" to avoid compiling issue
This patch fixes kernel panic/interrupt storm/etc issues if bootloader
left s3c-hsotg module in enabled state. Now interrupt handler is enabled
only after proper configuration of hardware registers.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Cc: stable <stable@vger.kernel.org> # 3.16
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the Generic PHY Framework a NULL phy is considered to be a valid phy
thus the "if (hsotg->phy)" check does not give us the information whether
the Generic PHY Framework is used.
In addition to the above this patch also removes phy_init from probe and
phy_exit from remove. This is not necessary when init/exit is done in the
s3c_hsotg_phy_enable/disable functions.
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Cc: stable <stable@vger.kernel.org> # 3.16
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the driver is removed s3c_hsotg_phy_disable is called three times
instead of once. This results in decreasing of the phy reference counter
below zero and thus consecutive inserts of the module fails.
This patch removes calls to s3c_hsotg_phy_disable from s3c_hsotg_remove
and s3c_hsotg_udc_stop.
s3c_hsotg_udc_stop is called from udc-core.c only after
usb_gadget_disconnect, which in turn calls s3c_hsotg_pullup, which
already calls s3c_hsotg_phy_disable.
s3c_hsotg_remove must be called only after udc_stop, so there is no
point in disabling phy once again there.
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Cc: stable <stable@vger.kernel.org> # 3.16
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a queue is registered, the block layer turns off the bypass
setting (because bypass is enabled when the queue is created). This
doesn't work well for queues that are unregistered and then registered
again; we get a WARNING because of the unbalanced calls to
blk_queue_bypass_end().
This patch fixes the problem by making blk_register_queue() call
blk_queue_bypass_end() only the first time the queue is registered.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Tejun Heo <tj@kernel.org>
CC: James Bottomley <James.Bottomley@HansenPartnership.com>
CC: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Jens Axboe <axboe@fb.com>
On systems with special thermal configurations make sure we make
note of the thermal setup. This is required for proper firmware
configuration on these systems.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Pull EFI fixes from Matt Fleming:
* Fix early boot regression affecting x86 EFI boot stub when loading
initrds above 4GB - Yinghai Lu
* Relocate GOT entries in the x86 EFI boot stub now that we have
symbols with global visibility - Matt Fleming
* fdt memory reservation fix for arm64 - Mark Salter
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There is no need to use hex_dump_to_buffer() since we have a kernel helper to
dump up to 64 bytes just via printk(). In our case the actual size is 15 bytes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit 232de51437 ("ACPI / battery: fix wrong value of
capacity_now reported when fully charged")
There is nothing wrong or unexpected about 'capacity_now' increasing above
the last 'full_charge_capacity' value. Different charging cycles will cause
'full_charge_capacity' to vary, both up and down. Good battery firmwares
will update 'full_charge_capacity' when the current charging cycle is
complete, increasing it if necessary. It might even go above
'design_capacity' on a fresh and healthy battery.
Capping 'capacity_now' to 'full_charge_capacity' is plain wrong, and
printing a warning if this doesn't happen to match the 'design_capacity'
is both annoying and terribly wrong.
This results in bogus warnings on perfectly working systems/firmwares:
[Firmware Bug]: battery: reported current charge level (39800) is higher than reported maximum charge level (39800).
and wrong values being reported for 'capacity_now' and
'full_charge_capacity' after the warning has been triggered.
Fixes: 232de51437 ("ACPI / battery: fix wrong value of capacity_now reported when fully charged")
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This reverts commit d719870b41 ("ACPI / battery: Fix warning message in
acpi_battery_get_state()")
Capping 'capacity_now' to 'full_charge_capacity' is plain wrong. If this
is necessary to work around some buggy firmware, then the workaround needs
protection against being applied to working firmwares.
Good battery firmwares will allow 'capacity_now' to increase above
'full_charge_capacity', and will update the latter when the battery
is fully charged. By capping 'capacity_now' we lose accurate capacity
reporting until charging is complete whenever 'full_charge_capacity'
needs to be increased.
Fixes: d719870b41 ("ACPI / battery: Fix warning message in acpi_battery_get_state()")
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When DYNAMIC_DEBUG enabled, pr_debug() depends on KBUILD_MODNAME which
also depends on the modules number in Makefile. The related information
in "scripts/Makefile.lib" line 94:
# $(modname_flags) #defines KBUILD_MODNAME as the name of the module it will
# end up in (or would, if it gets compiled in)
# Note: Files that end up in two or more modules are compiled without the
# KBUILD_MODNAME definition. The reason is that any made-up name would
# differ in different configs.
For this case, 'radio-si470x-i2c.o' and 'radio-si470x-common.o' are in
one line, so cause compiling issue. And 'uaccess.h' is a common shared
header (not specially for drivers), so use pr_devel() instead of is OK.
The related error with allmodconfig:
CC [M] drivers/media/radio/si470x/radio-si470x-i2c.o
CC [M] drivers/media/radio/si470x/radio-si470x-common.o
In file included from include/linux/printk.h:257:0,
from include/linux/kernel.h:13,
from drivers/media/radio/si470x/radio-si470x.h:29,
from drivers/media/radio/si470x/radio-si470x-common.c:115:
./arch/microblaze/include/asm/uaccess.h: In function 'access_ok':
include/linux/dynamic_debug.h:66:14: error: 'KBUILD_MODNAME' undeclared (first use in this function)
.modname = KBUILD_MODNAME, \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
./arch/microblaze/include/asm/uaccess.h:101:3: note: in expansion of macro 'pr_debug'
pr_debug("ACCESS fail: %s at 0x%08x (size 0x%x), seg 0x%08x\n",
^
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
"entry.h" needs 'asmlinkage', and "asm/linkage.h" does not provide it.
So need include "linux/linkage.h" to use generic one instead of.
The related error (with allmodconfig under microblaze):
CC [M] drivers/net/ethernet/emulex/benet/be_main.o
In file included from ./arch/microblaze/include/asm/processor.h:17:0,
from include/linux/prefetch.h:14,
from drivers/net/ethernet/emulex/benet/be_main.c:18:
./arch/microblaze/include/asm/entry.h:33:19: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
extern asmlinkage void do_notify_resume(struct pt_regs *regs, int in_syscall);
^
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
This patch wires up three new syscalls for powerpc. The three
new syscalls are seccomp, getrandom and memfd_create.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
CONFIG_FHANDLE is a requirement for systemd and with the increasing
uptake of systemd within distros it makes sense for 64 bit defconfigs
to include it.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
As opal_message_init() uses machine_early_initcall(powernv, ), and
opal_hmi_handler_init() depends on that early initcall, so it also needs
use machine_* to check the machine_id.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
ABIv2 kernels are failing to backtrace through the kernel. An example:
39.30% readseek2_proce [kernel.kallsyms] [k] find_get_entry
|
--- find_get_entry
__GI___libc_read
The problem is in valid_next_sp() where we check that the new stack
pointer is at least STACK_FRAME_OVERHEAD below the previous one.
ABIv1 has a minimum stack frame size of 112 bytes consisting of 48 bytes
and 64 bytes of parameter save area. ABIv2 changes that to 32 bytes
with no paramter save area.
STACK_FRAME_OVERHEAD is in theory the minimum stack frame size,
but we over 240 uses of it, some of which assume that it includes
space for the parameter area.
We need to work through all our stack defines and rationalise them
but let's fix perf now by creating STACK_FRAME_MIN_SIZE and using
in valid_next_sp(). This fixes the issue:
30.64% readseek2_proce [kernel.kallsyms] [k] find_get_entry
|
--- find_get_entry
pagecache_get_page
generic_file_read_iter
new_sync_read
vfs_read
sys_read
syscall_exit
__GI___libc_read
Cc: stable@vger.kernel.org # 3.16+
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Commit 86c8b27a01:
"arm64: ignore DT memreserve entries when booting in UEFI mode
prevents early_init_fdt_scan_reserved_mem() from being called for
arm64 kernels booting via UEFI. This was done because the kernel
will use the UEFI memory map to determine reserved memory regions.
That approach has problems in that early_init_fdt_scan_reserved_mem()
also reserves the FDT itself and any node-specific reserved memory.
By chance of some kernel configs, the FDT may be overwritten before
it can be unflattened and the kernel will fail to boot. More subtle
problems will result if the FDT has node specific reserved memory
which is not really reserved.
This patch has the UEFI stub remove the memory reserve map entries
from the FDT as it does with the memory nodes. This allows
early_init_fdt_scan_reserved_mem() to be called unconditionally
so that the other needed reservations are made.
Signed-off-by: Mark Salter <msalter@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
