- 06 Apr, 2016 40 commits
-
-
Quinn Tran authored
BugLink: http://bugs.launchpad.net/bugs/1552332Signed-off-by: Quinn Tran <quinn.tran@qlogic.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com> Fixes: fb3269ba ("qla2xxx: Add selective command queuing") Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> (back ported from commit 9095adaa) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Conflicts: include/target/target_core_base.h
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1552314Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Tim Gardner authored
Ignore: yes Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Tim Gardner authored
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Jann Horn authored
BugLink: http://bugs.launchpad.net/bugs/1551894 It looks like smack and yama weren't aware that the ptrace mode can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch, all modes have flags ORed into them. Signed-off-by: Jann Horn <jann@thejh.net> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 3dfb7d8c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Dan Streetman authored
BugLink: http://bugs.launchpad.net/bugs/1545330 Move the __ARCH_SPIN_LOCK_UNLOCKED definition from qspinlock.h into qspinlock_types.h. The definition of __ARCH_SPIN_LOCK_UNLOCKED comes from the build arch's include files; but on x86 when CONFIG_QUEUED_SPINLOCKS=y, it just it's defined in asm-generic/qspinlock.h. In most cases, this doesn't matter because linux/spinlock.h includes asm/spinlock.h, which for x86 includes asm-generic/qspinlock.h. However, any code that only includes linux/mutex.h will break, because it only includes asm/spinlock_types.h. For example, this breaks systemtap, which only includes mutex.h. Signed-off-by: Dan Streetman <dan.streetman@canonical.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Waiman Long <Waiman.Long@hpe.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dan Streetman <ddstreet@ieee.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1455907767-17821-1-git-send-email-dan.streetman@canonical.comSigned-off-by: Ingo Molnar <mingo@kernel.org> (cherry-picked from commit b82e5302 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Tejun Heo authored
copy_cgroup_ns()'s error handling was broken and the attempt to fix it d2202557 ("cgroup: fix alloc_cgroup_ns() error handling in copy_cgroup_ns()") was broken too in that it ended up trying an ERR_PTR() value. There's only one place where copy_cgroup_ns() needs to perform cleanup after failure. Simplify and fix the error handling by removing the goto's. (Ported from upstream patch for linux-next - Serge) Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1520454 SDHCI has built-in DMA called ADMA2. ADMA2 uses a descriptor table to define DMA scatter-gather. Each desciptor can specify a data length up to 65536 bytes, however the length field is only 16-bits so zero means 65536. Consequently, putting zero when the size is zero must not be allowed. This patch fixes one case where zero data length could be set inadvertently. The problem happens because unaligned data gets split and the code did not consider that the remaining aligned portion might be zero length. That case really only happens for SDIO because SD and eMMC cards transfer blocks that are invariably sector- aligned. For SDIO, access to function registers is done by data transfer (CMD53) when the register is bigger than 1 byte. Generally registers are 4 bytes but 2-byte registers are possible. So DMA of 4 bytes or less can happen. When 32-bit DMA is used, the data alignment must be 4, so 4-byte transfers won't casue a problem, but a 2-byte transfer could. However with the introduction of 64-bit DMA, the data alignment for 64-bit DMA was made 8 bytes, so all 4-byte transfers not on 8-byte boundaries get "split" into a 4-byte chunk and a 0-byte chunk, thereby hitting the bug. In fact, a closer look at the SDHCI specs indicates that only the descriptor table requires 8-byte alignment for 64-bit DMA. That will be dealt with in a separate patch, but the potential for a 2-byte access remains, so this fix is needed anyway. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> (cherry picked from commit 347ea32d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1520454 The version 3.00 SDHCI spec. was a bit unclear about the required data alignment for 64-bit DMA, whereas the version 4.10 spec. uses different language and indicates that only 4-byte alignment is required rather than the 8-byte alignment currently implemented. That make no difference to SD and EMMC which invariably transfer data in sector-aligned blocks. However with SDIO, it results in using more DMA descriptors than necessary. Theoretically that slows DMA slightly although DMA is not the limiting factor for throughput, so there is no discernable impact on performance. Nevertheless, the driver should follw the spec unless there is good reason not to, so this patch corrects the alignment criterion. There is a more complicated criterion for the DMA descriptor table itself. However the table is allocated by dma_alloc_coherent() which allocates pages (i.e. aligned to a page boundary). For simplicity just check it is 8-byte aligned, but add a comment that some Intel controllers actually require 8-byte alignment even when using 32-bit DMA. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> (cherry picked from commit 04a5ae6f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Tim Gardner authored
Ignore: yes Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Tim Gardner authored
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Andy Whitcroft authored
Signed-off-by: Andy Whitcroft <apw@canonical.com>
-
Andy Whitcroft authored
Signed-off-by: Andy Whitcroft <apw@canonical.com>
-
Andy Whitcroft authored
Signed-off-by: Andy Whitcroft <apw@canonical.com>
-
John Johansen authored
label_merge_insert - requires that a replacedby exists on either the existing in tree label or on the label attempting to be added. If we get into a situation where the in tree label is replacedby and the replacedby doesn't exists an oops will occur. Unfortunately we can not know if the intree label was created with or without a replacedby so, we always have to create the replacedby. Instead Make sure this is so be tying to the label_allocation. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
The old label needs to be removed, so call label_remove on it. This is only needed by the inv path but that path shares code and removing won't hurt the non-inv path. Also the proxy redirect needs to be done at the insert or after to make sure the redirect target is correct. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
This also adds auditing of the targets name for Denials due to ptrace restrictions. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
When finding a child profile via an rcu critical section, the profile may be put and scheduled for deletion after the child is found but before its refcount is incremented. Protect against this by repeating the lookup if the profiles refcount is 0 and is one its way to deletion. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
aa_label_remove needs to take the ls write lock but, we are already holding it so move to __aa_label_remove also fix bug where the old label is not being forwarded to the new label when it results in a new namespace due to an the old ns being removed. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1482943 apparmor use kern_path() to lookup the path of the dev_name, and when this fails apparmor emits a DENIED log message. However for bind and move mounts the underlying code does a call to kern_path() regardless of apparmor being present and so has the same failure. In these cases when kern_path() fails apparmor is not responsible for the mount failure as the kernel will fail the mount regarless of apparmor's presence, so just return the error and don't log an apparmor audit message. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
fixup of [20/23] apparmor: Fix: refcount bug when inserting label update that transitions ns may want to split into 2 patches Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
File permissions have not been updated to use the newer compute_perms fn yet. So export the fn to compute the file permissions and use it in query_label until file permissions have been converted. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Double calling remove on a label does a double update of the replacedby which is extra work and messes up tracking stats. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
There are a few cases when racing an update where a label can be allocated with its replacedby, and end up being freed directly because it lost the race and will not be used. However without breaking the circular ref between the label and its replacedby, a double free of the label will occur: label being freed ref count from label to replacedby is put, ref count from replacedby is put label is scheduled to be freed replacedby is freed label is freed rcu call back to free label triggers label is freed again Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
We already have a refcount on l, and aa_label_insert() returns another refcount so we need to make sure to put the extra one. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
UBUNTU: SAUCE: apparmor: Fix: now that insert can force replacement use it instead of remove_and_insert Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
pivotroot medition may change the tasks current cred if the a transition rule is defined. However aa_begin_current_label(), and aa_end_current_label() define a critical section block where the tasks cred label are not allowed to be updated. Specifically they do not take a refcount on the tasks cred, but will return a refcounted label IF there is an updated version of the label that can not be immediately updated. The aa_end_current_label() fn detects whether the label used has a refcount to put by comparing the label to the task's cred label, and if its different putting label. When the task cred's label is changed within this critical section, the cred update will put the creds label reference, and then the aa_begin_current_label() fn will detect the difference in the cred and working label and subsequentially do an extra put on the label. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
don't put the reference when sharing a replacedby until after all over references are gotten, otherwise the label might drop to a 0 refcount and start being freed, even though it should be held by the shared replacedby. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 The allocation of a replacedby in the label merge path needs to be done using GFP_ATOMIC. specifically aa_label_merge() is called from a context in file.c that passes GFP_ATOMIC to aa_label_merge() which then is doing GFP_KERNEL for the replacedby allocation. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 replacedby updates must be able to occur when in an rcu critical sections, and when spin locks are held. As such it can not use a mutex lock to protect its critical section. Since replacedby updates are accompanied by labelset insertion and removals use the labelset write lock to protect the update critical section. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 __aa_update_replacedby needs the ns lock held, this is done for profile load/replace/remove case and the label_update case but not when called from the label merge paths. NOTE: this is just a conceptal "fix", it can not be validly used as label_merge is called from atomic context and taking a mutex_lock may sleep. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 When aa_put_label() is called from a fn that is holding the labelset lock, it can result in a deadlock if the put count reaches 0 triggering the kref callback, which tries to take the label set lock. Rework so the label_kref callback deferrs removing the label from the labelset until the rcu callback, ensuring the lock is not held by the calling code. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 label_vec_merge should only do the insertion after the vector is copied. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 Basic profile labels always have a replacedby allocated and set but the code used to create labels from merges without a replacedby and let label_update allocate and set those labels replacedby structs. While the label_merge fix addressed the race between label_merge and label_update, it still left a bug where labels from merges race label_update so that they remain permanently stale, because they don't have proper replacedby information that should be updated during their replacement. Specifically a label from a merge will not have a replacedby if it has never been through a label_update cycle, and the direct replacement from the label_merge fix is NOT updating the replacedby to avoid doing allocations under lock. This results in the old label being permanently diconnected and its references never updating correctly. To fix this create all labels that result from a merge with a replacedby. This results in all labels inserted into the labelset having valid replacedby structs. In the case that the insertion of a label results in a replacement due to it creating an updated version of the label, the old labels replacedby will be reused and the new one can be freed. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-