Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add periodictimer to net/MRP to enable retries #48

Closed
wants to merge 3 commits into from

Conversation

noelbk
Copy link
Contributor

@noelbk noelbk commented Sep 16, 2013

Added periodic timer from [802.1Q-2011] to retry if MRP loses messages. MRP used to lose JoinIn messages and never retry if it sent messages before the interface became ready.

The periodic timer from the 802.1Q spec never turns off. It fires every second, causing MRP to bounce from state QA to AA and back. You might think that would stop when the registrar responds with an JoinIn, but there's no state in the MRP state table to ignore the periodic timer after getting a reply. The result is MRP sends a JoinIn message every second. This may not be desirable, but it's what the spec requires.

[802.1Q-2011]
http://standards.ieee.org/findstds/standard/802.1Q-2011.html

@torvalds
Copy link
Owner

This is not how to do kernel development. You need to talk to the
maintainers of the code in question, which in this case would be

./scripts/get_maintainer.pl -f net/802/mrp.c:

"David S. Miller" davem@davemloft.net (maintainer:NETWORKING
[GENERAL],commit_signer:4/4=100%)
David Ward david.ward@ll.mit.edu (commit_signer:2/4=50%)
Patrick McHardy kaber@trash.net (commit_signer:1/4=25%)
Stephen Hemminger stephen@networkplumber.org (commit_signer:1/4=25%)
Eric Dumazet edumazet@google.com (commit_signer:1/4=25%)
netdev@vger.kernel.org (open list:NETWORKING [GENERAL])

and I'm pretty sure that they don't want just some random github pull
request either. Patches, explanations, background. And then when
they trust you, you can use the proper git "request-pull" script to
generate a high-quality pull request that you send from a real email
address, not the random stuff github generates. That said, for a
single small commit, an actual emailed patch is probably the way to
go.

github people - is there really no way to turn off Pull requests like
this and have an explanation pointing to
Documentation/SubmittingPatches or something? The kernel doesn't take
github pull requests, and never will. They don't contain enough
information, and they don't have the proper context.

                 Linus

On Mon, Sep 16, 2013 at 1:34 PM, noelbk notifications@github.com wrote:

Added periodic timer from [802.1Q-2011] to retry if MRP loses messages. MRP
used to lose JoinIn messages and never retry if it sent messages before the
interface became ready.

The periodic timer from the 802.1Q spec never turns off. It fires every
second, causing MRP to bounce from state QA to AA and back. You might think
that would stop when the registrar responds with an JoinIn, but there's no
state in the MRP state table to ignore the periodic timer after getting a
reply. The result is MRP sends a JoinIn message every second. This may not
be desirable, but it's what the spec requires.

[802.1Q-2011]
http://standards.ieee.org/findstds/standard/802.1Q-2011.html


You can merge this Pull Request by running

git pull https://github.com/noelbk/linux master

Or view, comment on, or merge it at:

#48

Commit Summary

added periodictimer to mrp to allow retries when packets get lost
cleaned up debug prints before committing back to master
clean up before pull request

File Changes

M include/net/mrp.h (1)
M net/802/mrp.c (45)

Patch Links:

https://github.com/torvalds/linux/pull/48.patch
https://github.com/torvalds/linux/pull/48.diff

@noelbk
Copy link
Contributor Author

noelbk commented Sep 16, 2013

Oops, sorry for wasting your time. I tried looking for a HOWTO to submit
this, but totally missed Documentation/SubmittingPatches. Duh.

Cheers,

Noel

On Mon, Sep 16, 2013 at 12:53 PM, Linus Torvalds
notifications@github.comwrote:

This is not how to do kernel development. You need to talk to the
maintainers of the code in question, which in this case would be

./scripts/get_maintainer.pl -f net/802/mrp.c:

"David S. Miller" davem@davemloft.net (maintainer:NETWORKING
[GENERAL],commit_signer:4/4=100%)
David Ward david.ward@ll.mit.edu (commit_signer:2/4=50%)
Patrick McHardy kaber@trash.net (commit_signer:1/4=25%)
Stephen Hemminger stephen@networkplumber.org (commit_signer:1/4=25%)
Eric Dumazet edumazet@google.com (commit_signer:1/4=25%)
netdev@vger.kernel.org (open list:NETWORKING [GENERAL])

and I'm pretty sure that they don't want just some random github pull
request either. Patches, explanations, background. And then when
they trust you, you can use the proper git "request-pull" script to
generate a high-quality pull request that you send from a real email
address, not the random stuff github generates. That said, for a
single small commit, an actual emailed patch is probably the way to
go.

github people - is there really no way to turn off Pull requests like
this and have an explanation pointing to
Documentation/SubmittingPatches or something? The kernel doesn't take
github pull requests, and never will. They don't contain enough
information, and they don't have the proper context.

Linus

On Mon, Sep 16, 2013 at 1:34 PM, noelbk notifications@github.com wrote:

Added periodic timer from [802.1Q-2011] to retry if MRP loses messages.
MRP
used to lose JoinIn messages and never retry if it sent messages before
the
interface became ready.

The periodic timer from the 802.1Q spec never turns off. It fires every
second, causing MRP to bounce from state QA to AA and back. You might
think
that would stop when the registrar responds with an JoinIn, but there's
no
state in the MRP state table to ignore the periodic timer after getting a
reply. The result is MRP sends a JoinIn message every second. This may
not
be desirable, but it's what the spec requires.

[802.1Q-2011]
http://standards.ieee.org/findstds/standard/802.1Q-2011.html


You can merge this Pull Request by running

git pull https://github.com/noelbk/linux master

Or view, comment on, or merge it at:

#48

Commit Summary

added periodictimer to mrp to allow retries when packets get lost
cleaned up debug prints before committing back to master
clean up before pull request

File Changes

M include/net/mrp.h (1)
M net/802/mrp.c (45)

Patch Links:

https://github.com/torvalds/linux/pull/48.patch
https://github.com/torvalds/linux/pull/48.diff


Reply to this email directly or view it on GitHubhttps://github.com//pull/48#issuecomment-24539030
.

swarren pushed a commit to swarren/linux-tegra that referenced this pull request Oct 14, 2013
As the new x86 CPU bootup printout format code maintainer, I am
taking immediate action to improve and clean (and thus indulge
my OCD) the reporting of the cores when coming up online.

Fix padding to a right-hand alignment, cleanup code and bind
reporting width to the max number of supported CPUs on the
system, like this:

 [    0.074509] smpboot: Booting Node   0, Processors:      #1  #2  #3  #4  #5  torvalds#6  torvalds#7 OK
 [    0.644008] smpboot: Booting Node   1, Processors:  torvalds#8  torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 OK
 [    1.245006] smpboot: Booting Node   2, Processors: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 OK
 [    1.864005] smpboot: Booting Node   3, Processors: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 OK
 [    2.489005] smpboot: Booting Node   4, Processors: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 OK
 [    3.093005] smpboot: Booting Node   5, Processors: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 OK
 [    3.698005] smpboot: Booting Node   6, Processors: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 OK
 [    4.304005] smpboot: Booting Node   7, Processors: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 OK
 [    4.961413] Brought up 64 CPUs

and this:

 [    0.072367] smpboot: Booting Node   0, Processors:    #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK
 [    0.686329] Brought up 8 CPUs

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Libin <huawei.libin@huawei.com>
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Link: http://lkml.kernel.org/r/20130927143554.GF4422@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
swarren pushed a commit to swarren/linux-tegra that referenced this pull request Oct 14, 2013
Turn it into (for example):

[    0.073380] x86: Booting SMP configuration:
[    0.074005] .... node   #0, CPUs:          #1   #2   #3   #4   #5   torvalds#6   torvalds#7
[    0.603005] .... node   #1, CPUs:     torvalds#8   torvalds#9  torvalds#10  torvalds#11  torvalds#12  torvalds#13  torvalds#14  torvalds#15
[    1.200005] .... node   #2, CPUs:    torvalds#16  torvalds#17  torvalds#18  torvalds#19  torvalds#20  torvalds#21  torvalds#22  torvalds#23
[    1.796005] .... node   #3, CPUs:    torvalds#24  torvalds#25  torvalds#26  torvalds#27  torvalds#28  torvalds#29  torvalds#30  torvalds#31
[    2.393005] .... node   #4, CPUs:    torvalds#32  torvalds#33  torvalds#34  torvalds#35  torvalds#36  torvalds#37  torvalds#38  torvalds#39
[    2.996005] .... node   #5, CPUs:    torvalds#40  torvalds#41  torvalds#42  torvalds#43  torvalds#44  torvalds#45  torvalds#46  torvalds#47
[    3.600005] .... node   torvalds#6, CPUs:    torvalds#48  torvalds#49  torvalds#50  torvalds#51  #52  #53  torvalds#54  torvalds#55
[    4.202005] .... node   torvalds#7, CPUs:    torvalds#56  torvalds#57  #58  torvalds#59  torvalds#60  torvalds#61  torvalds#62  torvalds#63
[    4.811005] .... node   torvalds#8, CPUs:    torvalds#64  torvalds#65  torvalds#66  torvalds#67  torvalds#68  torvalds#69  #70  torvalds#71
[    5.421006] .... node   torvalds#9, CPUs:    torvalds#72  torvalds#73  torvalds#74  torvalds#75  torvalds#76  torvalds#77  torvalds#78  torvalds#79
[    6.032005] .... node  torvalds#10, CPUs:    torvalds#80  torvalds#81  torvalds#82  torvalds#83  torvalds#84  torvalds#85  torvalds#86  torvalds#87
[    6.648006] .... node  torvalds#11, CPUs:    torvalds#88  torvalds#89  torvalds#90  torvalds#91  torvalds#92  torvalds#93  torvalds#94  torvalds#95
[    7.262005] .... node  torvalds#12, CPUs:    torvalds#96  torvalds#97  torvalds#98  torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103
[    7.865005] .... node  torvalds#13, CPUs:   torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111
[    8.466005] .... node  torvalds#14, CPUs:   torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119
[    9.073006] .... node  torvalds#15, CPUs:   torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127
[    9.679901] x86: Booted up 16 nodes, 128 CPUs

and drop useless elements.

Change num_digits() to hpa's division-avoiding, cell-phone-typed
version which he went at great lengths and pains to submit on a
Saturday evening.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
rjwysocki pushed a commit to rjwysocki/linux-pm that referenced this pull request Jan 9, 2014
This reverts commit 9d046cc.

Commit 9d046cc marks all state tables with __initdata, but
the state table may be accessed when doing CPU online, which then
causing system crash as below:

[  204.188841] BUG: unable to handle kernel paging request at ffffffff8227cce8
[  204.196844] IP: [<ffffffff814aa1c0>] intel_idle_cpu_init+0x40/0x130
[  204.203996] PGD 1e11067 PUD 1e12063 PMD 455859063 PTE 800000000227c062
[  204.211638] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[  204.216975] Modules linked in: x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd gpio_ich microcode joydev sb_edac edac_core ipmi_si lpc_ich ipmi_msghandler lp tpm_tis parport wmi mac_hid acpi_pad hid_generic ixgbe isci usbhid dca hid libsas ptp ahci libahci scsi_transport_sas megaraid_sas pps_core mdio
[  204.262815] CPU: 11 PID: 1489 Comm: bash Not tainted 3.13.0-rc7+ torvalds#48
[  204.269993] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0047.L09.1312061514 12/06/2013
[  204.281646] task: ffff8804303a24a0 ti: ffff880440fac000 task.ti: ffff880440fac000
[  204.290311] RIP: 0010:[<ffffffff814aa1c0>]  [<ffffffff814aa1c0>] intel_idle_cpu_init+0x40/0x130
[  204.300184] RSP: 0018:ffff880440fadd28  EFLAGS: 00010286
[  204.306192] RAX: ffffffff8227cca0 RBX: ffffe8fff1a03400 RCX: 0000000000000007
[  204.314244] RDX: ffff88045f400000 RSI: 0000000000000009 RDI: 0000000000001120
[  204.322296] RBP: ffff880440fadd38 R08: 0000000000000000 R09: 0000000000000001
[  204.330411] R10: 0000000000000001 R11: 0000000000000000 R12: 000000000000001e
[  204.338482] R13: 00000000ffffffdb R14: 0000000000000001 R15: 0000000000000000
[  204.346743] FS:  00007f64f7b0c740(0000) GS:ffff88045ce00000(0000) knlGS:0000000000000000
[  204.355919] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  204.362449] CR2: ffffffff8227cce8 CR3: 0000000444ab0000 CR4: 00000000001407e0
[  204.370520] Stack:
[  204.372853]  000000000000001e ffffffff81f10240 ffff880440fadd50 ffffffff814aa307
[  204.381519]  ffffffff81ea80e0 ffff880440fadda0 ffffffff8185a230 0000000000000000
[  204.390196]  000000000000001e 0000000000000002 0000000000000002 0000000000000000
[  204.398856] Call Trace:
[  204.401683]  [<ffffffff814aa307>] cpu_hotplug_notify+0x57/0x70
[  204.408638]  [<ffffffff8185a230>] notifier_call_chain+0x100/0x150
[  204.415553]  [<ffffffff810a7dae>] __raw_notifier_call_chain+0xe/0x10
[  204.422772]  [<ffffffff81072163>] cpu_notify+0x23/0x50
[  204.428616]  [<ffffffff810723b2>] _cpu_up+0x132/0x1a0
[  204.434361]  [<ffffffff8107249d>] cpu_up+0x7d/0xa0
[  204.439819]  [<ffffffff81836c9c>] cpu_subsys_online+0x3c/0x90
[  204.446345]  [<ffffffff81554625>] device_online+0x45/0xa0
[  204.452471]  [<ffffffff815546ce>] online_store+0x4e/0x80
[  204.458511]  [<ffffffff815519a8>] dev_attr_store+0x18/0x30
[  204.464744]  [<ffffffff812a68f1>] sysfs_write_file+0x151/0x1c0
[  204.471681]  [<ffffffff81217ef1>] vfs_write+0xe1/0x160
[  204.477524]  [<ffffffff8121889c>] SyS_write+0x4c/0x90
[  204.483270]  [<ffffffff8185f2ed>] system_call_fastpath+0x1a/0x1f
[  204.490081] Code: 41 54 41 89 fc 8b 3d 48 25 85 01 53 48 8b 1d 30 25 85 01 48 03 1c c5 40 90 fb 81 48 8b 05 19 25 85 01 c7 43 0c 01 00 00 00 66 90 <48> 83 78 48 00 74 4f 41 83 c0 01 41 39 f0 7e 10 48 c7 c7 38 79
[  204.515723] RIP  [<ffffffff814aa1c0>] intel_idle_cpu_init+0x40/0x130
[  204.522996]  RSP <ffff880440fadd28>
[  204.526976] CR2: ffffffff8227cce8
[  204.530766] ---[ end trace 336f56cc3d1cfc8c ]---

Fixes: 9d046cc (intel_idle: mark states tables with __initdata tag)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
andy-shev pushed a commit to andy-shev/linux that referenced this pull request Jan 24, 2015
…atch-fixes

WARNING: Missing a blank line after declarations
torvalds#48: FILE: fs/notify/fanotify/fanotify_user.c:495:
+		__u32 tmask = fsn_mark->mask & ~mask;
+		if (flags & FAN_MARK_ONDIR)

WARNING: Missing a blank line after declarations
torvalds#67: FILE: fs/notify/fanotify/fanotify_user.c:579:
+		__u32 tmask = fsn_mark->mask | mask;
+		if (flags & FAN_MARK_ONDIR)

total: 0 errors, 2 warnings, 54 lines checked

./patches/fanotify-dont-set-fan_ondir-implicitly-on-a-marks-ignored-mask.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
@noelbk noelbk closed this Feb 6, 2015
gthelen pushed a commit to gthelen/linux that referenced this pull request Apr 1, 2015
Sumeone needs to buy a tab key.

WARNING: please, no spaces at the start of a line
torvalds#29: FILE: security/tomoyo/util.c:951:
+       struct file *exe_file;$

WARNING: please, no spaces at the start of a line
torvalds#30: FILE: security/tomoyo/util.c:952:
+       const char *cp;$

WARNING: please, no spaces at the start of a line
torvalds#31: FILE: security/tomoyo/util.c:953:
+       struct mm_struct *mm = current->mm;$

WARNING: please, no spaces at the start of a line
torvalds#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)$

WARNING: suspect code indent for conditional statements (7, 15)
torvalds#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)
+	       return NULL;

WARNING: please, no spaces at the start of a line
torvalds#42: FILE: security/tomoyo/util.c:957:
+       exe_file = get_mm_exe_file(mm);$

WARNING: please, no spaces at the start of a line
torvalds#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)$

WARNING: suspect code indent for conditional statements (7, 15)
torvalds#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)
+	       return NULL;

WARNING: please, no spaces at the start of a line
torvalds#46: FILE: security/tomoyo/util.c:961:
+       cp = tomoyo_realpath_from_path(&exe_file->f_path);$

WARNING: please, no spaces at the start of a line
torvalds#47: FILE: security/tomoyo/util.c:962:
+       fput(exe_file);$

WARNING: please, no spaces at the start of a line
torvalds#48: FILE: security/tomoyo/util.c:963:
+       return cp;$

total: 0 errors, 11 warnings, 28 lines checked

