We should just return directly if memdup_user() fails. The current code
tries to free "param" which is an error pointer so it will Oops.
Fixes: 2baddf262e ("staging: lustre: use memdup_user to allocate memory and copy from user")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ksnc_rx_iov_space is currently a union of two arrays,
one of 'struct kvec', the other of 'struct bio_vec'.
The 'struct bio_vec' option is never used. The
array of kvec is used to read in a packet header, or
to read data that needs to be skipped so as to synchronize
with a packet boundary.
In each case the target memory location is a virtual address,
never a page, so 'struct bio_vec' is never needed.
When we read into a page, different code steps up a separate
array of 'struct bio_vec'.
So remove the bio_vec option, and remove the union ksock_rxiovspace..
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When fid fetches a new range from the server, it commits
to it (*output = *out) *before* performing sanity checks.
This looks backwards.
Don't commit to a value until it has been found to be sane.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
lcs_space can change while the lock is not held
if an RPC in underway. This can be detected by
seq->ls_update being set.
In this case, reading or writing the value should return
-EBUSY.
Also, the D_INFO CDEBUG() which reports the lcs_space being
updated never fires, as it tests the wrong value -
ldebugfs_fid_write_common() returns 'count' on success.
Finally, this return value should be returned from
ldebugfs_fid_space_seq_write(), rather than always returning 'count',
so that errors can be detected.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
seq_fid_alloc_fini() is tiny and only called
from two places in the one function. We can move
both those calls earlier and merge them so only
one call is needed. At that point, there is no
value added by having a separate function.
Also instead of using ++ and -- on ->lcs_update to
toggle between 0 and 1, explicitly set to 0 or 1
as appropriate.
Moving the locking earlier means that the code which updates
seq->lcs_fid is now protected, so
ldebugfs_fid_fid_seq_show() now cannot see a torn value.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rather than open-coding a wait event loop twice,
use wait_event_cmd() to wait, dropping the spinlock
over schedule().
This does require duplicating part of the wait
condition, but that is just three tests on values that
are in registers or in cache, so the cost is small
and the increased readability is large.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is only one place where this lock is held
while the task might sleep - in
ldebugfs_fid_space_seq_write()
while ldebugfs_fid_write_common() is called.
This call can easily be taken out of the locked region
by asking it to parse the user data into a local variable,
and then copying that variable into ->lcs_space while
holding the lock.
Note that ldebugfs_gid_write_common returns >0 on
success, so use that to gate updating ->lcs_space.
So make that change, and convert lcs_mutex to a spinlock
named lcs_lock. spinlocks are slightly cheaper than mutexes
and using one makes is clear that the lock is only held for
a short time.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1/ use list_for_each_entry_safe() instead of
list_for_each_safe() and similar.
2/ use list_first_entry() and list_last_entry() where appropriate.
3/ When removing everything from a list, use
while ((x = list_first_entry_or_null()) {
as it makes the intent clear
4/ No need to take a spinlock in a structure that is about
to be freed - we must have exclusive access at this stage.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Possibly the most interesting is the for-loop with no body.
Rearranging and initializing end_dirent on each iteration of
the outer while, makes the intent clearer.
Reviewed-by: "Eremin, Dmitry" <dmitry.eremin@intel.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no "struct cfs_crypto_hash_desc" structure. There
are only pointers to this structure, which are cast back and
forth to struct ahash_request.
So discard cfs_crypto_hash_desc, and just use ahash_request directly.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The only interesting difference between libcfs_kvzalloc()
and kvzalloc() is that the former appears to work
with GFP_NOFS, which the latter gives a WARN_ON_ONCE()
when that is attempted.
Each libcfs_kvzalloc() should really be analysed
and either converted to a kzalloc() call if the size is never
more than a page, or to use GFP_KERNEL if no locks are held.
If there is ever a case where locks are held and a large allocation
is needed, then some other technique should be used.
It might be nice to not always blindly zero pages too...
For now, just convert libcfs_kvzalloc() calls to
kvzalloc(), and let the warning remind us that there is work to do.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using vmalloc with GFP_NOFS is not supported as vmalloc
performs some internal allocations with GFP_KERNEL.
So in cases where the size passed to libcfs_kvzalloc()
is clearly at most 1 page, convert to kzalloc().
In cases where the call clearly doesn't hold any
filesystem locks, convert to GFP_KERNEL.
Unfortunately there are many more that are not easy to fix.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This library code is unnecessarily generic, but also
not generic enough. Library code that performs
allocations should always take a gfp_flags argument.
So discard the library and in the one file where it is used,
just use kzalloc or krealloc as needed.
In this context, it is clear that vmalloc is never needed.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This function is used precisely once, and is sufficiently
trivial that it may as well be open-coded.
Doing so helpfully highlights the similarity
between the new kvzalloc_node() call and the already existing
kzalloc_node() call in the same function.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cfs_block_sigsinv() and cfs_restore_sigs() are now
simple enough to inline them.
This means we can discard linux-prim.c
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
According to comment for set_current_blocked() in
kernel/signal.c, changing ->blocked directly is wrong.
sigprocmask() should be called instead.
So change cfs_block_sigsinv() and cfs_restore_sigs()
to use sigprocmask().
For consistency, change them to pass the sigset_t by reference
rather than by value.
Also fix cfs_block_sigsinv() so that it correctly blocks
signals above 32 on a 32bit host.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cfs_block_sigs() is never used.
cfs_clear_sigpending() is never used.
cfs_block_allsigs() is no longer used.
So those three functions can go.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Both places that cfs_block_allsigs() is used here,
the goal is to turn an interruptible wait into an
uninterruptible way.
So instead of blocking the signals, change TASK_INTERRUPTIBLE to
TASK_NOLOAD.
In each case, no other functions called while signals are blocked
will sleep - just the one that has been fixed.
In one case, an extra 'interruptible' flag needs to be passed
down so the waiting decision can be made at the right place.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Threads started by kthread_run() ignore all signals,
as kthreadd() calls ignore_signals(), and this is
inherited by all children.
So there is no need to call cfs_block_allsigs() in functions
that are only run from kthread_run().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The only functionality remaining here is
cfs_curproc_cap_pack(),
and it can be trivially implemented as an inline
in curproc.h.
So do that and remove the file.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Each of these functions is used precisely once, so having
a separate exported function seems like overkill.
cfs_cap_raised() is trivial - one line.
cfs_cap_raise() and cfs_cap_lower() are used as a pair
which is more effectively implemented with
override_cred() / revert_creds().
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lustre defines a few CFS_CAP_* macros which are exactly the
same as the corresponding CAP_* macro, with one exception.
CFS_CAP_SYS_BOOT is 23
CAP_SYS_BOOT is 22.
CFS_CAP_SYS_BOOT is only used through CFS_CAP_FS_MASK and
causes capability 23 (CAP_SYS_NICE) to be dropped in certain
circumstances.
It is probable that the intention was to drop CAP_SYS_BOOT,
and this is what is now done.
CFS_CAP_CHOWN_MASK and CFS_CAP_SYS_RESOURCE_MASK are never
used, so they have been removed.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix Coccinelle alert:
drivers/staging//rtl8188eu/os_dep/usb_intf.c:336:13-27: WARNING: casting value returned by memory allocation function to (struct adapter *) is useless.
This issue was detected by using the Coccinelle software.
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix Coccinelle alert:
drivers/staging//emxx_udc/emxx_udc.c:2689:19-21: WARNING: casting value returned by memory allocation function to (u8 *) is useless.
This issue was detected by using the Coccinelle software.
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix Coccinelle alert:
drivers/staging//rtl8723bs/os_dep/sdio_intf.c:340:13-27: WARNING: casting value returned by memory allocation function to (struct adapter *) is useless.
This issue was detected by using the Coccinelle software.
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix Coccinelle alert:
drivers/staging//netlogic/xlr_net.c:996:12-30: WARNING: casting value returned by memory allocation function to (struct xlr_adapter *) is useless.
This issue was detected by using the Coccinelle software.
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove 'if' statements testing struct's field address.
Since such statements always return true, they are redundant.
Signed-off-by: Dafna Hirschfeld <dafna3@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace all occurrences of functions' names in strings by a reference
to __func__, to improve robustness. Problem found with checkpatch.
Signed-off-by: Eisha Chen-yen-su <chenyensu0@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove a "tracing" call as it is not needed anymore
because there is an in-kernel function for that.
Signed-off-by: Eisha Chen-yen-su <chenyensu0@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We will go on initial idev if failed to create debug_root, and it does
not matter to check the return value of this debugfs call, just remove it.
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There's no need to check the return value of debug_file for it is just a
debugfs and we will go on the following process if we failed to create
debug_file. So just remove it.
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ioremap_page_range doesn't honour break-before-make and attempts to put
down huge mappings (using p*d_set_huge) over the top of pre-existing
table entries. This leads to us leaking page table memory and also gives
rise to TLB conflicts and spurious aborts, which have been seen in
practice on Cortex-A75.
Until this has been resolved, refuse to put block mappings when the
existing entry is found to be present.
Fixes: 324420bf91 ("arm64: add support for ioremap() block mappings")
Reported-by: Hanjun Guo <hanjun.guo@linaro.org>
Reported-by: Lei Li <lious.lilei@hisilicon.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
GPIO library can return -ENOSYS for the failed request.
Instead of failing ->probe() in this case override error code to 0.
Fixes: ca382f5b38 ("i2c: designware: add i2c gpio recovery option")
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
We were leaving them in the power on state (or the state the firmware
had set up for some client, if we were taking over from them). The
boot state was 30 core clocks, when we actually want to sample some
time after (to make sure that the new input bit has actually arrived).
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
On lkml suggestions were made to split up such trivial typo fixes into per subsystem
patches:
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -439,7 +439,7 @@ setup_uga32(void **uga_handle, unsigned long size, u32 *width, u32 *height)
struct efi_uga_draw_protocol *uga = NULL, *first_uga;
efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
unsigned long nr_ugas;
- u32 *handles = (u32 *)uga_handle;;
+ u32 *handles = (u32 *)uga_handle;
efi_status_t status = EFI_INVALID_PARAMETER;
int i;
This patch is the result of the following script:
$ sed -i 's/;;$/;/g' $(git grep -E ';;$' | grep "\.[ch]:" | grep -vwE 'for|ia64' | cut -d: -f1 | sort | uniq)
... followed by manual review to make sure it's all good.
Splitting this up is just crazy talk, let's get over with this and just do it.
Reported-by: Pavel Machek <pavel@ucw.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
I am using SECCOMP to filter syscalls on a ppc32 platform, and noticed
that the JIT compiler was failing on the BPF even though the
interpreter was working fine.
The issue was that the compiler was missing one of the instructions
used by SECCOMP, so here is a patch to enable JIT for that
instruction.
Fixes: eb84bab0fb ("ppc: Kconfig: Enable BPF JIT on ppc32")
Signed-off-by: Mark Lord <mlord@pobox.com>
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
This reverts commit 02ef6dd810.
The earlier patch tried to enable support for a new property
"ibm,drc-info" on powerpc systems.
Unfortunately, some errors in the associated patch set break things
in some of the DLPAR operations. In particular when attempting to
hot-add a new CPU or set of CPUs, the original patch failed to
properly calculate the available resources, and aborted the operation.
In addition, the original set missed several opportunities to compress
and reuse common code.
As the associated patch set was meant to provide an optimization of
storage and performance of a set of device-tree properties for future
systems with large amounts of resources, reverting just restores
the previous behavior for existing systems. It seems unnecessary
to enable this feature and introduce the consequent problems in the
field that it will cause at this time, so please revert it for now
until testing of the corrections are finished properly.
Fixes: 02ef6dd810 ("powerpc: Enable support for ibm,drc-info devtree property")
Signed-off-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
We had a mid-air collision between two new firmware features, DRMEM_V2
and DRC_INFO, and they ended up with the same value.
No one's actually reported any problems, presumably because the new
firmware that supports both properties is not widely available, and
the two properties tend to be enabled together.
Still if we ever had one enabled but not the other, the bugs that
could result are many and varied. So fix it.
Fixes: 3f38000eda ("powerpc/firmware: Add definitions for new drc-info firmware feature")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Let's test that we get the flags correctly, and that we preserve the filter
index across the ptrace(PTRACE_SECCOMP_GET_METADATA) correctly.
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
CC: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Previously if users passed a small size for the input structure size, they
would get get odd behavior. It doesn't make sense to pass a structure
smaller than at least filter_off size, so let's just give -EINVAL in this
case.
This changes userspace visible behavior, but was only introduced in commit
26500475ac ("ptrace, seccomp: add support for retrieving seccomp
metadata") in 4.16-rc2, so should be safe to change if merged before then.
Reported-by: Eugene Syromiatnikov <esyr@redhat.com>
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
CC: Kees Cook <keescook@chromium.org>
CC: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Commit 26500475ac ("ptrace, seccomp: add support for retrieving seccomp
metadata") introduced `struct seccomp_metadata`, which contained unsigned
longs that should be arch independent. The type of the flags member was
chosen to match the corresponding argument to seccomp(), and so we need
something at least as big as unsigned long. My understanding is that __u64
should fit the bill, so let's switch both types to that.
While this is userspace facing, it was only introduced in 4.16-rc2, and so
should be safe assuming it goes in before then.
Reported-by: "Dmitry V. Levin" <ldv@altlinux.org>
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
CC: Kees Cook <keescook@chromium.org>
CC: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: "Dmitry V. Levin" <ldv@altlinux.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Ajay Singh