* [PATCH AUTOSEL 5.4 157/459] selinux: revert "stop passing MAY_NOT_BLOCK to the AVC upon follow_link"
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stephen Smalley, Will Deacon, Paul Moore, Sasha Levin, selinux
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Stephen Smalley <sds@tycho.nsa.gov>
[ Upstream commit 1a37079c236d55fb31ebbf4b59945dab8ec8764c ]
This reverts commit e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK
to the AVC upon follow_link"). The correct fix is to instead fall
back to ref-walk if audit is required irrespective of the specific
audit data type. This is done in the next commit.
Fixes: e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK to the AVC upon follow_link")
Reported-by: Will Deacon <will@kernel.org>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
security/selinux/avc.c | 24 ++++++++++++++++++++++--
security/selinux/hooks.c | 5 +++--
security/selinux/include/avc.h | 5 +++++
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index ecd3829996aa4..74c43ebe34bb8 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -862,8 +862,9 @@ static int avc_update_node(struct selinux_avc *avc,
* permissive mode that only appear when in enforcing mode.
*
* See the corresponding handling in slow_avc_audit(), and the
- * logic in selinux_inode_permission for the MAY_NOT_BLOCK flag,
- * which is transliterated into AVC_NONBLOCKING.
+ * logic in selinux_inode_follow_link and selinux_inode_permission
+ * for the VFS MAY_NOT_BLOCK flag, which is transliterated into
+ * AVC_NONBLOCKING for avc_has_perm_noaudit().
*/
if (flags & AVC_NONBLOCKING)
return 0;
@@ -1205,6 +1206,25 @@ int avc_has_perm(struct selinux_state *state, u32 ssid, u32 tsid, u16 tclass,
return rc;
}
+int avc_has_perm_flags(struct selinux_state *state,
+ u32 ssid, u32 tsid, u16 tclass, u32 requested,
+ struct common_audit_data *auditdata,
+ int flags)
+{
+ struct av_decision avd;
+ int rc, rc2;
+
+ rc = avc_has_perm_noaudit(state, ssid, tsid, tclass, requested,
+ (flags & MAY_NOT_BLOCK) ? AVC_NONBLOCKING : 0,
+ &avd);
+
+ rc2 = avc_audit(state, ssid, tsid, tclass, requested, &avd, rc,
+ auditdata, flags);
+ if (rc2)
+ return rc2;
+ return rc;
+}
+
u32 avc_policy_seqno(struct selinux_state *state)
{
return state->avc->avc_cache.latest_notif;
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9625b99e677fd..9943539457906 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3008,8 +3008,9 @@ static int selinux_inode_follow_link(struct dentry *dentry, struct inode *inode,
if (IS_ERR(isec))
return PTR_ERR(isec);
- return avc_has_perm(&selinux_state,
- sid, isec->sid, isec->sclass, FILE__READ, &ad);
+ return avc_has_perm_flags(&selinux_state,
+ sid, isec->sid, isec->sclass, FILE__READ, &ad,
+ rcu ? MAY_NOT_BLOCK : 0);
}
static noinline int audit_inode_permission(struct inode *inode,
diff --git a/security/selinux/include/avc.h b/security/selinux/include/avc.h
index 7be0e1e90e8be..74ea50977c201 100644
--- a/security/selinux/include/avc.h
+++ b/security/selinux/include/avc.h
@@ -153,6 +153,11 @@ int avc_has_perm(struct selinux_state *state,
u32 ssid, u32 tsid,
u16 tclass, u32 requested,
struct common_audit_data *auditdata);
+int avc_has_perm_flags(struct selinux_state *state,
+ u32 ssid, u32 tsid,
+ u16 tclass, u32 requested,
+ struct common_audit_data *auditdata,
+ int flags);
int avc_has_extended_perms(struct selinux_state *state,
u32 ssid, u32 tsid, u16 tclass, u32 requested,
--
2.20.1
^ permalink raw reply related
* possible deadlock in n_tty_receive_buf_common
From: syzbot @ 2020-02-14 17:37 UTC (permalink / raw)
To: gregkh, jslaby, linux-kernel, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 9f01828e Add linux-next specific files for 20200214
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=119f6c29e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=ffb2752ee30931a0
dashboard link: https://syzkaller.appspot.com/bug?extid=41a045bca47dde704c4c
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1172fc09e00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15a3a431e00000
Bisection is inconclusive: the bug happens on the oldest tested release.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=106596b5e00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=126596b5e00000
console output: https://syzkaller.appspot.com/x/log.txt?x=146596b5e00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+41a045bca47dde704c4c@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
5.6.0-rc1-next-20200214-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor167/9787 is trying to acquire lock:
ffff88809a1872a0 (&tty->termios_rwsem){++++}, at: n_tty_receive_buf_common+0x8a/0x2b70 drivers/tty/n_tty.c:1705
but task is already holding lock:
ffffffff8a1414c0 (sel_lock){+.+.}, at: paste_selection+0x15a/0x4d0 drivers/tty/vt/selection.c:374
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (sel_lock){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:956 [inline]
__mutex_lock+0x156/0x13c0 kernel/locking/mutex.c:1103
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1118
set_selection_kernel+0x39d/0x13d0 drivers/tty/vt/selection.c:217
set_selection_user+0x95/0xd9 drivers/tty/vt/selection.c:181
tioclinux+0x11c/0x480 drivers/tty/vt/vt.c:3050
vt_ioctl+0x1a41/0x26c0 drivers/tty/vt/vt_ioctl.c:364
tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x123/0x180 fs/ioctl.c:763
__do_sys_ioctl fs/ioctl.c:772 [inline]
__se_sys_ioctl fs/ioctl.c:770 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:770
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (console_lock){+.+.}:
console_lock+0x47/0x80 kernel/printk/printk.c:2286
con_flush_chars drivers/tty/vt/vt.c:3223 [inline]
con_flush_chars+0x3d/0xa0 drivers/tty/vt/vt.c:3215
n_tty_write+0xc85/0x1080 drivers/tty/n_tty.c:2350
do_tty_write drivers/tty/tty_io.c:962 [inline]
tty_write+0x496/0x7f0 drivers/tty/tty_io.c:1046
__vfs_write+0x8a/0x110 fs/read_write.c:494
vfs_write+0x268/0x5d0 fs/read_write.c:558
ksys_write+0x14f/0x290 fs/read_write.c:611
__do_sys_write fs/read_write.c:623 [inline]
__se_sys_write fs/read_write.c:620 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:620
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (&tty->termios_rwsem){++++}:
check_prev_add kernel/locking/lockdep.c:2481 [inline]
check_prevs_add kernel/locking/lockdep.c:2586 [inline]
validate_chain kernel/locking/lockdep.c:3203 [inline]
__lock_acquire+0x29cd/0x6320 kernel/locking/lockdep.c:4190
lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4720
down_read+0x95/0x440 kernel/locking/rwsem.c:1492
n_tty_receive_buf_common+0x8a/0x2b70 drivers/tty/n_tty.c:1705
n_tty_receive_buf2+0x34/0x40 drivers/tty/n_tty.c:1777
tty_ldisc_receive_buf+0xad/0x1c0 drivers/tty/tty_buffer.c:461
paste_selection+0x1ff/0x4d0 drivers/tty/vt/selection.c:389
tioclinux+0x133/0x480 drivers/tty/vt/vt.c:3055
vt_ioctl+0x1a41/0x26c0 drivers/tty/vt/vt_ioctl.c:364
tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x123/0x180 fs/ioctl.c:763
__do_sys_ioctl fs/ioctl.c:772 [inline]
__se_sys_ioctl fs/ioctl.c:770 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:770
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
&tty->termios_rwsem --> console_lock --> sel_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sel_lock);
lock(console_lock);
lock(sel_lock);
lock(&tty->termios_rwsem);
*** DEADLOCK ***
3 locks held by syz-executor167/9787:
#0: ffff88809a187090 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:340
#1: ffff8880aa5be0a8 (&buf->lock){+.+.}, at: tty_buffer_lock_exclusive+0x30/0x40 drivers/tty/tty_buffer.c:61
#2: ffffffff8a1414c0 (sel_lock){+.+.}, at: paste_selection+0x15a/0x4d0 drivers/tty/vt/selection.c:374
stack backtrace:
CPU: 1 PID: 9787 Comm: syz-executor167 Not tainted 5.6.0-rc1-next-20200214-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x197/0x210 lib/dump_stack.c:118
print_circular_bug.isra.0.cold+0x163/0x172 kernel/locking/lockdep.c:1688
check_noncircular+0x32e/0x3e0 kernel/locking/lockdep.c:1812
check_prev_add kernel/locking/lockdep.c:2481 [inline]
check_prevs_add kernel/locking/lockdep.c:2586 [inline]
validate_chain kernel/locking/lockdep.c:3203 [inline]
__lock_acquire+0x29cd/0x6320 kernel/locking/lockdep.c:4190
lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4720
down_read+0x95/0x440 kernel/locking/rwsem.c:1492
n_tty_receive_buf_common+0x8a/0x2b70 drivers/tty/n_tty.c:1705
n_tty_receive_buf2+0x34/0x40 drivers/tty/n_tty.c:1777
tty_ldisc_receive_buf+0xad/0x1c0 drivers/tty/tty_buffer.c:461
paste_selection+0x1ff/0x4d0 drivers/tty/vt/selection.c:389
tioclinux+0x133/0x480 drivers/tty/vt/vt.c:3055
vt_ioctl+0x1a41/0x26c0 drivers/tty/vt/vt_ioctl.c:364
tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x123/0x180 fs/ioctl.c:763
__do_sys_ioctl fs/ioctl.c:772 [inline]
__se_sys_ioctl fs/ioctl.c:770 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:770
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440219
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 14 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffe5133a1c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440219
RDX: 0000000020000040 RSI: 000000000000541c RDI: 0000000000000004
RBP: 00000000006ca018 R08: 000000000000000d R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401b00
R13: 0000000000401b90 R14: 0000000000000000 R15: 000000000
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* memory leak in nfs_fs_context_parse_monolithic
From: syzbot @ 2020-02-14 17:37 UTC (permalink / raw)
To: anna.schumaker, linux-kernel, linux-nfs, syzkaller-bugs,
trond.myklebust
Hello,
syzbot found the following crash on:
HEAD commit: 0bf999f9 linux/pipe_fs_i.h: fix kernel-doc warnings after ..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1589bd4ee00000
kernel config: https://syzkaller.appspot.com/x/.config?x=2802e33434f4f863
dashboard link: https://syzkaller.appspot.com/bug?extid=193c375dcddb4f345091
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13dec65ee00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14c05311e00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+193c375dcddb4f345091@syzkaller.appspotmail.com
executing program
BUG: memory leak
unreferenced object 0xffff8881166b3ac0 (size 32):
comm "syz-executor191", pid 7127, jiffies 4294946216 (age 12.850s)
hex dump (first 32 bytes):
00 66 73 00 00 00 00 00 00 00 00 00 00 00 00 00 .fs.............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000006202a794>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
[<000000006202a794>] slab_post_alloc_hook mm/slab.h:586 [inline]
[<000000006202a794>] slab_alloc mm/slab.c:3320 [inline]
[<000000006202a794>] __do_kmalloc mm/slab.c:3654 [inline]
[<000000006202a794>] __kmalloc_track_caller+0x165/0x300 mm/slab.c:3671
[<000000007e324303>] kstrdup+0x3a/0x70 mm/util.c:60
[<000000002835aac3>] nfs23_parse_monolithic fs/nfs/fs_context.c:958 [inline]
[<000000002835aac3>] nfs_fs_context_parse_monolithic+0x5cf/0x8f0 fs/nfs/fs_context.c:1147
[<000000004fe3f934>] parse_monolithic_mount_data+0x37/0x40 fs/fs_context.c:679
[<00000000dccb779f>] do_new_mount fs/namespace.c:2818 [inline]
[<00000000dccb779f>] do_mount+0x945/0xc80 fs/namespace.c:3107
[<000000006234487e>] __do_sys_mount fs/namespace.c:3316 [inline]
[<000000006234487e>] __se_sys_mount fs/namespace.c:3293 [inline]
[<000000006234487e>] __x64_sys_mount+0xc0/0x140 fs/namespace.c:3293
[<00000000d2937fdd>] do_syscall_64+0x73/0x220 arch/x86/entry/common.c:294
[<00000000fa6ba8f3>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH AUTOSEL 5.4 129/459] drm/amdgpu: remove set but not used variable 'invalid'
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: yu kuai, Alex Deucher, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: yu kuai <yukuai3@huawei.com>
[ Upstream commit 9e089a29c696d86d26e79737bafbce94738fb462 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
‘amdgpu_amdkfd_evict_userptr’:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:1665:6: warning:
variable ‘invalid’ set but not used [-Wunused-but-set-variable]
'invalid' is never used, so can be removed. Thus 'atomic_inc_return'
can be replaced as 'atomic_inc'
Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
Signed-off-by: yu kuai <yukuai3@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 6d021ecc8d598..77e5dcecb4612 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1657,10 +1657,10 @@ int amdgpu_amdkfd_evict_userptr(struct kgd_mem *mem,
struct mm_struct *mm)
{
struct amdkfd_process_info *process_info = mem->process_info;
- int invalid, evicted_bos;
+ int evicted_bos;
int r = 0;
- invalid = atomic_inc_return(&mem->invalid);
+ atomic_inc(&mem->invalid);
evicted_bos = atomic_inc_return(&process_info->evicted_bos);
if (evicted_bos == 1) {
/* First eviction, stop the queues */
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 155/459] PCI/IOV: Fix memory leak in pci_iov_add_virtfn()
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Navid Emamdoost, Bjorn Helgaas, Sasha Levin, linux-pci
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Navid Emamdoost <navid.emamdoost@gmail.com>
[ Upstream commit 8c386cc817878588195dde38e919aa6ba9409d58 ]
In the implementation of pci_iov_add_virtfn() the allocated virtfn is
leaked if pci_setup_device() fails. The error handling is not calling
pci_stop_and_remove_bus_device(). Change the goto label to failed2.
Fixes: 156c55325d30 ("PCI: Check for pci_setup_device() failure in pci_iov_add_virtfn()")
Link: https://lore.kernel.org/r/20191125195255.23740-1-navid.emamdoost@gmail.com
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pci/iov.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index b3f972e8cfed6..deec9f9e0b616 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -187,10 +187,10 @@ int pci_iov_add_virtfn(struct pci_dev *dev, int id)
sprintf(buf, "virtfn%u", id);
rc = sysfs_create_link(&dev->dev.kobj, &virtfn->dev.kobj, buf);
if (rc)
- goto failed2;
+ goto failed1;
rc = sysfs_create_link(&virtfn->dev.kobj, &dev->dev.kobj, "physfn");
if (rc)
- goto failed3;
+ goto failed2;
kobject_uevent(&virtfn->dev.kobj, KOBJ_CHANGE);
@@ -198,11 +198,10 @@ int pci_iov_add_virtfn(struct pci_dev *dev, int id)
return 0;
-failed3:
- sysfs_remove_link(&dev->dev.kobj, buf);
failed2:
- pci_stop_and_remove_bus_device(virtfn);
+ sysfs_remove_link(&dev->dev.kobj, buf);
failed1:
+ pci_stop_and_remove_bus_device(virtfn);
pci_dev_put(dev);
failed0:
virtfn_remove_bus(dev->bus, bus);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 127/459] drm/amdgpu: remove set but not used variable 'amdgpu_connector'
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: yu kuai, Alex Deucher, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: yu kuai <yukuai3@huawei.com>
[ Upstream commit 4f2922d12d6c63d0f4aa4e859ad95aee6d0d4ea0 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: In function
‘amdgpu_display_crtc_scaling_mode_fixup’:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:693:27: warning: variable
‘amdgpu_connector’ set but not used [-Wunused-but-set-variable]
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai <yukuai3@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 82efc1e22e611..21c9cfa40e9d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -687,7 +687,6 @@ bool amdgpu_display_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct amdgpu_encoder *amdgpu_encoder;
struct drm_connector *connector;
- struct amdgpu_connector *amdgpu_connector;
u32 src_v = 1, dst_v = 1;
u32 src_h = 1, dst_h = 1;
@@ -699,7 +698,6 @@ bool amdgpu_display_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
continue;
amdgpu_encoder = to_amdgpu_encoder(encoder);
connector = amdgpu_get_connector_for_encoder(encoder);
- amdgpu_connector = to_amdgpu_connector(connector);
/* set scaling */
if (amdgpu_encoder->rmx_type == RMX_OFF)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 154/459] net/wan/fsl_ucc_hdlc: reject muram offsets above 64K
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rasmus Villemoes, Qiang Zhao, Timur Tabi, David S . Miller,
Li Yang, Sasha Levin, netdev, linuxppc-dev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
[ Upstream commit 148587a59f6b85831695e0497d9dd1af5f0495af ]
Qiang Zhao points out that these offsets get written to 16-bit
registers, and there are some QE platforms with more than 64K
muram. So it is possible that qe_muram_alloc() gives us an allocation
that can't actually be used by the hardware, so detect and reject
that.
Reported-by: Qiang Zhao <qiang.zhao@nxp.com>
Reviewed-by: Timur Tabi <timur@kernel.org>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wan/fsl_ucc_hdlc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index aef7de225783f..4ad0a0c33d853 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -245,6 +245,11 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
ret = -ENOMEM;
goto free_riptr;
}
+ if (riptr != (u16)riptr || tiptr != (u16)tiptr) {
+ dev_err(priv->dev, "MURAM allocation out of addressable range\n");
+ ret = -ENOMEM;
+ goto free_tiptr;
+ }
/* Set RIPTR, TIPTR */
iowrite16be(riptr, &priv->ucc_pram->riptr);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 153/459] regulator: rk808: Lower log level on optional GPIOs being not available
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Miquel Raynal, Mark Brown, Sasha Levin
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Miquel Raynal <miquel.raynal@bootlin.com>
[ Upstream commit b8a039d37792067c1a380dc710361905724b9b2f ]
RK808 can leverage a couple of GPIOs to tweak the ramp rate during DVS
(Dynamic Voltage Scaling). These GPIOs are entirely optional but a
dev_warn() appeared when cleaning this driver to use a more up-to-date
gpiod API. At least reduce the log level to 'info' as it is totally
fine to not populate these GPIO on a hardware design.
This change is trivial but it is worth not polluting the logs during
bringup phase by having real warnings and errors sorted out
correctly.
Fixes: a13eaf02e2d6 ("regulator: rk808: make better use of the gpiod API")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20191203164709.11127-1-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/regulator/rk808-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
index 61bd5ef0806c2..97c846c19c2f6 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -1297,7 +1297,7 @@ static int rk808_regulator_dt_parse_pdata(struct device *dev,
}
if (!pdata->dvs_gpio[i]) {
- dev_warn(dev, "there is no dvs%d gpio\n", i);
+ dev_info(dev, "there is no dvs%d gpio\n", i);
continue;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 01/30] configure: Allow user to specify sphinx-build binary
From: Peter Maydell @ 2020-02-14 17:36 UTC (permalink / raw)
To: Markus Armbruster
Cc: John Snow, Daniel P. Berrangé, QEMU Developers,
Stefan Hajnoczi, Michael Roth
In-Reply-To: <87a75lqe8e.fsf@dusky.pond.sub.org>
On Fri, 14 Feb 2020 at 17:18, Markus Armbruster <armbru@redhat.com> wrote:
> I decided I prefer this as a separate patch, between PATCH 01 and 02.
>
> Hmm, maybe I should squash the last hunk into PATCH 01.
>
>
> From 10d174a9f811708807fb60a610e88084f282c222 Mon Sep 17 00:00:00 2001
> From: Markus Armbruster <armbru@redhat.com>
> Date: Fri, 14 Feb 2020 07:33:43 +0100
> Subject: [PATCH] configure: Pick sphinx-build-3 when available
>
> The next commit will require a sphinx-build that uses Python 3. On
> some systems, sphinx-build is fine, on others you need to use
> sphinx-build-3. To keep things working out of the box on both kinds
> of systems, try sphinx-build-3, then sphinx-build.
>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
> configure | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 14172909f0..4cbeb06b86 100755
> --- a/configure
> +++ b/configure
> @@ -584,7 +584,6 @@ query_pkg_config() {
> }
> pkg_config=query_pkg_config
> sdl2_config="${SDL2_CONFIG-${cross_prefix}sdl2-config}"
> -sphinx_build=sphinx-build
>
> # If the user hasn't specified ARFLAGS, default to 'rv', just as make does.
> ARFLAGS="${ARFLAGS-rv}"
> @@ -903,6 +902,7 @@ fi
>
> : ${make=${MAKE-make}}
> : ${install=${INSTALL-install}}
> +
> # We prefer python 3.x. A bare 'python' is traditionally
> # python 2.x, but some distros have it as python 3.x, so
> # we check that too
Stray whitespace change.
> @@ -915,6 +915,17 @@ do
> break
> fi
> done
> +
> +sphinx_build=
> +for binary in sphinx-build-3 sphinx-build
> +do
> + if has "$binary"
> + then
> + sphinx_build=$(command -v "$binary")
> + break
> + fi
> +done
> +
> : ${smbd=${SMBD-/usr/sbin/smbd}}
>
> # Default objcc to clang if available, otherwise use CC
> @@ -4803,7 +4814,7 @@ has_sphinx_build() {
> # sphinx-build doesn't exist at all or if it is too old.
> mkdir -p "$TMPDIR1/sphinx"
> touch "$TMPDIR1/sphinx/index.rst"
> - $sphinx_build -c "$source_path/docs" -b html "$TMPDIR1/sphinx" "$TMPDIR1/sphinx/out" >/dev/null 2>&1
> + "$sphinx_build" -c "$source_path/docs" -b html "$TMPDIR1/sphinx" "$TMPDIR1/sphinx/out" >/dev/null 2>&1
> }
>
> # Check if tools are available to build documentation.
> --
> 2.21.1
Otherwise
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
-- PMM
^ permalink raw reply
* [PATCH AUTOSEL 5.4 152/459] ASoC: intel: sof_rt5682: Add support for tgl-max98357a-rt5682
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sathyanarayana Nujella, Jairaj Arava, Pierre-Louis Bossart,
Mark Brown, Sasha Levin, alsa-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
[ Upstream commit 6605f0ca3af3b964635287ec7c9dadc812b78eb0 ]
This patch adds the driver data and updates quirk info
for tgl with max98357a speaker amp and ALC5682 headset codec.
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Signed-off-by: Jairaj Arava <jairaj.arava@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191126143205.21987-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/intel/boards/sof_rt5682.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c
index 377ff17dedb98..9441ddfeea5e6 100644
--- a/sound/soc/intel/boards/sof_rt5682.c
+++ b/sound/soc/intel/boards/sof_rt5682.c
@@ -589,6 +589,9 @@ static int sof_audio_probe(struct platform_device *pdev)
if (!ctx)
return -ENOMEM;
+ if (pdev->id_entry && pdev->id_entry->driver_data)
+ sof_rt5682_quirk = (unsigned long)pdev->id_entry->driver_data;
+
dmi_check_system(sof_rt5682_quirk_table);
if (soc_intel_is_byt() || soc_intel_is_cht()) {
@@ -680,6 +683,21 @@ static int sof_rt5682_remove(struct platform_device *pdev)
return 0;
}
+static const struct platform_device_id board_ids[] = {
+ {
+ .name = "sof_rt5682",
+ },
+ {
+ .name = "tgl_max98357a_rt5682",
+ .driver_data = (kernel_ulong_t)(SOF_RT5682_MCLK_EN |
+ SOF_RT5682_SSP_CODEC(0) |
+ SOF_SPEAKER_AMP_PRESENT |
+ SOF_RT5682_SSP_AMP(1) |
+ SOF_RT5682_NUM_HDMIDEV(4)),
+ },
+ { }
+};
+
static struct platform_driver sof_audio = {
.probe = sof_audio_probe,
.remove = sof_rt5682_remove,
@@ -687,6 +705,7 @@ static struct platform_driver sof_audio = {
.name = "sof_rt5682",
.pm = &snd_soc_pm_ops,
},
+ .id_table = board_ids,
};
module_platform_driver(sof_audio)
@@ -696,3 +715,4 @@ MODULE_AUTHOR("Bard Liao <bard.liao@intel.com>");
MODULE_AUTHOR("Sathya Prakash M R <sathya.prakash.m.r@intel.com>");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:sof_rt5682");
+MODULE_ALIAS("platform:tgl_max98357a_rt5682");
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 151/459] ASoC: intel: sof_rt5682: Add quirk for number of HDMI DAI's
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sathyanarayana Nujella, Jairaj Arava, Pierre-Louis Bossart,
Mark Brown, Sasha Levin, alsa-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
[ Upstream commit c68e07970eca79106b0c35b88a12298569590081 ]
TGL supports one more HDMI DAI than previous models.
So add quirk support for number of HDMI DAI's.
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Signed-off-by: Jairaj Arava <jairaj.arava@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191126143205.21987-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/intel/boards/sof_rt5682.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c
index 4f6e58c3954a2..377ff17dedb98 100644
--- a/sound/soc/intel/boards/sof_rt5682.c
+++ b/sound/soc/intel/boards/sof_rt5682.c
@@ -34,6 +34,10 @@
#define SOF_RT5682_SSP_AMP(quirk) \
(((quirk) << SOF_RT5682_SSP_AMP_SHIFT) & SOF_RT5682_SSP_AMP_MASK)
#define SOF_RT5682_MCLK_BYTCHT_EN BIT(9)
+#define SOF_RT5682_NUM_HDMIDEV_SHIFT 10
+#define SOF_RT5682_NUM_HDMIDEV_MASK (GENMASK(12, 10))
+#define SOF_RT5682_NUM_HDMIDEV(quirk) \
+ ((quirk << SOF_RT5682_NUM_HDMIDEV_SHIFT) & SOF_RT5682_NUM_HDMIDEV_MASK)
/* Default: MCLK on, MCLK 19.2M, SSP0 */
static unsigned long sof_rt5682_quirk = SOF_RT5682_MCLK_EN |
@@ -585,6 +589,8 @@ static int sof_audio_probe(struct platform_device *pdev)
if (!ctx)
return -ENOMEM;
+ dmi_check_system(sof_rt5682_quirk_table);
+
if (soc_intel_is_byt() || soc_intel_is_cht()) {
is_legacy_cpu = 1;
dmic_be_num = 0;
@@ -595,11 +601,13 @@ static int sof_audio_probe(struct platform_device *pdev)
SOF_RT5682_SSP_CODEC(2);
} else {
dmic_be_num = 2;
- hdmi_num = 3;
+ hdmi_num = (sof_rt5682_quirk & SOF_RT5682_NUM_HDMIDEV_MASK) >>
+ SOF_RT5682_NUM_HDMIDEV_SHIFT;
+ /* default number of HDMI DAI's */
+ if (!hdmi_num)
+ hdmi_num = 3;
}
- dmi_check_system(sof_rt5682_quirk_table);
-
/* need to get main clock from pmc */
if (sof_rt5682_quirk & SOF_RT5682_MCLK_BYTCHT_EN) {
ctx->mclk = devm_clk_get(&pdev->dev, "pmc_plt_clk_3");
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 150/459] arm64: dts: uDPU: fix broken ethernet
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Russell King, Gregory CLEMENT, Sasha Levin, linux-arm-kernel,
devicetree
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Russell King <rmk+kernel@armlinux.org.uk>
[ Upstream commit 1eebac0240580b531954b02c05068051df41142a ]
The uDPU uses both ethernet controllers, which ties up COMPHY 0 for
eth1 and COMPHY 1 for eth0, with no USB3 comphy. The addition of
COMPHY support made the kernel override the setup by the boot loader
breaking this platform by assuming that COMPHY 0 was always used for
USB3. Delete the USB3 COMPHY definition at platform level, and add
phy specifications for the ethernet channels.
Fixes: bd3d25b07342 ("arm64: dts: marvell: armada-37xx: link USB hosts with their PHYs")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts b/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
index bd4aab6092e0f..e31813a4f9722 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
@@ -143,6 +143,7 @@
phy-mode = "sgmii";
status = "okay";
managed = "in-band-status";
+ phys = <&comphy1 0>;
sfp = <&sfp_eth0>;
};
@@ -150,11 +151,14 @@
phy-mode = "sgmii";
status = "okay";
managed = "in-band-status";
+ phys = <&comphy0 1>;
sfp = <&sfp_eth1>;
};
&usb3 {
status = "okay";
+ phys = <&usb2_utmi_otg_phy>;
+ phy-names = "usb2-utmi-otg-phy";
};
&uart0 {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v6 1/6] perf/cgroup: Reorder perf_cgroup_connect()
From: Peter Zijlstra @ 2020-02-14 17:37 UTC (permalink / raw)
To: Shuah Khan
Cc: Ian Rogers, Ingo Molnar, Arnaldo Carvalho de Melo, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, Andrew Morton,
Randy Dunlap, Masahiro Yamada, Krzysztof Kozlowski, Kees Cook,
Paul E. McKenney, Masami Hiramatsu, Marco Elver, Kent Overstreet,
Andy Shevchenko, Ard Biesheuvel, Gary Hook, Kan Liang,
linux-kernel, Stephane Eranian, Andi Kleen
In-Reply-To: <28dafe17-5a63-cc69-4f1e-fd75edb8b1bd@linuxfoundation.org>
On Fri, Feb 14, 2020 at 09:11:24AM -0700, Shuah Khan wrote:
> On 2/14/20 12:51 AM, Ian Rogers wrote:
> > From: Peter Zijlstra <peterz@infradead.org>
> >
> > Move perf_cgroup_connect() after perf_event_alloc(), such that we can
> > find/use the PMU's cpu context.
>
> Can you elaborate on this usage? It will helpful to know how
> this is used and what do we get from it. What were we missing
> with the way it was done before?
It says so right there. We need it after perf_event_alloc() so that we
can find/use the event's PMU cpu context.
^ permalink raw reply
* Re: Readiness for 14.2.8 ?
From: Jan Fajerski @ 2020-02-14 17:15 UTC (permalink / raw)
To: Yuri Weinstein
Cc: dev, Development, Ceph, Abhishek Lekshmanan, Nathan Cutler,
Casey Bodley, Patrick Donnelly, Neha Ojha, Durgin, Josh,
David Zafman, Weil, Sage, Ramana Venkatesh Raja,
Tamilarasi Muthamizhan, Dillaman, Jason, Sadeh-Weinraub, Yehuda,
Lekshmanan, Abhishek, Ilya Dryomov, Jeff Layton, ceph-qe-team,
Andrew Schoen, ceph-qa
In-Reply-To: <CAMMFjmGWrhC_gd3wY5SfqfSB6O=0Tp_QRAu0ibMTDPVrja2HSg@mail.gmail.com>
On Mon, Feb 10, 2020 at 11:57:19AM -0800, Yuri Weinstein wrote:
>Below is the current queue of PRs:
>https://github.com/ceph/ceph/pulls?page=2&q=is%3Aopen+label%3Anautilus-batch-1+label%3Aneeds-qa
>
>Most PRs are being tested.
>Unless there are objections, we will start QE validation as soon as
>all PRs in this queue were merged.
>
>Dev leads - pls add and tag all RRs that must be included.
ceph-volume is ready, al backports are merged and tested (thank you Nathan!).
>
>Thx
>YuriW
>
--
Jan Fajerski
Senior Software Engineer Enterprise Storage
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
^ permalink raw reply
* [PATCH] Input: gpio_keys_polled - replace zero-length array with flexible-array member
From: Gustavo A. R. Silva @ 2020-02-14 17:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Gustavo A. R. Silva
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/input/keyboard/gpio_keys_polled.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index 6eb0a2f3f9de..c3937d2fc744 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -38,7 +38,7 @@ struct gpio_keys_polled_dev {
const struct gpio_keys_platform_data *pdata;
unsigned long rel_axis_seen[BITS_TO_LONGS(REL_CNT)];
unsigned long abs_axis_seen[BITS_TO_LONGS(ABS_CNT)];
- struct gpio_keys_button_data data[0];
+ struct gpio_keys_button_data data[];
};
static void gpio_keys_button_event(struct input_dev *input,
--
2.25.0
^ permalink raw reply related
* Re: [PATCH userspace v2] libsepol: cache ebitmap cardinality value
From: Stephen Smalley @ 2020-02-14 17:38 UTC (permalink / raw)
To: Ondrej Mosnacek, selinux, James Carter
In-Reply-To: <20200213133959.14217-1-omosnace@redhat.com>
On 2/13/20 8:39 AM, Ondrej Mosnacek wrote:
> According to profiling of semodule -BN, ebitmap_cardinality() is called
> quite often and contributes a lot to the total runtime. Cache its result
> in the ebitmap struct to reduce this overhead. The cached value is
> invalidated on most modifying operations, but ebitmap_cardinality() is
> usually called once the ebitmap doesn't change any more.
>
> After this patch, the time to do 'semodule -BN' on Fedora Rawhide has
> decreased from ~14.6s to ~12.4s (2.2s saved).
>
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
This seems fine but I was wondering how many of the callers of
ebitmap_cardinality() actually need anything more than ebitmap_length()?
> ---
>
> v2: corrected time values in commit message
>
> libsepol/include/sepol/policydb/ebitmap.h | 1 +
> libsepol/src/ebitmap.c | 10 ++++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/libsepol/include/sepol/policydb/ebitmap.h b/libsepol/include/sepol/policydb/ebitmap.h
> index e62df01c..53fafdaa 100644
> --- a/libsepol/include/sepol/policydb/ebitmap.h
> +++ b/libsepol/include/sepol/policydb/ebitmap.h
> @@ -37,6 +37,7 @@ typedef struct ebitmap_node {
> typedef struct ebitmap {
> ebitmap_node_t *node; /* first node in the bitmap */
> uint32_t highbit; /* highest position in the total bitmap */
> + unsigned int cardinality; /* cached value of cardinality */
> } ebitmap_t;
>
> #define ebitmap_length(e) ((e)->highbit)
> diff --git a/libsepol/src/ebitmap.c b/libsepol/src/ebitmap.c
> index 6c9951b7..d23444ce 100644
> --- a/libsepol/src/ebitmap.c
> +++ b/libsepol/src/ebitmap.c
> @@ -67,6 +67,7 @@ int ebitmap_union(ebitmap_t * dst, const ebitmap_t * e1)
> ebitmap_destroy(dst);
> dst->node = tmp.node;
> dst->highbit = tmp.highbit;
> + dst->cardinality = 0;
>
> return 0;
> }
> @@ -128,9 +129,14 @@ int ebitmap_andnot(ebitmap_t *dst, ebitmap_t *e1, ebitmap_t *e2, unsigned int ma
> unsigned int ebitmap_cardinality(ebitmap_t *e1)
> {
> unsigned int i, count = 0;
> +
> + if (e1->cardinality || e1->highbit == 0)
> + return e1->cardinality;
> +
> for (i=ebitmap_startbit(e1); i < ebitmap_length(e1); i++)
> if (ebitmap_get_bit(e1, i))
> count++;
> + e1->cardinality = count;
> return count;
> }
>
> @@ -194,6 +200,7 @@ int ebitmap_cpy(ebitmap_t * dst, const ebitmap_t * src)
> }
>
> dst->highbit = src->highbit;
> + dst->cardinality = src->cardinality;
> return 0;
> }
>
> @@ -309,6 +316,7 @@ int ebitmap_set_bit(ebitmap_t * e, unsigned int bit, int value)
> free(n);
> }
> }
> + e->cardinality = 0; /* invalidate cached cardinality */
> return 0;
> }
> prev = n;
> @@ -339,6 +347,7 @@ int ebitmap_set_bit(ebitmap_t * e, unsigned int bit, int value)
> e->node = new;
> }
>
> + e->cardinality = 0; /* invalidate cached cardinality */
> return 0;
> }
>
> @@ -358,6 +367,7 @@ void ebitmap_destroy(ebitmap_t * e)
>
> e->highbit = 0;
> e->node = 0;
> + e->cardinality = 0;
> return;
> }
>
>
^ permalink raw reply
* [PATCH AUTOSEL 5.4 145/459] ath10k: correct the tlv len of ath10k_wmi_tlv_op_gen_config_pno_start
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Wen Gong, Kalle Valo, Sasha Levin, ath10k, linux-wireless, netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Wen Gong <wgong@codeaurora.org>
[ Upstream commit e01cc82c4d1ec3bddcbb7cd991cf5dc0131ed9a1 ]
the tlv len is set to the total len of the wmi cmd, it will trigger
firmware crash, correct the tlv len.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWP-1 and QCA6174
PCIE with firmware WLAN.RM.4.4.1-00110-QCARMSWPZ-1.
Fixes: ce834e280f2f875 ("ath10k: support NET_DETECT WoWLAN feature")
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 4d5d10c010645..eb0c963d9fd51 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3650,6 +3650,7 @@ ath10k_wmi_tlv_op_gen_config_pno_start(struct ath10k *ar,
struct wmi_tlv *tlv;
struct sk_buff *skb;
__le32 *channel_list;
+ u16 tlv_len;
size_t len;
void *ptr;
u32 i;
@@ -3707,10 +3708,12 @@ ath10k_wmi_tlv_op_gen_config_pno_start(struct ath10k *ar,
/* nlo_configured_parameters(nlo_list) */
cmd->no_of_ssids = __cpu_to_le32(min_t(u8, pno->uc_networks_count,
WMI_NLO_MAX_SSIDS));
+ tlv_len = __le32_to_cpu(cmd->no_of_ssids) *
+ sizeof(struct nlo_configured_parameters);
tlv = ptr;
tlv->tag = __cpu_to_le16(WMI_TLV_TAG_ARRAY_STRUCT);
- tlv->len = __cpu_to_le16(len);
+ tlv->len = __cpu_to_le16(tlv_len);
ptr += sizeof(*tlv);
nlo_list = ptr;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 143/459] drm/radeon: remove set but not used variable 'blocks'
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhengbin, Hulk Robot, Alex Deucher, Sasha Levin, amd-gfx,
dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: zhengbin <zhengbin13@huawei.com>
[ Upstream commit 77441f77949807fda4a0aec0bdf3e86ae863fd56 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_combios.c: In function radeon_combios_get_power_modes:
drivers/gpu/drm/radeon/radeon_combios.c:2638:10: warning: variable blocks set but not used [-Wunused-but-set-variable]
It is introduced by commit 56278a8edace ("drm/radeon/kms:
pull power mode info from bios tables (v3)"), but never used,
so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/radeon/radeon_combios.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c
index c18ae15189f36..87794123e5e4d 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -2638,7 +2638,7 @@ void radeon_combios_get_power_modes(struct radeon_device *rdev)
{
struct drm_device *dev = rdev->ddev;
u16 offset, misc, misc2 = 0;
- u8 rev, blocks, tmp;
+ u8 rev, tmp;
int state_index = 0;
struct radeon_i2c_bus_rec i2c_bus;
@@ -2731,7 +2731,6 @@ void radeon_combios_get_power_modes(struct radeon_device *rdev)
offset = combios_get_table_offset(dev, COMBIOS_POWERPLAY_INFO_TABLE);
if (offset) {
rev = RBIOS8(offset);
- blocks = RBIOS8(offset + 0x2);
/* power mode 0 tends to be the only valid one */
rdev->pm.power_state[state_index].num_clock_modes = 1;
rdev->pm.power_state[state_index].clock_info[0].mclk = RBIOS32(offset + 0x5 + 0x2);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 144/459] drm/radeon: remove set but not used variable 'tv_pll_cntl1'
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhengbin, Hulk Robot, Alex Deucher, Sasha Levin, amd-gfx,
dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: zhengbin <zhengbin13@huawei.com>
[ Upstream commit dc9b3dbd28744510b78490dc6312848a8f918749 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_legacy_tv.c: In function radeon_legacy_tv_mode_set:
drivers/gpu/drm/radeon/radeon_legacy_tv.c:538:24: warning: variable tv_pll_cntl1 set but not used [-Wunused-but-set-variable]
It is introduced by commit 4ce001abafaf ("drm/radeon/kms:
add initial radeon tv-out support."), but never used,
so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/radeon/radeon_legacy_tv.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_tv.c b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
index f132eec737adf..d9df7f311e761 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
@@ -537,7 +537,7 @@ void radeon_legacy_tv_mode_set(struct drm_encoder *encoder,
uint32_t tv_master_cntl, tv_rgb_cntl, tv_dac_cntl;
uint32_t tv_modulator_cntl1, tv_modulator_cntl2;
uint32_t tv_vscaler_cntl1, tv_vscaler_cntl2;
- uint32_t tv_pll_cntl, tv_pll_cntl1, tv_ftotal;
+ uint32_t tv_pll_cntl, tv_ftotal;
uint32_t tv_y_fall_cntl, tv_y_rise_cntl, tv_y_saw_tooth_cntl;
uint32_t m, n, p;
const uint16_t *hor_timing;
@@ -709,12 +709,6 @@ void radeon_legacy_tv_mode_set(struct drm_encoder *encoder,
(((n >> 9) & RADEON_TV_N0HI_MASK) << RADEON_TV_N0HI_SHIFT) |
((p & RADEON_TV_P_MASK) << RADEON_TV_P_SHIFT);
- tv_pll_cntl1 = (((4 & RADEON_TVPCP_MASK) << RADEON_TVPCP_SHIFT) |
- ((4 & RADEON_TVPVG_MASK) << RADEON_TVPVG_SHIFT) |
- ((1 & RADEON_TVPDC_MASK) << RADEON_TVPDC_SHIFT) |
- RADEON_TVCLK_SRC_SEL_TVPLL |
- RADEON_TVPLL_TEST_DIS);
-
tv_dac->tv.tv_uv_adr = 0xc8;
if (tv_dac->tv_std == TV_STD_NTSC ||
--
2.20.1
^ permalink raw reply related
* [PATCH] image.h: Change android_image_get_dtb* to use uint and not u32
From: Tom Rini @ 2020-02-14 17:38 UTC (permalink / raw)
To: u-boot
The image.h header can be used fairly widely in U-Boot builds. We
cannot use u32 here as it may be used in cases where we don't have that
typedef available and don't want to expose it either. Use uint instead
here.
Cc: Eugeniu Rosca <roscaeugeniu@gmail.com>
Cc: Sam Protsenko <joe.skb7@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
include/image.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/image.h b/include/image.h
index b316d167d8d7..1dc3b48d8689 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1425,9 +1425,9 @@ int android_image_get_ramdisk(const struct andr_img_hdr *hdr,
ulong *rd_data, ulong *rd_len);
int android_image_get_second(const struct andr_img_hdr *hdr,
ulong *second_data, ulong *second_len);
-bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, u32 *size);
-bool android_image_get_dtb_by_index(ulong hdr_addr, u32 index, ulong *addr,
- u32 *size);
+bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, uint *size);
+bool android_image_get_dtb_by_index(ulong hdr_addr, uint index, ulong *addr,
+ uint *size);
ulong android_image_get_end(const struct andr_img_hdr *hdr);
ulong android_image_get_kload(const struct andr_img_hdr *hdr);
ulong android_image_get_kcomp(const struct andr_img_hdr *hdr);
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 142/459] drm/radeon: remove set but not used variable 'radeon_connector'
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhengbin, Hulk Robot, Alex Deucher, Sasha Levin, amd-gfx,
dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: zhengbin <zhengbin13@huawei.com>
[ Upstream commit 5952c48993375a9da2de39be30df475cf590b0ce ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_display.c: In function radeon_crtc_scaling_mode_fixup:
drivers/gpu/drm/radeon/radeon_display.c:1685:27: warning: variable radeon_connector set but not used [-Wunused-but-set-variable]
It is not used since commit 377bd8a98d7d ("drm/radeon:
use a fetch function to get the edid")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/radeon/radeon_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index e81b01f8db90e..84d3d885b7a46 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1687,7 +1687,6 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_encoder *radeon_encoder;
struct drm_connector *connector;
- struct radeon_connector *radeon_connector;
bool first = true;
u32 src_v = 1, dst_v = 1;
u32 src_h = 1, dst_h = 1;
@@ -1700,7 +1699,6 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
continue;
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
- radeon_connector = to_radeon_connector(connector);
if (first) {
/* set scaling */
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] ecryptfs: replace BUG_ON with error handling code
From: Tyler Hicks @ 2020-02-14 17:38 UTC (permalink / raw)
To: Aditya Pakki; +Cc: kjlu, ecryptfs, linux-kernel
In-Reply-To: <20191215172404.28204-1-pakki001@umn.edu>
On 2019-12-15 11:24:04, Aditya Pakki wrote:
> In crypt_scatterlist, if the crypt_stat argument is not set up
> correctly, we avoid crashing, by returning the error upstream.
> This patch performs the fix.
>
> Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Hi Aditya - I wanted to check in to see if you are able to submit a new
revision taking into account the feedback from Markus.
Also, I'm curious if you've been able to hit this BUG_ON() or if you are
just being proactive in cleaning up this function?
Let me know if I can help you prepare a v2 of this patch. Thanks!
Tyler
> ---
> fs/ecryptfs/crypto.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
> index f91db24bbf3b..a064b408d841 100644
> --- a/fs/ecryptfs/crypto.c
> +++ b/fs/ecryptfs/crypto.c
> @@ -311,8 +311,10 @@ static int crypt_scatterlist(struct ecryptfs_crypt_stat *crypt_stat,
> struct extent_crypt_result ecr;
> int rc = 0;
>
> - BUG_ON(!crypt_stat || !crypt_stat->tfm
> - || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED));
> + if (!crypt_stat || !crypt_stat->tfm
> + || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED))
> + return -EINVAL;
> +
> if (unlikely(ecryptfs_verbosity > 0)) {
> ecryptfs_printk(KERN_DEBUG, "Key size [%zd]; key:\n",
> crypt_stat->key_size);
> --
> 2.20.1
>
^ permalink raw reply
* [PATCH AUTOSEL 5.4 139/459] drm/radeon: remove set but not used variable 'size', 'relocs_chunk'
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhengbin, Hulk Robot, Alex Deucher, Sasha Levin, amd-gfx,
dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: zhengbin <zhengbin13@huawei.com>
[ Upstream commit e9f782dd22c0e17874b8b8e12aafcd3a06810dd0 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/r600_cs.c: In function r600_cs_track_validate_cb:
drivers/gpu/drm/radeon/r600_cs.c:353:22: warning: variable size set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/radeon/r600_cs.c: In function r600_cs_track_validate_db:
drivers/gpu/drm/radeon/r600_cs.c:520:27: warning: variable size set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/radeon/r600_cs.c: In function r600_dma_cs_next_reloc:
drivers/gpu/drm/radeon/r600_cs.c:2345:26: warning: variable relocs_chunk set but not used [-Wunused-but-set-variable]
The first 'size' is not used since commit f30df2fad0c9 ("drm/radeon/r600:
fix tiling issues in CS checker.")
The second 'size' is introduced by commit 88f50c80748b ("drm/radeon/kms:
add htile support to the cs checker v3"), but never used, so remove it.
'relocs_chunk' is not used since commit 9305ede6afe2 ("radeon/kms:
fix dma relocation checking")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/radeon/r600_cs.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index d6c28a5d77abb..49e8266461f85 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -350,7 +350,7 @@ static void r600_cs_track_init(struct r600_cs_track *track)
static int r600_cs_track_validate_cb(struct radeon_cs_parser *p, int i)
{
struct r600_cs_track *track = p->track;
- u32 slice_tile_max, size, tmp;
+ u32 slice_tile_max, tmp;
u32 height, height_align, pitch, pitch_align, depth_align;
u64 base_offset, base_align;
struct array_mode_checker array_check;
@@ -360,7 +360,6 @@ static int r600_cs_track_validate_cb(struct radeon_cs_parser *p, int i)
/* When resolve is used, the second colorbuffer has always 1 sample. */
unsigned nsamples = track->is_resolve && i == 1 ? 1 : track->nsamples;
- size = radeon_bo_size(track->cb_color_bo[i]) - track->cb_color_bo_offset[i];
format = G_0280A0_FORMAT(track->cb_color_info[i]);
if (!r600_fmt_is_valid_color(format)) {
dev_warn(p->dev, "%s:%d cb invalid format %d for %d (0x%08X)\n",
@@ -517,7 +516,7 @@ static int r600_cs_track_validate_cb(struct radeon_cs_parser *p, int i)
static int r600_cs_track_validate_db(struct radeon_cs_parser *p)
{
struct r600_cs_track *track = p->track;
- u32 nviews, bpe, ntiles, size, slice_tile_max, tmp;
+ u32 nviews, bpe, ntiles, slice_tile_max, tmp;
u32 height_align, pitch_align, depth_align;
u32 pitch = 8192;
u32 height = 8192;
@@ -564,7 +563,6 @@ static int r600_cs_track_validate_db(struct radeon_cs_parser *p)
}
ib[track->db_depth_size_idx] = S_028000_SLICE_TILE_MAX(tmp - 1) | (track->db_depth_size & 0x3FF);
} else {
- size = radeon_bo_size(track->db_bo);
/* pitch in pixels */
pitch = (G_028000_PITCH_TILE_MAX(track->db_depth_size) + 1) * 8;
slice_tile_max = G_028000_SLICE_TILE_MAX(track->db_depth_size) + 1;
@@ -2342,7 +2340,6 @@ int r600_cs_parse(struct radeon_cs_parser *p)
int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
struct radeon_bo_list **cs_reloc)
{
- struct radeon_cs_chunk *relocs_chunk;
unsigned idx;
*cs_reloc = NULL;
@@ -2350,7 +2347,6 @@ int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
DRM_ERROR("No relocation chunk !\n");
return -EINVAL;
}
- relocs_chunk = p->chunk_relocs;
idx = p->dma_reloc_idx;
if (idx >= p->nrelocs) {
DRM_ERROR("Relocs at %d after relocations chunk end %d !\n",
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 113/459] drm/amdkfd: Fix a bug in SDMA RLC queue counting under HWS mode
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Yong Zhao, Felix Kuehling, Alex Deucher, Sasha Levin, amd-gfx,
dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Yong Zhao <Yong.Zhao@amd.com>
[ Upstream commit f38abc15d157b7b31fa7f651dc8bf92858c963f8 ]
The sdma_queue_count increment should be done before
execute_queues_cpsch(), which calls pm_calc_rlib_size() where
sdma_queue_count is used to calculate whether over_subscription is
triggered.
With the previous code, when a SDMA queue is created,
compute_queue_count in pm_calc_rlib_size() is one more than the
actual compute queue number, because the queue_count has been
incremented while sdma_queue_count has not. This patch fixes that.
Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index f335f73919d15..a2ed9c257cb0d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1181,16 +1181,18 @@ static int create_queue_cpsch(struct device_queue_manager *dqm, struct queue *q,
list_add(&q->list, &qpd->queues_list);
qpd->queue_count++;
+
+ if (q->properties.type == KFD_QUEUE_TYPE_SDMA)
+ dqm->sdma_queue_count++;
+ else if (q->properties.type == KFD_QUEUE_TYPE_SDMA_XGMI)
+ dqm->xgmi_sdma_queue_count++;
+
if (q->properties.is_active) {
dqm->queue_count++;
retval = execute_queues_cpsch(dqm,
KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES, 0);
}
- if (q->properties.type == KFD_QUEUE_TYPE_SDMA)
- dqm->sdma_queue_count++;
- else if (q->properties.type == KFD_QUEUE_TYPE_SDMA_XGMI)
- dqm->xgmi_sdma_queue_count++;
/*
* Unconditionally increment this counter, regardless of the queue's
* type or whether the queue is active.
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 137/459] drm/amd/display: remove set but not used variable 'bp' in bios_parser2.c
From: Sasha Levin @ 2020-02-14 15:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhengbin, Harry Wentland, Hulk Robot, Alex Deucher, Sasha Levin,
amd-gfx, dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: zhengbin <zhengbin13@huawei.com>
[ Upstream commit 589d8d282ebe1eab2dd8b1fba3e60322787a50e6 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c: In function bios_get_board_layout_info:
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c:1826:22: warning: variable bp set but not used [-Wunused-but-set-variable]
It is introduced by commit 1eeedbcc20d6 ("drm/amd/display:
get board layout for edid emulation"), but never used,
so remove it.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index dff65c0fe82f8..270035473f120 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1829,7 +1829,6 @@ static enum bp_result bios_get_board_layout_info(
struct board_layout_info *board_layout_info)
{
unsigned int i;
- struct bios_parser *bp;
enum bp_result record_result;
const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
@@ -1838,7 +1837,6 @@ static enum bp_result bios_get_board_layout_info(
0, 0
};
- bp = BP_FROM_DCB(dcb);
if (board_layout_info == NULL) {
DC_LOG_DETECTION_EDID_PARSER("Invalid board_layout_info\n");
return BP_RESULT_BADINPUT;
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.