./patches/tomoyo-reduce-mmap_sem-hold-for-mm-exe_file.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: James Morris <jmorris@namei.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
torvalds pushed a commit that referenced this pull request Apr 14, 2015
Commit 297d716 ("power_supply: Change ownership from driver to
core") inverted the logic in battery_notify().  As an effect already
present battery was re-added on each system suspend or hibernation.

    WARNING: CPU: 0 PID: 303 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80()
    sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT0'
    CPU: 0 PID: 303 Comm: rtcwake Not tainted 4.0.0-ARCH-02621-g07e6253af953 #48
    Call Trace:
      sysfs_create_dir_ns+0x8d/0xa0
      kobject_add_internal+0xb6/0x370
      kobject_add+0x6f/0xd0
      device_add+0x120/0x6c0
      __power_supply_register+0x145/0x290
      power_supply_register_no_ws+0x10/0x20
      sysfs_add_battery+0x84/0xc5 [battery]
      battery_notify+0x45/0x6b [battery]
      notifier_call_chain+0x4f/0x80
      __blocking_notifier_call_chain+0x4b/0x70
      blocking_notifier_call_chain+0x16/0x20
      pm_notifier_call_chain+0x1a/0x40
      pm_suspend+0x3ed/0x4e0

Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
aejsmith pushed a commit to aejsmith/linux that referenced this pull request Jul 20, 2015
Ci20 v3.18 Add audio over hdmi + mono sound fixes
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Oct 22, 2015
the returned buffer of register_sysctl() is stored into net_header
variable, but net_header is not used after, and compiler maybe
optimise the variable out, and lead kmemleak reported the below warning

	comm "swapper/0", pid 1, jiffies 4294937448 (age 267.270s)
	hex dump (first 32 bytes):
	90 38 8b 01 c0 ff ff ff 00 00 00 00 01 00 00 00 .8..............
	01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
	backtrace:
	[<ffffffc00020f134>] create_object+0x10c/0x2a0
	[<ffffffc00070ff44>] kmemleak_alloc+0x54/0xa0
	[<ffffffc0001fe378>] __kmalloc+0x1f8/0x4f8
	[<ffffffc00028e984>] __register_sysctl_table+0x64/0x5a0
	[<ffffffc00028eef0>] register_sysctl+0x30/0x40
	[<ffffffc00099c304>] net_sysctl_init+0x20/0x58
	[<ffffffc000994dd8>] sock_init+0x10/0xb0
	[<ffffffc0000842e0>] do_one_initcall+0x90/0x1b8
	[<ffffffc000966bac>] kernel_init_freeable+0x218/0x2f0
	[<ffffffc00070ed6c>] kernel_init+0x1c/0xe8
	[<ffffffc000083bfc>] ret_from_fork+0xc/0x50
	[<ffffffffffffffff>] 0xffffffffffffffff <<end check kmemleak>>

Before fix, the objdump result on ARM64:
0000000000000000 <net_sysctl_init>:
   0:   a9be7bfd        stp     x29, x30, [sp,#-32]!
   4:   90000001        adrp    x1, 0 <net_sysctl_init>
   8:   90000000        adrp    x0, 0 <net_sysctl_init>
   c:   910003fd        mov     x29, sp
  10:   91000021        add     x1, x1, #0x0
  14:   91000000        add     x0, x0, #0x0
  18:   a90153f3        stp     x19, x20, [sp,torvalds#16]
  1c:   12800174        mov     w20, #0xfffffff4                // #-12
  20:   94000000        bl      0 <register_sysctl>
  24:   b4000120        cbz     x0, 48 <net_sysctl_init+0x48>
  28:   90000013        adrp    x19, 0 <net_sysctl_init>
  2c:   91000273        add     x19, x19, #0x0
  30:   9101a260        add     x0, x19, #0x68
  34:   94000000        bl      0 <register_pernet_subsys>
  38:   2a0003f4        mov     w20, w0
  3c:   35000060        cbnz    w0, 48 <net_sysctl_init+0x48>
  40:   aa1303e0        mov     x0, x19
  44:   94000000        bl      0 <register_sysctl_root>
  48:   2a1403e0        mov     w0, w20
  4c:   a94153f3        ldp     x19, x20, [sp,torvalds#16]
  50:   a8c27bfd        ldp     x29, x30, [sp],torvalds#32
  54:   d65f03c0        ret
After:
0000000000000000 <net_sysctl_init>:
   0:   a9bd7bfd        stp     x29, x30, [sp,#-48]!
   4:   90000000        adrp    x0, 0 <net_sysctl_init>
   8:   910003fd        mov     x29, sp
   c:   a90153f3        stp     x19, x20, [sp,torvalds#16]
  10:   90000013        adrp    x19, 0 <net_sysctl_init>
  14:   91000000        add     x0, x0, #0x0
  18:   91000273        add     x19, x19, #0x0
  1c:   f90013f5        str     x21, [sp,torvalds#32]
  20:   aa1303e1        mov     x1, x19
  24:   12800175        mov     w21, #0xfffffff4                // #-12
  28:   94000000        bl      0 <register_sysctl>
  2c:   f9002260        str     x0, [x19,torvalds#64]
  30:   b40001c0        cbz     x0, 68 <net_sysctl_init+0x68>
  34:   90000014        adrp    x20, 0 <net_sysctl_init>
  38:   91000294        add     x20, x20, #0x0
  3c:   9101a280        add     x0, x20, #0x68
  40:   94000000        bl      0 <register_pernet_subsys>
  44:   2a0003f5        mov     w21, w0
  48:   35000080        cbnz    w0, 58 <net_sysctl_init+0x58>
  4c:   aa1403e0        mov     x0, x20
  50:   94000000        bl      0 <register_sysctl_root>
  54:   14000005        b       68 <net_sysctl_init+0x68>
  58:   f9402260        ldr     x0, [x19,torvalds#64]
  5c:   94000000        bl      0 <unregister_sysctl_table>
  60:   f9402260        ldr     x0, [x19,torvalds#64]
  64:   94000000        bl      0 <kfree>
  68:   2a1503e0        mov     w0, w21
  6c:   f94013f5        ldr     x21, [sp,torvalds#32]
  70:   a94153f3        ldp     x19, x20, [sp,torvalds#16]
  74:   a8c37bfd        ldp     x29, x30, [sp],torvalds#48
  78:   d65f03c0        ret

Add the possible error handle to free the net_header to remove the
kmemleak warning

Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Oct 23, 2015
the returned buffer of register_sysctl() is stored into net_header
variable, but net_header is not used after, and compiler maybe
optimise the variable out, and lead kmemleak reported the below warning

	comm "swapper/0", pid 1, jiffies 4294937448 (age 267.270s)
	hex dump (first 32 bytes):
	90 38 8b 01 c0 ff ff ff 00 00 00 00 01 00 00 00 .8..............
	01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
	backtrace:
	[<ffffffc00020f134>] create_object+0x10c/0x2a0
	[<ffffffc00070ff44>] kmemleak_alloc+0x54/0xa0
	[<ffffffc0001fe378>] __kmalloc+0x1f8/0x4f8
	[<ffffffc00028e984>] __register_sysctl_table+0x64/0x5a0
	[<ffffffc00028eef0>] register_sysctl+0x30/0x40
	[<ffffffc00099c304>] net_sysctl_init+0x20/0x58
	[<ffffffc000994dd8>] sock_init+0x10/0xb0
	[<ffffffc0000842e0>] do_one_initcall+0x90/0x1b8
	[<ffffffc000966bac>] kernel_init_freeable+0x218/0x2f0
	[<ffffffc00070ed6c>] kernel_init+0x1c/0xe8
	[<ffffffc000083bfc>] ret_from_fork+0xc/0x50
	[<ffffffffffffffff>] 0xffffffffffffffff <<end check kmemleak>>

Before fix, the objdump result on ARM64:
0000000000000000 <net_sysctl_init>:
   0:   a9be7bfd        stp     x29, x30, [sp,#-32]!
   4:   90000001        adrp    x1, 0 <net_sysctl_init>
   8:   90000000        adrp    x0, 0 <net_sysctl_init>
   c:   910003fd        mov     x29, sp
  10:   91000021        add     x1, x1, #0x0
  14:   91000000        add     x0, x0, #0x0
  18:   a90153f3        stp     x19, x20, [sp,torvalds#16]
  1c:   12800174        mov     w20, #0xfffffff4                // #-12
  20:   94000000        bl      0 <register_sysctl>
  24:   b4000120        cbz     x0, 48 <net_sysctl_init+0x48>
  28:   90000013        adrp    x19, 0 <net_sysctl_init>
  2c:   91000273        add     x19, x19, #0x0
  30:   9101a260        add     x0, x19, #0x68
  34:   94000000        bl      0 <register_pernet_subsys>
  38:   2a0003f4        mov     w20, w0
  3c:   35000060        cbnz    w0, 48 <net_sysctl_init+0x48>
  40:   aa1303e0        mov     x0, x19
  44:   94000000        bl      0 <register_sysctl_root>
  48:   2a1403e0        mov     w0, w20
  4c:   a94153f3        ldp     x19, x20, [sp,torvalds#16]
  50:   a8c27bfd        ldp     x29, x30, [sp],torvalds#32
  54:   d65f03c0        ret
After:
0000000000000000 <net_sysctl_init>:
   0:   a9bd7bfd        stp     x29, x30, [sp,#-48]!
   4:   90000000        adrp    x0, 0 <net_sysctl_init>
   8:   910003fd        mov     x29, sp
   c:   a90153f3        stp     x19, x20, [sp,torvalds#16]
  10:   90000013        adrp    x19, 0 <net_sysctl_init>
  14:   91000000        add     x0, x0, #0x0
  18:   91000273        add     x19, x19, #0x0
  1c:   f90013f5        str     x21, [sp,torvalds#32]
  20:   aa1303e1        mov     x1, x19
  24:   12800175        mov     w21, #0xfffffff4                // #-12
  28:   94000000        bl      0 <register_sysctl>
  2c:   f9002260        str     x0, [x19,torvalds#64]
  30:   b40001a0        cbz     x0, 64 <net_sysctl_init+0x64>
  34:   90000014        adrp    x20, 0 <net_sysctl_init>
  38:   91000294        add     x20, x20, #0x0
  3c:   9101a280        add     x0, x20, #0x68
  40:   94000000        bl      0 <register_pernet_subsys>
  44:   2a0003f5        mov     w21, w0
  48:   35000080        cbnz    w0, 58 <net_sysctl_init+0x58>
  4c:   aa1403e0        mov     x0, x20
  50:   94000000        bl      0 <register_sysctl_root>
  54:   14000004        b       64 <net_sysctl_init+0x64>
  58:   f9402260        ldr     x0, [x19,torvalds#64]
  5c:   94000000        bl      0 <unregister_sysctl_table>
  60:   f900227f        str     xzr, [x19,torvalds#64]
  64:   2a1503e0        mov     w0, w21
  68:   f94013f5        ldr     x21, [sp,torvalds#32]
  6c:   a94153f3        ldp     x19, x20, [sp,torvalds#16]
  70:   a8c37bfd        ldp     x29, x30, [sp],torvalds#48
  74:   d65f03c0        ret

Add the possible error handle to free the net_header to remove the
kmemleak warning

Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Oct 23, 2015
the returned buffer of register_sysctl() is stored into net_header
variable, but net_header is not used after, and compiler maybe
optimise the variable out, and lead kmemleak reported the below warning

	comm "swapper/0", pid 1, jiffies 4294937448 (age 267.270s)
	hex dump (first 32 bytes):
	90 38 8b 01 c0 ff ff ff 00 00 00 00 01 00 00 00 .8..............
	01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
	backtrace:
	[<ffffffc00020f134>] create_object+0x10c/0x2a0
	[<ffffffc00070ff44>] kmemleak_alloc+0x54/0xa0
	[<ffffffc0001fe378>] __kmalloc+0x1f8/0x4f8
	[<ffffffc00028e984>] __register_sysctl_table+0x64/0x5a0
	[<ffffffc00028eef0>] register_sysctl+0x30/0x40
	[<ffffffc00099c304>] net_sysctl_init+0x20/0x58
	[<ffffffc000994dd8>] sock_init+0x10/0xb0
	[<ffffffc0000842e0>] do_one_initcall+0x90/0x1b8
	[<ffffffc000966bac>] kernel_init_freeable+0x218/0x2f0
	[<ffffffc00070ed6c>] kernel_init+0x1c/0xe8
	[<ffffffc000083bfc>] ret_from_fork+0xc/0x50
	[<ffffffffffffffff>] 0xffffffffffffffff <<end check kmemleak>>

Before fix, the objdump result on ARM64:
0000000000000000 <net_sysctl_init>:
   0:   a9be7bfd        stp     x29, x30, [sp,#-32]!
   4:   90000001        adrp    x1, 0 <net_sysctl_init>
   8:   90000000        adrp    x0, 0 <net_sysctl_init>
   c:   910003fd        mov     x29, sp
  10:   91000021        add     x1, x1, #0x0
  14:   91000000        add     x0, x0, #0x0
  18:   a90153f3        stp     x19, x20, [sp,torvalds#16]
  1c:   12800174        mov     w20, #0xfffffff4                // #-12
  20:   94000000        bl      0 <register_sysctl>
  24:   b4000120        cbz     x0, 48 <net_sysctl_init+0x48>
  28:   90000013        adrp    x19, 0 <net_sysctl_init>
  2c:   91000273        add     x19, x19, #0x0
  30:   9101a260        add     x0, x19, #0x68
  34:   94000000        bl      0 <register_pernet_subsys>
  38:   2a0003f4        mov     w20, w0
  3c:   35000060        cbnz    w0, 48 <net_sysctl_init+0x48>
  40:   aa1303e0        mov     x0, x19
  44:   94000000        bl      0 <register_sysctl_root>
  48:   2a1403e0        mov     w0, w20
  4c:   a94153f3        ldp     x19, x20, [sp,torvalds#16]
  50:   a8c27bfd        ldp     x29, x30, [sp],torvalds#32
  54:   d65f03c0        ret
After:
0000000000000000 <net_sysctl_init>:
   0:   a9bd7bfd        stp     x29, x30, [sp,#-48]!
   4:   90000000        adrp    x0, 0 <net_sysctl_init>
   8:   910003fd        mov     x29, sp
   c:   a90153f3        stp     x19, x20, [sp,torvalds#16]
  10:   90000013        adrp    x19, 0 <net_sysctl_init>
  14:   91000000        add     x0, x0, #0x0
  18:   91000273        add     x19, x19, #0x0
  1c:   f90013f5        str     x21, [sp,torvalds#32]
  20:   aa1303e1        mov     x1, x19
  24:   12800175        mov     w21, #0xfffffff4                // #-12
  28:   94000000        bl      0 <register_sysctl>
  2c:   f9002260        str     x0, [x19,torvalds#64]
  30:   b40001a0        cbz     x0, 64 <net_sysctl_init+0x64>
  34:   90000014        adrp    x20, 0 <net_sysctl_init>
  38:   91000294        add     x20, x20, #0x0
  3c:   9101a280        add     x0, x20, #0x68
  40:   94000000        bl      0 <register_pernet_subsys>
  44:   2a0003f5        mov     w21, w0
  48:   35000080        cbnz    w0, 58 <net_sysctl_init+0x58>
  4c:   aa1403e0        mov     x0, x20
  50:   94000000        bl      0 <register_sysctl_root>
  54:   14000004        b       64 <net_sysctl_init+0x64>
  58:   f9402260        ldr     x0, [x19,torvalds#64]
  5c:   94000000        bl      0 <unregister_sysctl_table>
  60:   f900227f        str     xzr, [x19,torvalds#64]
  64:   2a1503e0        mov     w0, w21
  68:   f94013f5        ldr     x21, [sp,torvalds#32]
  6c:   a94153f3        ldp     x19, x20, [sp,torvalds#16]
  70:   a8c37bfd        ldp     x29, x30, [sp],torvalds#48
  74:   d65f03c0        ret

Add the possible error handle to free the net_header to remove the
kmemleak warning

Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Dec 8, 2015
I get the splat below when modprobing/rmmoding EDAC drivers. It happens
because bus->name is invalid after bus_unregister() has run. The Code: section
below corresponds to:

  .loc 1 1108 0
  movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
  .loc 1 1109 0
  popq    %rbx    #

  .loc 1 1108 0
  movq    (%rax), %rdi    # _7->name,
  jmp     kfree   #

and %rax has some funky stuff 2030203020312030 which looks a lot like
something walked over it.

Fix that by saving the name ptr before doing stuff to string it points to.

  general protection fault: 0000 [#1] SMP
  Modules linked in: ...
  CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ torvalds#48
  Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
  task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
  RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
  RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
  RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
  RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
  RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
  R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
  R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
  FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
  Stack:
  Call Trace:
    i7core_unregister_mci.isra.9
    i7core_remove
    pci_device_remove
    __device_release_driver
    driver_detach
    bus_remove_driver
    pci_unregister_driver
    i7core_exit
    SyS_delete_module
    system_call_fastpath
    0x7fc9bf426536
  Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
  RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
   RSP <ffff88030da3fe28>

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: <stable@vger.kernel.org> # v3.6..
Fixes: 7a623c0 ("edac: rewrite the sysfs code to use struct device")
ddstreet pushed a commit to ddstreet/linux that referenced this pull request Dec 10, 2015
GIT 4e757c85baca72dda85112d53a2d8e799a640f48

commit 4675390a9e7183bf45590e84a183e22e32c485a7
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Mon Dec 7 10:09:06 2015 +0100

    ethernet: aurora: AURORA_NB8800 should depend on HAS_DMA
    
    If NO_DMA=y:
    
        ERROR: "dma_map_single" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
        ERROR: "dma_unmap_page" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
        ERROR: "dma_sync_single_for_cpu" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
        ERROR: "dma_unmap_single" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
        ERROR: "dma_alloc_coherent" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
        ERROR: "dma_mapping_error" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
        ERROR: "dma_map_page" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
        ERROR: "dma_free_coherent" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Mans Rullgard <mans@mansr.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 668dda06d48fc16a5b40e6a32057bd18589e3f95
Author: Sunil Goutham <sgoutham@cavium.com>
Date:   Mon Dec 7 10:30:33 2015 +0530

    net, thunderx: Remove unnecessary rcv buffer start address management
    
    Since we have moved on to using allocated pages to carve receive
    buffers instead of netdev_alloc_skb() there is no need to store
    any pointers for later retrieval. Earlier we had to store
    skb and skb->data pointers which later are used to handover
    received packet to network stack.
    
    This will avoid an unnecessary cache miss as well.
    
    Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit b45ceb406e4fd3045180b8d70bff60b1d43c7ff4
Author: Yury Norov <yury.norov@auriga.com>
Date:   Mon Dec 7 10:30:32 2015 +0530

    net: thunderx: nicvf_queues: nivc_*_intr: remove duplication
    
    The same switch-case repeates for nivc_*_intr functions.
    In this patch it is moved to a helper nicvf_int_type_to_mask().
    
    By the way:
     - Unneeded write to NICVF register dropped if int_type is unknown.
     - netdev_dbg() is used instead of netdev_err().
    
    Signed-off-by: Yury Norov <yury.norov@auriga.com>
    Signed-off-by: Aleksey Makarov <aleksey.makarov@caviumnetworks.com>
    Acked-by: Vadim Lomovtsev <Vadim.Lomovtsev@caiumnetworks.com>
    Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 2dc487b6ebe8593d694034680389579edc7c1bd6
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Wed Dec 2 00:33:32 2015 +0100

    ARM: mvebu: update v5 defconfig for Orion5x machines
    
    Now that Orion5x is part of the multiarch kernel, add it to
    mvebu_v5_defconfig.
    
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

commit 5ff2a92d4e131a846fdb0aa91b50c46efc7d94c9
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Wed Dec 2 00:33:31 2015 +0100

    ARM: mvebu: Reenable DSA in mvebu_v5_defconfig
    
    DSA now depends on switchdev. Enable it, and re-enable DSA and its
    drivers, which were removed when mvebu_v5_defconfig was regenerated.
    
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

commit f549707af5650162434a8627c95482a829555450
Author: Borislav Petkov <bp@suse.de>
Date:   Mon Nov 30 19:02:01 2015 +0100

    EDAC: Rework workqueue handling
    
    Hide the EDAC workqueue pointer in a separate compilation unit and add
    accessors for the workqueue manipulations needed.
    
    Remove edac_pci_reset_delay_period() which wasn't used by anything. It
    seems it got added without a user with
    
      91b99041c1d5 ("drivers/edac: updated PCI monitoring")
    
    Signed-off-by: Borislav Petkov <bp@suse.de>

commit 56fb0cc3b7b6a02b90f2e3457702f014259b1e24
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Tue Nov 17 04:38:15 2015 +0300

    video: fbdev: rivafb: unlock chip before probiding EDID
    
    At least NV3 requires for chip to be unlocked before it is possible to
    access I2C registers. Without it, it is not possible to read EDID.
    
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

commit c5fec49f4208f67ef4574af956091093b11c566a
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 20 22:48:36 2015 +0100

    fbdev: sm712fb: avoid unused function warnings
    
    The sm712fb framebuffer driver encloses the power-management
    functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume
    functions are only really used when CONFIG_PM_SLEEP is also
    set, as a frequent gcc warning shows:
    
    fbdev/sm712fb.c:1549:12: warning: 'smtcfb_pci_suspend' defined but not used
    fbdev/sm712fb.c:1572:12: warning: 'smtcfb_pci_resume' defined but not used
    
    The driver also avoids using the SIMPLE_DEV_PM_OPS macro when
    CONFIG_PM is unset, which is redundant.
    
    This changes the driver to remove the #ifdef and instead mark
    the functions as __maybe_unused, which is a nicer anyway, as it
    provides build testing for all the code in all configurations
    and is harder to get wrong.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

commit 0f08cf9f7bdf80ebe1ec366de43cd251e39d1e2d
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 20 22:47:41 2015 +0100

    fbdev: auo_k190x: avoid unused function warnings
    
    The auo_k190x framebuffer driver encloses the power-management
    functions in #ifdef CONFIG_PM, but the auok190x_suspend/resume
    functions are only really used when CONFIG_PM_SLEEP is also
    set, as a frequent gcc warning shows:
    
    drivers/video/fbdev/auo_k190x.c:859:12: warning: 'auok190x_suspend' defined but not used
    drivers/video/fbdev/auo_k190x.c:899:12: warning: 'auok190x_resume' defined but not used
    
    This changes the driver to remove the #ifdef and instead mark
    the functions as __maybe_unused, which is a nicer anyway, as it
    provides build testing for all the code in all configurations
    and is harder to get wrong.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

commit 2a48fd5f89910ed6ed45a953f886de249b496b6c
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Dec 7 10:58:57 2015 -0500

    workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue
    
    Task or work item involved in memory reclaim trying to flush a
    non-WQ_MEM_RECLAIM workqueue or one of its work items can lead to
    deadlock.  Trigger WARN_ONCE() if such conditions are detected.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>

commit 1add6cb735c5a8e9f411d16680b60c0b6a66de49
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 27 15:33:11 2015 +0100

    fbdev: sis: enforce selection of at least one backend
    
    The sis framebuffer driver complains with a compile-time warning
    if neither the FB_SIS_300 nor FB_SIS_315 symbols are selected:
    
    drivers/video/fbdev/sis/sis_main.c:61:2: warning: #warning Neither CONFIG_FB_SIS_300 nor CONFIG_FB_SIS_315 is se
    
    This is reasonable because it doesn't work in that case, but it's
    also annoying for randconfig builds and is one of the most common
    warnings I'm seeing on ARM now.
    
    This changes the Kconfig logic to prevent the silly configuration,
    by always selecting the FB_SIS_300 variant if the other one is
    not set.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

commit bfc98c9c2e0ced00b79771bb65f1a79fd02041dd
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Dec 4 16:14:58 2015 +0300

    OMAPDSS: DSS: fix a warning message
    
    The WARN() macro has to take a condition.  The current code will just
    print the stack trace and the function name instead of the intended
    warning message.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

commit b79f09261174f0782f6d6b7b3fe48eb4b0ec9d06
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Dec 4 17:01:43 2015 +0100

    fbdev: Remove unused SH-Mobile HDMI driver
    
    As of commit 44d88c754e57a6d9 ("ARM: shmobile: Remove legacy SoC code
    for R-Mobile A1"), the SH-Mobile HDMI driver is no longer used.
    In theory it could still be used on R-Mobile A1 SoCs, but that requires
    adding DT support to the driver, which is not planned.
    
    Remove the driver, it can be resurrected from git history when needed.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

commit e11362bb25d97ea1cbe9e3b1e5f3d32aa4e75e13
Author: Yuan Sun <sunyuan3@huawei.com>
Date:   Mon Dec 7 10:28:46 2015 -0500

    Subject: cgroup: Fix incomplete dd command in blkio documentation
    
    Signed-off-by: Yuan Sun <sunyuan3@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit 2286bbcb6bd3823311279f04a7962941f94f8c58
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Dec 6 13:31:30 2015 +0200

    virtio: drop heuristics on ring full
    
    Old hypervisors used tricks for selecting signalling, but modern ones
    use event index to detect ring full.
    Drop heuristics in this case.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

commit a05c3fb05e2e46e46eeca5aff2d387d63f58665a
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Dec 6 13:30:59 2015 +0200

    virtio_ring: check used idx correctly on interrupt
    
    squash ino RING_POLL
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

commit 5d04cdb6377659237591e932086128b22e2047e8
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Nov 29 12:44:43 2015 +0200

    vring_bench: simple vring benchmark with poll support
    
    Integrate the benchmark that Rusty wrote.
    Add ring poll support.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

commit 7b064765a864030d8f65ad6d2a274b39591418f2
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Mon Nov 30 11:13:18 2015 +0200

    virtio: skip avail/used index reads
    
    This adds a new vring feature bit: when enabled, host and guest poll the
    available/used ring directly instead of looking at the index field
    first.
    
    To guarantee it is possible to detect updates, the high bits (above
    vring.num - 1) in the ring head ID value are modified to match the index
    bits - these change on each wrap-around.  Writer also XORs this with
    0x8000 such that rings can be zero-initialized.
    
    Reader is modified to ignore these high bits when looking
    up descriptors.
    
    The point is to reduce the number of cacheline misses
    for both reads and writes.
    
    I see a performance improvement of about 20% on multithreaded benchmarks
    (e.g. virtio-test), but regression of about 2% on vring_bench.
    I think this has to do with the fact that complete_multi_user
    is implemented suboptimally.
    
    TODO:
    	investigate single-threaded regression
    	look at more aggressive ring layout changes
    	better name for a feature flag
    	split the patch to make it easier to review
    
    This is on top of the following patches in my tree:
    	virtio_ring: Shadow available ring flags & index
    	vhost: replace % with & on data path
    	tools/virtio: fix byteswap logic
    	tools/virtio: move list macro stubs
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

commit 8ce47633e652f2df54b7495a716bc4b5f4574da1
Author: Borislav Petkov <bp@suse.de>
Date:   Mon Nov 30 15:07:28 2015 +0100

    EDAC: Make edac_device workqueue setup/teardown functions static
    
    They're not used anywhere else.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>

commit 4f2568f5cb475529aa2894adc7c7912517c83cb0
Author: Andreas Werner <andreas.werner@men.de>
Date:   Fri Dec 4 18:14:14 2015 +0100

    ata/sata_fsl.c: add ATA_FLAG_NO_LOG_PAGE to blacklist the controller for log page reads
    
    Every attempt to issue a read log page command lockup the controller.
    The command is currently sent if the sata device includes the devlsp feature
    to read out the timing data.
    This attempt to read the data, locks up the controller and the device
    is not recognzied correctly (failed to set xfermode) and cannot be accessed.
    
    This was found on Freescale P1013/P1022 and T4240 CPUs
    using a ATP IG mSATA 4GB with the devslp feature.
    
    fsl-sata ff718000.sata: Sata FSL Platform/CSB Driver init
    [    1.254195] scsi0 : sata_fsl
    [    1.256004] ata1: SATA max UDMA/133 irq 74
    [    1.370666] fsl-gianfar ethernet.3: enabled errata workarounds, flags: 0x4
    [    1.470671] fsl-gianfar ethernet.4: enabled errata workarounds, flags: 0x4
    [    1.775584] ata1: Signature Update detected @ 504 msecs
    [    1.947594] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
    [    1.948366] ata1.00: ATA-8: ATP IG mSATA, 20150311, max UDMA/133
    [    1.948371] ata1.00: 7732368 sectors, multi 0: LBA
    [    1.948843] ata1.00: failed to get Identify Device Data, Emask 0x1
    [    1.948857] ata1.00: failed to set xfermode (err_mask=0x40)
    [    7.467557] ata1: Signature Update detected @ 504 msecs
    [    7.639560] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
    [    7.651320] ata1.00: failed to get Identify Device Data, Emask 0x1
    [    7.651360] ata1.00: failed to set xfermode (err_mask=0x40)
    [    7.655628] ata1: limiting SATA link speed to 1.5 Gbps
    [    7.659458] ata1.00: limiting speed to UDMA/133:PIO3
    [   13.163554] ata1: Signature Update detected @ 504 msecs
    [   13.335558] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
    [   13.347298] ata1.00: failed to get Identify Device Data, Emask 0x1
    [   13.347334] ata1.00: failed to set xfermode (err_mask=0x40)
    [   13.351601] ata1.00: disabled
    [   13.353278] ata1: exception Emask 0x50 SAct 0x0 SErr 0x800 action 0x6 frozen t4
    [   13.359281] ata1: SError: { HostInt }
    [   13.361644] ata1: hard resetting link
    
    Signed-off-by: Andreas Werner <andreas.werner@men.de>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit ea013a9b205b47b1fcbc72522146fad560af0712
Author: Andreas Werner <andreas.werner@men.de>
Date:   Fri Dec 4 18:12:49 2015 +0100

    libata-eh.c: Introduce new ata port flag for controller which lockup on read log page
    
    Some controller lockup on a ata_read_log_page.
    Add new ata port flag ATA_FLAG_NO_LOG_PAGE which can used
    to blacklist a controller.
    
    If this flag is set, any attempt to read a log page returns an error
    without actually issuing the command.
    
    Signed-off-by: Andreas Werner <andreas.werner@men.de>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit f2000f11fc88b8030962ea6aa6e06dfc3df8bb10
Author: Borislav Petkov <bp@suse.de>
Date:   Mon Nov 30 14:20:41 2015 +0100

    EDAC: Remove edac_get_sysfs_subsys() error handling
    
    It cannot fail now. We either load EDAC core after having successfully
    initialized edac_subsys or we don't.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>

commit ab77579321508e4234213c71d0a187bca67e550b
Author: Borislav Petkov <bp@suse.de>
Date:   Mon Nov 30 14:15:31 2015 +0100

    EDAC: Unexport and make edac_subsys static
    
    ... and use the accessor instead.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>

commit f893180b79f6ada44068e4fe764eb2de70ee6bea
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Sat Dec 5 16:18:44 2015 -0800

    ahci: compile out msi/msix infrastructure
    
    Quoting Arnd:
        The AHCI driver is used for some on-chip devices that do not use PCI
        for probing, and it can be built even when CONFIG_PCI is disabled, but
        that now results in a build failure:
    
        ata/libahci.c: In function 'ahci_host_activate_multi_irqs':
        ata/libahci.c:2475:4: error: invalid use of undefined type 'struct msix_entry'
        ata/libahci.c:2475:21: error: dereferencing pointer to incomplete type 'struct msix_entry'
    
    Add ifdef CONFIG_PCI_MSI infrastructure to compile out the multi-msi and
    multi-msix code.
    
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Tested--by: Arnd Bergmann <arnd@arndb.de>
    [arnd: fix up pci enabled case]
    Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Fixes: d684a90d38e2 ("ahci: per-port msix support")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit 7e22c0024cf89404407f19955eab39b6d66de7b6
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Dec 6 21:56:33 2015 +0100

    ata: core: fix irq description on AHCI single irq systems
    
    On my machine with single irq AHCI just the PCI id is printed as
    description in /proc/interrupts.
    I found a related discussion from beginning of this year:
    http://www.gossamer-threads.com/lists/linux/kernel/2117335
    
    Seems like 4f37b504768c ("libata: Use dev_name() for request_irq() to
    distinguish devices") tried to fix displaying a proper interrupt
    description for one scenario but broke it for another one.
    
    The mentioned discussion ended in the current situation being
    considered as broken but w/o a patch to fix it.
    
    The following patch is based on a proposal in this mail thread.
    Now the interrupt is properly described as:
    PCI-MSI 512000-edge      ahci[0000:00:1f.2]
    
    By combining both values also the scenario that commit 4f37b504768c
    ("libata: Use dev_name() for request_irq() to distinguish devices")
    refers to should still be fine. There it should look like this now:
    ahci[20100000.ide]
    
    Using managed memory allocation ensures that the irq description
    lives at least as long as the interrupt.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

commit 8d8fcba6d1eabcb11ea0a6027d150a7f2cd0e019
Author: Borislav Petkov <bp@suse.de>
Date:   Fri Nov 27 11:40:43 2015 +0100

    EDAC: Rip out the edac_subsys reference counting
    
    This was really dumb - reference counting for the main EDAC sysfs
    object. While we could've simply registered it as the first thing in the
    module init path and then hand it around to what needs it.
    
    Do that and rip out all the code around it, thus simplifying the whole
    handling significantly.
    
    Move the edac_subsys node back to edac_module.c.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>

commit 6d1a2adef782d26113d4f18a617ccb33c4774d54
Author: Alexey Brodkin <abrodkin@synopsys.com>
Date:   Mon Dec 7 14:21:37 2015 +0300

    ARC: [axs10x] cap ethernet phy to 100 Mbit/sec
    
    Current ARC SDP boards cannot reliably handle 1Gbit
    Ethernet connections due to limitations in hardware.
    
    To make sure networking is stable on the board we're
    limiting phy to 100 Mbit.
    
    Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

commit 4c835b57b8de88aef8446867701034128a8a3522
Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Date:   Wed Nov 18 19:07:15 2015 +0100

    fixdep: constify strrcmp arguments
    
    strrcmp only performs read access to the memory addressed by its
    arguments so make them const pointers.
    
    Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
    Signed-off-by: Michal Marek <mmarek@suse.com>

commit b46ae2f3e2882fad71630a6b7c5ea23fa8bc9b84
Author: Borislav Petkov <bp@suse.de>
Date:   Fri Nov 27 10:38:38 2015 +0100

    EDAC: Robustify workqueues destruction
    
    EDAC workqueue destruction is really fragile. We cancel delayed work
    but if it is still running and requeues itself, we still go ahead and
    destroy the workqueue and the queued work explodes when workqueue core
    attempts to run it.
    
    Make the destruction more robust by switching op_state to offline so
    that requeuing stops. Cancel any pending work *synchronously* too.
    
      EDAC i7core: Driver loaded.
      general protection fault: 0000 [#1] SMP
      CPU 12
      Modules linked in:
      Supported: Yes
      Pid: 0, comm: kworker/0:1 Tainted: G          IE   3.0.101-0-default #1 HP ProLiant DL380 G7
      RIP: 0010:[<ffffffff8107dcd7>]  [<ffffffff8107dcd7>] __queue_work+0x17/0x3f0
      < ... regs ...>
      Process kworker/0:1 (pid: 0, threadinfo ffff88019def6000, task ffff88019def4600)
      Stack:
       ...
      Call Trace:
       call_timer_fn
       run_timer_softirq
       __do_softirq
       call_softirq
       do_softirq
       irq_exit
       smp_apic_timer_interrupt
       apic_timer_interrupt
       intel_idle
       cpuidle_idle_call
       cpu_idle
      Code: ...
      RIP  __queue_work
       RSP <...>
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: <stable@vger.kernel.org>

commit 138500d1da4ec2a24025891ddc345151189ece5e
Author: Borislav Petkov <bp@suse.de>
Date:   Tue Dec 1 15:52:36 2015 +0100

    EDAC, mc_sysfs: Fix freeing bus' name
    
    I get the splat below when modprobing/rmmoding EDAC drivers. It happens
    because bus->name is invalid after bus_unregister() has run. The Code: section
    below corresponds to:
    
      .loc 1 1108 0
      movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
      .loc 1 1109 0
      popq    %rbx    #
    
      .loc 1 1108 0
      movq    (%rax), %rdi    # _7->name,
      jmp     kfree   #
    
    and %rax has some funky stuff 2030203020312030 which looks a lot like
    something walked over it.
    
    Fix that by saving the name ptr before doing stuff to string it points to.
    
      general protection fault: 0000 [#1] SMP
      Modules linked in: ...
      CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ #48
      Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
      task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
      RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
      RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
      RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
      RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
      RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
      R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
      R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
      FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
      Stack:
      Call Trace:
        i7core_unregister_mci.isra.9
        i7core_remove
        pci_device_remove
        __device_release_driver
        driver_detach
        bus_remove_driver
        pci_unregister_driver
        i7core_exit
        SyS_delete_module
        system_call_fastpath
        0x7fc9bf426536
      Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
      RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
       RSP <ffff88030da3fe28>
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Cc: <stable@vger.kernel.org> # v3.6..
    Fixes: 7a623c039075 ("edac: rewrite the sysfs code to use struct device")

commit 02f6ff90400d055f08b0ba0b5f0707630b6faed7
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Mon Dec 7 11:29:31 2015 +0100

    ALSA: hda - Add inverted dmic for Packard Bell DOTS
    
    On the internal mic of the Packard Bell DOTS, one channel
    has an inverted signal. Add a quirk to fix this up.
    
    Cc: stable@vger.kernel.org
    BugLink: https://bugs.launchpad.net/bugs/1523232
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 1b894521e60c1b91db1e8ba1278660e5c89f1b5f
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Sun Dec 6 21:19:15 2015 +0200

    mac80211: handle HW ROC expired properly
    
    In case of HW ROC, when the driver reports that the ROC expired,
    it is not sufficient to purge the ROCs based on the remaining
    time, as it possible that the device finished the ROC session
    before the actual requested duration.
    
    To handle such cases, in case of ROC expired notification from
    the driver, complete all the ROCs which are marked with hw_begun,
    regardless of the remaining duration.
    
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit 0d014ff344abc9c8e56cf1870ab3a144d2e2e37a
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Thu Nov 19 16:07:17 2015 +0100

    drm/i915: Remove double wait_for_vblank on broadwell.
    
    wait_vblank is already set in intel_plane_atomic_calc_changes
    for broadwell, waiting for a double vblank is overkill.
    
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-5-git-send-email-maarten.lankhorst@linux.intel.com

commit b900111459e2f4a538697f75b63478f3a6acec3c
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Thu Nov 19 16:07:16 2015 +0100

    drm/i915/skl: Update watermarks before the crtc is disabled.
    
    On skylake some of the registers are only writable when the correct
    power wells are enabled. Because of this watermarks have to be updated
    before the crtc turns off, or you get unclaimed register read and write
    warnings.
    
    This patch needs to be modified slightly to apply to -fixes.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92181
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: stable@vger.kernel.org
    Cc: Matt Roper <matthew.d.roper@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-4-git-send-email-maarten.lankhorst@linux.intel.com
    Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>

commit 526c0ab13672fa2ec0fddb7efa9a7797e11fddea
Author: Damien Riegel <damien.riegel@savoirfairelinux.com>
Date:   Mon Nov 30 10:59:47 2015 -0500

    mfd: syscon: Add a DT property to set value width
    
    Currently syscon has a fixed configuration of 32 bits for register and
    values widths. In some cases, it would be desirable to be able to
    customize the value width.
    
    For example, certain boards (like the ones manufactured by Technologic
    Systems) have a FPGA that is memory-mapped, but its registers are only
    16-bit wide.
    
    This patch adds an optional "reg-io-width" DT binding for syscon that
    allows to change the width for the data bus (i.e. val_bits). If this
    property is provided, it will also set the register stride to
    reg-io-width's value. If not provided, the default configuration is
    used.
    
    Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit 92826fcdfc147a7d16766e987c12a9dfe1860c3f
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Thu Dec 3 13:49:13 2015 +0100

    drm/i915: Calculate watermark related members in the crtc_state, v4.
    
    This removes pre/post_wm_update from intel_crtc->atomic, and
    creates atomic state for it in intel_crtc.
    
    Changes since v1:
    - Rebase on top of wm changes.
    Changes since v2:
    - Split disable_cxsr into a separate patch.
    Changes since v3:
    - Move some of the changes to intel_wm_need_update.
    
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/56603A49.5000507@linux.intel.com
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit ab1d3a0e5a44f5b1a8d1f811e925c8519b56fba4
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Thu Nov 19 16:07:14 2015 +0100

    drm/i915: Move disable_cxsr to the crtc_state.
    
    intel_crtc->atomic will be removed later on, move this member
    to intel_crtc_state.
    
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-2-git-send-email-maarten.lankhorst@linux.intel.com
    Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>

commit c10368897e104c008c610915a218f0fe5fa4ec96
Author: Ravindra Lokhande <rlokhande@nvidia.com>
Date:   Mon Dec 7 12:08:31 2015 +0530

    ALSA: compress: add support for 32bit calls in a 64bit kernel
    
    Compress offload does not support ioctl calls from a 32bit userspace
    in a 64 bit kernel. This patch adds support for ioctls from a 32bit
    userspace in a 64bit kernel
    
    Signed-off-by: Ravindra Lokhande <rlokhande@nvidia.com>
    Acked-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit ee65ad0e2a9e5c1a61f86be9365c17f4fddb3818
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Wed Nov 18 18:12:25 2015 +0100

    backlight: pwm_bl: Avoid backlight flicker when probed from DT
    
    If the driver is probed from the device tree, and there is a phandle
    property set on it, and the enable GPIO is already configured as output,
    and the backlight is currently disabled, keep it disabled.
    If all these conditions are met, assume there will be some other driver
    that can enable the backlight at the appropriate time.
    
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Tested-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit 7c23b7c1996597dd9d60bb282fb5fa1be6ebd18b
Author: Lu, Han <han.lu@intel.com>
Date:   Mon Dec 7 15:59:13 2015 +0800

    ALSA: hda - Fix playback noise with 24/32 bit sample size on BXT
    
    In BXT-P A0, HD-Audio DMA requests is later than expected,
    and makes an audio stream sensitive to system latencies when
    24/32 bits are playing.
    Adjusting threshold of DMA fifo to force the DMA request
    sooner to improve latency tolerance at the expense of power.
    
    v2: move Intel specific code to hda_intel.c
    
    Signed-off-by: Lu, Han <han.lu@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit a4d8a0fe4500b87817eebdb363c116922de87453
Author: Zeng Zhaoxiu <zhaoxiu.zeng@gmail.com>
Date:   Sun Dec 6 18:26:30 2015 +0800

    i915: Replace "hweight8(dev_priv->info.subslice_7eu[i]) != 1" with "!is_power_of_2(dev_priv->info.subslice_7eu[i])"
    
    Signed-off-by: Zeng Zhaoxiu <zhaoxiu.zeng@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: http://patchwork.freedesktop.org/patch/msgid/1449397590-14292-1-git-send-email-zhaoxiu.zeng@gmail.com

commit f00be687f5fd2b626aa975dc4513cad525823c05
Author: Simon Horman <horms+renesas@verge.net.au>
Date:   Thu Nov 26 13:26:20 2015 +0900

    ARM: shmobile: r8a7793: remove deprecated #gpio-range-cells
    
    Commit a1bc260bb5f5d9 ("gpio: clean up gpio-ranges documentation")
    declares the above property deprecated. That was more than 2 years ago.
    Remove it, so it doesn't get copied around needlessly.
    
    Based on similar work for the r8a7791 and r8a7794 by Wolfram Sang.
    
    Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

commit 46ece349aa54f6e55b5f8d30bbecbaf2884ba869
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Thu Dec 3 01:23:03 2015 +0300

    ARM: shmobile: r8a7791: add EtherAVB DT support
    
    Define the generic R8A7791 part of the EtherAVB device node.
    
    Based on the commit f25d6b977240 ("ARM: shmobile: r8a7790: add EtherAVB DT
    support").
    
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

commit eaa870b3055384092d8fc075bca3a3a819f73c43
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Thu Dec 3 01:21:49 2015 +0300

    ARM: shmobile: r8a7791: add EtherAVB clock
    
    Add the EtherAVB clock to the R8A7791 device tree.
    
    Based on the commit 63d2d750c902 ("ARM: shmobile: r8a7790: add EtherAVB
    clocks").
    
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

commit 64874280889e7c0b2c9266705363627d4c92cf01
Author: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Date:   Sun Dec 6 21:11:38 2015 +0000

    af_unix: fix unix_dgram_recvmsg entry locking
    
    The current unix_dgram_recvsmg code acquires the u->readlock mutex in
    order to protect access to the peek offset prior to calling
    __skb_recv_datagram for actually receiving data. This implies that a
    blocking reader will go to sleep with this mutex held if there's
    presently no data to return to userspace. Two non-desirable side effects
    of this are that a later non-blocking read call on the same socket will
    block on the ->readlock mutex until the earlier blocking call releases it
    (or the readers is interrupted) and that later blocking read calls
    will wait longer than the effective socket read timeout says they
    should: The timeout will only start 'ticking' once such a reader hits
    the schedule_timeout in wait_for_more_packets (core.c) while the time it
    already had to wait until it could acquire the mutex is unaccounted for.
    
    The patch avoids both by using the __skb_try_recv_datagram and
    __skb_wait_for_more packets functions created by the first patch to
    implement a unix_dgram_recvmsg read loop which releases the readlock
    mutex prior to going to sleep and reacquires it as needed
    afterwards. Non-blocking readers will thus immediately return with
    -EAGAIN if there's no data available regardless of any concurrent
    blocking readers and all blocking readers will end up sleeping via
    schedule_timeout, thus honouring the configured socket receive timeout.
    
    Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ea3793ee29d3621faf857fa8ef5425e9ff9a756d
Author: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Date:   Sun Dec 6 21:11:34 2015 +0000

    core: enable more fine-grained datagram reception control
    
    The __skb_recv_datagram routine in core/ datagram.c provides a general
    skb reception factility supposed to be utilized by protocol modules
    providing datagram sockets. It encompasses both the actual recvmsg code
    and a surrounding 'sleep until data is available' loop. This is
    inconvenient if a protocol module has to use additional locking in order
    to maintain some per-socket state the generic datagram socket code is
    unaware of (as the af_unix code does). The patch below moves the recvmsg
    proper code into a new __skb_try_recv_datagram routine which doesn't
    sleep and renames wait_for_more_packets to
    __skb_wait_for_more_packets, both routines being exported interfaces. The
    original __skb_recv_datagram routine is reimplemented on top of these
    two functions such that its user-visible behaviour remains unchanged.
    
    Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit dc15c60e39a3092df845f9bfc29b9c40cc63934d
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Sun Dec 6 20:20:14 2015 -0800

    rcutorture: Don't keep empty console.log.diags files
    
    Currently, an error-free run produces an empty console.log.diags file.
    This can be annoying when using "vi */console.log.diags" to see a full
    summary of the errors.  This commit therefore removes any empty files
    during the analysis process.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 0485e1b35866693ff3ec975ca4c3c8ea8db63678
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Sun Dec 6 20:18:37 2015 -0800

    rcutorture: Add checks for rcutorture writer starvation
    
    This commit adds checks for rcutorture writer starvation, so that
    instances will be added to the test summary.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 7bf9ae016efc0cf08263fbee5ac708c23b90792e
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Mon Dec 7 04:38:58 2015 +0100

    PHY: DP83867: Remove looking in parent device for OF properties
    
    Device tree properties for a phy device are expected to be in the phy
    node. The current code for the DP83867 also tries to look in the
    parent node. The devices binding documentation does not mention this,
    no current device tree file makes use of this, and it is not behaviour
    we want. So remove looking in the parent device.
    
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 404814af69d4732276319b90886b81fb2884ae1b
Author: Bjørn Mork <bjorn@mork.no>
Date:   Sun Dec 6 22:47:15 2015 +0100

    net: cdc_ncm: add "ndp_to_end" sysfs attribute
    
    Adding a writable sysfs attribute for the "NDP to end"
    quirk flag.
    
    This makes it easier for end users to test new devices for
    this firmware bug.  We've been lucky so far, but we should
    not depend on reporters capable of rebuilding the driver.
    
    Cc: Enrico Mioso <mrkiko.rs@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e57968a10bc1b3da6d2b8b0bdbbe4c5a43de2ad1
Author: Moni Shoua <monis@mellanox.com>
Date:   Sun Dec 6 18:07:43 2015 +0200

    net/mlx4_core: Support the HA mode for SRIOV VFs too
    
    When the mlx4 driver runs in HA mode, and all VFs are single ported
    ones, we make their single port Highly-Available.
    
    This is done by taking advantage of the HA mode properties (following
    bonding changes with programming the port V2P map, etc) and adding
    the missing parts which are unique to SRIOV such as mirroring VF
    steering rules on both ports.
    
    Due to limits on the MAC and VLAN table this mode is enabled only when
    number of total VFs is under 64.
    
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit f1b4e12a9ab6cc08b1a047bf021d90c7e07b1517
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Sun Dec 6 18:07:42 2015 +0200

    IB/mlx4: Use the VF base-port when demuxing mad from wire
    
    Under HA mode, it's possible that the VF registered its GID
    (and expects to get mads through the PV scheme) on a port which is
    different from the one this mad arrived on, due to HA fail over.
    
    Therefore, if the gid is not matched on the port that the packet arrived
    on, check for a match on the other port if HA mode is active -- and if a
    match is found on the other port, continue processing the mad using that
    other port.
    
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 5f61385d2ebc2bd62bc389c7da0d8d2f263be1eb
Author: Moni Shoua <monis@mellanox.com>
Date:   Sun Dec 6 18:07:41 2015 +0200

    net/mlx4_core: Keep VLAN/MAC tables mirrored in multifunc HA mode
    
    Due to HW limitations, indexes to MAC and VLAN tables are always taken
    from the table of the actual port. So, if a resource holds an index to
    a table, it may refer to different values during the lifetime of the
    resource,  unless the tables are mirrored. Also, even when
    driver is not in HA mode the policy of allocating an index to these
    tables is such to make sure, as much as possible, that when the time
    comes the mirroring will be successful. This means that in multifunction
    mode the allocation of a free index in a port's table tries to make sure
    that the same index in the other's port table is also free.
    
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 78efed275117b189f06f8937798eab5cba53ed18
Author: Moni Shoua <monis@mellanox.com>
Date:   Sun Dec 6 18:07:40 2015 +0200

    net/mlx4_core: Support mirroring VF DMFS rules on both ports
    
    Under HA mode, steering rules set by VFs should be mirrored on both
    ports of the device so packets will be accepted no matter on which
    port they arrived.
    
    Since getting into HA mode is done dynamically when the user bonds mlx4
    Ethernet netdevs, we keep hold of the VF DMFS rule mbox with the port
    value flipped (1->2,2->1) and execute the mirroring when getting into
    HA mode. Later, when going out of HA mode, we unset the mirrored rules.
    In that context note that mirrored rules cannot be removed explicitly.
    
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 8d80d04a521d4acf949a449403040c38ec648f57
Author: Moni Shoua <monis@mellanox.com>
Date:   Sun Dec 6 18:07:39 2015 +0200

    net/mlx4_core: Use both physical ports to dispatch link state events to VF
    
    Under HA mode, the link down event should be sent to VFs only if both
    ports are down.
    
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e34305c85f86112838cb332696513bed8e04a211
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Sun Dec 6 18:07:38 2015 +0200

    net/mlx4_core: Use both physical ports to set the VF link state
    
    In HA mode, the link state for VFs for which the policy is "auto"
    (i.e. follow the physical link state) should be ORed from both ports.
    
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0d76d6e8b2507983a2cae4c09880798079007421
Author: Julia Lawall <julia.lawall@lip6.fr>
Date:   Sun Dec 6 06:56:23 2015 +0100

    VSOCK: fix returnvar.cocci warnings
    
    Remove unneeded variable used to store return value.
    
    Generated by: scripts/coccinelle/misc/returnvar.cocci
    
    CC: Asias He <asias@redhat.com>
    Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit eeaef728978bc4da94d04d5e44bb81221279c418
Author: Loic Poulain <loic.poulain@intel.com>
Date:   Sun Dec 6 16:18:34 2015 +0100

    Bluetooth: btintel: Create common Intel Version Read function
    
    The Intel Version Read command is used to retrieve information
    about hardware and firmware version/revision of Intel Bluetooth
    controllers. This is an Intel generic command used in USB and
    UART drivers.
    
    Signed-off-by: Loic Poulain <loic.poulain@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

commit 326fcfa5acca446b3f71e99f6d19881145556e5c
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sat Dec 5 13:58:11 2015 +0100

    net: remove unnecessary semicolon in netdev_alloc_pcpu_stats()
    
    This semicolon causes a build error if the function call is wrapped in
    parentheses.
    
    Fixes: aabc92bbe3cf ("net: add __netdev_alloc_pcpu_stats() to indicate gfp flags")
    Reported-by: Imre Kaloz <kaloz@openwrt.org>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 8a0d19c5ed417c78d03f4e0fa7215e58c40896d8
Author: lucien <lucien.xin@gmail.com>
Date:   Sat Dec 5 15:35:36 2015 +0800

    sctp: start t5 timer only when peer rwnd is 0 and local state is SHUTDOWN_PENDING
    
    when A sends a data to B, then A close() and enter into SHUTDOWN_PENDING
    state, if B neither claim his rwnd is 0 nor send SACK for this data, A
    will keep retransmitting this data until t5 timeout, Max.Retrans times
    can't work anymore, which is bad.
    
    if B's rwnd is not 0, it should send abort after Max.Retrans times, only
    when B's rwnd == 0 and A's retransmitting beyonds Max.Retrans times, A
    will start t5 timer, which is also commit f8d960524328 ("sctp: Enforce
    retransmission limit during shutdown") means, but it lacks the condition
    peer rwnd == 0.
    
    so fix it by adding a bit (zero_window_announced) in peer to record if
    the last rwnd is 0. If it was, zero_window_announced will be set. and use
    this bit to decide if start t5 timer when local.state is SHUTDOWN_PENDING.
    
    Fixes: commit f8d960524328 ("sctp: Enforce retransmission limit during shutdown")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 6c730080e663b1d629f8aa89348291fbcdc46cd9
Author: Bjørn Mork <bjorn@mork.no>
Date:   Sun Dec 6 21:25:50 2015 +0100

    net: qmi_wwan: should hold RTNL while changing netdev type
    
    The notifier calls were thrown in as a last-minute fix for an
    imagined "this device could be part of a bridge" problem. That
    revealed a certain lack of locking.  Not to mention testing...
    
    Avoid this splat:
    
    RTNL: assertion failed at net/core/dev.c (1639)
    CPU: 0 PID: 4293 Comm: bash Not tainted 4.4.0-rc3+ #358
    Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
     0000000000000000 ffff8800ad253d60 ffffffff8122f7cf ffff8800ad253d98
     ffff8800ad253d88 ffffffff813833ab 0000000000000002 ffff880230f48560
     ffff880230a12900 ffff8800ad253da0 ffffffff813833da 0000000000000002
    Call Trace:
     [<ffffffff8122f7cf>] dump_stack+0x4b/0x63
     [<ffffffff813833ab>] call_netdevice_notifiers_info+0x3d/0x59
     [<ffffffff813833da>] call_netdevice_notifiers+0x13/0x15
     [<ffffffffa09be227>] raw_ip_store+0x81/0x193 [qmi_wwan]
     [<ffffffff8131e149>] dev_attr_store+0x20/0x22
     [<ffffffff811d858b>] sysfs_kf_write+0x49/0x50
     [<ffffffff811d8027>] kernfs_fop_write+0x10a/0x151
     [<ffffffff8117249a>] __vfs_write+0x26/0xa5
     [<ffffffff81085ed4>] ? percpu_down_read+0x53/0x7f
     [<ffffffff81174c9e>] ? __sb_start_write+0x5f/0xb0
     [<ffffffff81174c9e>] ? __sb_start_write+0x5f/0xb0
     [<ffffffff81172c37>] vfs_write+0xa3/0xe7
     [<ffffffff811734ad>] SyS_write+0x50/0x7e
     [<ffffffff8145c517>] entry_SYSCALL_64_fastpath+0x12/0x6f
    
    Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit dc085392a3a760b5788db368c1b2c116be08b201
Author: Inki Dae <inki.dae@samsung.com>
Date:   Thu Dec 3 14:35:23 2015 +0900

    drm/exynos: dsi: modify a error type when getting a node failed
    
    This patch makes it to return -EINVAL instead of -ENXIO
    when getting a port or remote node failed.
    
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>

commit 5e4500d8dba16d88b528cf037566b84747ec23f0
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Thu Dec 3 09:37:52 2015 +0530

    cpufreq: governor: initialize/destroy timer_mutex with 'shared'
    
    timer_mutex is required to be initialized only while memory for 'shared'
    is allocated and in a similar way it is required to be destroyed only
    when memory for 'shared' is freed.
    
    There is no need to do the same every time we start/stop the governor.
    Move code to initialize/destroy timer_mutex to the relevant places.
    
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit affde5d06af1e39c2929e36a063e3912f02fc58f
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Thu Dec 3 09:37:51 2015 +0530

    cpufreq: governor: Pass policy as argument to ->gov_dbs_timer()
    
    Pass 'policy' as argument to ->gov_dbs_timer() instead of cdbs and
    dbs_data.
    
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit e68fe18c5b5442baca162ccf3b273326e6132a51
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Thu Dec 3 09:37:50 2015 +0530

    cpufreq: ondemand: Work is guaranteed to be pending
    
    We are guaranteed to have works scheduled for policy->cpus, as the
    policy isn't stopped yet. And so there is no need to check that again.
    Drop it.
    
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit e128c864070055e062f6c90c64c03aad18452ac3
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Thu Dec 3 09:37:49 2015 +0530

    cpufreq: ondemand: Update sampling rate only for concerned policies
    
    We are comparing policy->governor against cpufreq_gov_ondemand to make
    sure that we update sampling rate only for the concerned CPUs. But that
    isn't enough.
    
    In case of governor_per_policy, there can be multiple instances of
    ondemand governor and we will always end up updating all of them with
    current code. What we rather need to do, is to compare dbs_data with
    poilcy->governor_data, which will match only for the policies governed
    by dbs_data.
    
    This code is also racy as the governor might be getting stopped at that
    time and we may end up scheduling work for a policy, which we have just
    disabled.
    
    Fix that by protecting the entire function with &od_dbs_cdata.mutex,
    which will prevent against races with policy START/STOP/etc.
    
    After these locks are in place, we can safely get the policy via per-cpu
    dbs_info.
    
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 7b06a6d7bff563d82ddf8769617632f26793a83e
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Dec 5 01:54:47 2015 +0100

    MAINTAINERS: Add an entry for the PM core
    
    Add a MAINTAINERS entry for the PM core with myself as the maintainer
    and linux-pm as the mailing list.
    
    This actually documents the current state of things.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce657b1cddf1f88c56ae683efa7130341c92808b
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Tue Nov 17 12:08:01 2015 +0000

    component: add support for releasing match data
    
    The component helper treats the void match data pointer as an opaque
    object which needs no further management.  When device nodes being
    passed, this is not true: the caller should pass its refcount to the
    component helper, and there should be a way to drop the refcount when
    the matching information is destroyed.
    
    This patch provides a per-match release method in addition to the match
    method to solve this issue.  Rather than using component_match_add(),
    users should use component_match_add_release() which takes an additional
    function pointer for releasing this reference.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Fri Apr 18 23:05:53 2014 +0100

    component: track components via array rather than list
    
    Since we now have an array which defines each component, maintain the
    components to be bound in the array rather than a separate list.  We
    also need duplicate tracking so we can eliminate multiple bind calls
    for the same component: we preserve the list-based component order in
    that the first match which adds the component determines its position.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 29f1c7fd61a31e0335ce41d4b2788959ad7c468d
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Wed Apr 23 10:46:11 2014 +0100

    component: move check for unbound master into try_to_bring_up_masters()
    
    Clean up the code a little; we don't need to check that the master is
    unbound for every invocation of try_to_bring_up_master(), so let's move
    it to where it's really needed - try_to_bring_up_masters(), where we may
    encounter already bound masters.
    
    Reviewed-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit fae9e2e07af07baabb8c26a31b3f7d8fdf89809e
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Fri Apr 18 22:10:32 2014 +0100

    component: remove old add_components method
    
    Now that drivers create an array of component matches at probe time, we
    can retire the old methods.  This involves removing the add_components
    master method, and removing component_master_add_child() from public
    view.  We also remove component_add_master() as that interface is no
    longer useful.
    
    Acked-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 072151bb01547816d82ec06565de5559d679fbeb
Author: Jordan Hargrave <jharg93@gmail.com>
Date:   Mon Dec 7 10:07:15 2015 +1100

    firmware: dmi_scan: Save SMBIOS Type 9 System Slots
    
    Save SMBIOS Type 9 System Slots during DMI scan. PCI address of
    onboard devices was already saved but not for slots.
    
    Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
    Signed-off-by: Jean Delvare <jdelvare@suse.de>

commit c625c7eb2eb48f21aaab5bc762e063f770eee479
Author: Jean Delvare <jdelvare@suse.de>
Date:   Mon Dec 7 10:07:15 2015 +1100

    firmware: dmi_scan: Fix dmi_find_device description
    
    The description of dmi_find_device was apparently copied from a
    similar function in a different subsystem, but the parameter names
    were not adjusted as needed.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Cc: Andrey Panin <pazke@donpac.ru>

commit d40ad8376edb951737111330e8fba087e5c1d831
Author: Jean Delvare <jdelvare@suse.de>
Date:   Mon Dec 7 10:07:15 2015 +1100

    firmware: dmi_scan: Clarify dmi_save_extended_devices
    
    Get rid of the arbitrary 5-byte pointer offset, it served no purpose
    and made it harder to match the code with the SMBIOS specification.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Cc: Jordan Hargrave <jordan_hargrave@dell.com>
    Cc: Narendra K <narendra_k@dell.com>

commit af94859f09787d2b782743812c61032ddfd6f987
Author: Jean Delvare <jdelvare@suse.de>
Date:   Mon Dec 7 10:07:14 2015 +1100

    firmware: dmi_scan: Optimize dmi_save_extended_devices
    
    Calling dmi_string_nosave isn't cheap, so avoid calling it twice in a
    row for the same string.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Cc: Jordan Hargrave <jordan_hargrave@dell.com>
    Cc: Narendra K <narendra_k@dell.com>

commit 54046148cf6826a5a3f61e571b131e0224580d53
Author: Helge Deller <deller@gmx.de>
Date:   Sun Dec 6 21:56:26 2015 +0100

    parisc: Wire up mlock2 syscall
    
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 73c5e2661b712bb63408555037e6ac38b39e04dc
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Dec 1 10:41:47 2015 -0600

    parisc: Remove unused pcibios_init_bus()
    
    There are no callers of pcibios_init_bus(), so remove it.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Helge Deller <deller@gmx.de>

commit f316cb0a60c29cb00a42d6da8d42c48fe067901b
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Nov 30 14:47:46 2015 -0500

    parisc iommu: fix panic due to trying to allocate too large region
    
    When using the Promise TX2+ SATA controller on PA-RISC, the system often
    crashes with kernel panic, for example just writing data with the dd
    utility will make it crash.
    
    Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources
    
    CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
    Backtrace:
     [<000000004021497c>] show_stack+0x14/0x20
     [<0000000040410bf0>] dump_stack+0x88/0x100
     [<000000004023978c>] panic+0x124/0x360
     [<0000000040452c18>] sba_alloc_range+0x698/0x6a0
     [<0000000040453150>] sba_map_sg+0x260/0x5b8
     [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata]
     [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata]
     [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata]
     [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130
     [<000000004049da34>] scsi_request_fn+0x6e4/0x970
     [<00000000403e95a8>] __blk_run_queue+0x40/0x60
     [<00000000403e9d8c>] blk_run_queue+0x3c/0x68
     [<000000004049a534>] scsi_run_queue+0x2a4/0x360
     [<000000004049be68>] scsi_end_request+0x1a8/0x238
     [<000000004049de84>] scsi_io_completion+0xfc/0x688
     [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0
    
    The cause of the crash is not exhaustion of the IOMMU space, there is
    plenty of free pages. The function sba_alloc_range is called with size
    0x11000, thus the pages_needed variable is 0x11. The function
    sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
    0x10 (because dma_get_seg_boundary(dev) returns 0xffff).
    
    The function sba_search_bitmap attempts to allocate 17 pages that must not
    cross 16-page boundary - it can't satisfy this requirement
    (iommu_is_span_boundary always returns true) and fails even if there are
    many free entries in the IOMMU space.
    
    How did it happen that we try to allocate 17 pages that don't cross
    16-page boundary? The cause is in the function iommu_coalesce_chunks. This
    function tries to coalesce adjacent entries in the scatterlist. The
    function does several checks if it may coalesce one entry with the next,
    one of those checks is this:
    
    	if (startsg->length + dma_len > max_seg_size)
    		break;
    
    When it finishes coalescing adjacent entries, it allocates the mapping:
    
    sg_dma_len(contig_sg) = dma_len;
    dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
    sg_dma_address(contig_sg) =
    	PIDE_FLAG
    	| (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT)
    	| dma_offset;
    
    It is possible that (startsg->length + dma_len > max_seg_size) is false
    (we are just near the 0x10000 max_seg_size boundary), so the funcion
    decides to coalesce this entry with the next entry. When the coalescing
    succeeds, the function performs
    	dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
    And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
    iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
    to allocate 17 pages for a device that must not cross 16-page boundary.
    
    To fix the bug, we must make sure that dma_len after addition of
    dma_offset and alignment doesn't cross the segment boundary. I.e. change
    	if (startsg->length + dma_len > max_seg_size)
    		break;
    to
    	if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size)
    		break;
    
    This patch makes this change (it precalculates max_seg_boundary at the
    beginning of the function iommu_coalesce_chunks). I also added a check
    that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
    not needed for Promise TX2+ SATA, but it may be needed for other devices
    that have dma_get_seg_boundary lower than dma_get_max_seg_size).
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 9fa547b2b7c37507fb04c93fa2d0ccddf7d4d234
Author: Helge Deller <deller@gmx.de>
Date:   Thu Nov 26 21:14:02 2015 +0100

    parisc: protect huge pte changes with spinlocks
    
    Protect all changes of huge page pte entries with purge_tlb_start() and
    purge_tlb_end() spinlocks.
    
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 63424eeaab1e61af0c3eecc0f85fb9ee4877f219
Author: Helge Deller <deller@gmx.de>
Date:   Wed Nov 25 15:39:38 2015 +0100

    parisc: Disable tlb flush optimization with huge pages
    
    It seems calling flush_tlb_all() doesn't reliable flush the tlb on all
    CPUs. Disable it when used with huge pages.
    
    Signed-off-by: Helge Deller <deller@gmx.de>

commit d17fad0a588f399dcda8c6c0c77be0527d85fdd5
Author: Helge Deller <deller@gmx.de>
Date:   Sun Dec 6 21:25:20 2015 +0100

    parisc: Disable huge pages on Mako machines
    
    Mako-based machines (PA8800 and PA8900 CPUs) don't allow aliasing on
    non-equaivalent addresses.
    
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 7fdc06ab013ec847cd25a66208f403e124e6371b
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Tue Nov 24 22:10:26 2015 +0900

    of/irq: optimize device node matching loop in of_irq_init()
    
    Currently, of_irq_init() iterates over interrupt controller nodes
    with for_each_matching_node(), and then gets each init function with
    of_match_node() later.
    
    This routine can be optimized with for_each_matching_node_and_match().
    It allows to get the interrupt controller node and its init function
    at the same time, saving __of_match_node() callings.
    
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Rob Herring <robh@kernel.org>

commit 5e2bfc010f63b3ede1746c53052064fa8fcd7622
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date:   Wed Dec 2 11:35:39 2015 +0000

    dt-bindings: tda998x: Document the required 'port' node.
    
    All the users of the tda998x driver are component based and bind the
    driver via the device graph method described in
    Documentation/devicetree/bindings/graph.txt. Add the fact that the
    'port' node is required to the bindings.
    
    Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
    Signed-off-by: Rob Herring <robh@kernel.org>

commit 8b570dc9f7b634e853866ce40097c0342ac5bb81
Author: lucien <lucien.xin@gmail.com>
Date:   Sat Dec 5 15:19:27 2015 +0800

    sctp: only drop the reference on the datamsg after sending a msg
    
    If the chunks are enqueued successfully but sctp_cmd_interpreter()
    return err to sctp_sendmsg() (mainly because of no mem), the chunks will
    get re-queued, but we are dropping the reference and freeing them.
    
    The fix is to just drop the reference on the datamsg just as it had
    succeeded, as:
     - if the chunks weren't queued, this is enough to get them freed.
     - if they were queued, they will get freed when they finally get out or
     discarded.
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 69b5777f2e5779bb987d4a25a33401d5ac257c14
Author: lucien <lucien.xin@gmail.com>
Date:   Sat Dec 5 15:15:17 2015 +0800

    sctp: hold the chunks only after the chunk is enqueued in outq
    
    When a msg is sent, sctp will hold the chunks of this msg and then try
    to enqueue them. But if the chunks are not enqueued in sctp_outq_tail()
    because of the invalid state, sctp_cmd_interpreter() may still return
    success to sctp_sendmsg() after calling sctp_outq_flush(), these chunks
    will become orphans and will leak.
    
    So we fix them by moving sctp_chunk_hold() to sctp_outq_tail(), where we
    are sure that the chunk is going to get queued.
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit aa1c25666a0c5a37073e06c8308ae93916b1e6df
Author: Guenter Roeck <linux@roeck-us.net>
Date:…
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Dec 14, 2015
I get the splat below when modprobing/rmmoding EDAC drivers. It happens
because bus->name is invalid after bus_unregister() has run. The Code: section
below corresponds to:

  .loc 1 1108 0
  movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
  .loc 1 1109 0
  popq    %rbx    #

  .loc 1 1108 0
  movq    (%rax), %rdi    # _7->name,
  jmp     kfree   #

and %rax has some funky stuff 2030203020312030 which looks a lot like
something walked over it.

Fix that by saving the name ptr before doing stuff to string it points to.

  general protection fault: 0000 [#1] SMP
  Modules linked in: ...
  CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ torvalds#48
  Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
  task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
  RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
  RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
  RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
  RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
  RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
  R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
  R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
  FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
  Stack:
  Call Trace:
    i7core_unregister_mci.isra.9
    i7core_remove
    pci_device_remove
    __device_release_driver
    driver_detach
    bus_remove_driver
    pci_unregister_driver
    i7core_exit
    SyS_delete_module
    system_call_fastpath
    0x7fc9bf426536
  Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
  RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
   RSP <ffff88030da3fe28>

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: <stable@vger.kernel.org> # v3.6..
Fixes: 7a623c0 ("edac: rewrite the sysfs code to use struct device")
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jan 12, 2016
This driver registers for extcon events as part of its probe, but
never unregisters them in case of error in the probe path.

There were multiple issues noticed due to this missing error handling.
One of them is random crashes if the regulators are not ready yet by the
time probe is invoked.

Ivan's previous attempt [1] to fix this issue, did not really address
all the failure cases like regualtor failures.

[1] https://lkml.org/lkml/2015/9/7/62

Without this patch the kernel would carsh with log:
...
Unable to handle kernel paging request at virtual address 17d78410
pgd = ffffffc001a5c000
[17d78410] *pgd=00000000b6806003, *pud=00000000b6806003, *pmd=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.4.0+ torvalds#48
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Workqueue: deferwq deferred_probe_work_func
task: ffffffc03686e900 ti: ffffffc0368b0000 task.ti: ffffffc0368b0000
PC is at raw_notifier_chain_register+0x1c/0x44
LR is at extcon_register_notifier+0x88/0xc8
pc : [<ffffffc0000da43c>] lr : [<ffffffc000606298>] pstate: 80000085
sp : ffffffc0368b3a70
x29: ffffffc0368b3a70 x28: ffffffc03680c310
x27: ffffffc035518000 x26: ffffffc035518000
x25: ffffffc03bfa20e0 x24: ffffffc035580a18
x23: 0000000000000000 x22: ffffffc035518458
x21: ffffffc0355e9a60 x20: ffffffc035518000
x19: 0000000000000000 x18: 0000000000000028
x17: 0000000000000003 x16: ffffffc0018153c8
x15: 0000000000000001 x14: ffffffc03686f0f8
x13: ffffffc03686f0f8 x12: 0000000000000003
x11: 0000000000000001 x10: 0000000000000001
x9 : ffffffc03686f0f8 x8 : 0000e3872014c1a1
x7 : 0000000000000028 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000
x3 : 00000000354fb170 x2 : 0000000017d78400
x1 : ffffffc0355e9a60 x0 : ffffffc0354fb268

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jan 13, 2016
This driver registers for extcon events as part of its probe, but
never unregisters them in case of error in the probe path.

There were multiple issues noticed due to this missing error handling.
One of them is random crashes if the regulators are not ready yet by the
time probe is invoked.

Ivan's previous attempt [1] to fix this issue, did not really address
all the failure cases like regualtor/get_irq failures.

[1] https://lkml.org/lkml/2015/9/7/62

Without this patch the kernel would carsh with log:
...
Unable to handle kernel paging request at virtual address 17d78410
pgd = ffffffc001a5c000
[17d78410] *pgd=00000000b6806003, *pud=00000000b6806003, *pmd=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.4.0+ torvalds#48
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Workqueue: deferwq deferred_probe_work_func
task: ffffffc03686e900 ti: ffffffc0368b0000 task.ti: ffffffc0368b0000
PC is at raw_notifier_chain_register+0x1c/0x44
LR is at extcon_register_notifier+0x88/0xc8
pc : [<ffffffc0000da43c>] lr : [<ffffffc000606298>] pstate: 80000085
sp : ffffffc0368b3a70
x29: ffffffc0368b3a70 x28: ffffffc03680c310
x27: ffffffc035518000 x26: ffffffc035518000
x25: ffffffc03bfa20e0 x24: ffffffc035580a18
x23: 0000000000000000 x22: ffffffc035518458
x21: ffffffc0355e9a60 x20: ffffffc035518000
x19: 0000000000000000 x18: 0000000000000028
x17: 0000000000000003 x16: ffffffc0018153c8
x15: 0000000000000001 x14: ffffffc03686f0f8
x13: ffffffc03686f0f8 x12: 0000000000000003
x11: 0000000000000001 x10: 0000000000000001
x9 : ffffffc03686f0f8 x8 : 0000e3872014c1a1
x7 : 0000000000000028 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000
x3 : 00000000354fb170 x2 : 0000000017d78400
x1 : ffffffc0355e9a60 x0 : ffffffc0354fb268

Fixes: 	591fc11 ("usb: phy: msm: Use extcon framework for VBUS and ID detection")
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
nkskjames referenced this pull request in nkskjames/linux Jan 13, 2016
the returned buffer of register_sysctl() is stored into net_header
variable, but net_header is not used after, and compiler maybe
optimise the variable out, and lead kmemleak reported the below warning

	comm "swapper/0", pid 1, jiffies 4294937448 (age 267.270s)
	hex dump (first 32 bytes):
	90 38 8b 01 c0 ff ff ff 00 00 00 00 01 00 00 00 .8..............
	01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
	backtrace:
	[<ffffffc00020f134>] create_object+0x10c/0x2a0
	[<ffffffc00070ff44>] kmemleak_alloc+0x54/0xa0
	[<ffffffc0001fe378>] __kmalloc+0x1f8/0x4f8
	[<ffffffc00028e984>] __register_sysctl_table+0x64/0x5a0
	[<ffffffc00028eef0>] register_sysctl+0x30/0x40
	[<ffffffc00099c304>] net_sysctl_init+0x20/0x58
	[<ffffffc000994dd8>] sock_init+0x10/0xb0
	[<ffffffc0000842e0>] do_one_initcall+0x90/0x1b8
	[<ffffffc000966bac>] kernel_init_freeable+0x218/0x2f0
	[<ffffffc00070ed6c>] kernel_init+0x1c/0xe8
	[<ffffffc000083bfc>] ret_from_fork+0xc/0x50
	[<ffffffffffffffff>] 0xffffffffffffffff <<end check kmemleak>>

Before fix, the objdump result on ARM64:
0000000000000000 <net_sysctl_init>:
   0:   a9be7bfd        stp     x29, x30, [sp,#-32]!
   4:   90000001        adrp    x1, 0 <net_sysctl_init>
   8:   90000000        adrp    x0, 0 <net_sysctl_init>
   c:   910003fd        mov     x29, sp
  10:   91000021        add     x1, x1, #0x0
  14:   91000000        add     x0, x0, #0x0
  18:   a90153f3        stp     x19, x20, [sp,openbmc#16]
  1c:   12800174        mov     w20, #0xfffffff4                // #-12
  20:   94000000        bl      0 <register_sysctl>
  24:   b4000120        cbz     x0, 48 <net_sysctl_init+0x48>
  28:   90000013        adrp    x19, 0 <net_sysctl_init>
  2c:   91000273        add     x19, x19, #0x0
  30:   9101a260        add     x0, x19, #0x68
  34:   94000000        bl      0 <register_pernet_subsys>
  38:   2a0003f4        mov     w20, w0
  3c:   35000060        cbnz    w0, 48 <net_sysctl_init+0x48>
  40:   aa1303e0        mov     x0, x19
  44:   94000000        bl      0 <register_sysctl_root>
  48:   2a1403e0        mov     w0, w20
  4c:   a94153f3        ldp     x19, x20, [sp,openbmc#16]
  50:   a8c27bfd        ldp     x29, x30, [sp],openbmc#32
  54:   d65f03c0        ret
After:
0000000000000000 <net_sysctl_init>:
   0:   a9bd7bfd        stp     x29, x30, [sp,#-48]!
   4:   90000000        adrp    x0, 0 <net_sysctl_init>
   8:   910003fd        mov     x29, sp
   c:   a90153f3        stp     x19, x20, [sp,openbmc#16]
  10:   90000013        adrp    x19, 0 <net_sysctl_init>
  14:   91000000        add     x0, x0, #0x0
  18:   91000273        add     x19, x19, #0x0
  1c:   f90013f5        str     x21, [sp,openbmc#32]
  20:   aa1303e1        mov     x1, x19
  24:   12800175        mov     w21, #0xfffffff4                // #-12
  28:   94000000        bl      0 <register_sysctl>
  2c:   f9002260        str     x0, [x19,openbmc#64]
  30:   b40001a0        cbz     x0, 64 <net_sysctl_init+0x64>
  34:   90000014        adrp    x20, 0 <net_sysctl_init>
  38:   91000294        add     x20, x20, #0x0
  3c:   9101a280        add     x0, x20, #0x68
  40:   94000000        bl      0 <register_pernet_subsys>
  44:   2a0003f5        mov     w21, w0
  48:   35000080        cbnz    w0, 58 <net_sysctl_init+0x58>
  4c:   aa1403e0        mov     x0, x20
  50:   94000000        bl      0 <register_sysctl_root>
  54:   14000004        b       64 <net_sysctl_init+0x64>
  58:   f9402260        ldr     x0, [x19,openbmc#64]
  5c:   94000000        bl      0 <unregister_sysctl_table>
  60:   f900227f        str     xzr, [x19,openbmc#64]
  64:   2a1503e0        mov     w0, w21
  68:   f94013f5        ldr     x21, [sp,openbmc#32]
  6c:   a94153f3        ldp     x19, x20, [sp,openbmc#16]
  70:   a8c37bfd        ldp     x29, x30, [sp],openbmc#48
  74:   d65f03c0        ret

Add the possible error handle to free the net_header to remove the
kmemleak warning

Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Feb 4, 2016
This driver registers for extcon events as part of its probe, but
never unregisters them in case of error in the probe path.

There were multiple issues noticed due to this missing error handling.
One of them is random crashes if the regulators are not ready yet by the
time probe is invoked.

Ivan's previous attempt [1] to fix this issue, did not really address
all the failure cases like regualtor/get_irq failures.

[1] https://lkml.org/lkml/2015/9/7/62

Without this patch the kernel would carsh with log:
...
Unable to handle kernel paging request at virtual address 17d78410
pgd = ffffffc001a5c000
[17d78410] *pgd=00000000b6806003, *pud=00000000b6806003, *pmd=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.4.0+ torvalds#48
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Workqueue: deferwq deferred_probe_work_func
task: ffffffc03686e900 ti: ffffffc0368b0000 task.ti: ffffffc0368b0000
PC is at raw_notifier_chain_register+0x1c/0x44
LR is at extcon_register_notifier+0x88/0xc8
pc : [<ffffffc0000da43c>] lr : [<ffffffc000606298>] pstate: 80000085
sp : ffffffc0368b3a70
x29: ffffffc0368b3a70 x28: ffffffc03680c310
x27: ffffffc035518000 x26: ffffffc035518000
x25: ffffffc03bfa20e0 x24: ffffffc035580a18
x23: 0000000000000000 x22: ffffffc035518458
x21: ffffffc0355e9a60 x20: ffffffc035518000
x19: 0000000000000000 x18: 0000000000000028
x17: 0000000000000003 x16: ffffffc0018153c8
x15: 0000000000000001 x14: ffffffc03686f0f8
x13: ffffffc03686f0f8 x12: 0000000000000003
x11: 0000000000000001 x10: 0000000000000001
x9 : ffffffc03686f0f8 x8 : 0000e3872014c1a1
x7 : 0000000000000028 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000
x3 : 00000000354fb170 x2 : 0000000017d78400
x1 : ffffffc0355e9a60 x0 : ffffffc0354fb268

Fixes: 	591fc11 ("usb: phy: msm: Use extcon framework for VBUS and ID detection")
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
rsalveti pushed a commit to rsalveti/linux that referenced this pull request Feb 9, 2016
This driver registers for extcon events as part of its probe, but
never unregisters them in case of error in the probe path.

There were multiple issues noticed due to this missing error handling.
One of them is random crashes if the regulators are not ready yet by the
time probe is invoked.

Ivan's previous attempt [1] to fix this issue, did not really address
all the failure cases like regualtor failures.

[1] https://lkml.org/lkml/2015/9/7/62

Without this patch the kernel would carsh with log:
...
Unable to handle kernel paging request at virtual address 17d78410
pgd = ffffffc001a5c000
[17d78410] *pgd=00000000b6806003, *pud=00000000b6806003, *pmd=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.4.0+ torvalds#48
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Workqueue: deferwq deferred_probe_work_func
task: ffffffc03686e900 ti: ffffffc0368b0000 task.ti: ffffffc0368b0000
PC is at raw_notifier_chain_register+0x1c/0x44
LR is at extcon_register_notifier+0x88/0xc8
pc : [<ffffffc0000da43c>] lr : [<ffffffc000606298>] pstate: 80000085
sp : ffffffc0368b3a70
x29: ffffffc0368b3a70 x28: ffffffc03680c310
x27: ffffffc035518000 x26: ffffffc035518000
x25: ffffffc03bfa20e0 x24: ffffffc035580a18
x23: 0000000000000000 x22: ffffffc035518458
x21: ffffffc0355e9a60 x20: ffffffc035518000
x19: 0000000000000000 x18: 0000000000000028
x17: 0000000000000003 x16: ffffffc0018153c8
x15: 0000000000000001 x14: ffffffc03686f0f8
x13: ffffffc03686f0f8 x12: 0000000000000003
x11: 0000000000000001 x10: 0000000000000001
x9 : ffffffc03686f0f8 x8 : 0000e3872014c1a1
x7 : 0000000000000028 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000
x3 : 00000000354fb170 x2 : 0000000017d78400
x1 : ffffffc0355e9a60 x0 : ffffffc0354fb268

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Noltari pushed a commit to Noltari/linux that referenced this pull request Feb 16, 2016
[ Upstream commit 12e2696 ]

I get the splat below when modprobing/rmmoding EDAC drivers. It happens
because bus->name is invalid after bus_unregister() has run. The Code: section
below corresponds to:

  .loc 1 1108 0
  movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
  .loc 1 1109 0
  popq    %rbx    #

  .loc 1 1108 0
  movq    (%rax), %rdi    # _7->name,
  jmp     kfree   #

and %rax has some funky stuff 2030203020312030 which looks a lot like
something walked over it.

Fix that by saving the name ptr before doing stuff to string it points to.

  general protection fault: 0000 [#1] SMP
  Modules linked in: ...
  CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ torvalds#48
  Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
  task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
  RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
  RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
  RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
  RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
  RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
  R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
  R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
  FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
  Stack:
  Call Trace:
    i7core_unregister_mci.isra.9
    i7core_remove
    pci_device_remove
    __device_release_driver
    driver_detach
    bus_remove_driver
    pci_unregister_driver
    i7core_exit
    SyS_delete_module
    system_call_fastpath
    0x7fc9bf426536
  Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
  RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
   RSP <ffff88030da3fe28>

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: <stable@vger.kernel.org> # v3.6..
Fixes: 7a623c0 ("edac: rewrite the sysfs code to use struct device")
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Noltari pushed a commit to Noltari/linux that referenced this pull request Feb 17, 2016
commit a38a08d upstream.

This driver registers for extcon events as part of its probe, but
never unregisters them in case of error in the probe path.

There were multiple issues noticed due to this missing error handling.
One of them is random crashes if the regulators are not ready yet by the
time probe is invoked.

Ivan's previous attempt [1] to fix this issue, did not really address
all the failure cases like regualtor/get_irq failures.

[1] https://lkml.org/lkml/2015/9/7/62

Without this patch the kernel would carsh with log:
...
Unable to handle kernel paging request at virtual address 17d78410
pgd = ffffffc001a5c000
[17d78410] *pgd=00000000b6806003, *pud=00000000b6806003, *pmd=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.4.0+ torvalds#48
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Workqueue: deferwq deferred_probe_work_func
task: ffffffc03686e900 ti: ffffffc0368b0000 task.ti: ffffffc0368b0000
PC is at raw_notifier_chain_register+0x1c/0x44
LR is at extcon_register_notifier+0x88/0xc8
pc : [<ffffffc0000da43c>] lr : [<ffffffc000606298>] pstate: 80000085
sp : ffffffc0368b3a70
x29: ffffffc0368b3a70 x28: ffffffc03680c310
x27: ffffffc035518000 x26: ffffffc035518000
x25: ffffffc03bfa20e0 x24: ffffffc035580a18
x23: 0000000000000000 x22: ffffffc035518458
x21: ffffffc0355e9a60 x20: ffffffc035518000
x19: 0000000000000000 x18: 0000000000000028
x17: 0000000000000003 x16: ffffffc0018153c8
x15: 0000000000000001 x14: ffffffc03686f0f8
x13: ffffffc03686f0f8 x12: 0000000000000003
x11: 0000000000000001 x10: 0000000000000001
x9 : ffffffc03686f0f8 x8 : 0000e3872014c1a1
x7 : 0000000000000028 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000
x3 : 00000000354fb170 x2 : 0000000017d78400
x1 : ffffffc0355e9a60 x0 : ffffffc0354fb268

Fixes: 	591fc11 ("usb: phy: msm: Use extcon framework for VBUS and ID detection")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
damentz referenced this pull request in zen-kernel/zen-kernel Feb 20, 2016
commit a38a08d upstream.

This driver registers for extcon events as part of its probe, but
never unregisters them in case of error in the probe path.

There were multiple issues noticed due to this missing error handling.
One of them is random crashes if the regulators are not ready yet by the
time probe is invoked.

Ivan's previous attempt [1] to fix this issue, did not really address
all the failure cases like regualtor/get_irq failures.

[1] https://lkml.org/lkml/2015/9/7/62

Without this patch the kernel would carsh with log:
...
Unable to handle kernel paging request at virtual address 17d78410
pgd = ffffffc001a5c000
[17d78410] *pgd=00000000b6806003, *pud=00000000b6806003, *pmd=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.4.0+ #48
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Workqueue: deferwq deferred_probe_work_func
task: ffffffc03686e900 ti: ffffffc0368b0000 task.ti: ffffffc0368b0000
PC is at raw_notifier_chain_register+0x1c/0x44
LR is at extcon_register_notifier+0x88/0xc8
pc : [<ffffffc0000da43c>] lr : [<ffffffc000606298>] pstate: 80000085
sp : ffffffc0368b3a70
x29: ffffffc0368b3a70 x28: ffffffc03680c310
x27: ffffffc035518000 x26: ffffffc035518000
x25: ffffffc03bfa20e0 x24: ffffffc035580a18
x23: 0000000000000000 x22: ffffffc035518458
x21: ffffffc0355e9a60 x20: ffffffc035518000
x19: 0000000000000000 x18: 0000000000000028
x17: 0000000000000003 x16: ffffffc0018153c8
x15: 0000000000000001 x14: ffffffc03686f0f8
x13: ffffffc03686f0f8 x12: 0000000000000003
x11: 0000000000000001 x10: 0000000000000001
x9 : ffffffc03686f0f8 x8 : 0000e3872014c1a1
x7 : 0000000000000028 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000
x3 : 00000000354fb170 x2 : 0000000017d78400
x1 : ffffffc0355e9a60 x0 : ffffffc0354fb268

Fixes: 	591fc11 ("usb: phy: msm: Use extcon framework for VBUS and ID detection")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ddstreet pushed a commit to ddstreet/linux that referenced this pull request Feb 29, 2016
BugLink: http://bugs.launchpad.net/bugs/1540532

commit 12e2696 upstream.

I get the splat below when modprobing/rmmoding EDAC drivers. It happens
because bus->name is invalid after bus_unregister() has run. The Code: section
below corresponds to:

  .loc 1 1108 0
  movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
  .loc 1 1109 0
  popq    %rbx    #

  .loc 1 1108 0
  movq    (%rax), %rdi    # _7->name,
  jmp     kfree   #

and %rax has some funky stuff 2030203020312030 which looks a lot like
something walked over it.

Fix that by saving the name ptr before doing stuff to string it points to.

  general protection fault: 0000 [#1] SMP
  Modules linked in: ...
  CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ torvalds#48
  Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
  task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
  RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
  RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
  RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
  RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
  RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
  R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
  R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
  FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
  Stack:
  Call Trace:
    i7core_unregister_mci.isra.9
    i7core_remove
    pci_device_remove
    __device_release_driver
    driver_detach
    bus_remove_driver
    pci_unregister_driver
    i7core_exit
    SyS_delete_module
    system_call_fastpath
    0x7fc9bf426536
  Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
  RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
   RSP <ffff88030da3fe28>

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Fixes: 7a623c0 ("edac: rewrite the sysfs code to use struct device")
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Noltari pushed a commit to Noltari/linux that referenced this pull request Mar 4, 2016
commit 12e2696 upstream.

I get the splat below when modprobing/rmmoding EDAC drivers. It happens
because bus->name is invalid after bus_unregister() has run. The Code: section
below corresponds to:

  .loc 1 1108 0
  movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
  .loc 1 1109 0
  popq    %rbx    #

  .loc 1 1108 0
  movq    (%rax), %rdi    # _7->name,
  jmp     kfree   #

and %rax has some funky stuff 2030203020312030 which looks a lot like
something walked over it.

Fix that by saving the name ptr before doing stuff to string it points to.

  general protection fault: 0000 [#1] SMP
  Modules linked in: ...
  CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ torvalds#48
  Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
  task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
  RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
  RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
  RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
  RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
  RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
  R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
  R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
  FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
  Stack:
  Call Trace:
    i7core_unregister_mci.isra.9
    i7core_remove
    pci_device_remove
    __device_release_driver
    driver_detach
    bus_remove_driver
    pci_unregister_driver
    i7core_exit
    SyS_delete_module
    system_call_fastpath
    0x7fc9bf426536
  Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
  RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
   RSP <ffff88030da3fe28>

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Fixes: 7a623c0 ("edac: rewrite the sysfs code to use struct device")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari pushed a commit to Noltari/linux that referenced this pull request Mar 9, 2016
commit 12e2696 upstream.

I get the splat below when modprobing/rmmoding EDAC drivers. It happens
because bus->name is invalid after bus_unregister() has run. The Code: section
below corresponds to:

  .loc 1 1108 0
  movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
  .loc 1 1109 0
  popq    %rbx    #

  .loc 1 1108 0
  movq    (%rax), %rdi    # _7->name,
  jmp     kfree   #

and %rax has some funky stuff 2030203020312030 which looks a lot like
something walked over it.

Fix that by saving the name ptr before doing stuff to string it points to.

  general protection fault: 0000 [#1] SMP
  Modules linked in: ...
  CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ torvalds#48
  Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
  task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
  RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
  RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
  RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
  RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
  RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
  R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
  R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
  FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
  Stack:
  Call Trace:
    i7core_unregister_mci.isra.9
    i7core_remove
    pci_device_remove
    __device_release_driver
    driver_detach
    bus_remove_driver
    pci_unregister_driver
    i7core_exit
    SyS_delete_module
    system_call_fastpath
    0x7fc9bf426536
  Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
  RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
   RSP <ffff88030da3fe28>

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Fixes: 7a623c0 ("edac: rewrite the sysfs code to use struct device")
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Sep 1, 2024
This is to allow copying into the buffer from the application
without the need to copy in ring context (and with that,
the need that the ring task is active in kernel space).

Also absolutely needed for now to avoid this teardown issue

 1525.905504] KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]
[ 1525.910431] CPU: 15 PID: 183 Comm: kworker/15:1 Tainted: G           O       6.10.0+ torvalds#48
[ 1525.916449] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 1525.922470] Workqueue: events io_fallback_req_func
[ 1525.925840] RIP: 0010:__lock_acquire+0x74/0x7b80
[ 1525.929010] Code: 89 bc 24 80 00 00 00 0f 85 1c 5f 00 00 83 3d 6e 80 b0 02 00 0f 84 1d 12 00 00 83 3d 65 c7 67 02 00 74 27 48 89 f8 48 c1 e8 03 <42> 80 3c 30 00 74 0d e8 50 44 42 00 48 8b bc 24 80 00 00 00 48 c7
[ 1525.942211] RSP: 0018:ffff88810b2af490 EFLAGS: 00010002
[ 1525.945672] RAX: 0000000000000034 RBX: 0000000000000000 RCX: 0000000000000001
[ 1525.950421] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000001a0
[ 1525.955200] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[ 1525.959979] R10: dffffc0000000000 R11: fffffbfff07b1cbe R12: 0000000000000000
[ 1525.964252] R13: 0000000000000001 R14: dffffc0000000000 R15: 0000000000000001
[ 1525.968225] FS:  0000000000000000(0000) GS:ffff88875b200000(0000) knlGS:0000000000000000
[ 1525.973932] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1525.976694] CR2: 00005555b6a381f0 CR3: 000000012f5f1000 CR4: 00000000000006f0
[ 1525.980030] Call Trace:
[ 1525.981371]  <TASK>
[ 1525.982567]  ? __die_body+0x66/0xb0
[ 1525.984376]  ? die_addr+0xc1/0x100
[ 1525.986111]  ? exc_general_protection+0x1c6/0x330
[ 1525.988401]  ? asm_exc_general_protection+0x22/0x30
[ 1525.990864]  ? __lock_acquire+0x74/0x7b80
[ 1525.992901]  ? mark_lock+0x9f/0x360
[ 1525.994635]  ? __lock_acquire+0x1420/0x7b80
[ 1525.996629]  ? attach_entity_load_avg+0x47d/0x550
[ 1525.998765]  ? hlock_conflict+0x5a/0x1f0
[ 1526.000515]  ? __bfs+0x2dc/0x5a0
[ 1526.001993]  lock_acquire+0x1fb/0x3d0
[ 1526.004727]  ? gup_fast_fallback+0x13f/0x1d80
[ 1526.006586]  ? gup_fast_fallback+0x13f/0x1d80
[ 1526.008412]  gup_fast_fallback+0x158/0x1d80
[ 1526.010170]  ? gup_fast_fallback+0x13f/0x1d80
[ 1526.011999]  ? __lock_acquire+0x2b07/0x7b80
[ 1526.013793]  __iov_iter_get_pages_alloc+0x36e/0x980
[ 1526.015876]  ? do_raw_spin_unlock+0x5a/0x8a0
[ 1526.017734]  iov_iter_get_pages2+0x56/0x70
[ 1526.019491]  fuse_copy_fill+0x48e/0x980 [fuse]
[ 1526.021400]  fuse_copy_args+0x174/0x6a0 [fuse]
[ 1526.023199]  fuse_uring_prepare_send+0x319/0x6c0 [fuse]
[ 1526.025178]  fuse_uring_send_req_in_task+0x42/0x100 [fuse]
[ 1526.027163]  io_fallback_req_func+0xb4/0x170
[ 1526.028737]  ? process_scheduled_works+0x75b/0x1160
[ 1526.030445]  process_scheduled_works+0x85c/0x1160
[ 1526.032073]  worker_thread+0x8ba/0xce0
[ 1526.033388]  kthread+0x23e/0x2b0
[ 1526.035404]  ? pr_cont_work_flush+0x290/0x290
[ 1526.036958]  ? kthread_blkcg+0xa0/0xa0
[ 1526.038321]  ret_from_fork+0x30/0x60
[ 1526.039600]  ? kthread_blkcg+0xa0/0xa0
[ 1526.040942]  ret_from_fork_asm+0x11/0x20
[ 1526.042353]  </TASK>

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
bsbernd added a commit to bsbernd/linux that referenced this pull request Sep 3, 2024
This is to allow copying into the buffer from the application
without the need to copy in ring context (and with that,
the need that the ring task is active in kernel space).

Also absolutely needed for now to avoid this teardown issue

 1525.905504] KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]
[ 1525.910431] CPU: 15 PID: 183 Comm: kworker/15:1 Tainted: G           O       6.10.0+ torvalds#48
[ 1525.916449] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 1525.922470] Workqueue: events io_fallback_req_func
[ 1525.925840] RIP: 0010:__lock_acquire+0x74/0x7b80
[ 1525.929010] Code: 89 bc 24 80 00 00 00 0f 85 1c 5f 00 00 83 3d 6e 80 b0 02 00 0f 84 1d 12 00 00 83 3d 65 c7 67 02 00 74 27 48 89 f8 48 c1 e8 03 <42> 80 3c 30 00 74 0d e8 50 44 42 00 48 8b bc 24 80 00 00 00 48 c7
[ 1525.942211] RSP: 0018:ffff88810b2af490 EFLAGS: 00010002
[ 1525.945672] RAX: 0000000000000034 RBX: 0000000000000000 RCX: 0000000000000001
[ 1525.950421] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000001a0
[ 1525.955200] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[ 1525.959979] R10: dffffc0000000000 R11: fffffbfff07b1cbe R12: 0000000000000000
[ 1525.964252] R13: 0000000000000001 R14: dffffc0000000000 R15: 0000000000000001
[ 1525.968225] FS:  0000000000000000(0000) GS:ffff88875b200000(0000) knlGS:0000000000000000
[ 1525.973932] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1525.976694] CR2: 00005555b6a381f0 CR3: 000000012f5f1000 CR4: 00000000000006f0
[ 1525.980030] Call Trace:
[ 1525.981371]  <TASK>
[ 1525.982567]  ? __die_body+0x66/0xb0
[ 1525.984376]  ? die_addr+0xc1/0x100
[ 1525.986111]  ? exc_general_protection+0x1c6/0x330
[ 1525.988401]  ? asm_exc_general_protection+0x22/0x30
[ 1525.990864]  ? __lock_acquire+0x74/0x7b80
[ 1525.992901]  ? mark_lock+0x9f/0x360
[ 1525.994635]  ? __lock_acquire+0x1420/0x7b80
[ 1525.996629]  ? attach_entity_load_avg+0x47d/0x550
[ 1525.998765]  ? hlock_conflict+0x5a/0x1f0
[ 1526.000515]  ? __bfs+0x2dc/0x5a0
[ 1526.001993]  lock_acquire+0x1fb/0x3d0
[ 1526.004727]  ? gup_fast_fallback+0x13f/0x1d80
[ 1526.006586]  ? gup_fast_fallback+0x13f/0x1d80
[ 1526.008412]  gup_fast_fallback+0x158/0x1d80
[ 1526.010170]  ? gup_fast_fallback+0x13f/0x1d80
[ 1526.011999]  ? __lock_acquire+0x2b07/0x7b80
[ 1526.013793]  __iov_iter_get_pages_alloc+0x36e/0x980
[ 1526.015876]  ? do_raw_spin_unlock+0x5a/0x8a0
[ 1526.017734]  iov_iter_get_pages2+0x56/0x70
[ 1526.019491]  fuse_copy_fill+0x48e/0x980 [fuse]
[ 1526.021400]  fuse_copy_args+0x174/0x6a0 [fuse]
[ 1526.023199]  fuse_uring_prepare_send+0x319/0x6c0 [fuse]
[ 1526.025178]  fuse_uring_send_req_in_task+0x42/0x100 [fuse]
[ 1526.027163]  io_fallback_req_func+0xb4/0x170
[ 1526.028737]  ? process_scheduled_works+0x75b/0x1160
[ 1526.030445]  process_scheduled_works+0x85c/0x1160
[ 1526.032073]  worker_thread+0x8ba/0xce0
[ 1526.033388]  kthread+0x23e/0x2b0
[ 1526.035404]  ? pr_cont_work_flush+0x290/0x290
[ 1526.036958]  ? kthread_blkcg+0xa0/0xa0
[ 1526.038321]  ret_from_fork+0x30/0x60
[ 1526.039600]  ? kthread_blkcg+0xa0/0xa0
[ 1526.040942]  ret_from_fork_asm+0x11/0x20
[ 1526.042353]  </TASK>

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
bsbernd added a commit to bsbernd/linux that referenced this pull request Sep 30, 2024
This is to allow copying into the buffer from the application
without the need to copy in ring context (and with that,
the need that the ring task is active in kernel space).

Also absolutely needed for now to avoid this teardown issue

 1525.905504] KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]
[ 1525.910431] CPU: 15 PID: 183 Comm: kworker/15:1 Tainted: G           O       6.10.0+ torvalds#48
[ 1525.916449] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 1525.922470] Workqueue: events io_fallback_req_func
[ 1525.925840] RIP: 0010:__lock_acquire+0x74/0x7b80
[ 1525.929010] Code: 89 bc 24 80 00 00 00 0f 85 1c 5f 00 00 83 3d 6e 80 b0 02 00 0f 84 1d 12 00 00 83 3d 65 c7 67 02 00 74 27 48 89 f8 48 c1 e8 03 <42> 80 3c 30 00 74 0d e8 50 44 42 00 48 8b bc 24 80 00 00 00 48 c7
[ 1525.942211] RSP: 0018:ffff88810b2af490 EFLAGS: 00010002
[ 1525.945672] RAX: 0000000000000034 RBX: 0000000000000000 RCX: 0000000000000001
[ 1525.950421] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000001a0
[ 1525.955200] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[ 1525.959979] R10: dffffc0000000000 R11: fffffbfff07b1cbe R12: 0000000000000000
[ 1525.964252] R13: 0000000000000001 R14: dffffc0000000000 R15: 0000000000000001
[ 1525.968225] FS:  0000000000000000(0000) GS:ffff88875b200000(0000) knlGS:0000000000000000
[ 1525.973932] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1525.976694] CR2: 00005555b6a381f0 CR3: 000000012f5f1000 CR4: 00000000000006f0
[ 1525.980030] Call Trace:
[ 1525.981371]  <TASK>
[ 1525.982567]  ? __die_body+0x66/0xb0
[ 1525.984376]  ? die_addr+0xc1/0x100
[ 1525.986111]  ? exc_general_protection+0x1c6/0x330
[ 1525.988401]  ? asm_exc_general_protection+0x22/0x30
[ 1525.990864]  ? __lock_acquire+0x74/0x7b80
[ 1525.992901]  ? mark_lock+0x9f/0x360
[ 1525.994635]  ? __lock_acquire+0x1420/0x7b80
[ 1525.996629]  ? attach_entity_load_avg+0x47d/0x550
[ 1525.998765]  ? hlock_conflict+0x5a/0x1f0
[ 1526.000515]  ? __bfs+0x2dc/0x5a0
[ 1526.001993]  lock_acquire+0x1fb/0x3d0
[ 1526.004727]  ? gup_fast_fallback+0x13f/0x1d80
[ 1526.006586]  ? gup_fast_fallback+0x13f/0x1d80
[ 1526.008412]  gup_fast_fallback+0x158/0x1d80
[ 1526.010170]  ? gup_fast_fallback+0x13f/0x1d80
[ 1526.011999]  ? __lock_acquire+0x2b07/0x7b80
[ 1526.013793]  __iov_iter_get_pages_alloc+0x36e/0x980
[ 1526.015876]  ? do_raw_spin_unlock+0x5a/0x8a0
[ 1526.017734]  iov_iter_get_pages2+0x56/0x70
[ 1526.019491]  fuse_copy_fill+0x48e/0x980 [fuse]
[ 1526.021400]  fuse_copy_args+0x174/0x6a0 [fuse]
[ 1526.023199]  fuse_uring_prepare_send+0x319/0x6c0 [fuse]
[ 1526.025178]  fuse_uring_send_req_in_task+0x42/0x100 [fuse]
[ 1526.027163]  io_fallback_req_func+0xb4/0x170
[ 1526.028737]  ? process_scheduled_works+0x75b/0x1160
[ 1526.030445]  process_scheduled_works+0x85c/0x1160
[ 1526.032073]  worker_thread+0x8ba/0xce0
[ 1526.033388]  kthread+0x23e/0x2b0
[ 1526.035404]  ? pr_cont_work_flush+0x290/0x290
[ 1526.036958]  ? kthread_blkcg+0xa0/0xa0
[ 1526.038321]  ret_from_fork+0x30/0x60
[ 1526.039600]  ? kthread_blkcg+0xa0/0xa0
[ 1526.040942]  ret_from_fork_asm+0x11/0x20
[ 1526.042353]  </TASK>

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Sep 30, 2024
Fix a checkpatch --strict issue:

  CHECK: Alignment should match open parenthesis
  torvalds#48: FILE: drivers/reset/amlogic/reset-meson-common.c:48:
  +static int meson_reset_level(struct reset_controller_dev *rcdev,
  +			    unsigned long id, bool assert)

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Oct 2, 2024
Fix a checkpatch --strict issue:

  CHECK: Alignment should match open parenthesis
  torvalds#48: FILE: drivers/reset/amlogic/reset-meson-common.c:48:
  +static int meson_reset_level(struct reset_controller_dev *rcdev,
  +			    unsigned long id, bool assert)

Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20240930-reset-align-amlogic-v1-1-f64ed5c4efc1@pengutronix.de
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Oct 9, 2024
During the migration of Soundwire runtime stream allocation from
the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845
soundcard was forgotten.

At this point any playback attempt or audio daemon startup, for instance
on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer
NULL dereference:

 Unable to handle kernel NULL pointer dereference at virtual
 address 0000000000000020
 Mem abort info:
   ESR = 0x0000000096000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x04: level 0 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000
 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 5 UID: 0 PID: 1198 Comm: aplay
 Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty torvalds#18
 Hardware name: Thundercomm Dragonboard 845c (DT)
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 sp : ffff80008a2035c0
 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000
 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800
 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003
 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec
 x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003
 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8
 Call trace:
  sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
  wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]
  snd_soc_dai_hw_params+0x3c/0xa4
  __soc_pcm_hw_params+0x230/0x660
  dpcm_be_dai_hw_params+0x1d0/0x3f8
  dpcm_fe_dai_hw_params+0x98/0x268
  snd_pcm_hw_params+0x124/0x460
  snd_pcm_common_ioctl+0x998/0x16e8
  snd_pcm_ioctl+0x34/0x58
  __arm64_sys_ioctl+0xac/0xf8
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x34/0xe0
  el0t_64_sync_handler+0x120/0x12c
  el0t_64_sync+0x190/0x194
 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)
 ---[ end trace 0000000000000000 ]---

0000000000006108 <sdw_stream_add_slave>:
    6108:       d503233f        paciasp
    610c:       a9b97bfd        stp     x29, x30, [sp, #-112]!
    6110:       910003fd        mov     x29, sp
    6114:       a90153f3        stp     x19, x20, [sp, torvalds#16]
    6118:       a9025bf5        stp     x21, x22, [sp, torvalds#32]
    611c:       aa0103f6        mov     x22, x1
    6120:       2a0303f5        mov     w21, w3
    6124:       a90363f7        stp     x23, x24, [sp, torvalds#48]
    6128:       aa0003f8        mov     x24, x0
    612c:       aa0203f7        mov     x23, x2
    6130:       a9046bf9        stp     x25, x26, [sp, torvalds#64]
    6134:       aa0403f9        mov     x25, x4        <-- x4 copied to x25
    6138:       a90573fb        stp     x27, x28, [sp, torvalds#80]
    613c:       aa0403fb        mov     x27, x4
    6140:       f9418400        ldr     x0, [x0, torvalds#776]
    6144:       9100e000        add     x0, x0, #0x38
    6148:       94000000        bl      0 <mutex_lock>
    614c:       f8420f22        ldr     x2, [x25, torvalds#32]!  <-- offset 0x44
    ^^^
This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()
where data abort happens.
wsa881x_hw_params() is called with stream = NULL and passes it further
in register x4 (5th argument) to sdw_stream_add_slave() without any checks.
Value from x4 is copied to x25 and finally it aborts on trying to load
a value from address in x25 plus offset 32 (in dec) which corresponds
to master_list member in struct sdw_stream_runtime:

struct sdw_stream_runtime {
        const char  *              name;	/*     0     8 */
        struct sdw_stream_params   params;	/*     8    12 */
        enum sdw_stream_state      state;	/*    20     4 */
        enum sdw_stream_type       type;	/*    24     4 */
        /* XXX 4 bytes hole, try to pack */
 here-> struct list_head           master_list;	/*    32    16 */
        int                        m_rt_count;	/*    48     4 */
        /* size: 56, cachelines: 1, members: 6 */
        /* sum members: 48, holes: 1, sum holes: 4 */
        /* padding: 4 */
        /* last cacheline: 56 bytes */

Fix this by adding required calls to qcom_snd_sdw_startup() and
sdw_release_stream() to startup and shutdown routines which restores
the previous correct behaviour when ->set_stream() method is called to
set a valid stream runtime pointer on playback startup.

Reproduced and then fix was tested on db845c RB3 board.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: stable@vger.kernel.org
Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Oct 10, 2024
During the migration of Soundwire runtime stream allocation from
the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845
soundcard was forgotten.

At this point any playback attempt or audio daemon startup, for instance
on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer
NULL dereference:

 Unable to handle kernel NULL pointer dereference at virtual
 address 0000000000000020
 Mem abort info:
   ESR = 0x0000000096000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x04: level 0 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000
 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 5 UID: 0 PID: 1198 Comm: aplay
 Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty torvalds#18
 Hardware name: Thundercomm Dragonboard 845c (DT)
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 sp : ffff80008a2035c0
 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000
 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800
 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003
 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec
 x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003
 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8
 Call trace:
  sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
  wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]
  snd_soc_dai_hw_params+0x3c/0xa4
  __soc_pcm_hw_params+0x230/0x660
  dpcm_be_dai_hw_params+0x1d0/0x3f8
  dpcm_fe_dai_hw_params+0x98/0x268
  snd_pcm_hw_params+0x124/0x460
  snd_pcm_common_ioctl+0x998/0x16e8
  snd_pcm_ioctl+0x34/0x58
  __arm64_sys_ioctl+0xac/0xf8
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x34/0xe0
  el0t_64_sync_handler+0x120/0x12c
  el0t_64_sync+0x190/0x194
 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)
 ---[ end trace 0000000000000000 ]---

0000000000006108 <sdw_stream_add_slave>:
    6108:       d503233f        paciasp
    610c:       a9b97bfd        stp     x29, x30, [sp, #-112]!
    6110:       910003fd        mov     x29, sp
    6114:       a90153f3        stp     x19, x20, [sp, torvalds#16]
    6118:       a9025bf5        stp     x21, x22, [sp, torvalds#32]
    611c:       aa0103f6        mov     x22, x1
    6120:       2a0303f5        mov     w21, w3
    6124:       a90363f7        stp     x23, x24, [sp, torvalds#48]
    6128:       aa0003f8        mov     x24, x0
    612c:       aa0203f7        mov     x23, x2
    6130:       a9046bf9        stp     x25, x26, [sp, torvalds#64]
    6134:       aa0403f9        mov     x25, x4        <-- x4 copied to x25
    6138:       a90573fb        stp     x27, x28, [sp, torvalds#80]
    613c:       aa0403fb        mov     x27, x4
    6140:       f9418400        ldr     x0, [x0, torvalds#776]
    6144:       9100e000        add     x0, x0, #0x38
    6148:       94000000        bl      0 <mutex_lock>
    614c:       f8420f22        ldr     x2, [x25, torvalds#32]!  <-- offset 0x44
    ^^^
This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()
where data abort happens.
wsa881x_hw_params() is called with stream = NULL and passes it further
in register x4 (5th argument) to sdw_stream_add_slave() without any checks.
Value from x4 is copied to x25 and finally it aborts on trying to load
a value from address in x25 plus offset 32 (in dec) which corresponds
to master_list member in struct sdw_stream_runtime:

struct sdw_stream_runtime {
        const char  *              name;	/*     0     8 */
        struct sdw_stream_params   params;	/*     8    12 */
        enum sdw_stream_state      state;	/*    20     4 */
        enum sdw_stream_type       type;	/*    24     4 */
        /* XXX 4 bytes hole, try to pack */
 here-> struct list_head           master_list;	/*    32    16 */
        int                        m_rt_count;	/*    48     4 */
        /* size: 56, cachelines: 1, members: 6 */
        /* sum members: 48, holes: 1, sum holes: 4 */
        /* padding: 4 */
        /* last cacheline: 56 bytes */

Fix this by adding required calls to qcom_snd_sdw_startup() and
sdw_release_stream() to startup and shutdown routines which restores
the previous correct behaviour when ->set_stream() method is called to
set a valid stream runtime pointer on playback startup.

Reproduced and then fix was tested on db845c RB3 board.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: stable@vger.kernel.org
Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://patch.msgid.link/20241009213922.999355-1-alexey.klimov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Oct 28, 2024
[ Upstream commit 60f07e2 ]

We use uprobe in aarch64_be, which we found the tracee task would exit
due to SIGILL when we enable the uprobe trace.
We can see the replace inst from uprobe is not correct in aarch big-endian.
As in Armv8-A, instruction fetches are always treated as little-endian,
we should treat the UPROBE_SWBP_INSN as little-endian。

The test case is as following。
bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null &
bash-4.4# cd /sys/kernel/debug/tracing/
bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events
bash-4.4# echo 1 > events/uprobes/enable
bash-4.4#
bash-4.4# ps
  PID TTY          TIME CMD
  140 ?        00:00:01 bash
  237 ?        00:00:00 ps
[1]+  Illegal instruction     ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null

which we debug use gdb as following:

bash-4.4# gdb attach 155
(gdb) disassemble send
Dump of assembler code for function send:
   0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]
   0x0000000000400c44 <+20>:    str     xzr, [sp, torvalds#48]
   0x0000000000400c48 <+24>:    add     x0, sp, #0x1b
   0x0000000000400c4c <+28>:    mov     w3, #0x0                 // #0
   0x0000000000400c50 <+32>:    mov     x2, #0x1                 // #1
   0x0000000000400c54 <+36>:    mov     x1, x0
   0x0000000000400c58 <+40>:    ldr     w0, [sp, torvalds#28]
   0x0000000000400c5c <+44>:    bl      0x405e10 <mq_send>
   0x0000000000400c60 <+48>:    str     w0, [sp, torvalds#60]
   0x0000000000400c64 <+52>:    ldr     w0, [sp, torvalds#60]
   0x0000000000400c68 <+56>:    ldp     x29, x30, [sp], torvalds#64
   0x0000000000400c6c <+60>:    ret
End of assembler dump.
(gdb) info b
No breakpoints or watchpoints.
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x0000000000400c30 in send ()
(gdb) x/10x 0x400c30
0x400c30 <send>:    0xd42000a0   0xfd030091      0xe01f00b9      0xe16f0039
0x400c40 <send+16>: 0xff1700f9   0xff1b00f9      0xe06f0091      0x03008052
0x400c50 <send+32>: 0x220080d2   0xe10300aa
(gdb) disassemble 0x400c30
Dump of assembler code for function send:
=> 0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]

Signed-off-by: junhua huang <huang.junhua@zte.com.cn>
Link: https://lore.kernel.org/r/202212021511106844809@zte.com.cn
Signed-off-by: Will Deacon <will@kernel.org>
Stable-dep-of: 13f8f1e ("arm64: probes: Fix uprobes for big-endian kernels")
Signed-off-by: Sasha Levin <sashal@kernel.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Oct 28, 2024
commit d0e806b upstream.

During the migration of Soundwire runtime stream allocation from
the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845
soundcard was forgotten.

At this point any playback attempt or audio daemon startup, for instance
on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer
NULL dereference:

 Unable to handle kernel NULL pointer dereference at virtual
 address 0000000000000020
 Mem abort info:
   ESR = 0x0000000096000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x04: level 0 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000
 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 5 UID: 0 PID: 1198 Comm: aplay
 Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty torvalds#18
 Hardware name: Thundercomm Dragonboard 845c (DT)
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 sp : ffff80008a2035c0
 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000
 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800
 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003
 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec
 x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003
 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8
 Call trace:
  sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
  wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]
  snd_soc_dai_hw_params+0x3c/0xa4
  __soc_pcm_hw_params+0x230/0x660
  dpcm_be_dai_hw_params+0x1d0/0x3f8
  dpcm_fe_dai_hw_params+0x98/0x268
  snd_pcm_hw_params+0x124/0x460
  snd_pcm_common_ioctl+0x998/0x16e8
  snd_pcm_ioctl+0x34/0x58
  __arm64_sys_ioctl+0xac/0xf8
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x34/0xe0
  el0t_64_sync_handler+0x120/0x12c
  el0t_64_sync+0x190/0x194
 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)
 ---[ end trace 0000000000000000 ]---

0000000000006108 <sdw_stream_add_slave>:
    6108:       d503233f        paciasp
    610c:       a9b97bfd        stp     x29, x30, [sp, #-112]!
    6110:       910003fd        mov     x29, sp
    6114:       a90153f3        stp     x19, x20, [sp, torvalds#16]
    6118:       a9025bf5        stp     x21, x22, [sp, torvalds#32]
    611c:       aa0103f6        mov     x22, x1
    6120:       2a0303f5        mov     w21, w3
    6124:       a90363f7        stp     x23, x24, [sp, torvalds#48]
    6128:       aa0003f8        mov     x24, x0
    612c:       aa0203f7        mov     x23, x2
    6130:       a9046bf9        stp     x25, x26, [sp, torvalds#64]
    6134:       aa0403f9        mov     x25, x4        <-- x4 copied to x25
    6138:       a90573fb        stp     x27, x28, [sp, torvalds#80]
    613c:       aa0403fb        mov     x27, x4
    6140:       f9418400        ldr     x0, [x0, torvalds#776]
    6144:       9100e000        add     x0, x0, #0x38
    6148:       94000000        bl      0 <mutex_lock>
    614c:       f8420f22        ldr     x2, [x25, torvalds#32]!  <-- offset 0x44
    ^^^
This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()
where data abort happens.
wsa881x_hw_params() is called with stream = NULL and passes it further
in register x4 (5th argument) to sdw_stream_add_slave() without any checks.
Value from x4 is copied to x25 and finally it aborts on trying to load
a value from address in x25 plus offset 32 (in dec) which corresponds
to master_list member in struct sdw_stream_runtime:

struct sdw_stream_runtime {
        const char  *              name;	/*     0     8 */
        struct sdw_stream_params   params;	/*     8    12 */
        enum sdw_stream_state      state;	/*    20     4 */
        enum sdw_stream_type       type;	/*    24     4 */
        /* XXX 4 bytes hole, try to pack */
 here-> struct list_head           master_list;	/*    32    16 */
        int                        m_rt_count;	/*    48     4 */
        /* size: 56, cachelines: 1, members: 6 */
        /* sum members: 48, holes: 1, sum holes: 4 */
        /* padding: 4 */
        /* last cacheline: 56 bytes */

Fix this by adding required calls to qcom_snd_sdw_startup() and
sdw_release_stream() to startup and shutdown routines which restores
the previous correct behaviour when ->set_stream() method is called to
set a valid stream runtime pointer on playback startup.

Reproduced and then fix was tested on db845c RB3 board.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: stable@vger.kernel.org
Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://patch.msgid.link/20241009213922.999355-1-alexey.klimov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ninelore pushed a commit to ninelore/linux that referenced this pull request Oct 28, 2024
During the migration of Soundwire runtime stream allocation from
the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845
soundcard was forgotten.

At this point any playback attempt or audio daemon startup, for instance
on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer
NULL dereference:

 Unable to handle kernel NULL pointer dereference at virtual
 address 0000000000000020
 Mem abort info:
   ESR = 0x0000000096000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x04: level 0 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000
 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 5 UID: 0 PID: 1198 Comm: aplay
 Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty torvalds#18
 Hardware name: Thundercomm Dragonboard 845c (DT)
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 sp : ffff80008a2035c0
 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000
 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800
 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003
 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec
 x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003
 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8
 Call trace:
  sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
  wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]
  snd_soc_dai_hw_params+0x3c/0xa4
  __soc_pcm_hw_params+0x230/0x660
  dpcm_be_dai_hw_params+0x1d0/0x3f8
  dpcm_fe_dai_hw_params+0x98/0x268
  snd_pcm_hw_params+0x124/0x460
  snd_pcm_common_ioctl+0x998/0x16e8
  snd_pcm_ioctl+0x34/0x58
  __arm64_sys_ioctl+0xac/0xf8
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x34/0xe0
  el0t_64_sync_handler+0x120/0x12c
  el0t_64_sync+0x190/0x194
 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)
 ---[ end trace 0000000000000000 ]---

0000000000006108 <sdw_stream_add_slave>:
    6108:       d503233f        paciasp
    610c:       a9b97bfd        stp     x29, x30, [sp, #-112]!
    6110:       910003fd        mov     x29, sp
    6114:       a90153f3        stp     x19, x20, [sp, torvalds#16]
    6118:       a9025bf5        stp     x21, x22, [sp, torvalds#32]
    611c:       aa0103f6        mov     x22, x1
    6120:       2a0303f5        mov     w21, w3
    6124:       a90363f7        stp     x23, x24, [sp, torvalds#48]
    6128:       aa0003f8        mov     x24, x0
    612c:       aa0203f7        mov     x23, x2
    6130:       a9046bf9        stp     x25, x26, [sp, torvalds#64]
    6134:       aa0403f9        mov     x25, x4        <-- x4 copied to x25
    6138:       a90573fb        stp     x27, x28, [sp, torvalds#80]
    613c:       aa0403fb        mov     x27, x4
    6140:       f9418400        ldr     x0, [x0, torvalds#776]
    6144:       9100e000        add     x0, x0, #0x38
    6148:       94000000        bl      0 <mutex_lock>
    614c:       f8420f22        ldr     x2, [x25, torvalds#32]!  <-- offset 0x44
    ^^^
This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()
where data abort happens.
wsa881x_hw_params() is called with stream = NULL and passes it further
in register x4 (5th argument) to sdw_stream_add_slave() without any checks.
Value from x4 is copied to x25 and finally it aborts on trying to load
a value from address in x25 plus offset 32 (in dec) which corresponds
to master_list member in struct sdw_stream_runtime:

struct sdw_stream_runtime {
        const char  *              name;	/*     0     8 */
        struct sdw_stream_params   params;	/*     8    12 */
        enum sdw_stream_state      state;	/*    20     4 */
        enum sdw_stream_type       type;	/*    24     4 */
        /* XXX 4 bytes hole, try to pack */
 here-> struct list_head           master_list;	/*    32    16 */
        int                        m_rt_count;	/*    48     4 */
        /* size: 56, cachelines: 1, members: 6 */
        /* sum members: 48, holes: 1, sum holes: 4 */
        /* padding: 4 */
        /* last cacheline: 56 bytes */

Fix this by adding required calls to qcom_snd_sdw_startup() and
sdw_release_stream() to startup and shutdown routines which restores
the previous correct behaviour when ->set_stream() method is called to
set a valid stream runtime pointer on playback startup.

Reproduced and then fix was tested on db845c RB3 board.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: stable@vger.kernel.org
Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://patch.msgid.link/20241009213922.999355-1-alexey.klimov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Oct 29, 2024
[ Upstream commit 60f07e2 ]

We use uprobe in aarch64_be, which we found the tracee task would exit
due to SIGILL when we enable the uprobe trace.
We can see the replace inst from uprobe is not correct in aarch big-endian.
As in Armv8-A, instruction fetches are always treated as little-endian,
we should treat the UPROBE_SWBP_INSN as little-endian。

The test case is as following。
bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null &
bash-4.4# cd /sys/kernel/debug/tracing/
bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events
bash-4.4# echo 1 > events/uprobes/enable
bash-4.4#
bash-4.4# ps
  PID TTY          TIME CMD
  140 ?        00:00:01 bash
  237 ?        00:00:00 ps
[1]+  Illegal instruction     ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null

which we debug use gdb as following:

bash-4.4# gdb attach 155
(gdb) disassemble send
Dump of assembler code for function send:
   0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]
   0x0000000000400c44 <+20>:    str     xzr, [sp, torvalds#48]
   0x0000000000400c48 <+24>:    add     x0, sp, #0x1b
   0x0000000000400c4c <+28>:    mov     w3, #0x0                 // #0
   0x0000000000400c50 <+32>:    mov     x2, #0x1                 // #1
   0x0000000000400c54 <+36>:    mov     x1, x0
   0x0000000000400c58 <+40>:    ldr     w0, [sp, torvalds#28]
   0x0000000000400c5c <+44>:    bl      0x405e10 <mq_send>
   0x0000000000400c60 <+48>:    str     w0, [sp, torvalds#60]
   0x0000000000400c64 <+52>:    ldr     w0, [sp, torvalds#60]
   0x0000000000400c68 <+56>:    ldp     x29, x30, [sp], torvalds#64
   0x0000000000400c6c <+60>:    ret
End of assembler dump.
(gdb) info b
No breakpoints or watchpoints.
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x0000000000400c30 in send ()
(gdb) x/10x 0x400c30
0x400c30 <send>:    0xd42000a0   0xfd030091      0xe01f00b9      0xe16f0039
0x400c40 <send+16>: 0xff1700f9   0xff1b00f9      0xe06f0091      0x03008052
0x400c50 <send+32>: 0x220080d2   0xe10300aa
(gdb) disassemble 0x400c30
Dump of assembler code for function send:
=> 0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]

Signed-off-by: junhua huang <huang.junhua@zte.com.cn>
Link: https://lore.kernel.org/r/202212021511106844809@zte.com.cn
Signed-off-by: Will Deacon <will@kernel.org>
Stable-dep-of: 13f8f1e ("arm64: probes: Fix uprobes for big-endian kernels")
Signed-off-by: Sasha Levin <sashal@kernel.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Oct 29, 2024
commit d0e806b upstream.

During the migration of Soundwire runtime stream allocation from
the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845
soundcard was forgotten.

At this point any playback attempt or audio daemon startup, for instance
on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer
NULL dereference:

 Unable to handle kernel NULL pointer dereference at virtual
 address 0000000000000020
 Mem abort info:
   ESR = 0x0000000096000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x04: level 0 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000
 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 5 UID: 0 PID: 1198 Comm: aplay
 Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty torvalds#18
 Hardware name: Thundercomm Dragonboard 845c (DT)
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 sp : ffff80008a2035c0
 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000
 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800
 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003
 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec
 x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003
 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8
 Call trace:
  sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
  wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]
  snd_soc_dai_hw_params+0x3c/0xa4
  __soc_pcm_hw_params+0x230/0x660
  dpcm_be_dai_hw_params+0x1d0/0x3f8
  dpcm_fe_dai_hw_params+0x98/0x268
  snd_pcm_hw_params+0x124/0x460
  snd_pcm_common_ioctl+0x998/0x16e8
  snd_pcm_ioctl+0x34/0x58
  __arm64_sys_ioctl+0xac/0xf8
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x34/0xe0
  el0t_64_sync_handler+0x120/0x12c
  el0t_64_sync+0x190/0x194
 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)
 ---[ end trace 0000000000000000 ]---

0000000000006108 <sdw_stream_add_slave>:
    6108:       d503233f        paciasp
    610c:       a9b97bfd        stp     x29, x30, [sp, #-112]!
    6110:       910003fd        mov     x29, sp
    6114:       a90153f3        stp     x19, x20, [sp, torvalds#16]
    6118:       a9025bf5        stp     x21, x22, [sp, torvalds#32]
    611c:       aa0103f6        mov     x22, x1
    6120:       2a0303f5        mov     w21, w3
    6124:       a90363f7        stp     x23, x24, [sp, torvalds#48]
    6128:       aa0003f8        mov     x24, x0
    612c:       aa0203f7        mov     x23, x2
    6130:       a9046bf9        stp     x25, x26, [sp, torvalds#64]
    6134:       aa0403f9        mov     x25, x4        <-- x4 copied to x25
    6138:       a90573fb        stp     x27, x28, [sp, torvalds#80]
    613c:       aa0403fb        mov     x27, x4
    6140:       f9418400        ldr     x0, [x0, torvalds#776]
    6144:       9100e000        add     x0, x0, #0x38
    6148:       94000000        bl      0 <mutex_lock>
    614c:       f8420f22        ldr     x2, [x25, torvalds#32]!  <-- offset 0x44
    ^^^
This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()
where data abort happens.
wsa881x_hw_params() is called with stream = NULL and passes it further
in register x4 (5th argument) to sdw_stream_add_slave() without any checks.
Value from x4 is copied to x25 and finally it aborts on trying to load
a value from address in x25 plus offset 32 (in dec) which corresponds
to master_list member in struct sdw_stream_runtime:

struct sdw_stream_runtime {
        const char  *              name;	/*     0     8 */
        struct sdw_stream_params   params;	/*     8    12 */
        enum sdw_stream_state      state;	/*    20     4 */
        enum sdw_stream_type       type;	/*    24     4 */
        /* XXX 4 bytes hole, try to pack */
 here-> struct list_head           master_list;	/*    32    16 */
        int                        m_rt_count;	/*    48     4 */
        /* size: 56, cachelines: 1, members: 6 */
        /* sum members: 48, holes: 1, sum holes: 4 */
        /* padding: 4 */
        /* last cacheline: 56 bytes */

Fix this by adding required calls to qcom_snd_sdw_startup() and
sdw_release_stream() to startup and shutdown routines which restores
the previous correct behaviour when ->set_stream() method is called to
set a valid stream runtime pointer on playback startup.

Reproduced and then fix was tested on db845c RB3 board.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: stable@vger.kernel.org
Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://patch.msgid.link/20241009213922.999355-1-alexey.klimov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request Oct 30, 2024
commit d0e806b upstream.

During the migration of Soundwire runtime stream allocation from
the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845
soundcard was forgotten.

At this point any playback attempt or audio daemon startup, for instance
on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer
NULL dereference:

 Unable to handle kernel NULL pointer dereference at virtual
 address 0000000000000020
 Mem abort info:
   ESR = 0x0000000096000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x04: level 0 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000
 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 5 UID: 0 PID: 1198 Comm: aplay
 Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty torvalds#18
 Hardware name: Thundercomm Dragonboard 845c (DT)
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 sp : ffff80008a2035c0
 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000
 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800
 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003
 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec
 x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003
 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8
 Call trace:
  sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
  wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]
  snd_soc_dai_hw_params+0x3c/0xa4
  __soc_pcm_hw_params+0x230/0x660
  dpcm_be_dai_hw_params+0x1d0/0x3f8
  dpcm_fe_dai_hw_params+0x98/0x268
  snd_pcm_hw_params+0x124/0x460
  snd_pcm_common_ioctl+0x998/0x16e8
  snd_pcm_ioctl+0x34/0x58
  __arm64_sys_ioctl+0xac/0xf8
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x34/0xe0
  el0t_64_sync_handler+0x120/0x12c
  el0t_64_sync+0x190/0x194
 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)
 ---[ end trace 0000000000000000 ]---

0000000000006108 <sdw_stream_add_slave>:
    6108:       d503233f        paciasp
    610c:       a9b97bfd        stp     x29, x30, [sp, #-112]!
    6110:       910003fd        mov     x29, sp
    6114:       a90153f3        stp     x19, x20, [sp, torvalds#16]
    6118:       a9025bf5        stp     x21, x22, [sp, torvalds#32]
    611c:       aa0103f6        mov     x22, x1
    6120:       2a0303f5        mov     w21, w3
    6124:       a90363f7        stp     x23, x24, [sp, torvalds#48]
    6128:       aa0003f8        mov     x24, x0
    612c:       aa0203f7        mov     x23, x2
    6130:       a9046bf9        stp     x25, x26, [sp, torvalds#64]
    6134:       aa0403f9        mov     x25, x4        <-- x4 copied to x25
    6138:       a90573fb        stp     x27, x28, [sp, torvalds#80]
    613c:       aa0403fb        mov     x27, x4
    6140:       f9418400        ldr     x0, [x0, torvalds#776]
    6144:       9100e000        add     x0, x0, #0x38
    6148:       94000000        bl      0 <mutex_lock>
    614c:       f8420f22        ldr     x2, [x25, torvalds#32]!  <-- offset 0x44
    ^^^
This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()
where data abort happens.
wsa881x_hw_params() is called with stream = NULL and passes it further
in register x4 (5th argument) to sdw_stream_add_slave() without any checks.
Value from x4 is copied to x25 and finally it aborts on trying to load
a value from address in x25 plus offset 32 (in dec) which corresponds
to master_list member in struct sdw_stream_runtime:

struct sdw_stream_runtime {
        const char  *              name;	/*     0     8 */
        struct sdw_stream_params   params;	/*     8    12 */
        enum sdw_stream_state      state;	/*    20     4 */
        enum sdw_stream_type       type;	/*    24     4 */
        /* XXX 4 bytes hole, try to pack */
 here-> struct list_head           master_list;	/*    32    16 */
        int                        m_rt_count;	/*    48     4 */
        /* size: 56, cachelines: 1, members: 6 */
        /* sum members: 48, holes: 1, sum holes: 4 */
        /* padding: 4 */
        /* last cacheline: 56 bytes */

Fix this by adding required calls to qcom_snd_sdw_startup() and
sdw_release_stream() to startup and shutdown routines which restores
the previous correct behaviour when ->set_stream() method is called to
set a valid stream runtime pointer on playback startup.

Reproduced and then fix was tested on db845c RB3 board.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: stable@vger.kernel.org
Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://patch.msgid.link/20241009213922.999355-1-alexey.klimov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
heftig pushed a commit to archlinux/linux that referenced this pull request Nov 1, 2024
commit d0e806b upstream.

During the migration of Soundwire runtime stream allocation from
the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845
soundcard was forgotten.

At this point any playback attempt or audio daemon startup, for instance
on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer
NULL dereference:

 Unable to handle kernel NULL pointer dereference at virtual
 address 0000000000000020
 Mem abort info:
   ESR = 0x0000000096000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x04: level 0 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000
 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 5 UID: 0 PID: 1198 Comm: aplay
 Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty torvalds#18
 Hardware name: Thundercomm Dragonboard 845c (DT)
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 sp : ffff80008a2035c0
 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000
 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800
 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003
 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec
 x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003
 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8
 Call trace:
  sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
  wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]
  snd_soc_dai_hw_params+0x3c/0xa4
  __soc_pcm_hw_params+0x230/0x660
  dpcm_be_dai_hw_params+0x1d0/0x3f8
  dpcm_fe_dai_hw_params+0x98/0x268
  snd_pcm_hw_params+0x124/0x460
  snd_pcm_common_ioctl+0x998/0x16e8
  snd_pcm_ioctl+0x34/0x58
  __arm64_sys_ioctl+0xac/0xf8
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x34/0xe0
  el0t_64_sync_handler+0x120/0x12c
  el0t_64_sync+0x190/0x194
 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)
 ---[ end trace 0000000000000000 ]---

0000000000006108 <sdw_stream_add_slave>:
    6108:       d503233f        paciasp
    610c:       a9b97bfd        stp     x29, x30, [sp, #-112]!
    6110:       910003fd        mov     x29, sp
    6114:       a90153f3        stp     x19, x20, [sp, torvalds#16]
    6118:       a9025bf5        stp     x21, x22, [sp, torvalds#32]
    611c:       aa0103f6        mov     x22, x1
    6120:       2a0303f5        mov     w21, w3
    6124:       a90363f7        stp     x23, x24, [sp, torvalds#48]
    6128:       aa0003f8        mov     x24, x0
    612c:       aa0203f7        mov     x23, x2
    6130:       a9046bf9        stp     x25, x26, [sp, torvalds#64]
    6134:       aa0403f9        mov     x25, x4        <-- x4 copied to x25
    6138:       a90573fb        stp     x27, x28, [sp, torvalds#80]
    613c:       aa0403fb        mov     x27, x4
    6140:       f9418400        ldr     x0, [x0, torvalds#776]
    6144:       9100e000        add     x0, x0, #0x38
    6148:       94000000        bl      0 <mutex_lock>
    614c:       f8420f22        ldr     x2, [x25, torvalds#32]!  <-- offset 0x44
    ^^^
This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()
where data abort happens.
wsa881x_hw_params() is called with stream = NULL and passes it further
in register x4 (5th argument) to sdw_stream_add_slave() without any checks.
Value from x4 is copied to x25 and finally it aborts on trying to load
a value from address in x25 plus offset 32 (in dec) which corresponds
to master_list member in struct sdw_stream_runtime:

struct sdw_stream_runtime {
        const char  *              name;	/*     0     8 */
        struct sdw_stream_params   params;	/*     8    12 */
        enum sdw_stream_state      state;	/*    20     4 */
        enum sdw_stream_type       type;	/*    24     4 */
        /* XXX 4 bytes hole, try to pack */
 here-> struct list_head           master_list;	/*    32    16 */
        int                        m_rt_count;	/*    48     4 */
        /* size: 56, cachelines: 1, members: 6 */
        /* sum members: 48, holes: 1, sum holes: 4 */
        /* padding: 4 */
        /* last cacheline: 56 bytes */

Fix this by adding required calls to qcom_snd_sdw_startup() and
sdw_release_stream() to startup and shutdown routines which restores
the previous correct behaviour when ->set_stream() method is called to
set a valid stream runtime pointer on playback startup.

Reproduced and then fix was tested on db845c RB3 board.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: stable@vger.kernel.org
Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://patch.msgid.link/20241009213922.999355-1-alexey.klimov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Nov 1, 2024
[ Upstream commit 60f07e2 ]

We use uprobe in aarch64_be, which we found the tracee task would exit
due to SIGILL when we enable the uprobe trace.
We can see the replace inst from uprobe is not correct in aarch big-endian.
As in Armv8-A, instruction fetches are always treated as little-endian,
we should treat the UPROBE_SWBP_INSN as little-endian。

The test case is as following。
bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null &
bash-4.4# cd /sys/kernel/debug/tracing/
bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events
bash-4.4# echo 1 > events/uprobes/enable
bash-4.4#
bash-4.4# ps
  PID TTY          TIME CMD
  140 ?        00:00:01 bash
  237 ?        00:00:00 ps
[1]+  Illegal instruction     ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null

which we debug use gdb as following:

bash-4.4# gdb attach 155
(gdb) disassemble send
Dump of assembler code for function send:
   0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]
   0x0000000000400c44 <+20>:    str     xzr, [sp, torvalds#48]
   0x0000000000400c48 <+24>:    add     x0, sp, #0x1b
   0x0000000000400c4c <+28>:    mov     w3, #0x0                 // #0
   0x0000000000400c50 <+32>:    mov     x2, #0x1                 // #1
   0x0000000000400c54 <+36>:    mov     x1, x0
   0x0000000000400c58 <+40>:    ldr     w0, [sp, torvalds#28]
   0x0000000000400c5c <+44>:    bl      0x405e10 <mq_send>
   0x0000000000400c60 <+48>:    str     w0, [sp, torvalds#60]
   0x0000000000400c64 <+52>:    ldr     w0, [sp, torvalds#60]
   0x0000000000400c68 <+56>:    ldp     x29, x30, [sp], torvalds#64
   0x0000000000400c6c <+60>:    ret
End of assembler dump.
(gdb) info b
No breakpoints or watchpoints.
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x0000000000400c30 in send ()
(gdb) x/10x 0x400c30
0x400c30 <send>:    0xd42000a0   0xfd030091      0xe01f00b9      0xe16f0039
0x400c40 <send+16>: 0xff1700f9   0xff1b00f9      0xe06f0091      0x03008052
0x400c50 <send+32>: 0x220080d2   0xe10300aa
(gdb) disassemble 0x400c30
Dump of assembler code for function send:
=> 0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]

Signed-off-by: junhua huang <huang.junhua@zte.com.cn>
Link: https://lore.kernel.org/r/202212021511106844809@zte.com.cn
Signed-off-by: Will Deacon <will@kernel.org>
Stable-dep-of: 13f8f1e ("arm64: probes: Fix uprobes for big-endian kernels")
Signed-off-by: Sasha Levin <sashal@kernel.org>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Nov 1, 2024
[ Upstream commit 60f07e2 ]

We use uprobe in aarch64_be, which we found the tracee task would exit
due to SIGILL when we enable the uprobe trace.
We can see the replace inst from uprobe is not correct in aarch big-endian.
As in Armv8-A, instruction fetches are always treated as little-endian,
we should treat the UPROBE_SWBP_INSN as little-endian。

The test case is as following。
bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null &
bash-4.4# cd /sys/kernel/debug/tracing/
bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events
bash-4.4# echo 1 > events/uprobes/enable
bash-4.4#
bash-4.4# ps
  PID TTY          TIME CMD
  140 ?        00:00:01 bash
  237 ?        00:00:00 ps
[1]+  Illegal instruction     ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null

which we debug use gdb as following:

bash-4.4# gdb attach 155
(gdb) disassemble send
Dump of assembler code for function send:
   0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]
   0x0000000000400c44 <+20>:    str     xzr, [sp, torvalds#48]
   0x0000000000400c48 <+24>:    add     x0, sp, #0x1b
   0x0000000000400c4c <+28>:    mov     w3, #0x0                 // #0
   0x0000000000400c50 <+32>:    mov     x2, #0x1                 // #1
   0x0000000000400c54 <+36>:    mov     x1, x0
   0x0000000000400c58 <+40>:    ldr     w0, [sp, torvalds#28]
   0x0000000000400c5c <+44>:    bl      0x405e10 <mq_send>
   0x0000000000400c60 <+48>:    str     w0, [sp, torvalds#60]
   0x0000000000400c64 <+52>:    ldr     w0, [sp, torvalds#60]
   0x0000000000400c68 <+56>:    ldp     x29, x30, [sp], torvalds#64
   0x0000000000400c6c <+60>:    ret
End of assembler dump.
(gdb) info b
No breakpoints or watchpoints.
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x0000000000400c30 in send ()
(gdb) x/10x 0x400c30
0x400c30 <send>:    0xd42000a0   0xfd030091      0xe01f00b9      0xe16f0039
0x400c40 <send+16>: 0xff1700f9   0xff1b00f9      0xe06f0091      0x03008052
0x400c50 <send+32>: 0x220080d2   0xe10300aa
(gdb) disassemble 0x400c30
Dump of assembler code for function send:
=> 0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]

Signed-off-by: junhua huang <huang.junhua@zte.com.cn>
Link: https://lore.kernel.org/r/202212021511106844809@zte.com.cn
Signed-off-by: Will Deacon <will@kernel.org>
Stable-dep-of: 13f8f1e ("arm64: probes: Fix uprobes for big-endian kernels")
Signed-off-by: Sasha Levin <sashal@kernel.org>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Nov 8, 2024
[ Upstream commit 60f07e2 ]

We use uprobe in aarch64_be, which we found the tracee task would exit
due to SIGILL when we enable the uprobe trace.
We can see the replace inst from uprobe is not correct in aarch big-endian.
As in Armv8-A, instruction fetches are always treated as little-endian,
we should treat the UPROBE_SWBP_INSN as little-endian。

The test case is as following。
bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null &
bash-4.4# cd /sys/kernel/debug/tracing/
bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events
bash-4.4# echo 1 > events/uprobes/enable
bash-4.4#
bash-4.4# ps
  PID TTY          TIME CMD
  140 ?        00:00:01 bash
  237 ?        00:00:00 ps
[1]+  Illegal instruction     ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null

which we debug use gdb as following:

bash-4.4# gdb attach 155
(gdb) disassemble send
Dump of assembler code for function send:
   0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]
   0x0000000000400c44 <+20>:    str     xzr, [sp, torvalds#48]
   0x0000000000400c48 <+24>:    add     x0, sp, #0x1b
   0x0000000000400c4c <+28>:    mov     w3, #0x0                 // #0
   0x0000000000400c50 <+32>:    mov     x2, #0x1                 // #1
   0x0000000000400c54 <+36>:    mov     x1, x0
   0x0000000000400c58 <+40>:    ldr     w0, [sp, torvalds#28]
   0x0000000000400c5c <+44>:    bl      0x405e10 <mq_send>
   0x0000000000400c60 <+48>:    str     w0, [sp, torvalds#60]
   0x0000000000400c64 <+52>:    ldr     w0, [sp, torvalds#60]
   0x0000000000400c68 <+56>:    ldp     x29, x30, [sp], torvalds#64
   0x0000000000400c6c <+60>:    ret
End of assembler dump.
(gdb) info b
No breakpoints or watchpoints.
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x0000000000400c30 in send ()
(gdb) x/10x 0x400c30
0x400c30 <send>:    0xd42000a0   0xfd030091      0xe01f00b9      0xe16f0039
0x400c40 <send+16>: 0xff1700f9   0xff1b00f9      0xe06f0091      0x03008052
0x400c50 <send+32>: 0x220080d2   0xe10300aa
(gdb) disassemble 0x400c30
Dump of assembler code for function send:
=> 0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]

Signed-off-by: junhua huang <huang.junhua@zte.com.cn>
Link: https://lore.kernel.org/r/202212021511106844809@zte.com.cn
Signed-off-by: Will Deacon <will@kernel.org>
Stable-dep-of: 13f8f1e ("arm64: probes: Fix uprobes for big-endian kernels")
Signed-off-by: Sasha Levin <sashal@kernel.org>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Nov 8, 2024
[ Upstream commit 60f07e2 ]

We use uprobe in aarch64_be, which we found the tracee task would exit
due to SIGILL when we enable the uprobe trace.
We can see the replace inst from uprobe is not correct in aarch big-endian.
As in Armv8-A, instruction fetches are always treated as little-endian,
we should treat the UPROBE_SWBP_INSN as little-endian。

The test case is as following。
bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null &
bash-4.4# cd /sys/kernel/debug/tracing/
bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events
bash-4.4# echo 1 > events/uprobes/enable
bash-4.4#
bash-4.4# ps
  PID TTY          TIME CMD
  140 ?        00:00:01 bash
  237 ?        00:00:00 ps
[1]+  Illegal instruction     ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null

which we debug use gdb as following:

bash-4.4# gdb attach 155
(gdb) disassemble send
Dump of assembler code for function send:
   0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]
   0x0000000000400c44 <+20>:    str     xzr, [sp, torvalds#48]
   0x0000000000400c48 <+24>:    add     x0, sp, #0x1b
   0x0000000000400c4c <+28>:    mov     w3, #0x0                 // #0
   0x0000000000400c50 <+32>:    mov     x2, #0x1                 // #1
   0x0000000000400c54 <+36>:    mov     x1, x0
   0x0000000000400c58 <+40>:    ldr     w0, [sp, torvalds#28]
   0x0000000000400c5c <+44>:    bl      0x405e10 <mq_send>
   0x0000000000400c60 <+48>:    str     w0, [sp, torvalds#60]
   0x0000000000400c64 <+52>:    ldr     w0, [sp, torvalds#60]
   0x0000000000400c68 <+56>:    ldp     x29, x30, [sp], torvalds#64
   0x0000000000400c6c <+60>:    ret
End of assembler dump.
(gdb) info b
No breakpoints or watchpoints.
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x0000000000400c30 in send ()
(gdb) x/10x 0x400c30
0x400c30 <send>:    0xd42000a0   0xfd030091      0xe01f00b9      0xe16f0039
0x400c40 <send+16>: 0xff1700f9   0xff1b00f9      0xe06f0091      0x03008052
0x400c50 <send+32>: 0x220080d2   0xe10300aa
(gdb) disassemble 0x400c30
Dump of assembler code for function send:
=> 0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]

Signed-off-by: junhua huang <huang.junhua@zte.com.cn>
Link: https://lore.kernel.org/r/202212021511106844809@zte.com.cn
Signed-off-by: Will Deacon <will@kernel.org>
Stable-dep-of: 13f8f1e ("arm64: probes: Fix uprobes for big-endian kernels")
Signed-off-by: Sasha Levin <sashal@kernel.org>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Nov 8, 2024
[ Upstream commit 60f07e2 ]

We use uprobe in aarch64_be, which we found the tracee task would exit
due to SIGILL when we enable the uprobe trace.
We can see the replace inst from uprobe is not correct in aarch big-endian.
As in Armv8-A, instruction fetches are always treated as little-endian,
we should treat the UPROBE_SWBP_INSN as little-endian。

The test case is as following。
bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null &
bash-4.4# cd /sys/kernel/debug/tracing/
bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events
bash-4.4# echo 1 > events/uprobes/enable
bash-4.4#
bash-4.4# ps
  PID TTY          TIME CMD
  140 ?        00:00:01 bash
  237 ?        00:00:00 ps
[1]+  Illegal instruction     ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null

which we debug use gdb as following:

bash-4.4# gdb attach 155
(gdb) disassemble send
Dump of assembler code for function send:
   0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]
   0x0000000000400c44 <+20>:    str     xzr, [sp, torvalds#48]
   0x0000000000400c48 <+24>:    add     x0, sp, #0x1b
   0x0000000000400c4c <+28>:    mov     w3, #0x0                 // #0
   0x0000000000400c50 <+32>:    mov     x2, #0x1                 // #1
   0x0000000000400c54 <+36>:    mov     x1, x0
   0x0000000000400c58 <+40>:    ldr     w0, [sp, torvalds#28]
   0x0000000000400c5c <+44>:    bl      0x405e10 <mq_send>
   0x0000000000400c60 <+48>:    str     w0, [sp, torvalds#60]
   0x0000000000400c64 <+52>:    ldr     w0, [sp, torvalds#60]
   0x0000000000400c68 <+56>:    ldp     x29, x30, [sp], torvalds#64
   0x0000000000400c6c <+60>:    ret
End of assembler dump.
(gdb) info b
No breakpoints or watchpoints.
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x0000000000400c30 in send ()
(gdb) x/10x 0x400c30
0x400c30 <send>:    0xd42000a0   0xfd030091      0xe01f00b9      0xe16f0039
0x400c40 <send+16>: 0xff1700f9   0xff1b00f9      0xe06f0091      0x03008052
0x400c50 <send+32>: 0x220080d2   0xe10300aa
(gdb) disassemble 0x400c30
Dump of assembler code for function send:
=> 0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
   0x0000000000400c34 <+4>:     mov     x29, sp
   0x0000000000400c38 <+8>:     str     w0, [sp, torvalds#28]
   0x0000000000400c3c <+12>:    strb    w1, [sp, torvalds#27]
   0x0000000000400c40 <+16>:    str     xzr, [sp, torvalds#40]

Signed-off-by: junhua huang <huang.junhua@zte.com.cn>
Link: https://lore.kernel.org/r/202212021511106844809@zte.com.cn
Signed-off-by: Will Deacon <will@kernel.org>
Stable-dep-of: 13f8f1e ("arm64: probes: Fix uprobes for big-endian kernels")
Signed-off-by: Sasha Levin <sashal@kernel.org>
alexelder pushed a commit to alexelder/linux that referenced this pull request Nov 26, 2024
During the migration of Soundwire runtime stream allocation from
the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845
soundcard was forgotten.

At this point any playback attempt or audio daemon startup, for instance
on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer
NULL dereference:

 Unable to handle kernel NULL pointer dereference at virtual
 address 0000000000000020
 Mem abort info:
   ESR = 0x0000000096000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x04: level 0 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000
 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 5 UID: 0 PID: 1198 Comm: aplay
 Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty torvalds#18
 Hardware name: Thundercomm Dragonboard 845c (DT)
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
 sp : ffff80008a2035c0
 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000
 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800
 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003
 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec
 x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003
 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8
 Call trace:
  sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
  wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]
  snd_soc_dai_hw_params+0x3c/0xa4
  __soc_pcm_hw_params+0x230/0x660
  dpcm_be_dai_hw_params+0x1d0/0x3f8
  dpcm_fe_dai_hw_params+0x98/0x268
  snd_pcm_hw_params+0x124/0x460
  snd_pcm_common_ioctl+0x998/0x16e8
  snd_pcm_ioctl+0x34/0x58
  __arm64_sys_ioctl+0xac/0xf8
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x34/0xe0
  el0t_64_sync_handler+0x120/0x12c
  el0t_64_sync+0x190/0x194
 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)
 ---[ end trace 0000000000000000 ]---

0000000000006108 <sdw_stream_add_slave>:
    6108:       d503233f        paciasp
    610c:       a9b97bfd        stp     x29, x30, [sp, #-112]!
    6110:       910003fd        mov     x29, sp
    6114:       a90153f3        stp     x19, x20, [sp, torvalds#16]
    6118:       a9025bf5        stp     x21, x22, [sp, torvalds#32]
    611c:       aa0103f6        mov     x22, x1
    6120:       2a0303f5        mov     w21, w3
    6124:       a90363f7        stp     x23, x24, [sp, torvalds#48]
    6128:       aa0003f8        mov     x24, x0
    612c:       aa0203f7        mov     x23, x2
    6130:       a9046bf9        stp     x25, x26, [sp, torvalds#64]
    6134:       aa0403f9        mov     x25, x4        <-- x4 copied to x25
    6138:       a90573fb        stp     x27, x28, [sp, torvalds#80]
    613c:       aa0403fb        mov     x27, x4
    6140:       f9418400        ldr     x0, [x0, torvalds#776]
    6144:       9100e000        add     x0, x0, #0x38
    6148:       94000000        bl      0 <mutex_lock>
    614c:       f8420f22        ldr     x2, [x25, torvalds#32]!  <-- offset 0x44
    ^^^
This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()
where data abort happens.
wsa881x_hw_params() is called with stream = NULL and passes it further
in register x4 (5th argument) to sdw_stream_add_slave() without any checks.
Value from x4 is copied to x25 and finally it aborts on trying to load
a value from address in x25 plus offset 32 (in dec) which corresponds
to master_list member in struct sdw_stream_runtime:

struct sdw_stream_runtime {
        const char  *              name;	/*     0     8 */
        struct sdw_stream_params   params;	/*     8    12 */
        enum sdw_stream_state      state;	/*    20     4 */
        enum sdw_stream_type       type;	/*    24     4 */
        /* XXX 4 bytes hole, try to pack */
 here-> struct list_head           master_list;	/*    32    16 */
        int                        m_rt_count;	/*    48     4 */
        /* size: 56, cachelines: 1, members: 6 */
        /* sum members: 48, holes: 1, sum holes: 4 */
        /* padding: 4 */
        /* last cacheline: 56 bytes */

Fix this by adding required calls to qcom_snd_sdw_startup() and
sdw_release_stream() to startup and shutdown routines which restores
the previous correct behaviour when ->set_stream() method is called to
set a valid stream runtime pointer on playback startup.

Reproduced and then fix was tested on db845c RB3 board.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: stable@vger.kernel.org
Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://patch.msgid.link/20241009213922.999355-1-alexey.klimov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit d0e806b)

BUG=b:326869955
TEST=Test Audio use cases.

Signed-off-by: Linux Patches Robot <linux-patches-robot@chromeos-missing-patches.google.com.iam.gserviceaccount.com>
Change-Id: I4cb196f08486e9f36efe4d7e2288155b41779c41
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/6042850
Commit-Queue: Curtis Malainey <cujomalainey@chromium.org>
Reviewed-by: Terry Cheong <htcheong@chromium.org>
Reviewed-by: Curtis Malainey <cujomalainey@chromium.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Dec 5, 2024
Currently, the maximum supported physical address space can be
configured as either 48 bits or 52 bits. The only remaining difference
between these in practice is that the former omits the masking and
shifting required to construct TTBR and PTE values, which carry bits torvalds#48
and higher disjoint from the rest of the physical address.

The overhead of performing these additional calculations is negligible,
and so there is little reason to retain support for two different
configurations, and we can simply support whatever the hardware
supports.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Dec 12, 2024
Currently, the maximum supported physical address space can be
configured as either 48 bits or 52 bits. The only remaining difference
between these in practice is that the former omits the masking and
shifting required to construct TTBR and PTE values, which carry bits torvalds#48
and higher disjoint from the rest of the physical address.

The overhead of performing these additional calculations is negligible,
and so there is little reason to retain support for two different
configurations, and we can simply support whatever the hardware
supports.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
torvalds pushed a commit that referenced this pull request Dec 14, 2024
blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To
walk up, it uses blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:

  ==================================================================
  BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270
  Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117

  CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022
  Workqueue: cgwb_release cgwb_release_workfn
  Call Trace:
   <TASK>
   dump_stack_lvl+0x27/0x80
   print_report+0x151/0x710
   kasan_report+0xc0/0x100
   blkcg_unpin_online+0x15a/0x270
   cgwb_release_workfn+0x194/0x480
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30
   </TASK>
  ...
  Freed by task 1944:
   kasan_save_track+0x2b/0x70
   kasan_save_free_info+0x3c/0x50
   __kasan_slab_free+0x33/0x50
   kfree+0x10c/0x330
   css_free_rwork_fn+0xe6/0xb30
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30

Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online().

Fix it by reading the parent pointer before destroying the blkcg's blkg's.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Abagail ren <renzezhongucas@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Fixes: 4308a43 ("blkcg: don't offline parent blkcg first")
Cc: stable@vger.kernel.org # v5.7+
Signed-off-by: Jens Axboe <axboe@kernel.dk>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Dec 17, 2024
commit 86e6ca5 upstream.

blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To
walk up, it uses blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:

  ==================================================================
  BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270
  Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117

  CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty torvalds#48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022
  Workqueue: cgwb_release cgwb_release_workfn
  Call Trace:
   <TASK>
   dump_stack_lvl+0x27/0x80
   print_report+0x151/0x710
   kasan_report+0xc0/0x100
   blkcg_unpin_online+0x15a/0x270
   cgwb_release_workfn+0x194/0x480
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30
   </TASK>
  ...
  Freed by task 1944:
   kasan_save_track+0x2b/0x70
   kasan_save_free_info+0x3c/0x50
   __kasan_slab_free+0x33/0x50
   kfree+0x10c/0x330
   css_free_rwork_fn+0xe6/0xb30
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30

Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online().

Fix it by reading the parent pointer before destroying the blkcg's blkg's.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Abagail ren <renzezhongucas@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Fixes: 4308a43 ("blkcg: don't offline parent blkcg first")
Cc: stable@vger.kernel.org # v5.7+
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Dec 17, 2024
commit 86e6ca5 upstream.

blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To
walk up, it uses blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:

  ==================================================================
  BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270
  Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117

  CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty torvalds#48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022
  Workqueue: cgwb_release cgwb_release_workfn
  Call Trace:
   <TASK>
   dump_stack_lvl+0x27/0x80
   print_report+0x151/0x710
   kasan_report+0xc0/0x100
   blkcg_unpin_online+0x15a/0x270
   cgwb_release_workfn+0x194/0x480
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30
   </TASK>
  ...
  Freed by task 1944:
   kasan_save_track+0x2b/0x70
   kasan_save_free_info+0x3c/0x50
   __kasan_slab_free+0x33/0x50
   kfree+0x10c/0x330
   css_free_rwork_fn+0xe6/0xb30
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30

Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online().

Fix it by reading the parent pointer before destroying the blkcg's blkg's.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Abagail ren <renzezhongucas@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Fixes: 4308a43 ("blkcg: don't offline parent blkcg first")
Cc: stable@vger.kernel.org # v5.7+
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Dec 17, 2024
commit 86e6ca5 upstream.

blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To
walk up, it uses blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:

  ==================================================================
  BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270
  Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117

  CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty torvalds#48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022
  Workqueue: cgwb_release cgwb_release_workfn
  Call Trace:
   <TASK>
   dump_stack_lvl+0x27/0x80
   print_report+0x151/0x710
   kasan_report+0xc0/0x100
   blkcg_unpin_online+0x15a/0x270
   cgwb_release_workfn+0x194/0x480
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30
   </TASK>
  ...
  Freed by task 1944:
   kasan_save_track+0x2b/0x70
   kasan_save_free_info+0x3c/0x50
   __kasan_slab_free+0x33/0x50
   kfree+0x10c/0x330
   css_free_rwork_fn+0xe6/0xb30
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30

Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online().

Fix it by reading the parent pointer before destroying the blkcg's blkg's.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Abagail ren <renzezhongucas@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Fixes: 4308a43 ("blkcg: don't offline parent blkcg first")
Cc: stable@vger.kernel.org # v5.7+
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ptr1337 pushed a commit to CachyOS/linux that referenced this pull request Dec 19, 2024
commit 86e6ca5 upstream.

blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To
walk up, it uses blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:

  ==================================================================
  BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270
  Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117

  CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty torvalds#48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022
  Workqueue: cgwb_release cgwb_release_workfn
  Call Trace:
   <TASK>
   dump_stack_lvl+0x27/0x80
   print_report+0x151/0x710
   kasan_report+0xc0/0x100
   blkcg_unpin_online+0x15a/0x270
   cgwb_release_workfn+0x194/0x480
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30
   </TASK>
  ...
  Freed by task 1944:
   kasan_save_track+0x2b/0x70
   kasan_save_free_info+0x3c/0x50
   __kasan_slab_free+0x33/0x50
   kfree+0x10c/0x330
   css_free_rwork_fn+0xe6/0xb30
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30

Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online().

Fix it by reading the parent pointer before destroying the blkcg's blkg's.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Abagail ren <renzezhongucas@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Fixes: 4308a43 ("blkcg: don't offline parent blkcg first")
Cc: stable@vger.kernel.org # v5.7+
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Dec 20, 2024
commit 86e6ca5 upstream.

blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To
walk up, it uses blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:

  ==================================================================
  BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270
  Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117

  CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty torvalds#48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022
  Workqueue: cgwb_release cgwb_release_workfn
  Call Trace:
   <TASK>
   dump_stack_lvl+0x27/0x80
   print_report+0x151/0x710
   kasan_report+0xc0/0x100
   blkcg_unpin_online+0x15a/0x270
   cgwb_release_workfn+0x194/0x480
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30
   </TASK>
  ...
  Freed by task 1944:
   kasan_save_track+0x2b/0x70
   kasan_save_free_info+0x3c/0x50
   __kasan_slab_free+0x33/0x50
   kfree+0x10c/0x330
   css_free_rwork_fn+0xe6/0xb30
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30

Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online().

Fix it by reading the parent pointer before destroying the blkcg's blkg's.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Abagail ren <renzezhongucas@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Fixes: 4308a43 ("blkcg: don't offline parent blkcg first")
Cc: stable@vger.kernel.org # v5.7+
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Dec 20, 2024
Currently, the maximum supported physical address space can be
configured as either 48 bits or 52 bits. The only remaining difference
between these in practice is that the former omits the masking and
shifting required to construct TTBR and PTE values, which carry bits torvalds#48
and higher disjoint from the rest of the physical address.

The overhead of performing these additional calculations is negligible,
and so there is little reason to retain support for two different
configurations, and we can simply support whatever the hardware
supports.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20241212081841.2168124-14-ardb+git@google.com
Signed-off-by: Will Deacon <will@kernel.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Dec 20, 2024
commit 86e6ca5 upstream.

blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To
walk up, it uses blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:

  ==================================================================
  BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270
  Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117

  CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty torvalds#48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022
  Workqueue: cgwb_release cgwb_release_workfn
  Call Trace:
   <TASK>
   dump_stack_lvl+0x27/0x80
   print_report+0x151/0x710
   kasan_report+0xc0/0x100
   blkcg_unpin_online+0x15a/0x270
   cgwb_release_workfn+0x194/0x480
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30
   </TASK>
  ...
  Freed by task 1944:
   kasan_save_track+0x2b/0x70
   kasan_save_free_info+0x3c/0x50
   __kasan_slab_free+0x33/0x50
   kfree+0x10c/0x330
   css_free_rwork_fn+0xe6/0xb30
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30

Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online().

Fix it by reading the parent pointer before destroying the blkcg's blkg's.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Abagail ren <renzezhongucas@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Fixes: 4308a43 ("blkcg: don't offline parent blkcg first")
Cc: stable@vger.kernel.org # v5.7+
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants