| Age | Commit message (Collapse) | Author |
|---|
|
Gianluca Borello says:
====================
This set includes some fixes in semantics and usability issues that emerged
recently, and would be good to have them in net before the next release.
In particular, ARG_CONST_SIZE_OR_ZERO semantics was recently changed in
commit 9fd29c08e520 ("bpf: improve verifier ARG_CONST_SIZE_OR_ZERO
semantics") with the goal of letting the compiler generate simpler code
that the verifier can more easily accept.
To handle this change in semantics, a few checks in some helpers were
added, like in commit 9c019e2bc4b2 ("bpf: change helper bpf_probe_read arg2
type to ARG_CONST_SIZE_OR_ZERO"), and those checks are less than ideal
because once they make it into a released kernel bpf programs can start
relying on them, preventing the possibility of being removed later on.
This patch tries to fix the issue by introducing a new argument type
ARG_PTR_TO_MEM_OR_NULL that can be used for helpers that can receive a
<NULL, 0> tuple. By doing so, we can fix the semantics of the other helpers
that don't need <NULL, 0> and can just handle <!NULL, 0>, allowing the code
to get rid of those checks.
====================
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
|
Commit 9fd29c08e520 ("bpf: improve verifier ARG_CONST_SIZE_OR_ZERO
semantics") relaxed the treatment of ARG_CONST_SIZE_OR_ZERO due to the way
the compiler generates optimized BPF code when checking boundaries of an
argument from C code. A typical example of this optimized code can be
generated using the bpf_perf_event_output helper when operating on variable
memory:
/* len is a generic scalar */
if (len > 0 && len <= 0x7fff)
bpf_perf_event_output(ctx, &perf_map, 0, buf, len);
110: (79) r5 = *(u64 *)(r10 -40)
111: (bf) r1 = r5
112: (07) r1 += -1
113: (25) if r1 > 0x7ffe goto pc+6
114: (bf) r1 = r6
115: (18) r2 = 0xffff94e5f166c200
117: (b7) r3 = 0
118: (bf) r4 = r7
119: (85) call bpf_perf_event_output#25
R5 min value is negative, either use unsigned or 'var &= const'
With this code, the verifier loses track of the variable.
Replacing arg5 with ARG_CONST_SIZE_OR_ZERO is thus desirable since it
avoids this quite common case which leads to usability issues, and the
compiler generates code that the verifier can more easily test:
if (len <= 0x7fff)
bpf_perf_event_output(ctx, &perf_map, 0, buf, len);
or
bpf_perf_event_output(ctx, &perf_map, 0, buf, len & 0x7fff);
No changes to the bpf_perf_event_output helper are necessary since it can
handle a case where size is 0, and an empty frame is pushed.
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Gianluca Borello <g.borello@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
|
Commit 9fd29c08e520 ("bpf: improve verifier ARG_CONST_SIZE_OR_ZERO
semantics") relaxed the treatment of ARG_CONST_SIZE_OR_ZERO due to the way
the compiler generates optimized BPF code when checking boundaries of an
argument from C code. A typical example of this optimized code can be
generated using the bpf_probe_read_str helper when operating on variable
memory:
/* len is a generic scalar */
if (len > 0 && len <= 0x7fff)
bpf_probe_read_str(p, len, s);
251: (79) r1 = *(u64 *)(r10 -88)
252: (07) r1 += -1
253: (25) if r1 > 0x7ffe goto pc-42
254: (bf) r1 = r7
255: (79) r2 = *(u64 *)(r10 -88)
256: (bf) r8 = r4
257: (85) call bpf_probe_read_str#45
R2 min value is negative, either use unsigned or 'var &= const'
With this code, the verifier loses track of the variable.
Replacing arg2 with ARG_CONST_SIZE_OR_ZERO is thus desirable since it
avoids this quite common case which leads to usability issues, and the
compiler generates code that the verifier can more easily test:
if (len <= 0x7fff)
bpf_probe_read_str(p, len, s);
or
bpf_probe_read_str(p, len & 0x7fff, s);
No changes to the bpf_probe_read_str helper are necessary since
strncpy_from_unsafe itself immediately returns if the size passed is 0.
Signed-off-by: Gianluca Borello <g.borello@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
|
Commit 9c019e2bc4b2 ("bpf: change helper bpf_probe_read arg2 type to
ARG_CONST_SIZE_OR_ZERO") changed arg2 type to ARG_CONST_SIZE_OR_ZERO to
simplify writing bpf programs by taking advantage of the new semantics
introduced for ARG_CONST_SIZE_OR_ZERO which allows <!NULL, 0> arguments.
In order to prevent the helper from actually passing a NULL pointer to
probe_kernel_read, which can happen when <NULL, 0> is passed to the helper,
the commit also introduced an explicit check against size == 0.
After the recent introduction of the ARG_PTR_TO_MEM_OR_NULL type,
bpf_probe_read can not receive a pair of <NULL, 0> arguments anymore, thus
the check is not needed anymore and can be removed, since probe_kernel_read
can correctly handle a <!NULL, 0> call. This also fixes the semantics of
the helper before it gets officially released and bpf programs start
relying on this check.
Fixes: 9c019e2bc4b2 ("bpf: change helper bpf_probe_read arg2 type to ARG_CONST_SIZE_OR_ZERO")
Signed-off-by: Gianluca Borello <g.borello@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
|
With the current ARG_PTR_TO_MEM/ARG_PTR_TO_UNINIT_MEM semantics, an helper
argument can be NULL when the next argument type is ARG_CONST_SIZE_OR_ZERO
and the verifier can prove the value of this next argument is 0. However,
most helpers are just interested in handling <!NULL, 0>, so forcing them to
deal with <NULL, 0> makes the implementation of those helpers more
complicated for no apparent benefits, requiring them to explicitly handle
those corner cases with checks that bpf programs could start relying upon,
preventing the possibility of removing them later.
Solve this by making ARG_PTR_TO_MEM/ARG_PTR_TO_UNINIT_MEM never accept NULL
even when ARG_CONST_SIZE_OR_ZERO is set, and introduce a new argument type
ARG_PTR_TO_MEM_OR_NULL to explicitly deal with the NULL case.
Currently, the only helper that needs this is bpf_csum_diff_proto(), so
change arg1 and arg3 to this new type as well.
Also add a new battery of tests that explicitly test the
!ARG_PTR_TO_MEM_OR_NULL combination: all the current ones testing the
various <NULL, 0> variations are focused on bpf_csum_diff, so cover also
other helpers.
Signed-off-by: Gianluca Borello <g.borello@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
|
The previous fix for addressing the breakage in vmaster slave
initialization, commit a91d66129fb9 ("ALSA: hda - Fix incorrect TLV
callback check introduced during set_fs() removal"), introduced a new
helper to process over each slave kctl. However, this helper passes
only the original kctl, not the virtual slave kctl. As a result,
HD-audio driver (which is the only user so far) couldn't initialize
the slave correctly because it's trying to update the value directly
with the original kctl, not with the mapped kctl.
This patch fixes the situation again by passing both the mapped slaved
and original slave kctls to the function. Luckily there is a single
caller as of now, so changing the call signature is no big matter.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197959
Fixes: a91d66129fb9 ("ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The original issue being fixed in this patch was seen with the ixgbe
driver, but the same issue exists with i40evf as well, as the code is
very similar. read_barrier_depends is not sufficient to ensure
loads following it are not speculatively loaded out of order
by the CPU, which can result in stale data being loaded, causing
potential system crashes.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The original issue being fixed in this patch was seen with the ixgbe
driver, but the same issue exists with fm10k as well, as the code is
very similar. read_barrier_depends is not sufficient to ensure
loads following it are not speculatively loaded out of order
by the CPU, which can result in stale data being loaded, causing
potential system crashes.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The original issue being fixed in this patch was seen with the ixgbe
driver, but the same issue exists with igb as well, as the code is
very similar. read_barrier_depends is not sufficient to ensure
loads following it are not speculatively loaded out of order
by the CPU, which can result in stale data being loaded, causing
potential system crashes.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The original issue being fixed in this patch was seen with the ixgbe
driver, but the same issue exists with igbvf as well, as the code is
very similar. read_barrier_depends is not sufficient to ensure
loads following it are not speculatively loaded out of order
by the CPU, which can result in stale data being loaded, causing
potential system crashes.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The original issue being fixed in this patch was seen with the ixgbe
driver, but the same issue exists with ixgbevf as well, as the code is
very similar. read_barrier_depends is not sufficient to ensure
loads following it are not speculatively loaded out of order
by the CPU, which can result in stale data being loaded, causing
potential system crashes.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The original issue being fixed in this patch was seen with the ixgbe
driver, but the same issue exists with i40e as well, as the code is
very similar. read_barrier_depends is not sufficient to ensure
loads following it are not speculatively loaded out of order
by the CPU, which can result in stale data being loaded, causing
potential system crashes.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This patch fixes an issue seen on Power systems with ixgbe which results
in skb list corruption and an eventual kernel oops. The following is what
was observed:
CPU 1 CPU2
============================ ============================
1: ixgbe_xmit_frame_ring ixgbe_clean_tx_irq
2: first->skb = skb eop_desc = tx_buffer->next_to_watch
3: ixgbe_tx_map read_barrier_depends()
4: wmb check adapter written status bit
5: first->next_to_watch = tx_desc napi_consume_skb(tx_buffer->skb ..);
6: writel(i, tx_ring->tail);
The read_barrier_depends is insufficient to ensure that tx_buffer->skb does not
get loaded prior to tx_buffer->next_to_watch, which then results in loading
a stale skb pointer. This patch replaces the read_barrier_depends with
smp_rmb to ensure loads are ordered with respect to the load of
tx_buffer->next_to_watch.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
After a reset we rebuild the VSIs which is going to clobber any
promiscuous settings we had before reset. This makes it so that we
restore the promiscuous settings we had before reset.
Signed-off-by: Alan Brady <alan.brady@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The current method for notifying clients of l2 parameters is broken
because we fail to copy the new parameters to the client instance
struct, we need to do the notification before the client 'open' function
pointer gets called, and lastly we should set the l2 parameters when
first adding a client instance.
This patch first introduces the i40evf_client_get_params function to
prevent code duplication in the i40evf_client_add_instance and the
i40evf_notify_client_l2_params functions. We then fix the notify l2
params function to actually copy the parameters to client instance
struct and do the same in the *_add_instance' function. Lastly this
patch reorganizes the priority in which client tasks fire so that if the
flag for notifying l2 params is set, it will trigger before the open
because the client needs these new parameters as part of a client open
task.
Signed-off-by: Alan Brady <alan.brady@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This patch allows detection of upcoming core reset in case NIC gets
stuck while performing FLR reset. The i40e_pf_reset() function returns
I40E_ERR_NOT_READY when global reset was detected.
Signed-off-by: Filip Sadowski <filip.sadowski@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
It is safe to remove the upper limit of 64 queues on a channel
VSI. The upper bound is determined by the VSI's num_queue_pairs
and gets validated when the queue mapping info through mqprio
interface is subject to bound checking in the driver.
Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
num_mac should be increased only after the call to i40e_add_mac_filter().
Fixes: 5f527ba962e2 ("i40e: Limit the number of MAC and VLAN addresses that can be added for VFs")
Signed-off-by: Zijie Pan <zijie.pan@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Reviewed-by: Tushar Dave <tushar.n.dave@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
Since commit 96a39aed25e6 ("i40e: Acquire NVM lock before
reads on all devices") we've used the NVM lock
to synchronize NVM reads even on devices which don't strictly
need the lock.
Doing so can cause a regression on older firmware prior to 1.5,
especially when downgrading the firmware.
Fix this by only grabbing the lock if we're running on an X722
device (which requires the lock as it uses the AdminQ to read
the NVM), or if we're currently running 1.5 or newer firmware.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
There are four tests in test_verifier using bpf_probe_write_user
helper. These four tests will emit the following kernel messages
[ 12.974753] test_verifier[220] is installing a program with bpf_probe_write_user
helper that may corrupt user memory!
[ 12.979285] test_verifier[220] is installing a program with bpf_probe_write_user
helper that may corrupt user memory!
......
This may confuse certain users. This patch replaces bpf_probe_write_user
with bpf_trace_printk. The test_verifier already uses bpf_trace_printk
earlier in the test and a trace_printk warning message has been printed.
So this patch does not emit any more kernel messages.
Fixes: b6ff63911232 ("bpf: fix and add test cases for ARG_CONST_SIZE_OR_ZERO semantics change")
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
|
Fix to return error code -ENOMEM from the kzalloc() error handling
case instead of 0, as done elsewhere in this function.
Fixes: 549b4930f057 ("platform/x86: dell-smbios: Introduce dispatcher for SMM calls")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
The helper functions to parse and look for the clock source, selector
and multiplier unit may return the descriptor with a too short length
than required, while there is no sanity check in the caller side.
Add some sanity checks in the parsers, at least, to guarantee the
given descriptor size, for avoiding the potential crashes.
Fixes: 79f920fbff56 ("ALSA: usb-audio: parse clock topology of UAC2 devices")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
parse_audio_feature_unit() contains a code dividing potentially with
zero when a malformed FU descriptor is passed. Although there is
already a sanity check, it checks only the value zero, hence it can
still lead to a zero-division when a value 1 is passed there.
Fix it by correcting the sanity check (and the error message
thereof).
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The usb-audio driver may trigger an out-of-bound access at parsing a
malformed selector unit, as it checks the header length only after
evaluating bNrInPins field, which can be already above the given
length. Fix it by adding the length check beforehand.
Fixes: 99fc86450c43 ("ALSA: usb-mixer: parse descriptors with structs")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When the usb-audio descriptor contains the malformed feature unit
description with a too short length, the driver may access
out-of-bounds. Add a sanity check of the header size at the beginning
of parse_audio_feature_unit().
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Pull networking fixes from David Miller:
1) Fix a reference to a module parameter which was lost during the
GREv6 receive path rewrite, from Alexey Kodanev.
2) Fix deref before NULL check in ipheth, from Gustavo A. R. Silva.
3) RCU read lock imbalance in tun_build_skb(), from Xin Long.
4) Some stragglers from the mac80211 folks:
a) Timer conversions from Kees Cook
b) Fix some sequencing issue when cfg80211 is built statically,
from Johannes Berg
c) Memory leak in mac80211_hwsim, from Ben Hutchings.
5) Add new qmi_wwan device ID, from Sebastian Sjoholm.
6) Fix use after free in tipc, from Jon Maloy.
7) Missing kdoc in nfp driver, from Jakub Kicinski.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
nfp: flower: add missing kdoc
tipc: fix access of released memory
net: qmi_wwan: add Quectel BG96 2c7c:0296
mlxsw: spectrum: Do not try to create non-existing ports during unsplit
mac80211: properly free requested-but-not-started TX agg sessions
mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
cfg80211: initialize regulatory keys/database later
mac80211: aggregation: Convert timers to use timer_setup()
nl80211: don't expose wdev->ssid for most interfaces
mac80211: Convert timers to use timer_setup()
net: vxge: Fix some indentation issues
net: ena: fix race condition between device reset and link up setup
r8169: use same RTL8111EVL green settings as in vendor driver
r8169: fix RTL8111EVL EEE and green settings
tun: fix rcu_read_lock imbalance in tun_build_skb
tcp: when scheduling TLP, time of RTO should account for current ACK
usbnet: ipheth: fix potential null pointer dereference in ipheth_carrier_set
gre6: use log_ecn_error module parameter in ip6_tnl_rcv()
|
|
If gfx_v8_0_hw_fini is called after amdgpu_ucode_fini_bo, we will
hit KCQ disabled failed. Let amdgpu_ucode_fini_bo run after
gfx_v8_0_hw_fini.
BUG: SWDEV-135547
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Wang Hongcheng <Annie.Wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
After starting VNC server or running CTS test, kernel will hang and
can see below call trace:
[961816] INFO: task khugepaged:42 blocked for more than 120 seconds.
[968581] Tainted: G OE 4.13.0 #1
[973495] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[980962] khugepaged D 0 42 2 0x00000000
[980967] Call Trace:
[980977] __schedule+0x28d/0x890
[980982] schedule+0x36/0x80
[980986] rwsem_down_read_failed+0x139/0x1c0
[980991] ? update_curr+0x100/0x1c0
[981004] call_rwsem_down_read_failed+0x18/0x30
[981007] down_read+0x20/0x40
[981012] khugepaged_scan_mm_slot+0x78/0x1ac0
[981018] ? __switch_to+0x23e/0x4a0
[981022] ? finish_task_switch+0x79/0x240
[981026] khugepaged+0x146/0x480
[981031] ? remove_wait_queue+0x60/0x60
[981035] kthread+0x109/0x140
[981037] ? khugepaged_scan_mm_slot+0x1ac0/0x1ac0
[981039] ? kthread_park+0x60/0x60
[981044] ret_from_fork+0x25/0x30
After checking code and found 'commit b72cf4fca2bb7 ("drm/amdgpu: move
taking mmap_sem into get_user_pages v2")' forget to drop one case of
up_read.
Signed-off-by: Xiangliang.Yu <Xiangliang.Yu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux
Pull orangefs updates from Mike Marshall:
"Fix:
- stop setting atime on inode dirty (Martin Brandenburg)
Cleanups:
- remove initialization of i_version (Jeff Layton)
- use ARRAY_SIZE (Jérémy Lefaure)
- call op_release sooner when creating inodes (Mike MarshallMartin
Brandenburg)"
* tag 'for-linus-4.15-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux:
orangefs: call op_release sooner when creating inodes
orangefs: stop setting atime on inode dirty
orangefs: use ARRAY_SIZE
orangefs: remove initialization of i_version
|
|
Pull ceph updates from Ilya Dryomov:
"We have a set of file locking improvements from Zheng, rbd rw/ro state
handling code cleanup from myself and some assorted CephFS fixes from
Jeff.
rbd now defaults to single-major=Y, lifting the limit of ~240 rbd
images per host for everyone"
* tag 'ceph-for-4.15-rc1' of git://github.com/ceph/ceph-client:
rbd: default to single-major device number scheme
libceph: don't WARN() if user tries to add invalid key
rbd: set discard_alignment to zero
ceph: silence sparse endianness warning in encode_caps_cb
ceph: remove the bump of i_version
ceph: present consistent fsid, regardless of arch endianness
ceph: clean up spinlocking and list handling around cleanup_cap_releases()
rbd: get rid of rbd_mapping::read_only
rbd: fix and simplify rbd_ioctl_set_ro()
ceph: remove unused and redundant variable dropping
ceph: mark expected switch fall-throughs
ceph: -EINVAL on decoding failure in ceph_mdsc_handle_fsmap()
ceph: disable cached readdir after dropping positive dentry
ceph: fix bool initialization/comparison
ceph: handle 'session get evicted while there are file locks'
ceph: optimize flock encoding during reconnect
ceph: make lock_to_ceph_filelock() static
ceph: keep auth cap when inode has flocks or posix locks
|
|
Some timer compat ioctls have NULL checks of timer instance with
snd_BUG_ON() that bring up WARN_ON() when the debug option is set.
Actually the condition can be met in the normal situation and it's
confusing and bad to spew kernel warnings with stack trace there.
Let's remove snd_BUG_ON() invocation and replace with the simple
checks. Also, correct the error code to EBADFD to follow the native
ioctl error handling.
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk
Pull printk updates from Petr Mladek:
- print the warning about dropped messages on consoles on a separate
line. It makes it more legible.
- one typo fix and small code clean up.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk:
added new line symbol after warning about dropped messages
printk: fix typo in printk_safe.c
printk: simplify no_printk()
|
|
commit 3179f6200188 ("ALSA: core: add .get_time_info") had a side effect
of changing the behaviour of the PCM runtime tstamp. Prior to this
change tstamp was not updated by snd_pcm_update_hw_ptr0() unless the
hw_ptr had moved, after this change tstamp was always updated.
For an application using alsa-lib, doing snd_pcm_readi() followed by
snd_pcm_status() to estimate the age of the read samples by subtracting
status->avail * [sample rate] from status->tstamp this change degraded
the accuracy of the estimate on devices where the pcm hw does not
provide a granular hw_ptr, e.g., devices using
soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity
DMA_RESIDUE_GRANULARITY_DESCRIPTOR. The accuracy of the estimate
depended on the latency between the PCM hw completing a period and the
driver called snd_pcm_period_elapsed() to notify ALSA core, typically
determined by interrupt handling latency. After the change the accuracy
of the estimate depended on the latency between the PCM hw completing a
period and the application calling snd_pcm_status(), determined by the
scheduling of the application process. The maximum error of the
estimate is one period length in both cases, but the error average and
variance is smaller when it depends on interrupt latency.
Instead of always updating tstamp, update it only if audio_tstamp
changed.
Fixes: 3179f6200188 ("ALSA: core: add .get_time_info")
Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Henrik Eriksson <henrik.eriksson@axis.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
A few things:
* straggler timer conversions from Kees
* memory leak fix in hwsim
* fix some fallout from regdb changes if wireless is built-in
* also free aggregation sessions in startup state when station
goes away, to avoid crashing the timer
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit 0115552eac14 ("nfp: remove false positive offloads
in flower vxlan") missed adding kdoc for a new parameter
of nfp_flower_add_offload().
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When the function tipc_group_filter_msg() finds that a member event
indicates that the member is leaving the group, it first deletes the
member instance, and then purges the message queue being handled
by the call. But the message queue is an aggregated field in the
just deleted item, leading the purge call to access freed memory.
We fix this by swapping the order of the two actions.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel development
board (EVB). The USB id is added to qmi_wwan.c to allow QMI
communication with the BG96.
Signed-off-by: Sebastian Sjoholm <ssjoholm@mac.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On some systems, when we unsplit a port we need to re-create two ports
instead. On other systems, only one needs to be re-created.
Do not try to create a port if during driver initialization it was
assigned a negative module number, which is invalid.
This avoids the following error during unsplit:
[ 941.012478] mlxsw_spectrum 0000:01:00.0: Port 43: Failed to map module
The error is harmless and caused by the fact that a local port is
already mapped to module 0.
Fixes: be94535f9531 ("mlxsw: spectrum: Make split flow match firmware requirements")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Use mutex_lock_nested to provide lockdep the parent child lock ordering of
the tree.
This fixes the lockdep Warning
[ 305.275177] ============================================
[ 305.275178] WARNING: possible recursive locking detected
[ 305.275179] 4.14.0-rc7+ #320 Not tainted
[ 305.275180] --------------------------------------------
[ 305.275181] apparmor_parser/1339 is trying to acquire lock:
[ 305.275182] (&ns->lock){+.+.}, at: [<ffffffff970544dd>] __aa_create_ns+0x6d/0x1e0
[ 305.275187]
but task is already holding lock:
[ 305.275187] (&ns->lock){+.+.}, at: [<ffffffff97054b5d>] aa_prepare_ns+0x3d/0xd0
[ 305.275190]
other info that might help us debug this:
[ 305.275191] Possible unsafe locking scenario:
[ 305.275192] CPU0
[ 305.275193] ----
[ 305.275193] lock(&ns->lock);
[ 305.275194] lock(&ns->lock);
[ 305.275195]
*** DEADLOCK ***
[ 305.275196] May be due to missing lock nesting notation
[ 305.275198] 2 locks held by apparmor_parser/1339:
[ 305.275198] #0: (sb_writers#10){.+.+}, at: [<ffffffff96e9c6b7>] vfs_write+0x1a7/0x1d0
[ 305.275202] #1: (&ns->lock){+.+.}, at: [<ffffffff97054b5d>] aa_prepare_ns+0x3d/0xd0
[ 305.275205]
stack backtrace:
[ 305.275207] CPU: 1 PID: 1339 Comm: apparmor_parser Not tainted 4.14.0-rc7+ #320
[ 305.275208] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
[ 305.275209] Call Trace:
[ 305.275212] dump_stack+0x85/0xcb
[ 305.275214] __lock_acquire+0x141c/0x1460
[ 305.275216] ? __aa_create_ns+0x6d/0x1e0
[ 305.275218] ? ___slab_alloc+0x183/0x540
[ 305.275219] ? ___slab_alloc+0x183/0x540
[ 305.275221] lock_acquire+0xed/0x1e0
[ 305.275223] ? lock_acquire+0xed/0x1e0
[ 305.275224] ? __aa_create_ns+0x6d/0x1e0
[ 305.275227] __mutex_lock+0x89/0x920
[ 305.275228] ? __aa_create_ns+0x6d/0x1e0
[ 305.275230] ? trace_hardirqs_on_caller+0x11f/0x190
[ 305.275231] ? __aa_create_ns+0x6d/0x1e0
[ 305.275233] ? __lockdep_init_map+0x57/0x1d0
[ 305.275234] ? lockdep_init_map+0x9/0x10
[ 305.275236] ? __rwlock_init+0x32/0x60
[ 305.275238] mutex_lock_nested+0x1b/0x20
[ 305.275240] ? mutex_lock_nested+0x1b/0x20
[ 305.275241] __aa_create_ns+0x6d/0x1e0
[ 305.275243] aa_prepare_ns+0xc2/0xd0
[ 305.275245] aa_replace_profiles+0x168/0xf30
[ 305.275247] ? __might_fault+0x85/0x90
[ 305.275250] policy_update+0xb9/0x380
[ 305.275252] profile_load+0x7e/0x90
[ 305.275254] __vfs_write+0x28/0x150
[ 305.275256] ? rcu_read_lock_sched_held+0x72/0x80
[ 305.275257] ? rcu_sync_lockdep_assert+0x2f/0x60
[ 305.275259] ? __sb_start_write+0xdc/0x1c0
[ 305.275261] ? vfs_write+0x1a7/0x1d0
[ 305.275262] vfs_write+0xca/0x1d0
[ 305.275264] ? trace_hardirqs_on_caller+0x11f/0x190
[ 305.275266] SyS_write+0x49/0xa0
[ 305.275268] entry_SYSCALL_64_fastpath+0x23/0xc2
[ 305.275271] RIP: 0033:0x7fa6b22e8c74
[ 305.275272] RSP: 002b:00007ffeaaee6288 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 305.275273] RAX: ffffffffffffffda RBX: 00007ffeaaee62a4 RCX: 00007fa6b22e8c74
[ 305.275274] RDX: 0000000000000a51 RSI: 00005566a8198c10 RDI: 0000000000000004
[ 305.275275] RBP: 0000000000000a39 R08: 0000000000000a51 R09: 0000000000000000
[ 305.275276] R10: 0000000000000000 R11: 0000000000000246 R12: 00005566a8198c10
[ 305.275277] R13: 0000000000000004 R14: 00005566a72ecb88 R15: 00005566a72ec3a8
Fixes: 73688d1ed0b8 ("apparmor: refactor prepare_ns() and make usable from different views")
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
|
Break the per cpu buffer atomic section when creating a new null
complain profile. In learning mode this won't matter and we can
safely re-aquire the buffer.
This fixes the following lockdep BUG trace
nov. 14 14:09:09 cyclope audit[7152]: AVC apparmor="ALLOWED" operation="exec" profile="/usr/sbin/sssd" name="/usr/sbin/adcli" pid=7152 comm="sssd_be" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="/usr/sbin/sssd//null-/usr/sbin/adcli"
nov. 14 14:09:09 cyclope kernel: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
nov. 14 14:09:09 cyclope kernel: in_atomic(): 1, irqs_disabled(): 0, pid: 7152, name: sssd_be
nov. 14 14:09:09 cyclope kernel: 1 lock held by sssd_be/7152:
nov. 14 14:09:09 cyclope kernel: #0: (&sig->cred_guard_mutex){....}, at: [<ffffffff8182d53e>] prepare_bprm_creds+0x4e/0x100
nov. 14 14:09:09 cyclope kernel: CPU: 3 PID: 7152 Comm: sssd_be Not tainted 4.14.0prahal+intel #150
nov. 14 14:09:09 cyclope kernel: Hardware name: LENOVO 20CDCTO1WW/20CDCTO1WW, BIOS GQET53WW (1.33 ) 09/15/2017
nov. 14 14:09:09 cyclope kernel: Call Trace:
nov. 14 14:09:09 cyclope kernel: dump_stack+0xb0/0x135
nov. 14 14:09:09 cyclope kernel: ? _atomic_dec_and_lock+0x15b/0x15b
nov. 14 14:09:09 cyclope kernel: ? lockdep_print_held_locks+0xc4/0x130
nov. 14 14:09:09 cyclope kernel: ___might_sleep+0x29c/0x320
nov. 14 14:09:09 cyclope kernel: ? rq_clock+0xf0/0xf0
nov. 14 14:09:09 cyclope kernel: ? __kernel_text_address+0xd/0x40
nov. 14 14:09:09 cyclope kernel: __might_sleep+0x95/0x190
nov. 14 14:09:09 cyclope kernel: ? aa_new_null_profile+0x50a/0x960
nov. 14 14:09:09 cyclope kernel: __mutex_lock+0x13e/0x1a20
nov. 14 14:09:09 cyclope kernel: ? aa_new_null_profile+0x50a/0x960
nov. 14 14:09:09 cyclope kernel: ? save_stack+0x43/0xd0
nov. 14 14:09:09 cyclope kernel: ? kmem_cache_alloc_trace+0x13f/0x290
nov. 14 14:09:09 cyclope kernel: ? mutex_lock_io_nested+0x1880/0x1880
nov. 14 14:09:09 cyclope kernel: ? profile_transition+0x932/0x2d40
nov. 14 14:09:09 cyclope kernel: ? apparmor_bprm_set_creds+0x1479/0x1f70
nov. 14 14:09:09 cyclope kernel: ? security_bprm_set_creds+0x5a/0x80
nov. 14 14:09:09 cyclope kernel: ? prepare_binprm+0x366/0x980
nov. 14 14:09:09 cyclope kernel: ? do_execveat_common.isra.30+0x12a9/0x2350
nov. 14 14:09:09 cyclope kernel: ? SyS_execve+0x2c/0x40
nov. 14 14:09:09 cyclope kernel: ? do_syscall_64+0x228/0x650
nov. 14 14:09:09 cyclope kernel: ? entry_SYSCALL64_slow_path+0x25/0x25
nov. 14 14:09:09 cyclope kernel: ? deactivate_slab.isra.62+0x49d/0x5e0
nov. 14 14:09:09 cyclope kernel: ? save_stack_trace+0x16/0x20
nov. 14 14:09:09 cyclope kernel: ? init_object+0x88/0x90
nov. 14 14:09:09 cyclope kernel: ? ___slab_alloc+0x520/0x590
nov. 14 14:09:09 cyclope kernel: ? ___slab_alloc+0x520/0x590
nov. 14 14:09:09 cyclope kernel: ? aa_alloc_proxy+0xab/0x200
nov. 14 14:09:09 cyclope kernel: ? lock_downgrade+0x7e0/0x7e0
nov. 14 14:09:09 cyclope kernel: ? memcg_kmem_get_cache+0x970/0x970
nov. 14 14:09:09 cyclope kernel: ? kasan_unpoison_shadow+0x35/0x50
nov. 14 14:09:09 cyclope kernel: ? kasan_unpoison_shadow+0x35/0x50
nov. 14 14:09:09 cyclope kernel: ? kasan_kmalloc+0xad/0xe0
nov. 14 14:09:09 cyclope kernel: ? aa_alloc_proxy+0xab/0x200
nov. 14 14:09:09 cyclope kernel: ? kmem_cache_alloc_trace+0x13f/0x290
nov. 14 14:09:09 cyclope kernel: ? aa_alloc_proxy+0xab/0x200
nov. 14 14:09:09 cyclope kernel: ? aa_alloc_proxy+0xab/0x200
nov. 14 14:09:09 cyclope kernel: ? _raw_spin_unlock+0x22/0x30
nov. 14 14:09:09 cyclope kernel: ? vec_find+0xa0/0xa0
nov. 14 14:09:09 cyclope kernel: ? aa_label_init+0x6f/0x230
nov. 14 14:09:09 cyclope kernel: ? __label_insert+0x3e0/0x3e0
nov. 14 14:09:09 cyclope kernel: ? kmem_cache_alloc_trace+0x13f/0x290
nov. 14 14:09:09 cyclope kernel: ? aa_alloc_profile+0x58/0x200
nov. 14 14:09:09 cyclope kernel: mutex_lock_nested+0x16/0x20
nov. 14 14:09:09 cyclope kernel: ? mutex_lock_nested+0x16/0x20
nov. 14 14:09:09 cyclope kernel: aa_new_null_profile+0x50a/0x960
nov. 14 14:09:09 cyclope kernel: ? aa_fqlookupn_profile+0xdc0/0xdc0
nov. 14 14:09:09 cyclope kernel: ? aa_compute_fperms+0x4b5/0x640
nov. 14 14:09:09 cyclope kernel: ? disconnect.isra.2+0x1b0/0x1b0
nov. 14 14:09:09 cyclope kernel: ? aa_str_perms+0x8d/0xe0
nov. 14 14:09:09 cyclope kernel: profile_transition+0x932/0x2d40
nov. 14 14:09:09 cyclope kernel: ? up_read+0x1a/0x40
nov. 14 14:09:09 cyclope kernel: ? ext4_xattr_get+0x15c/0xaf0 [ext4]
nov. 14 14:09:09 cyclope kernel: ? x_table_lookup+0x190/0x190
nov. 14 14:09:09 cyclope kernel: ? ext4_xattr_ibody_get+0x590/0x590 [ext4]
nov. 14 14:09:09 cyclope kernel: ? sched_clock+0x9/0x10
nov. 14 14:09:09 cyclope kernel: ? sched_clock+0x9/0x10
nov. 14 14:09:09 cyclope kernel: ? ext4_xattr_security_get+0x1a/0x20 [ext4]
nov. 14 14:09:09 cyclope kernel: ? __vfs_getxattr+0x6d/0xa0
nov. 14 14:09:09 cyclope kernel: ? get_vfs_caps_from_disk+0x114/0x720
nov. 14 14:09:09 cyclope kernel: ? sched_clock+0x9/0x10
nov. 14 14:09:09 cyclope kernel: ? sched_clock+0x9/0x10
nov. 14 14:09:09 cyclope kernel: ? tsc_resume+0x10/0x10
nov. 14 14:09:09 cyclope kernel: ? get_vfs_caps_from_disk+0x720/0x720
nov. 14 14:09:09 cyclope kernel: ? native_sched_clock_from_tsc+0x201/0x2b0
nov. 14 14:09:09 cyclope kernel: ? sched_clock+0x9/0x10
nov. 14 14:09:09 cyclope kernel: ? sched_clock_cpu+0x1b/0x170
nov. 14 14:09:09 cyclope kernel: ? find_held_lock+0x3c/0x1e0
nov. 14 14:09:09 cyclope kernel: ? rb_insert_color_cached+0x1660/0x1660
nov. 14 14:09:09 cyclope kernel: apparmor_bprm_set_creds+0x1479/0x1f70
nov. 14 14:09:09 cyclope kernel: ? sched_clock+0x9/0x10
nov. 14 14:09:09 cyclope kernel: ? handle_onexec+0x31d0/0x31d0
nov. 14 14:09:09 cyclope kernel: ? tsc_resume+0x10/0x10
nov. 14 14:09:09 cyclope kernel: ? graph_lock+0xd0/0xd0
nov. 14 14:09:09 cyclope kernel: ? tsc_resume+0x10/0x10
nov. 14 14:09:09 cyclope kernel: ? sched_clock_cpu+0x1b/0x170
nov. 14 14:09:09 cyclope kernel: ? sched_clock+0x9/0x10
nov. 14 14:09:09 cyclope kernel: ? sched_clock+0x9/0x10
nov. 14 14:09:09 cyclope kernel: ? sched_clock_cpu+0x1b/0x170
nov. 14 14:09:09 cyclope kernel: ? find_held_lock+0x3c/0x1e0
nov. 14 14:09:09 cyclope kernel: security_bprm_set_creds+0x5a/0x80
nov. 14 14:09:09 cyclope kernel: prepare_binprm+0x366/0x980
nov. 14 14:09:09 cyclope kernel: ? install_exec_creds+0x150/0x150
nov. 14 14:09:09 cyclope kernel: ? __might_fault+0x89/0xb0
nov. 14 14:09:09 cyclope kernel: ? up_read+0x40/0x40
nov. 14 14:09:09 cyclope kernel: ? get_user_arg_ptr.isra.18+0x2c/0x70
nov. 14 14:09:09 cyclope kernel: ? count.isra.20.constprop.32+0x7c/0xf0
nov. 14 14:09:09 cyclope kernel: do_execveat_common.isra.30+0x12a9/0x2350
nov. 14 14:09:09 cyclope kernel: ? prepare_bprm_creds+0x100/0x100
nov. 14 14:09:09 cyclope kernel: ? _raw_spin_unlock+0x22/0x30
nov. 14 14:09:09 cyclope kernel: ? deactivate_slab.isra.62+0x49d/0x5e0
nov. 14 14:09:09 cyclope kernel: ? save_stack_trace+0x16/0x20
nov. 14 14:09:09 cyclope kernel: ? init_object+0x88/0x90
nov. 14 14:09:09 cyclope kernel: ? ___slab_alloc+0x520/0x590
nov. 14 14:09:09 cyclope kernel: ? ___slab_alloc+0x520/0x590
nov. 14 14:09:09 cyclope kernel: ? kasan_check_write+0x14/0x20
nov. 14 14:09:09 cyclope kernel: ? memcg_kmem_get_cache+0x970/0x970
nov. 14 14:09:09 cyclope kernel: ? kasan_unpoison_shadow+0x35/0x50
nov. 14 14:09:09 cyclope kernel: ? glob_match+0x730/0x730
nov. 14 14:09:09 cyclope kernel: ? kmem_cache_alloc+0x225/0x280
nov. 14 14:09:09 cyclope kernel: ? getname_flags+0xb8/0x510
nov. 14 14:09:09 cyclope kernel: ? mm_fault_error+0x2e0/0x2e0
nov. 14 14:09:09 cyclope kernel: ? getname_flags+0xf6/0x510
nov. 14 14:09:09 cyclope kernel: ? ptregs_sys_vfork+0x10/0x10
nov. 14 14:09:09 cyclope kernel: SyS_execve+0x2c/0x40
nov. 14 14:09:09 cyclope kernel: do_syscall_64+0x228/0x650
nov. 14 14:09:09 cyclope kernel: ? syscall_return_slowpath+0x2f0/0x2f0
nov. 14 14:09:09 cyclope kernel: ? syscall_return_slowpath+0x167/0x2f0
nov. 14 14:09:09 cyclope kernel: ? prepare_exit_to_usermode+0x220/0x220
nov. 14 14:09:09 cyclope kernel: ? prepare_exit_to_usermode+0xda/0x220
nov. 14 14:09:09 cyclope kernel: ? perf_trace_sys_enter+0x1060/0x1060
nov. 14 14:09:09 cyclope kernel: ? __put_user_4+0x1c/0x30
nov. 14 14:09:09 cyclope kernel: entry_SYSCALL64_slow_path+0x25/0x25
nov. 14 14:09:09 cyclope kernel: RIP: 0033:0x7f9320f23637
nov. 14 14:09:09 cyclope kernel: RSP: 002b:00007fff783be338 EFLAGS: 00000202 ORIG_RAX: 000000000000003b
nov. 14 14:09:09 cyclope kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9320f23637
nov. 14 14:09:09 cyclope kernel: RDX: 0000558c35002a70 RSI: 0000558c3505bd10 RDI: 0000558c35018b90
nov. 14 14:09:09 cyclope kernel: RBP: 0000558c34b63ae8 R08: 0000558c3505bd10 R09: 0000000000000080
nov. 14 14:09:09 cyclope kernel: R10: 0000000000000095 R11: 0000000000000202 R12: 0000000000000001
nov. 14 14:09:09 cyclope kernel: R13: 0000558c35018b90 R14: 0000558c3505bd18 R15: 0000558c3505bd10
Fixes: 4227c333f65c ("apparmor: Move path lookup to using preallocated buffers")
BugLink: http://bugs.launchpad.net/bugs/173228
Reported-by: Alban Browaeys <prahal@yahoo.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
|
It used to be that unconfined would never attach. However that is not
the case anymore as some special profiles can be marked as unconfined,
that are not the namespaces unconfined profile, and may have an
attachment.
Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels")
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
|
Profiles that have an undecidable overlap in their attachments are
being incorrectly handled. Instead of failing to attach the first one
encountered is being used.
eg.
profile A /** { .. }
profile B /*foo { .. }
have an unresolvable longest left attachment, they both have an exact
match on / and then have an overlapping expression that has no clear
winner.
Currently the winner will be the profile that is loaded first which
can result in non-deterministic behavior. Instead in this situation
the exec should fail.
Fixes: 898127c34ec0 ("AppArmor: functions for domain transitions")
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
|
Fixes: d07881d2edb0 ("apparmor: move new_null_profile to after profile lookup fns()")
Reported-by: Seth Arnold <seth.arnold@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
|
The boolean variable 'stop' is being set but never read. This
is a redundant variable and can be removed.
Cleans up clang warning: Value stored to 'stop' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
|
Bool initializations should use true and false. Bool tests don't need
comparisons.
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
|
gcc-4.4 points out suspicious code in compute_mnt_perms, where
the aa_perms structure is only partially initialized before getting
returned:
security/apparmor/mount.c: In function 'compute_mnt_perms':
security/apparmor/mount.c:227: error: 'perms.prompt' is used uninitialized in this function
security/apparmor/mount.c:227: error: 'perms.hide' is used uninitialized in this function
security/apparmor/mount.c:227: error: 'perms.cond' is used uninitialized in this function
security/apparmor/mount.c:227: error: 'perms.complain' is used uninitialized in this function
security/apparmor/mount.c:227: error: 'perms.stop' is used uninitialized in this function
security/apparmor/mount.c:227: error: 'perms.deny' is used uninitialized in this function
Returning or assigning partially initialized structures is a bit tricky,
in particular it is explicitly allowed in c99 to assign a partially
initialized structure to another, as long as only members are read that
have been initialized earlier. Looking at what various compilers do here,
the version that produced the warning copied uninitialized stack data,
while newer versions (and also clang) either set the other members to
zero or don't update the parts of the return buffer that are not modified
in the temporary structure, but they never warn about this.
In case of apparmor, it seems better to be a little safer and always
initialize the aa_perms structure. Most users already do that, this
changes the remaining ones, including the one instance that I got the
warning for.
Fixes: fa488437d0f9 ("apparmor: add mount mediation")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Seth Arnold <seth.arnold@canonical.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
ath.git fixes for 4.15. Major changes:
ath10k
* fix CCMP-256, GCMP and GCMP-256 in raw mode, they never worked with raw mode
wcn36xx
* fix device tree node search
|
|
And move them to xfs_linux.h so that xfsprogs can stub them out more
easily.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
|
|
found the issue by kmemleak.
unreferenced object 0xffff8800674611c0 (size 16):
xfs_iext_insert+0x82a/0xa90 [xfs]
xfs_bmap_add_extent_hole_delay+0x1e5/0x5b0 [xfs]
xfs_bmapi_reserve_delalloc+0x483/0x530 [xfs]
xfs_file_iomap_begin+0xac8/0xd40 [xfs]
iomap_apply+0xb8/0x1b0
iomap_file_buffered_write+0xac/0xe0
xfs_file_buffered_aio_write+0x198/0x420 [xfs]
xfs_file_write_iter+0x23f/0x2a0 [xfs]
__vfs_write+0x23e/0x340
vfs_write+0xe9/0x240
SyS_write+0xa1/0x120
do_syscall_64+0xda/0x260
Signed-off-by: Shu Wang <shuwang@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
|
|
Trivial fix to spelling mistake in comment and also with text in
audit_resource call.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
