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.

Sign up for GitHub

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

Jump to bottom

update to gnu3 #62

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

update to gnu3 #62

wants to merge 1 commit into from
+187 −340

Conversation

ghost
Copy link

@ghost ghost commented Dec 18, 2013

No description provided.

@badbadc0ffee
Copy link

bad idea.

@marcoms
Copy link

marcoms commented Dec 20, 2013

http://lwn.net/Articles/200422/

DestroyFX pushed a commit to DestroyFX/reiser4 that referenced this pull request Dec 25, 2013
@suryasaimadhu
x86: Improve the printout of the SMP bootup CPU table
646e29a 
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 <[email protected]>
Cc: Libin <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
DestroyFX pushed a commit to DestroyFX/reiser4 that referenced this pull request Dec 25, 2013
@bp3tk0v
x86/boot: Further compress CPUs bootup message
a17bce4 
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 <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
DestroyFX pushed a commit to DestroyFX/reiser4 that referenced this pull request Dec 25, 2013
@krzk @broonie
spi/s3c64xx: Fix doubled clock disable on suspend
9d7fd21 
Fix doubled clock disable and unprepare during PM suspend which triggered
the warnings:

WARNING: at drivers/clk/clk.c:800 clk_disable+0x18/0x24()
Modules linked in:
CPU: 0 PID: 1745 Comm: sh Not tainted 3.10.14-01211-ge2549bb-dirty torvalds#62
[<c0015980>] (unwind_backtrace+0x0/0x138) from [<c0012a44>] (show_stack+0x10/0x14)
[<c0012a44>] (show_stack+0x10/0x14) from [<c0022818>] (warn_slowpath_common+0x4c/0x68)
[<c0022818>] (warn_slowpath_common+0x4c/0x68) from [<c0022850>] (warn_slowpath_null+0x1c/0x24)
[<c0022850>] (warn_slowpath_null+0x1c/0x24) from [<c036e274>] (clk_disable+0x18/0x24)
[<c036e274>] (clk_disable+0x18/0x24) from [<c02d5f78>] (s3c64xx_spi_suspend+0x28/0x54)
[<c02d5f78>] (s3c64xx_spi_suspend+0x28/0x54) from [<c02b3a54>] (platform_pm_suspend+0x2c/0x5c)
[<c02b3a54>] (platform_pm_suspend+0x2c/0x5c) from [<c02b8a30>] (dpm_run_callback+0x44/0x7c)
[<c02b8a30>] (dpm_run_callback+0x44/0x7c) from [<c02b8b70>] (__device_suspend+0x108/0x300)
[<c02b8b70>] (__device_suspend+0x108/0x300) from [<c02ba4e0>] (dpm_suspend+0x54/0x208)
[<c02ba4e0>] (dpm_suspend+0x54/0x208) from [<c0066bcc>] (suspend_devices_and_enter+0x98/0x458)
[<c0066bcc>] (suspend_devices_and_enter+0x98/0x458) from [<c0067150>] (pm_suspend+0x1c4/0x25c)
[<c0067150>] (pm_suspend+0x1c4/0x25c) from [<c0066044>] (state_store+0x6c/0xbc)
[<c0066044>] (state_store+0x6c/0xbc) from [<c0203290>] (kobj_attr_store+0x14/0x20)
[<c0203290>] (kobj_attr_store+0x14/0x20) from [<c0157530>] (sysfs_write_file+0xfc/0x164)
[<c0157530>] (sysfs_write_file+0xfc/0x164) from [<c00fd6b0>] (vfs_write+0xbc/0x1bc)
[<c00fd6b0>] (vfs_write+0xbc/0x1bc) from [<c00fdaf0>] (SyS_write+0x40/0x68)
[<c00fdaf0>] (SyS_write+0x40/0x68) from [<c000ea80>] (ret_fast_syscall+0x0/0x3c)

The clocks may be already disabled before suspending. Check PM runtime
suspend status and disable clocks only if device is not suspended.
During resume do not enable the clocks if device is runtime suspended.

Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Reviewed-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
zeitgeist87 pushed a commit to zeitgeist87/linux that referenced this pull request Mar 14, 2014
@akpm00 @sfrothwell
ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endless…
b29f935 
…loop-during-umount-checkpatch-fixes

ERROR: code indent should use tabs where possible
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {$

WARNING: please, no spaces at the start of a line
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {$

WARNING: suspect code indent for conditional statements (23, 31)
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;

ERROR: code indent should use tabs where possible
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

WARNING: please, no spaces at the start of a line
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

ERROR: code indent should use tabs where possible
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: please, no spaces at the start of a line
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: quoted string split across lines
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "
+                                               "telling master to get ref "

ERROR: code indent should use tabs where possible
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

WARNING: please, no spaces at the start of a line
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

WARNING: quoted string split across lines
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "telling master to get ref "
+                                               "for cleared out mle during "

ERROR: code indent should use tabs where possible
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

WARNING: please, no spaces at the start of a line
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

WARNING: quoted string split across lines
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "for cleared out mle during "
+                                               "migration\n", dlm->name,

ERROR: code indent should use tabs where possible
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

WARNING: please, no spaces at the start of a line
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

ERROR: code indent should use tabs where possible
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
+                                               namelen, name, master,$

WARNING: please, no spaces at the start of a line
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
+                                               namelen, name, master,$

ERROR: code indent should use tabs where possible
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
+                                               new_master);$

WARNING: please, no spaces at the start of a line
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
+                                               new_master);$

ERROR: code indent should use tabs where possible
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
+                       }$

WARNING: please, no spaces at the start of a line
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
+                       }$

total: 9 errors, 13 warnings, 20 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endlessloop-during-umount.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: Joel Becker <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Xue jiufei <[email protected]>
Cc: jiangyiwen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
swarren pushed a commit to swarren/linux-tegra that referenced this pull request Mar 19, 2014
@akpm00 @sfrothwell
ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endless…
216ace2 
…loop-during-umount-checkpatch-fixes

ERROR: code indent should use tabs where possible
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {$

WARNING: please, no spaces at the start of a line
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {$

WARNING: suspect code indent for conditional statements (23, 31)
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;

ERROR: code indent should use tabs where possible
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

WARNING: please, no spaces at the start of a line
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

ERROR: code indent should use tabs where possible
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: please, no spaces at the start of a line
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: quoted string split across lines
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "
+                                               "telling master to get ref "

ERROR: code indent should use tabs where possible
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

WARNING: please, no spaces at the start of a line
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

WARNING: quoted string split across lines
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "telling master to get ref "
+                                               "for cleared out mle during "

ERROR: code indent should use tabs where possible
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

WARNING: please, no spaces at the start of a line
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

WARNING: quoted string split across lines
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "for cleared out mle during "
+                                               "migration\n", dlm->name,

ERROR: code indent should use tabs where possible
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

WARNING: please, no spaces at the start of a line
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

ERROR: code indent should use tabs where possible
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
+                                               namelen, name, master,$

WARNING: please, no spaces at the start of a line
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
+                                               namelen, name, master,$

ERROR: code indent should use tabs where possible
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
+                                               new_master);$

WARNING: please, no spaces at the start of a line
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
+                                               new_master);$

ERROR: code indent should use tabs where possible
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
+                       }$

WARNING: please, no spaces at the start of a line
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
+                       }$

total: 9 errors, 13 warnings, 20 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endlessloop-during-umount.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: Joel Becker <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Xue jiufei <[email protected]>
Cc: jiangyiwen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
torvalds pushed a commit that referenced this pull request Jul 24, 2014
@htejun
libata: introduce ata_host->n_tags to avoid oops on SAS controllers
1a112d1 
1871ee1 ("libata: support the ata host which implements a queue
depth less than 32") directly used ata_port->scsi_host->can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
leading to the following oops.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
 IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
 CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
 Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
 task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
 RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
 RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
 RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
 RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
 R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
 R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
 FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
 Stack:
  ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
  ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
  ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
 Call Trace:
  [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
  [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
  [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300
  [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
  [<ffffffff81317613>] __blk_run_queue+0x33/0x40
  [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
  [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
  [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
  [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
  [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
  [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
  [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
  [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
  [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
  [<ffffffff811e3734>] vfs_read+0x94/0x170
  [<ffffffff811e43c6>] SyS_read+0x46/0xb0
  [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
  [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
 Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00

Fix it by introducing ata_host->n_tags which is initialized to
ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
scsi_host_template->can_queue in ata_host_register() for !SAS ones.
As SAS hosts are never registered, this will give them the same
ATA_MAX_QUEUE - 1 as before.  Note that we can't use
scsi_host->can_queue directly for SAS hosts anyway as they can go
higher than the libata maximum.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Mike Qiu <[email protected]>
Reported-by: Jesse Brandeburg <[email protected]>
Reported-by: Peter Hurley <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Alexey Kardashevskiy <[email protected]>
Fixes: 1871ee1 ("libata: support the ata host which implements a queue depth less than 32")
Cc: Kevin Hao <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: [email protected]
heftig referenced this pull request in zen-kernel/zen-kernel Aug 1, 2014
@htejun @gregkh
libata: introduce ata_host->n_tags to avoid oops on SAS controllers
a8f3f50 
commit 1a112d1 upstream.

1871ee1 ("libata: support the ata host which implements a queue
depth less than 32") directly used ata_port->scsi_host->can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
leading to the following oops.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
 IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
 CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
 Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
 task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
 RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
 RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
 RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
 RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
 R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
 R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
 FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
 Stack:
  ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
  ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
  ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
 Call Trace:
  [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
  [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
  [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300 [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
  [<ffffffff81317613>] __blk_run_queue+0x33/0x40
  [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
  [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
  [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
  [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
  [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
  [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
  [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
  [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
  [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
  [<ffffffff811e3734>] vfs_read+0x94/0x170
  [<ffffffff811e43c6>] SyS_read+0x46/0xb0
  [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
  [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
 Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00

Fix it by introducing ata_host->n_tags which is initialized to
ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
scsi_host_template->can_queue in ata_host_register() for !SAS ones.
As SAS hosts are never registered, this will give them the same
ATA_MAX_QUEUE - 1 as before.  Note that we can't use
scsi_host->can_queue directly for SAS hosts anyway as they can go
higher than the libata maximum.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Mike Qiu <[email protected]>
Reported-by: Jesse Brandeburg <[email protected]>
Reported-by: Peter Hurley <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Alexey Kardashevskiy <[email protected]>
Fixes: 1871ee1 ("libata: support the ata host which implements a queue depth less than 32")
Cc: Kevin Hao <[email protected]>
Cc: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
pstglia pushed a commit to pstglia/linux that referenced this pull request Oct 6, 2014
@htejun @pstglia
libata: introduce ata_host->n_tags to avoid oops on SAS controllers
b826d0f 
1871ee1 ("libata: support the ata host which implements a queue
depth less than 32") directly used ata_port->scsi_host->can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
leading to the following oops.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
 IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
 CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ torvalds#62
 Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
 task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
 RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
 RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
 RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
 RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
 R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
 R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
 FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
 Stack:
  ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
  ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
  ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
 Call Trace:
  [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
  [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
  [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300
  [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
  [<ffffffff81317613>] __blk_run_queue+0x33/0x40
  [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
  [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
  [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
  [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
  [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
  [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
  [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
  [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
  [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
  [<ffffffff811e3734>] vfs_read+0x94/0x170
  [<ffffffff811e43c6>] SyS_read+0x46/0xb0
  [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
  [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
 Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00

Fix it by introducing ata_host->n_tags which is initialized to
ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
scsi_host_template->can_queue in ata_host_register() for !SAS ones.
As SAS hosts are never registered, this will give them the same
ATA_MAX_QUEUE - 1 as before.  Note that we can't use
scsi_host->can_queue directly for SAS hosts anyway as they can go
higher than the libata maximum.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Mike Qiu <[email protected]>
Reported-by: Jesse Brandeburg <[email protected]>
Reported-by: Peter Hurley <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Alexey Kardashevskiy <[email protected]>
Fixes: 1871ee1 ("libata: support the ata host which implements a queue depth less than 32")
Cc: Kevin Hao <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: [email protected]
kees pushed a commit to kees/linux that referenced this pull request Oct 9, 2014
@htejun
libata: introduce ata_host->n_tags to avoid oops on SAS controllers
b9ca136 
BugLink: http://bugs.launchpad.net/bugs/1356913

commit 1a112d1 upstream.

1871ee1 ("libata: support the ata host which implements a queue
depth less than 32") directly used ata_port->scsi_host->can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
leading to the following oops.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
 IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
 CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ torvalds#62
 Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
 task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
 RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
 RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
 RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
 RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
 R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
 R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
 FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
 Stack:
  ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
  ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
  ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
 Call Trace:
  [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
  [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
  [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300
  [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
  [<ffffffff81317613>] __blk_run_queue+0x33/0x40
  [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
  [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
  [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
  [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
  [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
  [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
  [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
  [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
  [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
  [<ffffffff811e3734>] vfs_read+0x94/0x170
  [<ffffffff811e43c6>] SyS_read+0x46/0xb0
  [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
  [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
 Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00

Fix it by introducing ata_host->n_tags which is initialized to
ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
scsi_host_template->can_queue in ata_host_register() for !SAS ones.
As SAS hosts are never registered, this will give them the same
ATA_MAX_QUEUE - 1 as before.  Note that we can't use
scsi_host->can_queue directly for SAS hosts anyway as they can go
higher than the libata maximum.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Mike Qiu <[email protected]>
Reported-by: Jesse Brandeburg <[email protected]>
Reported-by: Peter Hurley <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Alexey Kardashevskiy <[email protected]>
Fixes: 1871ee1 ("libata: support the ata host which implements a queue depth less than 32")
Cc: Kevin Hao <[email protected]>
Cc: Dan Williams <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Joseph Salisbury <[email protected]>
hzhuang1 pushed a commit to hzhuang1/linux that referenced this pull request May 22, 2015
@ldts
Merge pull request torvalds#62 from 96boards/revert-61-rtc
ac106f5 
Revert "Rtc"
gregkh pushed a commit to systemd/linux that referenced this pull request Jun 3, 2015
@szviagintsev @gregkh
kdbus: pool: use __vfs_read()
384ede7 
After commit 5d5d568 ("make new_sync_{read,write}() static")
->read() cannot be called directly.

kdbus_pool_slice_copy() leads to oops, which can be reproduced by
launching tools/testing/selftests/kdbus/kdbus-test -t message-quota:

[ 1167.146793] BUG: unable to handle kernel NULL pointer dereference at           (null)
[ 1167.147554] IP: [<          (null)>]           (null)
[ 1167.148670] PGD 3a9dd067 PUD 3a841067 PMD 0
[ 1167.149611] Oops: 0010 [#1] SMP
[ 1167.150088] Modules linked in: nfsv3 nfs kdbus lockd grace sunrpc
[ 1167.150771] CPU: 0 PID: 518 Comm: kdbus-test Not tainted 4.0.0-next-20150420-kdbus torvalds#62
[ 1167.150771] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 1167.150771] task: ffff88003daed120 ti: ffff88003a800000 task.ti: ffff88003a800000
[ 1167.150771] RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
[ 1167.150771] RSP: 0018:ffff88003a803bc0  EFLAGS: 00010286
[ 1167.150771] RAX: ffff8800377fb000 RBX: 00000000000201e8 RCX: ffff88003a803c00
[ 1167.150771] RDX: 0000000000000b40 RSI: ffff8800377fb4c0 RDI: ffff88003d815700
[ 1167.150771] RBP: ffff88003a803c48 R08: ffffffff8139e380 R09: ffff880039d80490
[ 1167.150771] R10: ffff88003a803a90 R11: 00000000000004c0 R12: 00000000002a24c0
[ 1167.150771] R13: 0000000000000b40 R14: ffff88003d815700 R15: ffffffff8139e460
[ 1167.150771] FS:  00007f41dccd4740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 1167.150771] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1167.150771] CR2: 0000000000000000 CR3: 000000003ccdf000 CR4: 00000000000007b0
[ 1167.150771] Stack:
[ 1167.150771]  ffffffffa0065497 ffff88003a803c10 00007ffffffff000 ffff88003aaa67c0
[ 1167.150771]  00000000000004c0 ffff88003aaa6870 ffff88003ca83300 ffffffffa006537d
[ 1167.150771]  00000000000201e8 ffffea0000ddfec0 ffff88003a803c20 0000000000000018
[ 1167.150771] Call Trace:
[ 1167.150771]  [<ffffffffa0065497>] ? kdbus_pool_slice_copy+0x127/0x200 [kdbus]
[ 1167.150771]  [<ffffffffa006537d>] ? kdbus_pool_slice_copy+0xd/0x200 [kdbus]
[ 1167.150771]  [<ffffffffa006670a>] kdbus_queue_entry_move+0xaa/0x180 [kdbus]
[ 1167.150771]  [<ffffffffa0059e64>] kdbus_conn_move_messages+0x1e4/0x2c0 [kdbus]
[ 1167.150771]  [<ffffffffa006234e>] kdbus_name_acquire+0x31e/0x390 [kdbus]
[ 1167.150771]  [<ffffffffa00625c5>] kdbus_cmd_name_acquire+0x125/0x130 [kdbus]
[ 1167.150771]  [<ffffffffa005db5d>] kdbus_handle_ioctl+0x4ed/0x610 [kdbus]
[ 1167.150771]  [<ffffffff811040e0>] do_vfs_ioctl+0x2e0/0x4e0
[ 1167.150771]  [<ffffffff81389750>] ? preempt_schedule_common+0x1f/0x3f
[ 1167.150771]  [<ffffffff8110431c>] SyS_ioctl+0x3c/0x80
[ 1167.150771]  [<ffffffff8138c36e>] system_call_fastpath+0x12/0x71
[ 1167.150771] Code:  Bad RIP value.
[ 1167.150771] RIP  [<          (null)>]           (null)
[ 1167.150771]  RSP <ffff88003a803bc0>
[ 1167.150771] CR2: 0000000000000000
[ 1167.168756] ---[ end trace a676bcfa75db5a96 ]---

Use __vfs_read() instead.

Signed-off-by: Sergei Zviagintsev <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ddstreet referenced this pull request in ddstreet/linux Jun 20, 2015
@hnaz
linux-next
1fed0d9 
GIT c5901c20eb0341722035975a272a2a7b647fbb32

commit eeb64c14275e52740d6410632e62e0ad9b88ca70
Author: Samuel Thibault <[email protected]>
Date:   Sat Jun 6 11:44:39 2015 -0700

    tty/vt/keyboard: define LED triggers for VT keyboard lock states
    
    In addition to defining triggers for VT LED states, let's define triggers
    for VT keyboard lock states, such as "kbd-shiftlock", "kbd-altgrlock", etc.
    
    This permits to fix #7063 from userland by using a modifier to implement
    proper CapsLock behavior and have the keyboard caps lock led show that
    modifier state.
    
    Signed-off-by: Samuel Thibault <[email protected]>
    Tested-by: Pavel Machek <[email protected]>
    Acked-by: Pavel Machek <[email protected]>
    Signed-off-by: Dmitry Torokhov <[email protected]>

commit 5235552273e6b68abbed3b3047af6344e2e60c2c
Author: Samuel Thibault <[email protected]>
Date:   Mon Mar 16 21:19:44 2015 -0700

    tty/vt/keyboard: define LED triggers for VT LED states
    
    Now that input core allows controlling keyboards LEDs via standard LED
    subsystem triggers let's switch VT keyboard code to make use of this
    feature. We will define the following standard triggers: "kbd-scrollock",
    "kbd-numlock", "kbd-capslock", and "kbd-kanalock" which are default
    triggers for respective LEDs on keyboards.
    
    Signed-off-by: Samuel Thibault <[email protected]>
    Tested-by: Pavel Machek <[email protected]>
    Acked-by: Pavel Machek <[email protected]>
    Signed-off-by: Dmitry Torokhov <[email protected]>

commit 10e87dc42a086c256b25334b6c1c89214feba9a7
Author: Andrew Duggan <[email protected]>
Date:   Tue Jun 16 14:08:41 2015 -0700

    HID: rmi: Disable populating F30 when the touchpad has physical buttons
    
    Physical buttons do not use F30 to report their state and in some cases the
    data reported in F30 is incorrect and inconsistent with what is reported by
    the HID descriptor. When physical buttons are present, ignore F30 and let
    hid-input report buttons based on what is defined in the HID descriptor.
    
    Signed-off-by: Andrew Duggan <[email protected]>
    Reviewed-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>

commit ba8d134e75deb1904b146a4decb0bc6a217333cd
Author: Nishanth Menon <[email protected]>
Date:   Mon Apr 20 19:51:34 2015 -0500

    rtc: ds1307: Enable the mcp794xx alarm after programming time
    
    Alarm interrupt enable register is at offset 0x7, while the time
    registers for the alarm follow that. When we program Alarm interrupt
    enable prior to programming the time, it is possible that previous
    time value could be close or match at the time of alarm enable
    resulting in interrupt trigger which is unexpected (and does not match
    the time we expect it to trigger).
    
    To prevent this scenario from occuring, program the ALM0_EN bit only
    after the alarm time is appropriately programmed.
    
    Ofcourse, I2C programming is non-atomic, so there are loopholes where
    the interrupt wont trigger if the time requested is in the past at
    the time of programming the ALM0_EN bit. However, we will not have
    unexpected interrupts while the time is programmed after the interrupt
    are enabled.
    
    Signed-off-by: Nishanth Menon <[email protected]>
    Reviewed-by: Grygorii Strashko <[email protected]>
    Signed-off-by: Alexandre Belloni <[email protected]>

commit b7ae128d728c42583dac9db48dce9a44bc0fb900
Author: Robert Richter <[email protected]>
Date:   Fri Jun 5 19:49:26 2015 +0200

    ahci: Add support for Cavium's ThunderX host controller
    
    This patch adds support for Cavium's ThunderX host controller. The
    controller resides on the SoC and is a AHCI compatible SATA controller
    with one port, compliant with Serial ATA 3.1 and AHCI Revision 1.31.
    There can exists multiple SATA controllers on the SoC.
    
    The controller depends on MSI-X support since the PCI ECAM controller
    on the SoC does not implement MSI nor lagacy intx interrupt support.
    Thus, during device initialization, if MSI fails MSI-X will be used to
    enable the device's interrupts.
    
    The controller uses non-standard BAR0 for its register range. The
    already existing device lookup (vendor and device id) that is already
    implemented for other host controllers is used to change the PCI BAR.
    
    Signed-off-by: Robert Richter <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit ee2aad42e4b6eaa9721196f07f7d5d8d049e6530
Author: Robert Richter <[email protected]>
Date:   Fri Jun 5 19:49:25 2015 +0200

    ahci: Add generic MSI-X support for single interrupts to SATA PCI driver
    
    This patch adds generic MSI-X support for single interrupts to the
    SATA PCI driver. MSI-X support is needed for host controller that only
    have MSI-X support implemented, but no MSI or intx. This patch only
    adds support for single interrupts, multiple per-port MSI-X interrupts
    are not yet implemented.
    
    The new implementation still initializes MSIs first. Only if that
    fails, the code tries to enable MSI-X. If that fails too, setup is
    continued with intx interrupts.
    
    To not break other chips by this generic code change, there are the
    following precautions:
    
     * Interrupt ranges are not enabled at all.
    
     * Only single interrupt mode is enabled for msix cap devices. Thus,
       only one interrupt will be setup.
    
     * During the discussion with Tejun we agreed to change the init
       sequence from msix-msi-intx to msi-msix-intx. Thus, if a device
       offers msi and init does not fail, the msix init code will not be
       executed. This is equivalent to current code.
    
    With this, the code only setups single mode msix as a last resort if
    msi fails. No interrupt range is enabled at all. Only one interrupt
    will be enabled.
    
    tj: comment edits.
    
    Changes of the patch series:
    
    v5:
     * updated patch subject that the patch only implements single IRQ
     * moved Cavium specific code to a separate patch
     * detect Cavium ThunderX device with PCI_CLASS_STORAGE_SATA_AHCI
       instead of vendor/dev id
     * added more comments to the code
     * enable single msix support for all kind of devices (removing strict
       check)
     * rebased onto update libata/for-4.2 with patch 1, 2 applied
    
    v4:
     * removed implementation of ahci_init_intx()
     * improved patch descriptions
     * rebased onto libata/for-4.2
    
    v3:
     * store irq number in struct ahci_host_priv
     * change initialization order from msix-msi-intx to msi-msix-intx
     * improve comments in ahci_init_msix()
     * improve error message in ahci_init_msix()
     * do not enable MSI-X if MSI is actively disabled for the device
    
    v2:
     * determine irq vector from pci_dev->msi_list
    
    Based on a patch from Sunil Goutham <[email protected]>.
    
    Signed-off-by: Robert Richter <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit e0dd268a2c983acf2b52130b489b3b5724e26b39
Author: Uwe Kleine-König <[email protected]>
Date:   Fri Jun 12 00:35:43 2015 -0700

    leds: aat1290: pass flags parameter to devm_gpiod_get
    
    Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
    which appeared in v3.17-rc1, the gpiod_get* functions take an additional
    parameter that allows to specify direction and initial value for output.
    
    In this case the driver cannot easily be simplified but as the flags
    parameter will become mandatory soon this change is necessary
    beforehand.
    
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Acked-by: Jacek Anaszewski <[email protected]>
    Signed-off-by: Bryan Wu <[email protected]>

commit c8e27605c687d2d628217bef721e955d4baa1ce1
Author: Uwe Kleine-König <[email protected]>
Date:   Fri Jun 12 00:32:23 2015 -0700

    leds: ktd2692: pass flags parameter to devm_gpiod_get
    
    Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
    which appeared in v3.17-rc1, the gpiod_get* functions take an additional
    parameter that allows to specify direction and initial value for output.
    
    In this case the driver cannot easily be simplified but as the flags
    parameter will become mandatory soon this change is necessary
    beforehand.
    
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Acked-by: Jacek Anaszewski <[email protected]>
    Signed-off-by: Bryan Wu <[email protected]>

commit bc3e452003d02b8ec21546490aaed36003a83864
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:13:42 2015 -0400

    module: relocate module_init from init.h to module.h
    
    Modular users will always be users of init functionality, but
    users of init functionality are not necessarily always modules.
    
    Hence any functionality like module_init and module_exit would
    be more at home in the module.h file.  And module.h should
    explicitly include init.h to make the dependency clear.
    
    We've already done all the legwork needed to ensure that this
    move does not cause any build regressions due to implicit
    header file include assumptions about where module_init lives.
    
    Cc: Rusty Russell <[email protected]>
    Acked-by: Rusty Russell <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit b0c6d93014c8f2f53b70e9362b9fbec13b8e3aa0
Author: Paul Gortmaker <[email protected]>
Date:   Mon Jun 15 09:56:26 2015 -0400

    MIPS: don't use module_init in non-modular cobalt/mtd.c file
    
    As of commit 34b1252bd91851f77f89fbb6829a04efad900f41 ("MIPS:
    Cobalt: Do not build MTD platform device registration code as module.")
    this file became built-in instead of modular.  So we should also
    stop using module_init as an alias for __initcall as that can be
    rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.
    
    Cc: Ralf Baechle <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 33d69ca12b44ef3c7be8f948ffa5a35652e1f2ff
Author: Paul Gortmaker <[email protected]>
Date:   Mon Jun 15 16:48:22 2015 -0500

    drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c
    
    This file is built for a bool Kconfig variable, and hence this
    code is either present or absent.  It currently can never be
    modular, so using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    And since it can't be modular, we remove all the __exitcall
    stuff related to module_exit() -- it is dead code that won't
    ever be executed.
    
    Cc: Bryan Wu <[email protected]>
    Cc: Richard Purdie <[email protected]>
    Cc: Jacek Anaszewski <[email protected]>
    Acked-by: Jacek Anaszewski <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 32e805e7c6a343894c95a3431973e8ddad4aa2cf
Author: Paul Gortmaker <[email protected]>
Date:   Fri Jun 5 09:37:19 2015 -0400

    tile: add init.h to usb.c to avoid compile failure
    
    Pending header cleanups will reveal this file is using the
    init.h content implicitly with the following fail:
    
    arch/tile/kernel/usb.c:69:1: warning: data definition has no type or storage class [enabled by default]
    arch/tile/kernel/usb.c:69:1: error: type defaults to 'int' in declaration of 'arch_initcall'
    arch/tile/kernel/usb.c:69:1: warning: parameter names (without types) in function declaration [enabled by default]
    arch/tile/kernel/usb.c:62:19: warning: 'tilegx_usb_init' defined but not used
    
    Explicitly add init.h to get arch_initcall and avoid this.
    
    Reported-by: kbuild test robot <[email protected]>
    Cc: Chris Metcalf <[email protected]>
    Acked-by: Chris Metcalf <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 9b9cf81a2d1f5336de2bebae71a9f2b8d5f1a8de
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:13:42 2015 -0400

    arm: fix implicit #include <linux/init.h> in entry asm.
    
    They use the "_INIT" macro and friends, and hence need to
    source this header file, vs. relying on getting it implicitly.
    
    Cc: Russell King <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 70c4f78b23c69013c908222d55a07c96fea4bba1
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:13:42 2015 -0400

    x86: replace __init_or_module with __init in non-modular vsmp_64.c
    
    The __init_or_module is from commit 05e12e1c4c09cd35ac9f4e6af1e
    ("x86: fix 27-rc crash on vsmp due to paravirt during module load").
    
    But as of commit 70511134f61bd6e5eed19f767381f9fb3e762d49
    ("Revert "x86: don't compile vsmp_64 for 32bit") this file became
    obj-y and hence is now only for built-in.  That makes any
    "_or_module" support no longer necessary.
    
    We need to distinguish between the two in order to do some header
    reorganization between init.h and module.h and we don't want to
    be including module.h in non-modular code.
    
    Cc: Thomas Gleixner <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 77459a0feca4ae8757a905fd1791f039479e8e1e
Author: Paul Gortmaker <[email protected]>
Date:   Wed Jun 3 11:20:05 2015 -0400

    drivers/clk: convert sunxi/clk-mod0.c to use builtin_platform_driver
    
    This driver builds based on obj-y and hence will not ever be
    modular.  Change it to use the non-modular registration so that it
    won't suffer a compile fail once a header move places the modular
    registration within the module.h file.
    
    Cc: "Emilio López" <[email protected]>
    Cc: Mike Turquette <[email protected]>
    Cc: Stephen Boyd <[email protected]>
    Acked-by: Stephen Boyd <[email protected]>
    Cc: Maxime Ripard <[email protected]>
    Acked-by: Maxime Ripard <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit e35415e59f86d6b546a3681e2cda4f22b5b142c0
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:10:58 2015 -0400

    drivers/power: Convert non-modular syscon-reboot to use builtin_platform_driver
    
    This file depends on Kconfig options all of which are a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: Sebastian Reichel <[email protected]>
    Acked-By: Sebastian Reichel <[email protected]>
    Cc: Dmitry Eremin-Solenikov <[email protected]>
    Cc: David Woodhouse <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 0159ae95e6a923f565937f10518aa3c919527733
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/soc: Convert non-modular soc-realview to use builtin_platform_driver
    
    This file depends on Kconfig SOC_REALVIEW which is a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: Arnd Bergmann <[email protected]>
    Cc: Linus Walleij <[email protected]>
    Acked-by: Linus Walleij <[email protected]>
    Cc: Axel Lin <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 7d4d9ed6ef5219857865dd57d425f9729d0a39ff
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/soc: Convert non-modular tegra/pmc to use builtin_platform_driver
    
    This file depends on Kconfig ARCH_TEGRA which is a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: Stephen Warren <[email protected]>
    Cc: Thierry Reding <[email protected]>
    Cc: Alexandre Courbot <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 5b64127e0529387d4538ecc3dfd49248baf619c5
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/cpufreq: Convert non-modular s5pv210-cpufreq.c to use builtin_platform_driver
    
    This file depends on a Kconfig option which is a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: "Rafael J. Wysocki" <[email protected]>
    Cc: Viresh Kumar <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Cc: Kukjin Kim <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 090d1cf103725f583b3f41fc3185698ae5a7aa64
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/cpuidle: Convert non-modular drivers to use builtin_platform_driver
    
    All these drivers are configured with Kconfig options that are
    declared as bool.  Hence it is not possible for the code
    to be built as modular.  However the code is currently using the
    module_platform_driver() macro for driver registration.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'll be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: "Rafael J. Wysocki" <[email protected]>
    Cc: Daniel Lezcano <[email protected]>
    Cc: Michal Simek <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 1dda2b42db1bbc788bf6de0a8141a305484f963b
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/platform: Convert non-modular pdev_bus to use builtin_platform_driver
    
    This driver is configured with a Kconfig option that is
    declared as a bool.  Hence it is not possible for the code
    to be built as modular.  However the code is currently using
    the module_platform_driver() macro for driver registration.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'll be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    And since we've already established that the code is non-modular,
    we can completely drop any code relating to module_exit.
    
    Signed-off-by: Paul Gortmaker <[email protected]>

commit f309d4443130bf814e991f836e919dca22df37ae
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:10:57 2015 -0400

    platform_device: better support builtin boilerplate avoidance
    
    We have macros that help reduce the boilerplate for modules
    that register with no extra init/exit complexity other than the
    most standard use case.  However we see an increasing number of
    non-modular drivers using these modular_driver() type register
    functions.
    
    There are several downsides to this:
    1) The code can appear modular to a reader of the code, and they
       won't know if the code really is modular without checking the
       Makefile and Kconfig to see if compilation is governed by a
       bool or tristate.
    2) Coders of drivers may be tempted to code up an __exit function
       that is never used, just in order to satisfy the required three
       args of the modular registration function.
    3) Non-modular code ends up including the <module.h> which increases
       CPP overhead that they don't need.
    4) It hinders us from performing better separation of the module
       init code and the generic init code.
    
    Here we introduce similar macros, with the mapping from module_driver
    to builtin_driver and similar, so that simple changes of:
    
      module_platform_driver()       --->  builtin_platform_driver()
      module_platform_driver_probe() --->  builtin_platform_driver_probe().
    
    can help us avoid #3 above, without having to code up the same
    __init functions and device_initcall() boilerplate.
    
    For non modular code, module_init becomes __initcall.  But direct use
    of __initcall is discouraged, vs. one of the priority categorized
    subgroups.  As __initcall gets mapped onto device_initcall, our
    use of device_initcall directly in this change means that the
    runtime impact is zero -- drivers will remain at level 6 in the
    initcall ordering.
    
    Cc: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 5b00c1eb94e5936e5bf5cdd9ad1ddfbed0c39159
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 21:57:34 2015 -0400

    x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling
    
    This was using module_init, but the current Kconfig situation is
    as follows:
    
    In arch/x86/kernel/cpu/Makefile:
    
      obj-$(CONFIG_CPU_SUP_INTEL)    += perf_event_intel_pt.o perf_event_intel_bts.o
    
    and in arch/x86/Kconfig.cpu:
    
      config CPU_SUP_INTEL
            default y
            bool "Support Intel processors" if PROCESSOR_SELECT
    
    So currently, the end user can not build this code into a module.
    If in the future, there is desire for this to be modular, then
    it can be changed to include <linux/module.h> and use module_init.
    
    But currently, in the non-modular case, a module_init becomes a
    device_initcall.  But this really isn't a device, so we should
    choose a more appropriate initcall bucket to put it in.
    
    The obvious choice here seems to be arch_initcall, but that does
    make it earlier than it was currently through device_initcall.
    As long as perf_pmu_register() is functional, we should be OK.
    
    Cc: Peter Zijlstra <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Arnaldo Carvalho de Melo <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit ca41d24cf56458a699b44e918c5a19b7077df422
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 21:57:34 2015 -0400

    x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling
    
    This was using module_init, but the current Kconfig situation is
    as follows:
    
    In arch/x86/kernel/cpu/Makefile:
    
      obj-$(CONFIG_CPU_SUP_INTEL)    += perf_event_intel_pt.o perf_event_intel_bts.o
    
    and in arch/x86/Kconfig.cpu:
    
      config CPU_SUP_INTEL
            default y
            bool "Support Intel processors" if PROCESSOR_SELECT
    
    So currently, the end user can not build this code into a module.
    If in the future, there is desire for this to be modular, then
    it can be changed to include <linux/module.h> and use module_init.
    
    But currently, in the non-modular case, a module_init becomes a
    device_initcall.  But this really isn't a device, so we should
    choose a more appropriate initcall bucket to put it in.
    
    The obvious choice here seems to be arch_initcall, but that does
    make it earlier than it was currently through device_initcall.
    As long as perf_pmu_register() is functional, we should be OK.
    
    Cc: Peter Zijlstra <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Arnaldo Carvalho de Melo <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 44c5af96de8230ff7268500f48995f9fea5cffe7
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 21:57:34 2015 -0400

    mm/page_owner.c: use late_initcall to hook in enabling
    
    This was using module_init, but there is no way this code can
    be modular.  In the non-modular case, a module_init becomes a
    device_initcall, but this really isn't a device.   So we should
    choose a more appropriate initcall bucket to put it in.
    
    In order of execution, our close choices are:
    
     fs_initcall(fn)
     rootfs_initcall(fn)
     device_initcall(fn)
     late_initcall(fn)
    
    ..and since the initcall here goes after debugfs, we really
    should be post-rootfs, which means late_initcall makes the
    most sense here.
    
    Cc: Andrew Morton <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 4c7217f1f0fe70af7b9e213ef16f1d2f4a4bacaf
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 21:57:34 2015 -0400

    lib/list_sort: use late_initcall to hook in self tests
    
    This was using module_init, but there is no way this code can
    be modular.  In the non-modular case, a module_init becomes a
    device_initcall, but this really isn't a device.   So we should
    choose a more appropriate initcall bucket to put it in.
    
    Assuming boot time self tests need to be observed over a console
    to be useful, and that the console device could possibly not be
    fully functional until after device_initcall, we move this to the
    late_initcall bucket, which is immediately after device_initcall.
    
    Cc: Andrew Morton <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 89f08f64408b630df7d559223f63e616d0814509
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:08:21 2015 -0400

    arm: use subsys_initcall in non-modular pl320 IPC code
    
    The drivers/mailbox/pl320-ipc.o is dependent on config PL320_MBOX
    which is declared as a bool.  Hence the code is never going to be
    modular.  So using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.  Also add an inclusion of init.h, as
    that was previously implicit.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of subsys_initcall (which
    seems to make sense for IPC code) will thus change this
    registration from level 6-device to level 4-subsys (i.e. slightly
    earlier).  However no impact of that small difference is expected.
    
    Cc: Russell King <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 6f114281c4ad543392f5b7c8345e11e103675cee
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:08:21 2015 -0400

    powerpc: don't use module_init for non-modular core hugetlb code
    
    The hugetlbpage.o is obj-y (always built in).  It will never
    be modular, so using module_init as an alias for __initcall is
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of arch_initcall (which
    makes sense for arch code) will thus change this registration
    from level 6-device to level 3-arch (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: Benjamin Herrenschmidt <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 383d14a5365879bc193d29ad2ed17ac5299753c3
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:08:21 2015 -0400

    powerpc: use subsys_initcall for Freescale Local Bus
    
    The FSL_SOC option is bool, and hence this code is either
    present or absent.  It will never be modular, so using
    module_init as an alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of subsys_initcall (which
    makes sense for bus code) will thus change this registration
    from level 6-device to level 4-subsys (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: Benjamin Herrenschmidt <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: Scott Wood <[email protected]>
    Acked-by: Scott Wood <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 1206f53589237b7e00b9b0a4e42815f14aedad2d
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:08:21 2015 -0400

    x86: don't use module_init for non-modular core bootflag code
    
    The bootflag.o is obj-y (always built in).  It will never be
    modular, so using module_init as an alias for __initcall is
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of arch_initcall (which
    makes sense for arch code) will thus change this registration
    from level 6-device to level 3-arch (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: Thomas Gleixner <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 55331060096f0e9a57356ec36476a49e4bf22bc1
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:08:20 2015 -0400

    netfilter: don't use module_init/exit in core IPV4 code
    
    The file net/ipv4/netfilter.o is created based on whether
    CONFIG_NETFILTER is set.  However that is defined as a bool, and
    hence this file with the core netfilter hooks will never be
    modular.  So using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.  Also add an inclusion of init.h, as
    that was previously implicit here in the netfilter.c file.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of subsys_initcall (which
    seems to make sense for netfilter code) will thus change this
    registration from level 6-device to level 4-subsys (i.e. slightly
    earlier).  However no observable impact of that small difference
    has been observed during testing, or is expected. (i.e. the
    location of the netfilter messages in dmesg remains unchanged
    with respect to all the other surrounding messages.)
    
    As for the module_exit, rather than replace it with __exitcall,
    we simply remove it, since it appears only UML does anything
    with those, and even for UML, there is no relevant cleanup
    to be done here.
    
    Cc: Pablo Neira Ayuso <[email protected]>
    Acked-by: Pablo Neira Ayuso <[email protected]>
    Cc: Patrick McHardy <[email protected]>
    Cc: Jozsef Kadlecsik <[email protected]>
    Cc: "David S. Miller" <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit c013d5a4581203e074a1065e17378984544fcaef
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:08:20 2015 -0400

    fs/notify: don't use module_init for non-modular inotify_user code
    
    The INOTIFY_USER option is bool, and hence this code is either
    present or absent.  It will never be modular, so using
    module_init as an alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of fs_initcall (which
    makes sense for fs code) will thus change this registration
    from level 6-device to level 5-fs (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: John McCutchan <[email protected]>
    Cc: Robert Love <[email protected]>
    Cc: Eric Paris <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit a4bc6fc79f94c5b4f850aabca9c5249adc597094
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:08:20 2015 -0400

    mm: replace module_init usages with subsys_initcall in nommu.c
    
    Compiling some arm/m68k configs with "# CONFIG_MMU is not set" reveals
    two more instances of module_init being used for code that can't
    possibly be modular, as CONFIG_MMU is either on or off.
    
    We replace them with subsys_initcall as per what was done in other
    mmu-enabled code.
    
    Note that direct use of __initcall is discouraged, vs.  one of the
    priority categorized subgroups.  As __initcall gets mapped onto
    device_initcall, our use of subsys_initcall (which makes sense for these
    files) will thus change this registration from level 6-device to level
    4-subsys (i.e.  slightly earlier).
    
    One might think that core_initcall (l2) or postcore_initcall (l3) would
    be more appropriate for anything in mm/ but if we look at the actual init
    functions themselves, we see they are just sysctl setup stuff, and
    hence the choice of subsys_initcall (l4) seems reasonable.  At the same
    time it minimizes the risk of changing the priority too drastically all
    at once.  We can adjust further in the future.
    
    Also, a couple instances of missing ";" at EOL are fixed.
    
    Cc: Andrew Morton <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 84c3e5bf1defc035d63869bbb0f5f80d276c1fc7
Author: Paul Gortmaker <[email protected]>
Date:   Sun Jun 14 16:55:25 2015 -0400

    cris: don't use module_init for non-modular core eeprom.c code
    
    The eeprom.c code is compiled based on the Kconfig setting
    ETRAX_I2C_EEPROM, which is bool.  So the code is either built in
    or absent.  It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: Mikael Starvik <[email protected]>
    Cc: Jesper Nilsson <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 4d38e5c48f4095be21343869ad741676ab4e518f
Author: James Hogan <[email protected]>
Date:   Fri Jun 5 22:17:18 2015 +0100

    tty/metag_da: Avoid module_init/module_exit in non-modular code
    
    The metag_da TTY driver can't get built as a module at the moment, but
    it still uses module_init() and module_exit(). Those macros are moving
    to module.h which isn't included by metag_da.c, which will result in the
    following build warnings (remarkably no build errors) and an apparent
    failure to boot as the TTY driver won't be loaded.
    
    drivers/tty/metag_da.c:660: warning: data definition has no type or storage class
    drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration of ‘module_init’
    drivers/tty/metag_da.c:660: warning: parameter names (without types) in function declaration
    drivers/tty/metag_da.c:661: warning: data definition has no type or storage class
    drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration of ‘module_exit’
    drivers/tty/metag_da.c:661: warning: parameter names (without types) in function declaration
    drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used
    drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used
    drivers/tty/metag_da.c In function ‘dash_console_write’:
    drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ discards qualifiers from pointer target type
    
    Instead of just adding the module.h include, now would be a good time to
    remove the use of these macros, replacing the module_init with
    device_initcall, and removing the exit function altogether since it
    isn't needed. If module support is added later the code can always be
    resurrected.
    
    Reported-by: Guenter Roeck <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: James Hogan <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Jiri Slaby <[email protected]>
    Cc: [email protected]
    Cc: Paul Gortmaker <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 791ed0bb5558dfdc4040563bd0b7dc24450fa732
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:51 2015 -0400

    drivers/clk: don't use module_init in clk-nomadik.c which is non-modular
    
    The clk-nomadik.o is built for ARCH_NOMADIK -- which is bool, and
    hence this code is either present or absent.  It will never be
    modular, so using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Mike Turquette <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 30e3c6428f18b5b8e78602a5a7cc653aee3bfe99
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:50 2015 -0400

    xtensa: don't use module_init for non-modular core network.c code
    
    The network.c code is piggybacking off of the arch independent
    CONFIG_NET, which is bool.  So the code is either built in or
    absent.  It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: Chris Zankel <[email protected]>
    Cc: Max Filippov <[email protected]>
    Cc: Thomas Meyer <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit b205118bdb4b515b4b4f5058aa9f5a12668386c3
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:50 2015 -0400

    sh: don't use module_init in non-modular psw.c code
    
    The psw.o is built for obj-y -- and hence this code is always
    present.  It will never be modular, so using module_init as an alias
    for __initcall can be somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Reported-by: kbuild test robot <[email protected]>
    Cc: Paul Mundt <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 1b4d5beecbeb4608a0fdb77c3b8ba182f0cfb4b6
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:50 2015 -0400

    mn10300: don't use module_init in non-modular flash.c code
    
    The flash.o is built for obj-y -- and hence this code is always
    present.  It will never be modular, so using module_init as an alias
    for __initcall can be somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Reported-by: kbuild test robot <[email protected]>
    Cc: David Howells <[email protected]>
    Acked-by: David Howells <[email protected]>
    Cc: Koichi Yasutake <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 15becabd89fa3fec6aa864fbd1b50b5b1871eee2
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:50 2015 -0400

    parisc64: don't use module_init for non-modular core perf code
    
    The perf.c code depends on CONFIG_64BIT, so it is either built-in
    or absent.  It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.  Aside from it not making sense, it also
    causes a ~10% increase in CPP overhead due to module.h having a
    large list of headers itself -- for example compare line counts:
    
     device_initcall() and <linux/init.h>
    	20238 arch/parisc/kernel/perf.i
    
     module_init() and <linux/module.h>
    	22194 arch/parisc/kernel/perf.i
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit aed6850a1390c2b208b91b2fae0199fc14b94a26
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:50 2015 -0400

    parisc: don't use module_init for non-modular core pdc_cons code
    
    The pdc_cons.c code is always built in.  It will never be modular,
    so using module_init as an alias for __initcall is rather
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Reported-by: kbuild test robot <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 73de14e8cdc733bbc8eda006f813d5aa51511139
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:50 2015 -0400

    cris: don't use module_init for non-modular core intmem.c code
    
    The intmem.c code is always built in.  It will never be modular,
    so using module_init as an alias for __initcall is rather
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Reported-by: kbuild test robot <[email protected]>
    Cc: Mikael Starvik <[email protected]>
    Cc: Jesper Nilsson <[email protected]>
    Acked-by: Jesper Nilsson <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 2a177fd1d92f669f8f493a61e195ff4e3c50f95f
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:50 2015 -0400

    ia64: don't use module_init in non-modular sim/simscsi.c code
    
    The simscsi.o is built for HP_SIMSCSI -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    And since it can't be modular, we remove all the __exitcall
    stuff related to module_exit() -- it is dead code that won't
    ever be executed.
    
    Cc: Tony Luck <[email protected]>
    Cc: Fenghua Yu <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 2e21fa2d11ab61e1827bd5bb1e0e2484931d68e1
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:49 2015 -0400

    ia64: don't use module_init for non-modular core kernel/mca.c code
    
    The mca.c code is always built in.  It will never be modular,
    so using module_init as an alias for __initcall is rather
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: Tony Luck <[email protected]>
    Cc: Fenghua Yu <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 4a0ece7ceceab251e92e7f98e7926642a065727b
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:49 2015 -0400

    arm: don't use module_init in non-modular mach-vexpress/spc.c code
    
    The spc.o is built for ARCH_VEXPRESS_SPC -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Russell King <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit a390a2f18147533359d4e45cb13438d42580da84
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:49 2015 -0400

    powerpc: don't use module_init in non-modular 83xx suspend code
    
    The suspend.o is built for SUSPEND -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Scott Wood <[email protected]>
    Cc: Benjamin Herrenschmidt <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 8f6b9512ceadc6bd52777c299111dc642b4c65b6
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:49 2015 -0400

    powerpc: use device_initcall for registering rtc devices
    
    Currently these two RTC devices are in core platform code
    where it is not possible for them to be modular.  It will
    never be modular, so using module_init as an alias for
    __initcall can be somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- they will remain at level 6 in initcall ordering.
    
    Cc: Benjamin Herrenschmidt <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: Geoff Levand <[email protected]>
    Acked-by: Geoff Levand <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit d54b675a6b0007422dc13acbecdb1ca2b1a53aeb
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:49 2015 -0400

    x86: don't use module_init in non-modular devicetree.c code
    
    The devicetree.o is built for "OF" -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Reported-by: kbuild test robot <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 4711e2f9caedaa07e7cdcb5e058a18762d6be9b1
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:05:49 2015 -0400

    x86: don't use module_init in non-modular intel_mid_vrtc.c
    
    The X86_INTEL_MID option is bool, and hence this code is either
    present or absent.  It will never be modular, so using
    module_init as an alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Thomas Gleixner <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 7cac34370a4dde12e6430c2f0985926d4ef0f459
Author: Paul Gortmaker <[email protected]>
Date:   Fri Jun 5 11:25:18 2015 -0400

    frv: add module.h to mb93090-mb00/flash.c to avoid compile fail
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Reported-by: kbuild test robot <[email protected]>
    Cc: David Howells <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 743492ccd53008736f169f242479bac6245f8379
Author: Paul Gortmaker <[email protected]>
Date:   Wed Jun 3 15:45:21 2015 -0400

    drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
    
    This file is built off of a tristate Kconfig option ("ARM_EXYNOS_CPUFREQ")
    and also contains modular function calls so it should explicitly include
    module.h to avoid compile breakage during pending header shuffles.
    
    Cc: "Rafael J. Wysocki" <[email protected]>
    Cc: Viresh Kumar <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Cc: Kukjin Kim <[email protected]>
    Cc: Krzysztof Kozlowski <[email protected]>
    Acked-by: Krzysztof Kozlowski <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit a7e9bc55cc144dc40e809e579bd932ef2ec324de
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:02:31 2015 -0400

    drivers/staging: include <module.h> for modular android tegra_ion code
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: "Arve Hj�nnev�g" <[email protected]>
    Cc: Riley Andrews <[email protected]>
    Cc: Stephen Warren <[email protected]>
    Cc: Thierry Reding <[email protected]>
    Cc: Alexandre Courbot <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 88775588b71d28a9020a7faa4ad95bbf76d8bb45
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 21:29:53 2015 -0400

    crypto/asymmetric_keys: pkcs7_key_type needs module.h
    
    This driver builds off of the tristate CONFIG_PKCS7_TEST_KEY and calls
    module_init and module_exit. So it should explicitly include module.h
    to avoid compile breakage during header shuffles done in the future.
    
    Cc: Herbert Xu <[email protected]>
    Cc: "David S. Miller" <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 0bbad249a6a4934203b50d574f5d5f9f480b389e
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:02:31 2015 -0400

    sh: mach-highlander/psw.c is tristate and should use module.h
    
    This file is controlled by a tristate Kconfig option, and hence
    needs to include module.h so that it can get module_init() once
    we relocate it from init.h into module.h in the future.
    
    Note that module_exit() appears to be missing from the driver, so
    it is questionable whether it would actually work for a removal
    and reload cycle if it was configured for a modular build.
    
    Cc: Paul Mundt <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit ca1c8e93c37e5a5e27e6149cd3612eb2247e0e4a
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:02:31 2015 -0400

    drivers/regulator: include <module.h> for modular max77802 code
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Cc: Liam Girdwood <[email protected]>
    Cc: Mark Brown <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 5468f887bc861b2fe2fa24a44bc6a616a5d33a73
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:02:31 2015 -0400

    drivers/pcmcia: include <module.h> for modular xxs1500_ss code
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Cc: Wolfram Sang <[email protected]>
    Acked-by: Wolfram Sang <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul Gortmaker <[email protected]>

commit a1a0bec593623f49740d7900e4b862c534f219bf
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:02:30 2015 -0400

    drivers/hsi: include <module.h> for modular omap_ssi code
    
    These files are built off of a tristate Kconfig option and also contain
    modular function calls so they should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    We change the one header file wich gives us coverage on both files:
       drivers/hsi/controllers/omap_ssi.c
       drivers/hsi/controllers/omap_ssi_port.c
    
    Cc: Sebastian Reichel <[email protected]>
    Signed-off-by: Paul Gortmaker <[email protected]>

commit 00fe614863eed7ca39fc72a307c6dff57b690476
Author: Paul Gortmaker <[email protected]>
Date:   Fri May 1 20:02:30 2015 -0400

    drivers/gpu: in…
ddstreet referenced this pull request in ddstreet/linux Jul 31, 2015
@hnaz
linux-next
d6974e5 
GIT 78add8a6901c143cfb091fae54e793af8a48ee41

commit e323d56eb06b266b77c2b430cb5f1977ba549e03
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Jun 12 10:53:25 2015 +0900

    clk: exynos4: Fix wrong clock for Exynos4x12 ADC
    
    The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
    However TSADC is present only on Exynos4210 so on Trats2 board (with
    Exynos4412 SoC) the exynos-adc driver could not be probed:
       ERROR: could not get clock /adc@126C0000:adc(0)
       exynos-adc 126c0000.adc: failed getting clock, err = -2
       exynos-adc: probe of 126c0000.adc failed with error -2
    
    Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
    Converter is located in different register and it is named in datasheet
    as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
    is the same as purpose of TSADC from Exynos4210.
    
    The patch adds gate clock for Exynos4x12 using the proper register so
    backward compatibility is preserved. This fixes the probe of exynos-adc
    driver on Exynos4x12 boards and allows accessing sensors connected to it
    on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Cc: <[email protected]>
    Fixes: c63c57433003 ("ARM: dts: Add ADC's dt data to read raw data for exynos4x12")
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Acked-by: Tomasz Figa <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit fe0d34d242fa1e0dec059e774d146a705420bc9a
Author: Rusty Russell <[email protected]>
Date:   Wed Jul 29 05:52:14 2015 +0930

    module: weaken locking assertion for oops path.
    
    We don't actually hold the module_mutex when calling find_module_all
    from module_kallsyms_lookup_name: that's because it's used by the oops
    code and we don't want to deadlock.
    
    However, access to the list read-only is safe if preempt is disabled,
    so we can weaken the assertion.  Keep a strong version for external
    callers though.
    
    Fixes: 0be964be0d45 ("module: Sanitize RCU usage and locking")
    Reported-by: He Kuang <[email protected]>
    Cc: [email protected]
    Acked-by: Peter Zijlstra (Intel) <[email protected]>
    Signed-off-by: Rusty Russell <[email protected]>

commit ca0169cfa2b37814a4da760e7097467042d2464d
Author: Hai Li <[email protected]>
Date:   Mon Jul 27 13:49:45 2015 -0400

    drm/msm: Enable clocks during enable/disable_vblank() callbacks
    
    AHB clock should be enabled before accessing registers during
    enable/disable_vblank(). Since these 2 callbacks are called in
    atomic context while clk_prepare may cause thread sleep, a work
    is scheduled to control vblanks.
    
    v2: fixup spinlock initialization
    
    Signed-off-by: Hai Li <[email protected]>
    [add comment about cancel_work_sync() before drm_irq_uninstall()]
    Signed-off-by: Rob Clark <[email protected]>

commit 55ceb5071d7a629ec290938c0a234467f57801f4
Author: jilai wang <[email protected]>
Date:   Wed Jul 8 18:25:40 2015 -0400

    drm/msm/mdp5: Add support for msm8x74v1
    
    msm8x74v1 has different MDP5 version (v1.0) from msm8x74v2 (v1.2).
    Add a separate config data to support msm8x74v1.
    
    Signed-off-by: Jilai Wang <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 4aeea572a7154c82abee18375db6dfc8379324ee
Author: jilai wang <[email protected]>
Date:   Tue Jul 7 17:17:28 2015 -0400

    drm/msm/mdp5: Add DMA pipe planes for MDP5
    
    This change is to add planes which use DMA pipes for MDP5.
    
    Signed-off-by: Jilai Wang <[email protected]>
    [slight comment adjust to s/Construct public planes/Construct video
    planes/ since DMA planes are public planes too, they just can't scale
    or CSC]
    Signed-off-by: Rob Clark <[email protected]>

commit 8e6170d1f73dd49a8b98d8b29d1d6e59ff819706
Author: Kyle Huey <[email protected]>
Date:   Mon Jul 13 10:35:45 2015 -0700

    ARM: tegra: Add Tegra124 PMU support
    
    This patch modifies the device tree for Tegra124 based devices to enable
    the Cortex A15 PMU. The interrupt numbers are taken from NVIDIA Tegra K1
    TRM (DP-06905-001_v03p). This patch was tested on a Jetson TK1.
    
    Signed-off-by: Kyle Huey <[email protected]>
    Acked-by: Mark Rutland <[email protected]>
    Acked-by: Jon Hunter <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>

commit b2df19e35e023e922ab7b6cc1cd9efd751e5d062
Author: jilai wang <[email protected]>
Date:   Wed Jul 8 18:12:40 2015 -0400

    drm/msm/mdp: Add capabilities to MDP planes (v2)
    
    MDP planes can be implemented using different type of HW pipes,
    RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type
    of pipe has different HW capabilities such as scaling, color space
    conversion, decimation... Add a variable in plane data structure
    to specify the difference of each plane which comes from mdp5_cfg data
    and use it to differenciate the plane operation.
    V1: Initial change
    V2: Fix a typo in mdp4_kms.h
    
    Signed-off-by: Jilai Wang <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit c09adc18aa2916c76322861e8a2120ff2a3452e0
Author: Stephane Viau <[email protected]>
Date:   Mon Jul 6 16:35:31 2015 -0400

    drm/msm/mdp5: add more YUV formats for MDP5
    
    Add packed YUV422 and planar YUV420 formats to MDP supported
    formats.
    
    Signed-off-by: Stephane Viau <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 6fd8b7e8b3aec6be833115c6f0e56fb888ec2c15
Author: Rob Clark <[email protected]>
Date:   Tue Jul 28 15:09:00 2015 -0400

    fixup! drm/msm/mdp5: use 2 memory clients for YUV formats on newer mdp5

commit 589e72d416fa4cea501d77d01e1b377d03779327
Author: Wentao Xu <[email protected]>
Date:   Mon Jul 6 16:35:30 2015 -0400

    drm/msm/mdp5: use 2 memory clients for YUV formats on newer mdp5
    
    Newer MDP5 uses 2 shared memory pool clients for certain YUV formats.
    For example, if VIG0 is used to fetch data in YUYV format, it will use
    VIG0_Y for Y component, and VIG0_Cr for UV packed.
    
    Signed-off-by: Wentao Xu <[email protected]>
    [rebase]
    Signed-off-by: Stephane Viau <[email protected]>

commit fe9e51fabcd9c32939e5e59ba695f0bfca97290b
Author: Wentao Xu <[email protected]>
Date:   Mon Jul 6 16:35:29 2015 -0400

    drm/msm/mdp: mark if a MDP format is YUV at definition
    
    This makes it easy to determine if a format is YUV. The old
    method of using chroma sample type incorrectly marks YUV444 as
    RGB format.
    
    Signed-off-by: Wentao Xu <[email protected]>
    [rebase]
    Signed-off-by: Stephane Viau <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 4e59a31078dc77ac07897c6f4dcb20c98e2b1611
Author: Uwe Kleine-König <[email protected]>
Date:   Mon Jul 6 11:09:41 2015 +0200

    drm/msm/dp: use flags argument of devm_gpiod_get to set direction
    
    Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
    which appeared in v3.17-rc1, the gpiod_get* functions take an additional
    parameter that allows to specify direction and initial value for output.
    
    Use this to simplify the driver. Furthermore this is one caller less
    that stops us making the flags argument to gpiod_get*() mandatory.
    
    Acked-by: Alexandre Courbot <[email protected]>
    Acked-by: Linus Walleij <[email protected]>
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 8ef625a74f6d1c9fa8d940b8c88757a859bb34f9
Author: Hai Li <[email protected]>
Date:   Fri Jul 3 10:09:46 2015 -0400

    drm/msm/dsi: Save/Restore PLL status across PHY reset
    
    Reset DSI PHY silently changes its PLL registers to reset status,
    which will make cached status in clock driver invalid and result
    in wrong output rate of link clocks. The current restore mechanism
    in DSI PLL does not cover all the cases. This change is to recover
    PLL status after PHY reset to match HW status with cached status
    in clock driver.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit de03fbbbfbd04a82ddb3fe3abf096d717ed97f57
Author: Markus Elfring <[email protected]>
Date:   Sat Jun 27 22:23:28 2015 +0200

    drm/msm/dsi: One function call less in dsi_init() after error detection
    
    The dsi_destroy() function was called in two cases by the dsi_init() function
    during error handling even if the passed variable contained a null pointer.
    
    * This implementation detail could be improved by adjustments for jump
      targets according to the Linux coding style convention.
    
    * Drop an unnecessary initialisation for the variable "msm_dsi" then.
    
    Signed-off-by: Markus Elfring <[email protected]>
    [add couple missing ERR_PTR()'s]
    Signed-off-by: Rob Clark <[email protected]>

commit 4d5fa81f42043e6a5bb9ce856b9f804cf21d202b
Author: Markus Elfring <[email protected]>
Date:   Sat Jun 27 22:05:31 2015 +0200

    drm/msm/dsi: Delete an unnecessary check before the function call "dsi_destroy"
    
    The dsi_destroy() function tests whether its argument is NULL and then
    returns immediately. Thus the test around the call is not needed.
    
    This issue was detected by using the Coccinelle software.
    
    Signed-off-by: Markus Elfring <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 37c5a9eea828c5b094ebfe3bba5b28712fbf3f30
Author: Hai Li <[email protected]>
Date:   Fri Jun 26 16:03:26 2015 -0400

    drm/msm/mdp5: Allocate CTL0/1 for dual DSI single FLUSH
    
    This change takes advantage of a HW feature that synchronize
    flush operation on CTL1 to CTL0, to keep dual DSI pipes in
    sync.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 2d9aa78a562c8b5e59eb7aab1c63b44ca3601ed6
Author: Hai Li <[email protected]>
Date:   Fri Jun 26 16:03:25 2015 -0400

    drm/msm/mdp5: Allocate CTL for each display interface
    
    In MDP5, CTL contains information of the whole pipeline whose
    output goes down to a display interface. In various cases, one
    interface may require 2 CRTCs, but only one CTL. Some interfaces
    also require to use certain CTLs.
    
    Instead of allocating CTL for each active CRTC, this change is to
    associate a CTL with each interface.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 00f3ec37d29efed8983a2add67b692ca509ec99b
Author: Rob Herring <[email protected]>
Date:   Mon Jul 27 15:55:14 2015 -0500

    clk: kill off set_irq_flags usage
    
    set_irq_flags is ARM specific with custom flags which have genirq
    equivalents. Convert drivers to use the genirq interfaces directly, so we
    can kill off set_irq_flags. The translation of flags is as follows:
    
    IRQF_VALID -> !IRQ_NOREQUEST
    IRQF_PROBE -> !IRQ_NOPROBE
    IRQF_NOAUTOEN -> IRQ_NOAUTOEN
    
    For IRQs managed by an irqdomain, the irqdomain core code handles clearing
    and setting IRQ_NOREQUEST already, so there is no need to do this in
    .map() functions and we can simply remove the set_irq_flags calls. Some
    users also modify IRQ_NOPROBE and this has been maintained although it
    is not clear that is really needed. There appears to be a great deal of
    blind copy and paste of this code.
    
    Signed-off-by: Rob Herring <[email protected]>
    Acked-by: Boris Brezillon <[email protected]>
    Cc: Mike Turquette <[email protected]>
    Acked-by: Stephen Boyd <[email protected]>
    Cc: [email protected]
    Signed-off-by: Stephen Boyd <[email protected]>

commit d99215ae06be51558b723a3648515e672898ca4b
Author: Jun Nie <[email protected]>
Date:   Thu Jul 23 15:02:53 2015 +0800

    clk: zx: Constify parent names in clock init data
    
    The array of parent names can be made as array of const pointers to
    const strings.
    
    Signed-off-by: Jun Nie <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 105644e59a2b1c43fe2eeba6595d142c390552c2
Author: Jun Nie <[email protected]>
Date:   Thu Jul 23 15:02:52 2015 +0800

    clk: zx: Add audio and GPIO clock for zx296702
    
    Add SPDIF/I2S and GPIO clock for zx296702
    
    Signed-off-by: Jun Nie <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 4599dd2c926915b5e8c27e0ca21a6172f9d6881c
Author: Jun Nie <[email protected]>
Date:   Thu Jul 23 15:02:51 2015 +0800

    clk: zx: Add audio div clock method for zx296702
    
    Add SPDIF/I2S divider clock method for zx296702
    
    Signed-off-by: Jun Nie <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 7764d0cdc3dbf15010f66e0e2e5786f0f03d402a
Author: Vaibhav Hiremath <[email protected]>
Date:   Wed Jul 22 15:04:53 2015 +0530

    clk: s2mps11: Use kcalloc instead of kzalloc for array allocation
    
    This patch cleans up the driver for,
    
      - Use devm_kcalloc() variant instead of devm_kzalloc() for array
        allocation.
      - clk_prepare()/unprepare(), remove "ret" variable as it is not required
      - use __exit for cleanup function
    
    As I am referring this driver as a reference for my 88pm800 clk driver,
    applying same changes here as well.
    
    Signed-off-by: Vaibhav Hiremath <[email protected]>
    Tested-by: Anand Moon <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit a57aa18539f8b232065f574f438edb646c6b9d9b
Author: Stephen Boyd <[email protected]>
Date:   Fri Jul 24 12:24:48 2015 -0700

    clk: Silence warnings about lock imbalances
    
    The recursive spinlock implementation trips up sparse and it
    complains that these functions have lock imbalances. That isn't
    really true though, so add some __acquires() and __releases()
    information so that sparse is quiet.
    
    drivers/clk/clk.c:116:22: warning: context imbalance in 'clk_enable_lock' - wrong count at exit
    drivers/clk/clk.c:141:9: warning: context imbalance in 'clk_enable_unlock' - unexpected unlock
    
    Signed-off-by: Stephen Boyd <[email protected]>

commit 661e2180cf050a2f859d466f30d74e990b9345be
Author: Stephen Boyd <[email protected]>
Date:   Fri Jul 24 12:21:12 2015 -0700

    clk: basic-type: Silence warnings about lock imbalances
    
    The basic clock types use conditional locking for the register
    accessor spinlocks. Add __acquire() and __release() markings in
    the right locations so that sparse isn't tripped up on the
    conditional locking.
    
    drivers/clk/clk-mux.c:68:12: warning: context imbalance in 'clk_mux_set_parent' - different lock contexts for basic block
    drivers/clk/clk-divider.c:379:12: warning: context imbalance in 'clk_divider_set_rate' - different lock contexts for basic block
    drivers/clk/clk-gate.c:71:9: warning: context imbalance in 'clk_gate_endisable' - different lock contexts for basic block
    drivers/clk/clk-fractional-divider.c:36:9: warning: context imbalance in 'clk_fd_recalc_rate' - different lock contexts for basic block
    drivers/clk/clk-fractional-divider.c:68:12: warning: context imbalance in 'clk_fd_set_rate' - different lock contexts for basic block
    
    Cc: Andy Shevchenko <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 169f05e80522e2848c9089a17976ebf31e735d5c
Author: Stephen Boyd <[email protected]>
Date:   Fri Jul 24 11:55:42 2015 -0700

    clk: qcom: Give clk-qcom.ko module a GPLv2 license
    
    The missing license causes the clk-qcom.ko module to taint the
    kernel. Add the appropriate license to avoid taint.
    
    Signed-off-by: Stephen Boyd <[email protected]>

commit 37bff2c159a3629b592e54162239cb8c337c965d
Author: Stephen Boyd <[email protected]>
Date:   Fri Jul 24 09:31:29 2015 -0700

    clk: gpio: Mark parent_names array const
    
    Let's encourage const arrays of parent names like other basic
    clock types.
    
    Cc: Sergej Sawazki <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit afe76c8fd030dd6b75fa69f7af7b7eb1e212f248
Author: Jim Quinlan <[email protected]>
Date:   Fri May 15 15:45:47 2015 -0400

    clk: allow a clk divider with max divisor when zero
    
    This commit allows certain Broadcom STB clock dividers to be used with
    clk-divider.c.  It allows for a clock whose field value is the equal
    to the divisor, execpt when the field value is zero, in which case the
    divisor is 2^width.  For example, consider a divisor clock with a two
    bit field:
    
    value		divisor
    0		4
    1		1
    2		2
    3		3
    
    Signed-off-by: Jim Quinlan <[email protected]>
    Signed-off-by: Michael Turquette <[email protected]>

commit 25d4d341d31b349836e1b12d10be34b9b575c12b
Author: Andy Shevchenko <[email protected]>
Date:   Mon Jul 13 17:07:43 2015 +0300

    clk: socfpga: switch to GENMASK()
    
    Convert the code to use GENMASK() helper instead of div_mask() macro.
    
    Signed-off-by: Andy Shevchenko <[email protected]>
    Acked-by: Dinh Nguyen <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 4b5fb7dc9096d949a22651370bb6bf11f21edb30
Author: Robert Jarzmik <[email protected]>
Date:   Sun Jul 12 22:49:53 2015 +0200

    clk: pxa: fix core frequency reporting unit
    
    Legacy drivers which are not yet ported, such as cpufreq-pxa[23]xx, rely
    on pxaXXx_get_clk_frequency_khz() to find the CPU core frequency.
    
    This reporting was broken because the expected unit is kHz and not
    Hz. Fix the reporting for pxa25x, pxa27x and pxa3xx.
    
    Fixes: fe7710fae477 ("clk: add pxa25x clock drivers")
    Fixes: d40670dc6169 ("clk: add pxa27x clock drivers")
    Fixes: 9bbb8a338fb2 ("clk: pxa: add pxa3xx clock driver")
    Signed-off-by: Robert Jarzmik <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 2bbfe00147a7c075f5c43e657ec218afea662819
Author: Douglas Anderson <[email protected]>
Date:   Tue Jul 21 13:41:23 2015 -0700

    clk: rockchip: Fix PLL bandwidth
    
    In the TRM we see that BWADJ is "a 12-bit bus that selects the values
    1-4096 for the bandwidth divider (NB)":
     NB = BWADJ[11:0] + 1
    The recommended setting of NB: NB = NF / 2.
    
    So:
      NB = NF / 2
      BWADJ[11:0] + 1 = NF / 2
      BWADJ[11:0] = NF / 2 - 1
    
    Right now, we have:
    
    {                                               \
            .rate   = _rate##U,                     \
            .nr = _nr,                              \
            .nf = _nf,                              \
            .no = _no,                              \
            .bwadj = (_nf >> 1),                    \
    }
    
    That means we set bwadj to NF / 2, not NF / 2 - 1
    
    All of this is a bit confusing because we specify "NR" (the 1-based
    value), "NF" (the 1-based value), "NO" (the 1-based value), but
    "BWADJ" (the 0-based value) instead of "NB" (the 1-based value).
    
    Let's change to working with "NB" and fix the off by one error.  This
    may affect PLL jitter in a small way (hopefully for the better).
    
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 9da9e761273702b3afd6e3538c23ece95693e586
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:06 2015 -0500

    clk: ti: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Cc: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 8a53fb2bceea00081c4a6af7b477bea8ec00b74b
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:05 2015 -0500

    clk: sunxi: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Acked-by: Maxime Ripard <[email protected]>
    Cc: "Emilio López" <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 0b4e7f0842fe5c8bd19654999f6c41c4119e7c90
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:04 2015 -0500

    clk: st: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Tested-by Gabriel Fernandez <[email protected]>
    Cc: Peter Griffin <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 5f23eff7af6bc1d8cc8e17fc12e8d989042236ed
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:03 2015 -0500

    clk: keystone: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Acked-by: Santosh Shilimkar <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit f0557fbe1303aade362bd578753a1c898a80851c
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:01 2015 -0500

    clk: at91: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Cc: Boris Brezillon <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 75ce0cdb6243d42daca6130e5feb71f536bb136e
Author: James Liao <[email protected]>
Date:   Fri Jul 10 16:39:34 2015 +0800

    clk: mediatek: Add MT8173 MMPLL change rate support
    
    MT8173 MMPLL frequency settings are different from common PLLs.
    It needs different post divider settings for some ranges of frequency.
    This patch add support for MT8173 MMPLL frequency setting by adding
    div-rate table to lookup suitable post divider setting under a
    specified frequency.
    
    Signed-off-by: James Liao <[email protected]>
    Acked-by: Sascha Hauer <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 196de71a9d9e9090406a87362d22b67ae633fa7a
Author: James Liao <[email protected]>
Date:   Fri Jul 10 16:39:33 2015 +0800

    clk: mediatek: Fix calculation of PLL rate settings
    
    Avoid u32 overflow when calculate post divider setting, and
    increase the max post divider setting from 3 (/8) to 4 (/16).
    
    Signed-off-by: James Liao <[email protected]>
    Acked-by: Sascha Hauer <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit b3be457e5854e3095cd0be850058c765aaf467ab
Author: James Liao <[email protected]>
Date:   Fri Jul 10 16:39:32 2015 +0800

    clk: mediatek: Fix PLL registers setting flow
    
    Write postdiv and pcw settings at the same time for PLLs if postdiv
    and pcw settings are on the same register.
    
    This is need by PLLs such as MT8173 MMPLL and ARM*PLL.
    
    Signed-off-by: James Liao <[email protected]>
    Acked-by: Sascha Hauer <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 9783c0d98501aa146ff467916ab4b8830a655d7c
Author: Stephen Boyd <[email protected]>
Date:   Thu Jul 16 12:50:27 2015 -0700

    clk: Allow providers to configure min/max rates
    
    clk providers are using the consumer APIs to set min/max rates on
    the clock they're providing. To encourage clk providers to move
    away from the consumer APIs, add a provider API to set the
    min/max rate of a clock. The assumption is that this is done
    before the clock can be requested via clk_get() and that the
    clock rate is already within the boundaries of the min/max that's
    configured.
    
    Tested-by: Sudeep Holla <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 5c757456c16ce056a40a120e63235bc00c94ee7f
Author: Axel Lin <[email protected]>
Date:   Thu Jul 16 22:15:53 2015 +0800

    clk: twl6040: Convert to use devm_clk_register
    
    Use devm_clk_register() to simplify the code by removing
    twl6040_clk_remove().
    
    Signed-off-by: Axel Lin <[email protected]>
    Acked-by: Peter Ujfalusi <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 264e3b75de4eee6e4ee4616bf2b2a3d522cad72a
Author: Axel Lin <[email protected]>
Date:   Thu Jul 16 21:59:43 2015 +0800

    clk: s2mps11: Simplify s2mps11_clk_probe unwind paths
    
    The devm_clk_unregister() in .probe error case is not necessary as it will
    be automatically called when probe fails.
    
    Signed-off-by: Axel Lin <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 5a1cfafaeab5237523d43cd033e1fb42bf5c1933
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Jun 23 15:09:27 2015 +0200

    clk: shmobile: Remove unneeded #include <linux/clkdev.h>
    
    The CCF implementations for the various shmobile SoCs don't use clkdev
    functionality, hence drop the inclusion of <linux/clkdev.h>.
    
    Add the missing #include <linux/slab.h>, which was included implicitly
    through <asm/clkdev.h> before.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 14cc4e9578841a4c0025ce064133b2da53c9d1c9
Author: Stephen Boyd <[email protected]>
Date:   Wed Jul 15 12:58:22 2015 -0700

    clk: ti: Force pointer to be __iomem
    
    Add __force here so that sparse doesn't complain about us playing
    tricks with __iomem.
    
    Acked-by: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 76642eb4cb040b436319e5aa747a5ef026207eef
Author: Stephen Boyd <[email protected]>
Date:   Wed Jul 15 12:04:53 2015 -0700

    clk: ti: clk-3xxx: Remove unused structures
    
    Sparse complains about these structures missing static, but they
    also don't look to be used. Remove them.
    
    drivers/clk/ti/clk-3xxx.c:74:30: warning: symbol 'clkhwops_omap3430es2_ssi_wait' was not declared. Should it be static?
    drivers/clk/ti/clk-3xxx.c:157:30: warning: symbol 'clkhwops_omap3430es2_hsotgusb_wait' was not declared. Should it be static?
    
    Acked-by: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 3fe6d697420c706b640730dbbae17f48b3aad506
Author: Stephen Boyd <[email protected]>
Date:   Wed Jul 15 12:03:52 2015 -0700

    clk: ti: Mark ti_clk_features static
    
    This variable isn't exported outside of this file so mark it
    static. Silences the following sparse warning:
    
    drivers/clk/ti/clk.c:36:24: warning: symbol 'ti_clk_features' was not declared. Should it be static?
    
    Acked-by: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit f645f72d876586c4950dcd5bf516744db0aeb30b
Author: Stephen Boyd <[email protected]>
Date:   Wed Jul 15 11:55:42 2015 -0700

    clk: ti: Check kzalloc() for failures
    
    smatch reports a failure to check kzalloc() here:
    
    drivers/clk/ti/clk.c:232
    omap2_clk_provider_init() error: potential null dereference 'io'.
    (kzalloc returns null)
    
    Check for an allocation failure and return -ENOMEM.
    
    Acked-by: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit e306479ac252928b84cc563c6e790f9b7e7ae427
Author: Axel Lin <[email protected]>
Date:   Sat Jun 20 15:27:03 2015 +0800

    clk: h8300: Fix signness bug
    
    of_clk_get_parent_count() may return negative error code, so num_parents
    needs to be int rather than unsigned int.
    
    Signed-off-by: Axel Lin <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit d7a304e9d018c99dda80f4c16ec0fe817b5be4a1
Author: Stephen Boyd <[email protected]>
Date:   Tue Jul 14 16:57:29 2015 -0700

    clk: qcom: Set CLK_SET_RATE_PARENT on ce1 clocks
    
    The other ce clocks have the flag set, but ce1 doesn't, so
    clk_set_rate() doesn't propagate up the tree to the ce1_src_clk.
    Set the flag as this is supported.
    
    Reported-by: Bjorn Andersson <[email protected]>
    Tested-by: Bjorn Andersson <[email protected]>
    Fixes: 02824653200b ("clk: qcom: Add APQ8084 Global Clock Controller support")
    Fixes: d33faa9ead8d ("clk: qcom: Add support for MSM8974's global clock controller (GCC)")
    Signed-off-by: Stephen Boyd <[email protected]>

commit c5e857a46af24a772f445edcc01a861ee2d6a713
Author: Stephen Boyd <[email protected]>
Date:   Tue Jul 14 12:45:19 2015 -0700

    clk: gpio: Unlock mutex on error path
    
    We don't unlock the mutex if we fail to allocate the parent names
    array. Unlock it and return an error in this case as well.
    
    Reported-by: kbuild test robot <[email protected]>
    Acked-by: Julia Lawall <[email protected]>
    Cc: Sergej Sawazki <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 006cb8b66e18ce7aff934883f6c50e3b85052681
Author: Stephen Boyd <[email protected]>
Date:   Mon Jul 13 17:06:53 2015 -0700

    clk: h8300: Use standard Linux I/O accessors
    
    There doesn't seem to be any reason why we can't use the standard
    readb()/writeb() accessors here because ctrl_inb() and
    ctrl_outb() match the generic implementation of readb() and
    writeb() that the h8300 architecture uses. This allows us to test
    compile this driver on other architectures besides h8300.
    
    Cc: Yoshinori Sato <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 9298f0267c7ed620f8d8261ded8518ebf8e89f9e
Author: Stephen Boyd <[email protected]>
Date:   Mon Jul 13 16:54:04 2015 -0700

    clk: h8300: Drop allocation printk and cleanup sizeof style
    
    We don't need to print an error on allocation failures, drop it.
    While we're here, change the sizeof() to be sizeof(*<ptr>) to
    make code more future proof.
    
    Cc: Yoshinori Sato <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit a8a7af8607a2551ce9699ffea7ccc7bd54b59064
Author: Daniel Vetter <[email protected]>
Date:   Tue Jul 28 13:18:42 2015 +0200

    drm: Remove __drm_modeset_lock_all
    
    The last user is gone, no need for trylocking any more in this legacy
    helper.
    
    Reviewed-by: Rob Clark <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit d553fca625bb9a147c5eadcede7e40c9ba2bd8eb
Author: Daniel Vetter <[email protected]>
Date:   Tue Jul 28 13:18:41 2015 +0200

    drm/fb-helper: Stop using trylocks in force_restore
    
    Since the panic handling is gone this is only used for force-restoring
    the fbdev/fbcon from sysrq, and that's done with a work item. No need
    any more to do trylocks, we can just do normal locking.
    
    Reviewed-by: Rob Clark <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 3828c43eb59d13f7105950021102bc0c787090fe
Author: Daniel Vetter <[email protected]>
Date:   Tue Jul 28 13:18:40 2015 +0200

    drm/fbdev: Return -EBUSY when oopsing
    
    Trying to do anything with kms drivers when oopsing has become a
    failing proposition. But since we can end up in the fbdev code simply
    due to the console unblanking that's done unconditionally just
    removing our panic handler isn't enough. We need to block all fbdev
    callbacks when oopsing.
    
    There was already one in the blank handler, but it failed silently.
    That makes it impossible for drivers (like i915) who subclass these
    functions to figure this out.
    
    Instead consistently return -EBUSY so that everyone knows that we
    really don't want to be bothered right now. This also allows us to
    remove a pile of FIXMEs from the i915 fbdev code (since due to the
    failure code they now won't attempt to grab dangerous locks any more).
    
    Cc: Dave Airlie <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Reviewed-by: Rob Clark <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 5de3bd463534117dc95e27c7f318e49e41985eff
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:20 2015 +0530

    drm/fb_cma_helper: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: Lars-Peter Clausen <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit e71570b47816b841c163d3a7a5bd540165523884
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:16 2015 +0530

    drm/udl: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    v2:
    - remove unused variable device in udlfb_create
    
    Cc: David Airlie <[email protected]>
    Cc: Haixia Shi <[email protected]>
    Cc: "Stéphane Marchesin" <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit dad4e3022391fa560f9062599764db993eb81af7
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:13 2015 +0530

    drm/qxl: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: David Airlie <[email protected]>
    Cc: Frediano Ziglio <[email protected]>
    Cc: Maarten Lankhorst <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 2115744d7b2f05bacdc069d0b49c307c6bcdbdfe
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:10 2015 +0530

    drm/gma500: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    v2:
    - removed unused variable 'device' in psbfb_create
    
    Cc: Patrik Jakobsson <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Reviewed-by: Patrik Jakobsson <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 1011f98d86dc6d6efe98ef04468d046189ce6ccb
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:09 2015 +0530

    drm/exynos: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    v2:
    - Remove unnecessary dealloc cmap in error handling path
    
    Cc: Inki Dae <[email protected]>
    Cc: Joonyoung Shim <[email protected]>
    Cc: Seung-Woo Kim <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 4960d05ef9f626e1e42ae0c0b4bdb65ce37fba0d
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:08 2015 +0530

    drm/msm: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: Rob Clark <[email protected]>
    Cc: Stephane Viau <[email protected]>
    Cc: Hai Li <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit b756ecb40a01b8d85bc7662d2bfb77da05d813c5
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:07 2015 +0530

    drm/tegra: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    v2:
    - Fix up error handling path in tegra_fbdev_probe
    
    Cc: Thierry Reding <[email protected]>
    Cc: "Terje Bergström" <[email protected]>
    Cc: Stephen Warren <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 377eb331375f54fb908a8d90b0807b184b639b14
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:06 2015 +0530

    drm/omap: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: Tomi Valkeinen <[email protected]>
    Cc: Laurent Pinchart <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit d0bda2cd4e30a65f671152e59d296f70f4cef8c2
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:05 2015 +0530

    drm/ast: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cleaned up the error handling in astfb_create a bit.
    
    v2:
    - removed unused variable 'device' in astfb_create
    
    Cc: David Airlie <[email protected]>
    Cc: "Y.C. Chen" <[email protected]>
    Cc: Alex Deucher <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 6d7906fce79a6606c35022d7f9f839ad3e403bec
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:04 2015 +0530

    drm/armada: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: Russell King <[email protected]>
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 27f8f10314120ca55a2a2a2ff455228aca6980f1
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:03 2015 +0530

    drm/rockchip: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    This is an effort to create a top level drm fbdev emulation option.
    
    Cc: Mark Yao <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: Rob Clark <[email protected]>
    Cc: Daniel Kurtz <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 8b34fe593ec6392aaef74c244fe2c091f424dee8
Author: Florian Fainelli <[email protected]>
Date:   Tue Jul 14 13:03:33 2015 -0700

    ata: ahci_brcmstb: Fix warnings with CONFIG_PM_SLEEP=n
    
    When CONFIG_PM_SLEEP is disabled, brcm_ahci_{suspend,resume} are not
    used, which causes such a build warning to occur:
    
      CC      drivers/ata/ahci_brcmstb.o
    drivers/ata/ahci_brcmstb.c:212:12: warning: 'brcm_ahci_suspend' defined
    but not used [-Wunused-function]
     static int brcm_ahci_suspend(struct device *dev)
                ^
    drivers/ata/ahci_brcmstb.c:224:12: warning: 'brcm_ahci_resume' defined
    but not used [-Wunused-function]
     static int brcm_ahci_resume(struct device *dev)
                ^
      LD      drivers/ata/built-in.o
    
    Fixes: 766a2d979632 ("ata: add Broadcom AHCI SATA3 driver for STB chips")
    Signed-off-by: Florian Fainelli <[email protected]>
    Acked-by: Brian Norris <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit c7906acec31005324b461195478dae5a65904630
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:14 2015 +0530

    drm/msm/dsi: Modify dsi manager bridge ops to work with external bridges
    
    The dsi bridge ops call drm_panel functions to set up the connected
    drm_panel. Add checks to make sure these aren't called when we're
    connected to an external bridge.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 77eb5ee6944ea00f10100f46ce521d247f573d48
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:13 2015 +0530

    drm/msm/dsi: Allow dsi to connect to an external bridge
    
    There are platforms where the DSI output can be connected to another
    encoder bridge chip (DSI to HDMI, DSI to LVDS etc).
    
    Add support for external bridge support to the dsi driver. We assume that
    the external bridge chip would be of the type drm_bridge. The dsi driver's
    internal drm_bridge (msm_dsi->bridge) is linked to the external bridge's
    drm_bridge struct.
    
    In the case we're connected to an external bridge, we don't need to create
    and manage a connector within our driver, it's the bridge driver's
    responsibility to create one.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 3213afb8bf5cf8d8c68a2c2376bf1dda52afae5d
Author: Dmitry Torokhov <[email protected]>
Date:   Tue Jul 28 10:25:03 2015 -0700

    Revert "Input: zforce - don't overwrite the stack"
    
    This reverts commit 7d01cd261c76f95913c81554a751968a1d282d3a because
    with given FRAME_MAXSIZE of 257 the check will never trigger and it
    causes warnings from GCC (with -Wtype-limits). Also the check was
    incorrect as it was not accounting for the already read 2 bytes of data
    stored in the buffer.

commit 40747338f97226962accfb5f70da193e750b398f
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:12 2015 +0530

    drm/msm/dsi: Create a helper to check if there is a connected device
    
    Create a helper msm_dsi_device_connected() which checks whether we have a
    device connected to the dsi host or not. This check gets messy when we
    have support external bridges too. Having an inline function makes it
    more legible.
    
    For now, the check only consists of msm_dsi->panel being non-NULL. Later,
    this will check if we have an external bridge or not.
    
    This helper isn't used in dsi_connector related code as that's specific
    to only when a drm_panel is connected.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 7a771d4b0d5827ff5528eab48b5e63f41ab15a37
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:11 2015 +0530

    drm/msm/dsi: Refer to connected device as 'device' instead of 'panel'
    
    We currently support only panels connected to dsi output. We're going to
    also support external bridge chips now.
    
    Change 'panel_node' to 'device_node' in the struct msm_dsi_host and
    'panel_flags' to 'device_flags' in msm_dsi. This makes things sound a
    bit more generic.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 2111491b81933189c9e8d0bc34de1ec5e4b52b33
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:10 2015 +0530

    drm/msm/dsi: Make TE gpio optional
    
    Platforms containing only DSI video mode devices don't need a TE gpio.
    Make TE gpio optional.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit c5d6f02944d27afabd5b474930031e933058da14
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:13:05 2015 +0530

    drm/msm: mdp4 lvds: get panel node via of graph parsing
    
    We currently get the output connected to LVDS by looking for a phandle
    called 'qcom,lvds-panel' under the mdp DT node.
    
    Use the more standard of_graph approach to create an lvds output port,
    and retrieve the panel node from the port's endpoint data.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit c3f502202f958661d197fc6cd4a2f43979cc7814
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:13:04 2015 +0530

    drm/msm: dsi host: Use device graph parsing to parse connected panel
    
    The dsi host looks for the connected panel node by parsing for a child
    named 'panel'. This hierarchy isn't very flexible. The connected
    panel is forced to be a child to the dsi host, and hence, a mipi dsi
    device. This isn't suitable for dsi devices that don't use mipi dsi
    as their control bus.
    
    Follow the of_graph approach of creating ports and endpoints to
    represent the connections between the dsi host and the panel connected
    to it. In our case, the dsi host will only have one output port, linked
    to the panel's input port.
    
    Update DT binding documentation with device graph usage info.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 50af680c113dd41c46cd1fd5b7f1dbfca956c0b1
Author: jilai wang <[email protected]>
Date:   Thu Jun 25 17:37:42 2015 -0400

    drm/msm/mdp5: Add plane blending operation support for MDP5 (v2)
    
    This change is to add properties alpha/zpos/blend_mode to mdp5 plane
    for alpha blending operation to generate the blended output.
    v1: Initial change
    v2: Change "premultilied" property to enum (Rob's comment)
    
    Signed-off-by: Jilai Wang <[email protected]>
    [Don't actually expose alpha/premultiplied props to userspace yet
    pending a chance for discussion and some userspace to exercise it]
    Signed-off-by: Rob Clark <[email protected]>

commit 967f092ae15206bdc89e1a204593116a1d470500
Author: Olof Johansson <[email protected]>
Date:   Tue Jul 28 18:31:18 2015 +0200

    arm-soc: document merges
    
    Signed-off-by: Olof Johansson <[email protected]>

commit 76f90d76c27aaf1408378cd2009002859a79da92
Author: Thierry Reding <[email protected]>
Date:   Fri Aug 1 15:50:44 2014 +0200

    of: Add vendor prefix for Sharp Microelectronics
    
    Use "sharp" as the vendor prefix for Sharp Microelectronics in device
    tree compatible strings.
    
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Rob Herring <[email protected]>

commit 0e3d05cf83a896268108f118c486916aafe86177
Author: Olof Johansson <[email protected]>
Date:   Tue Jul 28 17:32:43 2015 +0200

    arm-soc: document merges
    
    Signed-off-by: Olof Johansson <[email protected]>

commit 227942809b52f23cda414858b635c0285f11de00
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:23 2015 +0530

    cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling
    
    If frequency is throttled due to OCC reset then cpus will be in Psafe
    frequency, so restore the frequency on all cpus to policy->cur when
    OCCs are active again. And if frequency is throttled due to Pmax
    capping then restore the frequency of all the cpus  in the chip on
    unthrottling.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 3dd3ebe5bb3837aeac28a23f8f22b97cb84abab6
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:22 2015 +0530

    cpufreq: powernv: Report Psafe only if PMSR.psafe_mode_active bit is set
    
    On a reset cycle of OCC, although the system retires from safe
    frequency state the local pstate is not restored to Pmin or last
    requested pstate. Now if the cpufreq governor initiates a pstate
    change, the local pstate will be in Psafe and we will be reporting a
    false positive when we are not throttled.
    
    So in powernv_cpufreq_throttle_check() remove the condition which
    checks if local pstate is less than Pmin while checking for Psafe
    frequency. If the cpus are forced to Psafe then PMSR.psafe_mode_active
    bit will be set. So, when OCCs become active this bit will be cleared.
    Let us just rely on this bit for reporting throttling.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Reviewed-by: Preeti U Murthy <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 735366fc407755626058218fc8d0430735a669ac
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:21 2015 +0530

    cpufreq: powernv: Call throttle_check() on receiving OCC_THROTTLE
    
    Re-evaluate the chip's throttled state on recieving OCC_THROTTLE
    notification by executing *throttle_check() on any one of the cpu on
    the chip. This is a sanity check to verify if we were indeed
    throttled/unthrottled after receiving OCC_THROTTLE notification.
    
    We cannot call *throttle_check() directly from the notification
    handler because we could be handling chip1's notification in chip2. So
    initiate an smp_call to execute *throttle_check(). We are irq-disabled
    in the notification handler, so use a worker thread to smp_call
    throttle_check() on any of the cpu in the chipmask.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit cb166fa937a2fbc14badcafca86202354c34a213
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:20 2015 +0530

    cpufreq: powernv: Register for OCC related opal_message notification
    
    OCC is an On-Chip-Controller which takes care of power and thermal
    safety of the chip. During runtime due to power failure or
    overtemperature the OCC may throttle the frequencies of the CPUs to
    remain within the power budget.
    
    We want the cpufreq driver to be aware of such situations to be able
    to report the reason to the user. We register to opal_message_notifier
    to receive OCC messages from opal.
    
    powernv_cpufreq_throttle_check() reports any frequency throttling and
    this patch will report the reason or event that caused throttling. We
    can be throttled if OCC is reset or OCC limits Pmax due to power or
    thermal reasons. We are also notified of unthrottling after an OCC
    reset or if OCC restores Pmax on the chip.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 196ba2d514a13f6af1b3d78de71ce74ed2fc8bdc
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:19 2015 +0530

    powerpc/powernv: Add definition of OPAL_MSG_OCC message type
    
    Add OPAL_MSG_OCC message definition to opal_message_type to receive
    OCC events like reset, load and throttled. Host performance can be
    affected when OCC is reset or OCC throttles the max Pstate.
    We can register to opal_message_notifier to receive OPAL_MSG_OCC type
    of message and report it to the userspace so as to keep the user
    informed about the reason for a performance drop in workloads.
    
    The reset and load OCC events are notified to kernel when FSP sends
    OCC_RESET and OCC_LOAD commands.  Both reset and load messages are
    sent to kernel on successful completion of reset and load operation
    respectively.
    
    The throttle OCC event indicates that the Pmax of the chip is reduced.
    The chip_id and throttle reason for reducing Pmax is also queued along
    with the message.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 053819e0bf8407746cc5febf7a4947bee50377b4
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:18 2015 +0530

    cpufreq: powernv: Handle throttling due to Pmax capping at chip level
    
    The On-Chip-Controller(OCC) can throttle cpu frequency by reducing the
    max allowed frequency for that chip if the chip exceeds its power or
    temperature limits. As Pmax capping is a chip level condition report
    this throttling behavior at chip level and also do not set the global
    'throttled' on Pmax capping instead set the per-chip throttled
    variable. Report unthrottling if Pmax is restored after throttling.
    
    This patch adds a structure to store chip id and throttled state of
    the chip.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Reviewed-by: Preeti U Murthy <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit a34e63b14486e98cf78c99bf8ef141de7508dbc2
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:50 2015 +0200

    cpufreq: Pass CPU number to cpufreq_policy_alloc()
    
    Change cpufreq_policy_alloc() to take a CPU number instead of a CPU
    device pointer as its argument, as it is the only function called by
    cpufreq_add_dev() taking a device pointer argument at this point.
    
    That will allow us to split the CPU online part from cpufreq_add_dev()
    more cleanly going forward.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit 4d1f3a5bcb489cc6f7cbc128e0c292fed7868d32
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:44 2015 +0200

    cpufreq: Do not update related_cpus on every policy activation
    
    The related_cpus mask includes CPUs whose cpufreq_cpu_data per-CPU
    pointers have been set the the given policy.  Since those pointers
    are only set at the policy creation time and unset when the policy
    is deleted, the related_cpus should not be updated between those
    two operations.
    
    For this reason, avoid updating it whenever the first of the
    "related" CPUs goes online.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit d9612a495b0bc93f5db0e0033fe4ee7abb7167c7
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:37 2015 +0200

    cpufreq: Drop unused dev argument from two functions
    
    The dev argument of cpufreq_add_policy_cpu() and
    cpufreq_add_dev_interface() is not used by any of them,
    so drop it.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit d4d854d6c7706e6a5cda297e350e3626d55e9bc9
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:30 2015 +0200

    cpufreq: Drop unnecessary label from cpufreq_add_dev()
    
    The leftover out_release_rwsem label in cpufreq_add_dev() is not
    necessary any more and confusing, so drop it.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit 11ce707e6c2aea05e1f54680fb89a8a44ded5db4
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:21 2015 +0200

    cpufreq: Drop cpufreq_policy_restore()
    
    Notice that when cpufreq_policy_restore() is called, its per-CPU
    cpufreq_cpu_data variable has been already dereferenced and if that
    variable is not NULL, the policy local pointer in cpufreq_add_dev()
    contains its value.
    
    Therefore it is not necessary to dereference it again and the
    policy pointer can be used directly.  Moreover, if that pointer
    is not NULL, the policy is inactive (or the previous check would
    have made us return from cpufreq_add_dev()) so the restoration
    code from cpufreq_policy_restore() can be moved to that point
    in cpufreq_add_dev().
    
    Do that and drop cpufreq_policy_restore().
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit 15c0b4d222f83672407419f9c9e167e996d8ad2b
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:09 2015 +0200

    cpufreq: Rework two functions related to CPU offline
    
    Since __cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
    are about CPU offline rather than about CPU removal, rename them to
    cpufreq_offline_prepare() and cpufreq_offline_finish(), respectively.
    
    Also change their argument from a struct device pointer to a CPU
    number, because they use the CPU number only internally anyway
    and make them void as their return values are ignored.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit ede76209c1f166af8a6b8fb2c5e0f2fc0e2e317b
Author: Rob Clark <[email protected]>
Date:   Tue Jul 28 11:05:03 2015 -0400

    drm/msm: don't install plane properties on crtc
    
    This was a hold-over from the pre-atomic days and legacy userspace that
    only understood CRTCs.  Fortunately we don't have any properties, so
    this doesn't change anything.  But before we start growing some plane
    properties, we should fix this.
    
    Signed-off-by: Rob Clark <[email protected]>

commit 559ed40752dc63e68f9b9ad301b20e6a3fe5cf21
Author: Rafael J. Wysocki <[email protected]>
Date:   Sun Jul 26 02:07:47 2015 +0200

    cpufreq: Avoid attempts to create duplicate symbolic links
    
    After commit 87549141d516 (cpufreq: Stop migrating sysfs files on
    hotplug) there is a problem with CPUs that share cpufreq policy
    objects with other CPUs and are initially offline.
    
    Say CPU1 shares a policy with CPU0 which is online and is registered
    first.  As part of the registration process, cpufreq_add_dev() is
    called for it.  It creates the policy object and a symbolic link
    to it from the CPU1's sysfs directory.  If CPU1 is registered
    subsequently and it is offline at that time, cpufreq_add_dev() will
    attempt to create a symbolic link to the policy object for it, but
    that link is present already, so a warning about that will be
    triggered.
    
    To avoid that warning, make cpufreq use an additional CPU mask
    containing related CPUs that are actually present for each policy
    object.  That mask is initialized when the policy object is populated
    after its creation (for the first online CPU using it) and it includes
    CPUs from the "policy CPUs" mask returned by the cpufreq driver's
    ->init() callback that are physically present at that time.  Symbolic
    links to the policy are created only for the CPUs in that mask.
    
    If cpufreq_add_dev() is invoked for an offline CPU, it checks the
    new mask and only creates the symlink if the CPU was not in it (the
    CPU is added to the mask at the same time).
    
    In turn, cpufreq_remove_dev() drops the given CPU from the new mask,
    removes its symlink to the policy object and returns, unless it is
    the CPU owning the policy object.  In that case, the policy object
    is moved to a new CPU's sysfs directory or deleted if the CPU being
    removed was the last user of the policy.
    
    While at it, notice that cpufreq_remove_dev() can't fail, because
    its return value is ignored, so make it ignore return values from
    __cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
    and prevent these functions from aborting on errors returned by
    __cpufreq_governor().  Also drop the now unused sif argument from
    them.
    
    Fixes: 87549141d516 (cpufreq: Stop migrating sysfs files on hotplug)
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reported-and-tested-by: Russell King <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit 766ffb69803943c2b580a44ac14a189b875d21f6
Author: Will Deacon <[email protected]>
Date:   Tue Jul 28 16:14:03 2015 +0100

    arm64: pgtable: fix definition of pte_valid
    
    pte_valid should check if the PTE_VALID bit (1 << 0) is set in the pte,
    so fix the macro definition to use bitwise & instead of logical &&.
    
    Signed-off-by: Will Deacon <[email protected]>

commit 5dbaf90a6780b2989515212cb2584b7771cecad1
Author: David Woodhouse <[email protected]>
Date:   Tue Mar 24 14:54:56 2015 +0000

    iommu/vt-d: Add initial shell of SVM support
    
    Add CONFIG_INTEL_IOMMU_SVM, and allocate PASID tables.
    
    Signed-off-by: David Woodhouse <[email protected]>

commit 15bbdec3931e617231c12b0920e497e87ec8c2c6
Author: Sakari Ailus <[email protected]>
Date:   Mon Jul 13 14:31:30 2015 +0300

    iommu: Make the iova library a module
    
    The iova library has use outside the intel-iommu driver, thus make it a
    module.
    
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: David Woodhouse <[email protected]>

commit 9b41760b03816b34f4c9eee2cbb8fda8439920fc
Author: Sakari Ailus <[email protected]>
Date:   Mon Jul 13 14:31:29 2015 +0300

    iommu: iova: Export symbols
    
    Use EXPORT_SYMBOL_GPL() to export the iova library symbols. The symbols
    include:
    
    	init_iova_domain();
    	iova_cache_get();
    	iova_cache_put();
    	iova_cache_init();
    	alloc_iova();
    	find_iova();
    	__free_iova();
    	free_iova();
    	put_iova_domain();
    	reserve_iova();
    	copy_reserved_iova();
    
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: David Woodhouse <[email protected]>

commit ae1ff3d623905947158fd3394854c23026337810
Author: Sakari Ailus <[email protected]>
Date:   Mon Jul 13 14:31:28 2015 +0300

    iommu: iova: Move iova cache management to the iova library
    
    This is necessary to separate intel-iommu from the iova library.
    
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: David Woodhouse <[email protected]>

commit 8f6429c7cb59f28433253575cc8e3262eed63592
Author: Robin Murphy <[email protected]>
Date:   Thu Jul 16 19:40:12 2015 +0100

    iommu/iova: Avoid over-allocating when size-aligned
    
    Currently, allocating a size-aligned IOVA region quietly adjusts the
    actual allocation size in the process, returning a rounded-up
    power-of-two-sized allocation. This results in mismatched behaviour in
    the IOMMU driver if the original size was not a power of two, where the
    original size is mapped, but the rounded-up IOVA size is unmapped.
    
    Whilst some IOMMUs will happily unmap already-unmapped pages, others
    consider this an error, so fix it by computing the necessary alignment
    padding without altering the actual allocation size. Also clean up by
    making pad_size unsigned, since its callers always pass unsigned values
    and negative padding makes little sense here anyway.
    
    Signed-off-by: Robin Murphy <[email protected]>
    Signed-off-by: David Woodhouse <[email protected]>

commit d169ba3e093c0932f466ba68314555317e072def
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:13:03 2015 +0530

    drm/msm: dsi host: add missing of_node_put()
    
    Decrement device node refcount if of_get_child_by_name is successfully
    called.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 71b65445f0ed04c2afe3660f829779fddb2890c1
Author: Mika Westerberg <[email protected]>
Date:   Tue Jul 28 13:51:21 2015 +0300

    ACPI / PM: Use target_state to set the device power state
    
    Commit 20dacb71ad28 ("ACPI / PM: Rework device power management to follow
    ACPI 6") changed the device power management to use D3ho…
aejsmith pushed a commit to aejsmith/linux that referenced this pull request Aug 6, 2015
@ZubairLK
Merge pull request torvalds#62 from aejsmith/ci20-v3.18-tcu-fix
4da6a16 
clocksource: jz47xx-tcu: Mark functions used by sched_clock() as notrace
ddstreet referenced this pull request in ddstreet/linux Aug 6, 2015
@hnaz
linux-next
a7d83ca 
GIT 32f494c98c21b03a78c2305cde6ae1b421db576e

commit 32f494c98c21b03a78c2305cde6ae1b421db576e
Author: Stephen Rothwell <[email protected]>
Date:   Wed Aug 5 16:41:48 2015 +1000

    crypto: authenc - select CRYPTO_NULL
    
    Signed-off-by: Stephen Rothwell <[email protected]>

commit aa7c043d9783f538319e77deeae5d90ff5d6907b
Author: Richard Guy Briggs <[email protected]>
Date:   Sat Aug 1 15:41:13 2015 -0400

    audit: eliminate unnecessary extra layer of watch parent references
    
    The audit watch parent count was imbalanced, adding an unnecessary layer of
    watch parent references.  Decrement the additional parent reference when a
    watch is reused, already having a reference to the parent.
    
    audit_find_parent() gets a reference to the parent, if the parent is
    already known.  This additional parental reference is not needed if the
    watch is subsequently found by audit_add_to_parent(), and consumed if
    the watch does not already exist, so we need to put the parent if the
    watch is found, and do nothing if this new watch is added to the parent.
    
    If the parent wasn't already known, it is created with a refcount of 1
    and added to the audit_watch_group, then incremented by one to be
    subsequently consumed by the newly created watch in
    audit_add_to_parent().
    
    The rule points to the watch, not to the parent, so the rule's refcount
    gets bumped, not the parent's.
    
    See LKML, 2015-07-16
    
    Signed-off-by: Richard Guy Briggs <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>

commit f8259b262bedd5ec71e55de5953464ea86ff69d9
Author: Richard Guy Briggs <[email protected]>
Date:   Sat Aug 1 15:41:12 2015 -0400

    audit: eliminate unnecessary extra layer of watch references
    
    The audit watch count was imbalanced, adding an unnecessary layer of watch
    references.  Only add the second reference when it is added to a parent.
    
    Signed-off-by: Richard Guy Briggs <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>

commit 6abc8ca19df0078de17dc38340db3002ed489ce7
Author: Tejun Heo <[email protected]>
Date:   Tue Aug 4 15:20:55 2015 -0400

    cgroup: define controller file conventions
    
    Traditionally, each cgroup controller implemented whatever interface
    it wanted leading to interfaces which are widely inconsistent.
    Examining the requirements of the controllers readily yield that there
    are only a few control schemes shared among all.
    
    Two major controllers already had to implement new interface for the
    unified hierarchy due to significant structural changes.  Let's take
    the chance to establish common conventions throughout all controllers.
    
    This patch defines CGROUP_WEIGHT_MIN/DFL/MAX to be used on all weight
    based control knobs and documents the conventions that controllers
    should follow on the unified hierarchy.  Except for io.weight knob,
    all existing unified hierarchy knobs are already compliant.  A
    follow-up patch will update io.weight.
    
    v2: Added descriptions of min, low and high knobs.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Acked-by: Johannes Weiner <[email protected]>
    Cc: Li Zefan <[email protected]>
    Cc: Peter Zijlstra <[email protected]>

commit 1dadafa86a779884f14a6e7a3ddde1a57b0a0a65
Author: Tim Gardner <[email protected]>
Date:   Tue Aug 4 11:26:04 2015 -0600

    workqueue: Make flush_workqueue() available again to non GPL modules
    
    Commit 37b1ef31a568fc02e53587620226e5f3c66454c8 ("workqueue: move
    flush_scheduled_work() to workqueue.h") moved the exported non GPL
    flush_scheduled_work() from a function to an inline wrapper.
    Unfortunately, it directly calls flush_workqueue() which is a GPL function.
    This has the effect of changing the licensing requirement for this function
    and makes it unavailable to non GPL modules.
    
    See commit ad7b1f841f8a54c6d61ff181451f55b68175e15a ("workqueue: Make
    schedule_work() available again to non GPL modules") for precedent.
    
    Signed-off-by: Tim Gardner <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit b03ba9e314c12b2127243145b5c1f41b2408de62
Author: Sifan Naeem <[email protected]>
Date:   Wed Jul 29 11:55:26 2015 +0100

    spi: img-spfi: fix multiple calls to request gpio
    
    spfi_setup may be called many times by the spi framework, but
    gpio_request_one can only be called once without freeing, repeatedly
    calling gpio_request_one will cause an error to be thrown, which
    causes the request to spi_setup to be marked as failed.
    
    We can have a per-spi_device flag that indicates whether or not the
    gpio has been requested. If the gpio has already been requested use
    gpio_direction_output to set the direction of the gpio.
    
    Fixes: 8c2c8c03cdcb ("spi: img-spfi: Control CS lines with GPIO")
    Signed-off-by: Sifan Naeem <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Cc: [email protected]

commit d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec
Author: Ian Campbell <[email protected]>
Date:   Sat Aug 1 18:13:25 2015 +0100

    regulator: axp20x: Add module alias
    
    This allows the module to be autoloaded.
    
    Together with 07949bf9c63c ("cpufreq: dt: allow driver to boot
    automatically") this is sufficient to allow a modular kernel (such
    as Debian's) to enable cpufreq on a Cubietruck.
    
    Signed-off-by: Ian Campbell <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 5dbe135a153837ce9367bdfacf7aabfc6fb76f4b
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:51 2015 +0200

    usb: gadget: epautoconf: remove ep and desc configuration from ep_matches()
    
    As function ep_matches() is used to match endpoint with usb descriptor it's
    highly unintuitive that it modifies endpoint and descriptor structures fields.
    This patch moves code configuring ep and desc from ep_matches() to
    usb_ep_autoconfig_ss(), so now function ep_matches() does nothing more than
    its name suggests.
    
    [ [email protected] : fix build warning ]
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit b58713d53a8f41d57b24c93de0b1c7e9550ba70f
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:50 2015 +0200

    usb: gadget: epautoconf: remove pxa quirk from ep_matches()
    
    The same effect can be achieved by using capabilities flags, so now we can
    get rid of handling of hardware specific limitations in generic code.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit b86f33a3a371a4c3aa8dbb2f4125634a4e0d09dc
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:49 2015 +0200

    usb: gadget: epautoconf: add endpoint capabilities flags verification
    
    Introduce endpoint matching mechanism basing on endpoint capabilities
    flags. We check if endpoint supports transfer type and direction requested
    in ep descriptor. Since we have this new endpoint matching mechanism
    there is no need to have old code guessing endpoint capabilities basing
    on its name, so we are getting rid of it. Remove also the obsolete comment.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 47bef386511517449e2f24a89a41084af53616f8
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:48 2015 +0200

    usb: gadget: atmel_usba_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 916f7ac5dbc312969a90bc35a5f4fcbfc2965d60
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:47 2015 +0200

    usb: renesas: gadget: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 8501955e888662ca56775eec2eb804e7bc7fce0d
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:46 2015 +0200

    usb: musb: gadget: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit eb4cbc19526d62657b838d6f0b694a000e5b4c81
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:45 2015 +0200

    usb: isp1760: udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 927d9f77fe3d5f9261eeb465e2b60768e400ffc9
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:44 2015 +0200

    usb: gadget: udc-xilinx: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 0648772d51c0ff3949397cb0cbcf2435ee32c550
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:43 2015 +0200

    usb: gadget: s3c2410_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit bc1b9f300ae06c64fcd056fb959b3d709ad2ef33
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:42 2015 +0200

    usb: gadget: s3c-hsudc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 0ec8026d7afee625f52631708d84435ea4735da6
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:41 2015 +0200

    usb: gadget: r8a66597-udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit a180e3da97a323510071b2b5e42b5dc07df239da
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:40 2015 +0200

    usb: gadget: pxa27x_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 36411b6b042d350a43fe1e0d3ce78fbda30f4f02
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:39 2015 +0200

    usb: gadget: pxa25x_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 85a4ed003b39f70ba478e613a9be2c334f1079e7
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:38 2015 +0200

    usb: gadget: pch_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 7d4ba80d3a91222de577b652a8936f935de8b409
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:37 2015 +0200

    usb: gadget: omap_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit c23c3c3c3059f3dc47268cd7a28b96b9efdbc1ea
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:36 2015 +0200

    usb: gadget: net2280: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit f95aec51da16250841a4254db36f9771446cdbb6
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:35 2015 +0200

    usb: gadget: net2272: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 43710a8dba9ae607decdeaf7a56a51dd5b42184e
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:34 2015 +0200

    usb: gadget: mv_udc_core: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit c12a30629f8b5fe8c2aba42c3128df702bbc9e83
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:33 2015 +0200

    usb: gadget: mv_u3d_core: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 8ddbf94fd5b536b3adf5ffa631c5951718e7301d
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:32 2015 +0200

    usb: gadget: m66592-udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 4d75c8bd613c5ba99ee02cfe38610c82e7fe8362
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:31 2015 +0200

    usb: gadget: lpc32xx_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 892269925991b449ae47dcc0debb324ae451022e
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:30 2015 +0200

    usb: gadget: gr_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit b0bf5fbfbd30ffbb9e45169f78412f0596e16412
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:29 2015 +0200

    usb: gadget: goku_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 455d11c93582c4167f55af0969b83821450be120
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:28 2015 +0200

    usb: gadget: fusb300_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 60a28c63712f190b45e9d8f0ca593c927970fd51
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:27 2015 +0200

    usb: gadget: fsl_udc_core: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit e8fc42f6a19af320d7a4718c05c3f249bf5d3151
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:26 2015 +0200

    usb: gadget: fsl_qe_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 8d29237a436dc8e2b5c44dd0ca662a680f16deb5
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:25 2015 +0200

    usb: gadget: fotg210-udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 7a3b8e7098946b44c014f3df0ceef27fb273c142
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:24 2015 +0200

    usb: gadget: dummy-hcd: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit b079dd6156a6544e0383642a9ec97d17485aa244
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:23 2015 +0200

    usb: gadget: bdc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 1b0ba527702268992a62227dde4911477f057ca5
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:22 2015 +0200

    usb: gadget: bcm63xx_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit b9ed96d7d579416a8fd2e1cef66541bfdad2720f
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:21 2015 +0200

    usb: gadget: at91_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 6f02ac5ac9bba538593e4359dd5e83c4d42822fe
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:20 2015 +0200

    usb: gadget: amd5536udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit a474d3b73ba7f22844e672ac004f01cd9b8be159
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:19 2015 +0200

    usb: dwc3: gadget: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 2954522f135246287c36524bc96e9dae8c40f8a9
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:18 2015 +0200

    usb: dwc2: gadget: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit a7e3f1410855db6b67ec29a386e74be2df3cc311
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:17 2015 +0200

    usb: chipidea: udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 68b5c947515a252b9e416e419fca4c1382912948
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:16 2015 +0200

    staging: emxx_udc: add ep capabilities support
    
    Convert endpoint configuration to new capabilities model.
    
    Fixed typo in "epc-nulk" to "epc-bulk".
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 80e6e3847f851fc05e63265050115e29e2a50d7e
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:15 2015 +0200

    usb: gadget: add endpoint capabilities helper macros
    
    Add macros useful while initializing array of endpoint capabilities
    structures. These macros makes structure initialization more compact
    to decrease number of code lines and increase readability of code.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 734b5a2addd333829a6d647ee14a3609c7a87c44
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:14 2015 +0200

    usb: gadget: add endpoint capabilities flags
    
    Introduce struct usb_ep_caps which contains information about capabilities
    of usb endpoints - supported transfer types and directions. This structure
    should be filled by UDC driver for each of its endpoints, and will be
    used in epautoconf in new ep matching mechanism which will replace ugly
    guessing of endpoint capabilities basing on its name.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit cc476b42a39d5a66d94f46cade972dcb8ee278df
Author: Robert Baldyga <[email protected]>
Date:   Fri Jul 31 16:00:13 2015 +0200

    usb: gadget: encapsulate endpoint claiming mechanism
    
    So far it was necessary for usb functions to set ep->driver_data in
    endpoint obtained from autoconfig to non-null value, to indicate that
    endpoint is claimed by function (in autoconfig it was checked if endpoint
    has set this field to non-null value, and if it has, it was assumed that
    it is claimed). It could cause bugs because if some function doesn't
    set this field autoconfig could return the same endpoint more than one
    time.
    
    To help to avoid such bugs this patch adds claimed flag to struct usb_ep,
    and  encapsulates endpoint claiming mechanism inside usb_ep_autoconfig_ss()
    and usb_ep_autoconfig_reset(), so now usb functions don't need to perform
    any additional actions to mark endpoint obtained from autoconfig as claimed.
    
    Signed-off-by: Robert Baldyga <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 94e5c23d3c52f58f4051810a15aeacc085127ad1
Author: Axel Lin <[email protected]>
Date:   Tue Aug 4 13:52:22 2015 +0800

    spi: pxa2xx: Add terminating entry for pxa2xx_spi_pci_compound_match
    
    Signed-off-by: Axel Lin <[email protected]>
    Acked-by: Jarkko Nikula <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 89a6356676eba38e498507b5b67dcc07a714a149
Author: Colin Ian King <[email protected]>
Date:   Fri Jul 31 13:42:29 2015 +0100

    spi: spidev: fix inconsistent indenting
    
    Fix inconsistent indenting in spidev_open, no functional change.
    
    Signed-off-by: Colin Ian King <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 0f4315a8f1a73f130bbc5dde134b704ea6dda56c
Author: Felipe Balbi <[email protected]>
Date:   Tue Aug 4 11:02:45 2015 -0500

    usb: gadget: f_uac2: fix build warning
    
    commit 913e4a90b6f9 ("usb: gadget: f_uac2:
    finalize wMaxPacketSize according to bandwidth")
    added a possible build warning when calling
    min(). In order to fix the warning, we just
    make sure to call min_t() and tell that its
    arguments should be u16.
    
    Cc: Peter Chen <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 7f352964852ede9e95d18fd3825c5200fb48b3a5
Author: Saurabh Karajgaonkar <[email protected]>
Date:   Tue Aug 4 14:02:28 2015 +0000

    usb: musb: musb_dsps: Simplify return statement
    
    Replace redundant variable use in return statement.
    
    Signed-off-by: Saurabh Karajgaonkar <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit c5673f5ce4c0faa97df419877bcdebbd76d43151
Author: Saurabh Karajgaonkar <[email protected]>
Date:   Tue Aug 4 14:02:03 2015 +0000

    usb: phy: phy-keystone: Simplify return statement
    
    Replace redundant variable use in return statement.
    
    Signed-off-by: Saurabh Karajgaonkar <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 4b68b50fd45e2f429da574c74d9a3788a861434f
Author: Saurabh Karajgaonkar <[email protected]>
Date:   Tue Aug 4 14:01:31 2015 +0000

    usb: phy: phy-mxs-usb: Simplify return statement
    
    Replace redundant variable use in return statement.
    
    Signed-off-by: Saurabh Karajgaonkar <[email protected]>
    Signed-off-by: Felipe Balbi <[email protected]>

commit 5406898354ebfb11f49b955fb5e49a62786a542f
Author: Mengdong Lin <[email protected]>
Date:   Tue Aug 4 15:47:35 2015 +0100

    ASoC: topology: fix typo in soc_tplg_kcontrol_bind_io()
    
    Signed-off-by: Mengdong Lin <[email protected]>
    Signed-off-by: Liam Girdwood <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 6d3ec14d703c660c4baf8d726538b5415e23b4fb
Author: Lukas Czerner <[email protected]>
Date:   Tue Aug 4 11:21:52 2015 -0400

    jbd2: limit number of reserved credits
    
    Currently there is no limitation on number of reserved credits we can
    ask for. If we ask for more reserved credits than 1/2 of maximum
    transaction size, or if total number of credits exceeds the maximum
    transaction size per operation (which is currently only possible with
    the former) we will spin forever in start_this_handle().
    
    Fix this by adding this limitation at the start of start_this_handle().
    
    This patch also removes the credit limitation 1/2 of maximum transaction
    size, since we really only want to limit the number of reserved credits.
    There is not much point to limit the credits if there is still space in
    the journal.
    
    This accidentally also fixes the online resize, where due to the
    limitation of the journal credits we're unable to grow file systems with
    1k block size and size between 16M and 32M. It has been partially fixed
    by 2c869b262a10ca99cb866d04087d75311587a30c, but not entirely.
    
    Thanks Jan Kara for helping me getting the correct fix.
    
    Signed-off-by: Lukas Czerner <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>

commit 21caf3a765b0a88f8fedf63b36e5d15683b73fe5
Author: Lorenzo Nava <[email protected]>
Date:   Thu Jul 2 17:28:03 2015 +0100

    ARM: 8398/1: arm DMA: Fix allocation from CMA for coherent DMA
    
    This patch allows the use of CMA for DMA coherent memory allocation.
    At the moment if the input parameter "is_coherent" is set to true
    the allocation is not made using the CMA, which I think is not the
    desired behaviour.
    The patch covers the allocation and free of memory for coherent
    DMA.
    
    Signed-off-by: Lorenzo Nava <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Signed-off-by: Russell King <[email protected]>

commit c0e736629b89ec176ab4dba45943364cbdc135ba
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 15:22:11 2015 +0200

    drm/fb-helper: Move drm_fb_helper_force_kernel_mode() inside #ifdef
    
    If CONFIG_MAGIC_SYSRQ is not set:
    
        drivers/gpu/drm/drm_fb_helper.c:390:13: warning: 'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
         static bool drm_fb_helper_force_kernel_mode(void)
    		 ^
    
    Move drm_fb_helper_force_kernel_mode() inside the existing #ifdef to fix
    this.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit b996f201b74e52f9e9da47e1377e0b948d5ba25c
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 15:22:10 2015 +0200

    drm/fb-helper: Clarify drm_fb_helper_restore_fbdev_mode*()
    
    As of commit 5ea1f752ae04be40 ("drm: add
    drm_fb_helper_restore_fbdev_mode_unlocked()"),
    drm_fb_helper_restore_fbdev_mode() is no longer public, and drivers
    should call drm_fb_helper_restore_fbdev_mode_unlocked() from their
    ->lastclose callbacks instead.
    
    Update the documentation to reflect this, and absorb the one liner
    drm_fb_helper_restore_fbdev_mode() into its single caller.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 714dc94e0d22ef951722f5d6ec316f4a7867f850
Author: Jiri Kosina <[email protected]>
Date:   Tue Aug 4 15:46:10 2015 +0200

    Revert "HID: core/input: Fix accessing freed memory during driver unbind"
    
    This reverts commit e19232a20913513fbb4b21ac8f45a4b9a805d6e4.
    
    It's broken and is going to be replaced with the one from
    for-4.2/upstream-fixes-devm-fixed branch.
    
    This is for-next branch only revert, both the original commit and the
    revert will never make it to Linus (instead a fixed version will be
    sent directly).

commit 0621809e37936e7c2b3eac9165cf2aad7f9189eb
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Aug 3 14:57:30 2015 +0900

    HID: hid-input: Fix accessing freed memory during device disconnect
    
    During unbinding the driver was dereferencing a pointer to memory
    already freed by power_supply_unregister().
    
    Driver was freeing its internal description of battery through pointers
    stored in power_supply structure. However, because the core owns the
    power supply instance, after calling power_supply_unregister() this
    memory is freed and the driver cannot access these members.
    
    Fix this by storing the pointer to internal description of battery in a
    local variable before calling power_supply_unregister(), so the pointer
    remains valid.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reported-by: H.J. Lu <[email protected]>
    Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
    Cc: <[email protected]>
    Reviewed-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>

commit 3f14a63a544374225c17221a5058748360428dc3
Author: Jason Gerecke <[email protected]>
Date:   Mon Aug 3 10:17:05 2015 -0700

    HID: wacom: Remove WACOM_QUIRK_NO_INPUT
    
    WACOM_QUIRK_NO_INPUT is a signal to the driver that input devices
    should not be created for a particular device. This quirk was used by
    the wireless receiver to prevent any devices from being created during
    the initial probe (defering it instead until we got a tablet connection
    event in 'wacom_wireless_work').
    
    This quirk is not necessary now that a device_type is associated with each
    device. Any input device allocated by 'wacom_allocate_inputs' which is
    not necessary for a particular device is freed in 'wacom_register_inputs'.
    In particular, none of the wireless receivers devices have the pen, pad,
    or touch device types set so the same effect is achieved without the need
    to be explicit.
    
    We now return early in wacom_retrieve_hid_descriptor for wireless devices
    (to prevent the device_type from being overridden) but since we ignore the
    HID descriptor for the wireless reciever anyway, this is not an issue.
    
    Signed-off-by: Jason Gerecke <[email protected]>
    Reviewed-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>

commit ccad85cc1ee34509840e5af80a436ceaf0b71edb
Author: Jason Gerecke <[email protected]>
Date:   Mon Aug 3 10:17:04 2015 -0700

    HID: wacom: Replace WACOM_QUIRK_MONITOR with WACOM_DEVICETYPE_WL_MONITOR
    
    The monitor interface on the wireless receiver is more logically expressed
    as a type of device instead of a quirk.
    
    Signed-off-by: Jason Gerecke <[email protected]>
    Reviewed-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>

commit 8dc8641e619228153ab0bc609f9f534126e87c08
Author: Jason Gerecke <[email protected]>
Date:   Mon Aug 3 10:17:03 2015 -0700

    HID: wacom: Use calculated pkglen for wireless touch interface
    
    Commit 01c846f introduced the 'wacom_compute_pktlen' function which
    automatically determines the correct value for an interface's pkglen
    by scanning the HID descriptor. This function returns the correct
    value for the wireless receiver's touch interface, removing the need
    for us to set it manually here.
    
    Signed-off-by: Jason Gerecke <[email protected]>
    Reviewed-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>

commit 061357a06c69dfa805a033ae22d668de16191cd4
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:17 2015 +0200

    ARM: shmobile: R-Mobile: Use CPG/MSTP Clock Domain attach/detach helpers
    
    The R-Mobile PM Domain driver manages both power domains and a clock
    domain.
    
    The clock domain part is very similar to the CPG/MSTP Clock Domain,
    which is used on shmobile SoCs without device power domains, except for
    the way how clocks suitable for power management are selected:
      - The former uses the first clock tied to the device through the NULL
        con_id, which is a relic from the legacy pm_clk_notifier-based
        method in drivers/sh/pm_runtime.c,
      - The latter looks for suitable clocks in DT, which is more
        future-proof.
    
    All platforms using this driver are now supported in DT-based ARM
    multi-platform builds only, hence switch to using the CPG/MSTP Clock
    Domain helpers.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit a1a1fdd83722a30efc705a5032ace2ad20b2ca6d
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 15:25:35 2015 +0200

    clk: shmobile: mstp: Consider "zb_clk" suitable for power management
    
    Currently the CPG/MSTP Clock Domain code looks for MSTP clocks to power
    manage a device.
    
    Unfortunately, on R-Mobile APE6 (r8a73a4) and SH-Mobile AG5 (sh73a0),
    the Bus State Controller (BSC) is not power-managed by an MSTP clock,
    but by a plain CPG clock (zb_clk).  Add a special case to handle this,
    so the clock is properly managed, and devices connected to the BSC work
    as expected.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit 6989c8c4cfa7f7cd406906e1abbe7b073d3d66e0
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:15 2015 +0200

    drivers: sh: Disable PM runtime for multi-platform ARM with genpd
    
    If the default PM Domain using PM_CLK is used for PM runtime, the real
    Clock Domain cannot be registered from DT later.
    
    Hence do not enable it when running a multi-platform kernel with genpd
    support on R-Car or RZ.  The CPG/MSTP Clock Domain driver will take care
    of PM runtime management of the module clocks.
    
    Now most multi-platform ARM shmobile platforms (SH-Mobile, R-Mobile,
    R-Car, RZ) use DT-based PM Domains to take care of PM runtime management
    of the module clocks, simplify the platform logic by replacing the
    explicit SoC checks by a single check for the presence of MSTP clocks in
    DT.
    
    Backwards-compatiblity with old DTs (mainly for R-Car Gen2) is provided
    by checking for the presence of a "#power-domain-cells" property in DT.
    
    The default PM Domain is still needed for:
      - backwards-compatibility with old DTs that lack PM Domain properties,
      - the CONFIG_PM=n case,
      - legacy (non-DT) ARM/shmobile platforms without genpd support
        (r8a7778, r8a7779),
      - legacy SuperH.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit d7c01f3aba883c57aacc57f884e9081d00d1dec7
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:14 2015 +0200

    drivers: sh: Disable legacy default PM Domain on emev2
    
    EMMA Mobile EV2 doesn't have MSTP clocks. All its device drivers manage
    clocks explicitly, without relying on Runtime PM, so it doesn't need the
    legacy default PM Domain.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit ba56d432e1dc98aa5df5930a0707d79e40fd5e39
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:13 2015 +0200

    ARM: shmobile: r8a7794 dtsi: Add CPG/MSTP Clock Domain
    
    Add an appropriate "#power-domain-cells" property to the cpg_clocks
    device node, to create the CPG/MSTP Clock Domain.
    
    Add "power-domains" properties to all device nodes for devices that are
    part of the CPG/MSTP Clock Domain and can be power-managed through an
    MSTP clock.  This applies to most on-SoC devices, which have a
    one-to-one mapping from SoC device to DT device node.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit 23a7abb77197044b6e708e0d0d31d89bf1e68bf1
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:12 2015 +0200

    ARM: shmobile: r8a7793 dtsi: Add CPG/MSTP Clock Domain
    
    Add an appropriate "#power-domain-cells" property to the cpg_clocks
    device node, to create the CPG/MSTP Clock Domain.
    
    Add "power-domains" properties to all device nodes for devices that are
    part of the CPG/MSTP Clock Domain and can be power-managed through an
    MSTP clock.  This applies to most on-SoC devices, which have a
    one-to-one mapping from SoC device to DT device node.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit a5ab8bf59f7ec14081e161bad52430e37def1189
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:11 2015 +0200

    ARM: shmobile: r8a7791 dtsi: Add CPG/MSTP Clock Domain
    
    Add an appropriate "#power-domain-cells" property to the cpg_clocks
    device node, to create the CPG/MSTP Clock Domain.
    
    Add "power-domains" properties to all device nodes for devices that are
    part of the CPG/MSTP Clock Domain and can be power-managed through an
    MSTP clock.  This applies to most on-SoC devices, which have a
    one-to-one mapping from SoC device to DT device node.  Notable
    exceptions are the "display" and "sound" nodes, which represent multiple
    SoC devices, each having their own MSTP clocks.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit 835a058492b1d539e891af12ce37713b1fb327e9
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:10 2015 +0200

    ARM: shmobile: r8a7790 dtsi: Add CPG/MSTP Clock Domain
    
    Add an appropriate "#power-domain-cells" property to the cpg_clocks
    device node, to create the CPG/MSTP Clock Domain.
    
    Add "power-domains" properties to all device nodes for devices that are
    part of the CPG/MSTP Clock Domain and can be power-managed through an
    MSTP clock.  This applies to most on-SoC devices, which have a
    one-to-one mapping from SoC device to DT device node.  Notable
    exceptions are the "display" and "sound" nodes, which represent multiple
    SoC devices, each having their own MSTP clocks.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit 3397481089b3ab931536b26fb65ef4a41eefdb67
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:09 2015 +0200

    ARM: shmobile: r8a7779 dtsi: Add CPG/MSTP Clock Domain
    
    Add an appropriate "#power-domain-cells" property to the cpg_clocks
    device node, to create the CPG/MSTP Clock Domain.
    
    Add "power-domains" properties to all device nodes for devices that are
    part of the CPG/MSTP Clock Domain and can be power-managed through an
    MSTP clock.  This applies to most on-SoC devices, which have a
    one-to-one mapping from SoC device to DT device node.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit 6d3bba42aef6eb7594b845518a51d5aa094d3502
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:08 2015 +0200

    ARM: shmobile: r8a7778 dtsi: Add CPG/MSTP Clock Domain
    
    Add an appropriate "#power-domain-cells" property to the cpg_clocks
    device node, to create the CPG/MSTP Clock Domain.
    
    Add "power-domains" properties to all device nodes for devices that are
    part of the CPG/MSTP Clock Domain and can be power-managed through an
    MSTP clock.  This applies to most on-SoC devices, which have a
    one-to-one mapping from SoC device to DT device node.  A notable
    exception is the "sound" node, which represents multiple SoC devices,
    each having their own MSTP clocks.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit d45696723575a6a7fbb43b754fb89121746b5982
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:07 2015 +0200

    ARM: shmobile: r7s72100 dtsi: Add CPG/MSTP Clock Domain
    
    Add an appropriate "#power-domain-cells" property to the cpg_clocks
    device node, to create the CPG/MSTP Clock Domain.
    
    Add "power-domains" properties to all device nodes for devices that are
    part of the CPG/MSTP Clock Domain and can be power-managed through an
    MSTP clock.  This applies to most on-SoC devices, which have a
    one-to-one mapping from SoC device to DT device node.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit 584bf98feb6c38875b76d17ed52e89711b4b5577
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:06 2015 +0200

    clk: shmobile: rz: Add CPG/MSTP Clock Domain support
    
    Add Clock Domain support to the RZ Clock Pulse Generator (CPG) driver
    using the generic PM Domain.  This allows to power-manage the module
    clocks of SoC devices that are part of the CPG/MSTP Clock Domain using
    Runtime PM, or for system suspend/resume.
    
    SoC devices that are part of the CPG/MSTP Clock Domain and can be
    power-managed through an MSTP clock should be tagged in DT with a proper
    "power-domains" property.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Stephen Boyd <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit 3602362dcc18fd46a066583fe2a13b57b3df159e
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:05 2015 +0200

    clk: shmobile: rcar-gen2: Add CPG/MSTP Clock Domain support
    
    Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG)
    driver using the generic PM Domain.  This allows to power-manage the
    module clocks of SoC devices that are part of the CPG/MSTP Clock Domain
    using Runtime PM, or for system suspend/resume.
    
    SoC devices that are part of the CPG/MSTP Clock Domain and can be
    power-managed through an MSTP clock should be tagged in DT with a proper
    "power-domains" property.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Stephen Boyd <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit 4aabed77053836418de7065a37414526099b889c
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:04 2015 +0200

    clk: shmobile: r8a7779: Add CPG/MSTP Clock Domain support
    
    Add Clock Domain support to the R-Car H1 Clock Pulse Generator (CPG)
    driver using the generic PM Domain.  This allows to power-manage the
    module clocks of SoC devices that are part of the CPG/MSTP Clock Domain
    using Runtime PM, or for system suspend/resume.
    
    SoC devices that are part of the CPG/MSTP Clock Domain and can be
    power-managed through an MSTP clock should be tagged in DT with a proper
    "power-domains" property.
    
    Also update the reg property in the DT binding doc example to match the
    actual dtsi, which uses #address-cells and #size-cells == 1, not 2.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Stephen Boyd <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit aef2b0f2dbc72f79289d74d7c1fefcd25ae11627
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:03 2015 +0200

    clk: shmobile: r8a7778: Add CPG/MSTP Clock Domain support
    
    Add Clock Domain support to the R-Car M1A Clock Pulse Generator (CPG)
    driver using the generic PM Domain.  This allows to power-manage the
    module clocks of SoC devices that are part of the CPG/MSTP Clock Domain
    using Runtime PM, or for system suspend/resume.
    
    SoC devices that are part of the CPG/MSTP Clock Domain and can be
    power-managed through an MSTP clock should be tagged in DT with a proper
    "power-domains" property.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Stephen Boyd <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit 1fcc5dc775d0d79153dda6fee1502ab96344b823
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 4 14:28:02 2015 +0200

    clk: shmobile: Add CPG/MSTP Clock Domain support
    
    Add Clock Domain support to the Clock Pulse Generator (CPG) Module Stop
    (MSTP) Clocks driver using the generic PM Domain.  This allows to
    power-manage the module clocks of SoC devices that are part of the
    CPG/MSTP Clock Domain using Runtime PM, or for system suspend/resume.
    
    SoC devices that are part of the CPG/MSTP Clock Domain and can be
    power-managed through an MSTP clock should be tagged in DT with a
    proper "power-domains" property.
    
    The CPG/MSTP Clock Domain code will scan such devices for clocks that
    are suitable for power-managing the device, by looking for a clock that
    is compatible with "renesas,cpg-mstp-clocks".
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Laurent Pinchart <[email protected]>
    Acked-by: Stephen Boyd <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Reviewed-by: Kevin Hilman <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>

commit a4198fd4b487afc60810f5a12b994721df220022
Author: Herbert Xu <[email protected]>
Date:   Thu Jul 30 17:53:23 2015 +0800

    crypto: testmgr - Reenable authenc tests
    
    Now that all implementations of authenc have been converted we can
    reenable the tests.
    
    Signed-off-by: Herbert Xu <[email protected]>

commit aeb4c132f33d21f6cf37558a932e66e40dd8982e
Author: Herbert Xu <[email protected]>
Date:   Thu Jul 30 17:53:22 2015 +0800

    crypto: talitos - Convert to new AEAD interface
    
    This patch converts talitos to the new AEAD interface.  IV generation
    has been removed since it's equivalent to a software implementation.
    
    Signed-off-by: Herbert Xu <[email protected]>

commit e19ab1211d2848ebd028c824041d8ea249fa3aae
Author: Herbert Xu <[email protected]>
Date:   Thu Jul 30 17:53:20 2015 +0800

    crypto: qat - Convert to new AEAD interface
    
    This patch converts qat to the new AEAD interface.  IV generation
    has been removed since it's equivalent to a software implementation.
    
    Signed-off-by: Herbert Xu <[email protected]>
    Tested-by: Tadeusz Struk <[email protected]>

commit c1359495c8a19fa686aa48512e0290d2f3846273
Author: Herbert Xu <[email protected]>
Date:   Thu Jul 30 17:53:19 2015 +0800

    crypto: picoxcell - Convert to new AEAD interface
    
    This patch converts picoxcell to the new AEAD interface.  IV
    generation has been removed since it's equivalent to a software
    implementation.
    
    As picoxcell cannot handle SG lists longer than 16 elements,
    this patch has made the software fallback mandatory.  If an SG
    list comes in that exceeds the limit, we will simply use the
    fallback.
    
    Signed-off-by: Herbert Xu <[email protected]>

commit d7295a8dc965ee0d5b3f9b1eb7f556c2bfa78420
Author: Herbert Xu <[email protected]>
Date:   Thu Jul 30 17:53:18 2015 +0800

    crypto: ixp4xx - Convert to new AEAD interface
    
    This patch converts ixp4xx to the new AEAD interface.  IV generation
    has been removed since it's a purely software implementation.
    
    Signed-off-by: Herbert Xu <[email protected]>

commit 479bcc7c5b9e1cbf3278462d786c37e468d5d404
Author: Herbert Xu <[email protected]>
Date:   Thu Jul 30 17:53:17 2015 +0800

    crypto: caam - Convert authenc to new AEAD interface
    
    This patch converts the authenc implementations in caam to the
    new AEAD interface.  The biggest change is that seqiv no longer
    generates a random IV.  Instead the IPsec sequence number is used
    as the IV.
    
    Signed-off-by: Herbert Xu <[email protected]>

commit 92d95ba91772279b6ef9c6e09661f67abcf27259
Author: Herbert Xu <[email protected]>
Date:   Thu Jul 30 17:53:16 2015 +0800

    crypto: authenc - Convert to new AEAD interface
    
    This patch converts authenc to the new AEAD interface.
    
    Signed-off-by: Herbert Xu <[email protected]>

commit 7079ce62c0e9bfcca35214105c08a2d00fbea9ee
Author: Herbert Xu <[email protected]>
Date:   Thu Jul 30 17:53:14 2015 +0800

    crypto: testmgr - Disable authenc test and convert test vectors
    
    This patch disables the authenc tests while the conversion to the
    new IV calling convention takes place.  It also replaces the authenc
    test vectors with ones that will work with the new IV convention.
    
    Signed-off-by: Herbert Xu <[email protected]>

commit fdf036507f1fc036d5a06753e9e8b13f46de73e8
Author: Fan Zhang <[email protected]>
Date:   Wed May 13 10:58:41 2015 +0200

    KVM: s390: host STP toleration for VMs
    
    If the host has STP enabled, the TOD of the host will be changed during
    synchronization phases. These are performed during a stop_machine() call.
    
    As the guest TOD is based on the host TOD, we have to make sure that:
    - no VCPU is in the SIE (implicitly guaranteed via stop_machine())
    - manual guest TOD calculations are not affected
    
    "Epoch" is the guest TOD clock delta to the host TOD clock. We have to
    adjust that value during the STP synchronization and make sure that code
    that accesses the epoch won't get interrupted in between (via disabling
    preemption).
    
    Signed-off-by: Fan Zhang <[email protected]>
    Reviewed-by: David Hildenbrand <[email protected]>
    Reviewed-by: Christian Borntraeger <[email protected]>
    Acked-by: Martin Schwidefsky <[email protected]>
    Signed-off-by: Christian Borntraeger <[email protected]>

commit 8578531dea9672fa17cce66d320ed7d7c17c837f
Author: Martin Schwidefsky <[email protected]>
Date:   Mon Aug 3 16:16:40 2015 +0200

    s390/vtime: limit MT scaling value updates
    
    The MT scaling values are updated on each calll to do_account_vtime.
    This function is called for each HZ interrupt and for each context
    switch. Context switch can happen often, the STCCTM instruction
    on this path is noticable. Limit the updates to once per jiffy.
    
    Signed-off-by: Martin Schwidefsky <[email protected]>

commit 5a7ff75a0c63222d138d944240146dc49a9624e1
Author: Heiko Carstens <[email protected]>
Date:   Tue Aug 4 09:15:58 2015 +0200

    s390/syscalls: ignore syscalls reachable via sys_socketcall
    
    x86 will wire up all syscalls reachable via sys_socketcall. Therefore this
    will yield a lot of warnings from the checksyscalls.sh scripts on s390
    where we currently don't wire them up directly.
    
    This might change in the future, but this needs to be done carefully in
    order to not break anything.
    
    For the time being just tell the checksyscalls script to ignore the missing
    syscalls on s390.
    
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Martin Schwidefsky <[email protected]>

commit a763bc8b656d11b7424cd2696e19efca301d8aa4
Author: Philipp Hachtmann <[email protected]>
Date:   Fri May 8 17:40:44 2015 +0200

    s390/numa: enable support in s390 configs
    
    Signed-off-by: Philipp Hachtmann <[email protected]>
    Signed-off-by: Martin Schwidefsky <[email protected]>

commit c29a7baf091fc6b2c9e40561030f8c62e6145a19
Author: Michael Holzheu <[email protected]>
Date:   Thu Mar 6 18:47:21 2014 +0100

    s390/numa: add emulation support
    
    NUMA emulation (aka fake NUMA) distributes the available memory to nodes
    without using real topology information about the physical memory of the
    machine.
    
    Splitting the system memory into nodes replicates the memory management
    structures for each node. Particularly each node has its own "mm locks"
    and its own "kswapd" task.
    
    For large systems, under certain conditions, this results in improved
    system performance and/or latency based on reduced pressure on the mm
    locks and the kswapd tasks.
    
    NUMA emulation distributes CPUs to nodes while respecting the original
    machine topology information. This is done by trying to avoid to separate
    CPUs which reside on the same book or even on the same MC. Because the
    current Linux scheduler code requires a stable cpu to node mapping, cores
    are pinned to nodes when the first CPU thread is set online.
    
    This patch is based on the initial implementation from Philipp Hachtmann.
    
    Signed-off-by: Michael Holzheu <[email protected]>
    Signed-off-by: Martin Schwidefsky <[email protected]>

commit 56113f6e6f8d57d3c184544c6421422558a9988e
Author: Joe Perches <[email protected]>
Date:   Mon Aug 3 10:49:29 2015 -0700

    ASoC: atmel_ssc_dai: Correct misuse of 0x%<decimal>
    
    Correct misuse of 0x%d in logging message.
    
    Signed-off-by: Joe Perches <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 4e491fe7920cb84dd0a2ea79800173ab1802fa22
Author: Dan Carpenter <[email protected]>
Date:   Tue Aug 4 10:47:23 2015 +0300

    extcon: Fix signedness bugs about break error handling
    
    Unsigned is never less than zero so this error handling won't work.
    
    Fixes: be052cc87745 ('extcon: Fix hang and extcon_get/set_cable_state().')
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Roger Quadros <[email protected]>
    [cw00.choi: Change the patch title and fix signedness bug of find_cable_index_by_id() ]
    Signed-off-by: Chanwoo Choi <[email protected]>

commit 76bea64c4c8d7fa911eb485c4c2b8583e813331e
Author: Aaron Sierra <[email protected]>
Date:   Mon Aug 3 18:56:21 2015 -0500

    crypto: talitos - Remove zero_entry static initializer
    
    Compiling the talitos driver with my GCC 4.3.1 e500v2 cross-compiler
    resulted in a failed build due to the anonymous union/structures
    introduced in this commit:
    
      crypto: talitos - enhanced talitos_desc struct for SEC1
    
    The build error was:
    
      drivers/crypto/talitos.h:56: error: unknown field 'len' specified in initializer
      drivers/crypto/talitos.h:56: warning: missing braces around initializer
      drivers/crypto/talitos.h:56: warning: (near initialization for 'zero_entry.<anonymous>')
      drivers/crypto/talitos.h:57: error: unknown field 'j_extent' specified in initializer
      drivers/crypto/talitos.h:58: error: unknown field 'eptr' specified in initializer
      drivers/crypto/talitos.h:58: warning: excess elements in struct initializer
      drivers/crypto/talitos.h:58: warning: (near initialization for 'zero_entry')
      make[2]: *** [drivers/crypto/talitos.o] Error 1
      make[1]: *** [drivers/crypto] Error 2
      make: *** [drivers] Error 2
    
    This patch eliminates the errors by relying on the C standard's
    implicit assignment of zero to static variables.
    
    Signed-off-by: Aaron Sierra <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit f6e45c24f401f3d0e648bfba304c83b64d763559
Author: Stephan Mueller <[email protected]>
Date:   Mon Aug 3 09:08:05 2015 +0200

    crypto: doc - AEAD API conversion
    
    The AEAD API changes are now reflected in the crypto API doc book.
    
    Signed-off-by: Stephan Mueller <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit 327cbbabfb77c321fb9f21068c18e6bb951d07a7
Author: Colin Ian King <[email protected]>
Date:   Mon Aug 3 00:05:03 2015 +0100

    crypto: img-hash - fix spelling mistake in dev_err error message
    
    Trival change, fix spelling mistake 'aquire' -> 'acquire' in
    dev_err message.
    
    Signed-off-by: Colin Ian King <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit f109ff110b0f3e34cea45996734da485a2fdaa42
Author: Hariprasad Shenai <[email protected]>
Date:   Tue Aug 4 14:36:20 2015 +0530

    cxgb4: Update T6 register ranges
    
    Signed-off-by: Hariprasad Shenai <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d86bd29e0b31f30d5d85ab21385b59703ecc6464
Author: Hariprasad Shenai <[email protected]>
Date:   Tue Aug 4 14:36:19 2015 +0530

    cxgb4/cxgb4vf: read the correct bits of PL Who Am I register
    
    Read the correct bits of PL Who Am I for the Source PF field which has
    changed in T6
    
    Signed-off-by: Hariprasad Shenai <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit bf8ebb67dae0a07db7aebe7a65c178ff24d90842
Author: Hariprasad Shenai <[email protected]>
Date:   Tue Aug 4 14:36:18 2015 +0530

    cxgb4: Add support to dump edc bist status
    
    Add support to dump edc bist status for ECC data errors
    
    Signed-off-by: Hariprasad Shenai <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 5888111cb8f7368304db42787c9495d4b2b82e06
Author: Hariprasad Shenai <[email protected]>
Date:   Tue Aug 4 14:36:17 2015 +0530

    cxgb4: Add debugfs support to dump meminfo
    
    Add debug support to dump memory address ranges of various hardware
    modules of the adapter.
    
    Signed-off-by: Hariprasad Shenai <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit c231afa3ccf176490dcafc3666559e7567690e76
Author: Christian Borntraeger <[email protected]>
Date:   Tue Aug 4 09:33:44 2015 +0200

    compiler.h: cast away attributes in WRITE_ONCE magic
    
    kernel build bot showed a warning triggered by commit
    76695af20c01 ("locking, arch: use WRITE_ONCE()/READ_ONCE() in
    smp_store_release()/smp_load_acquire()"). Turns out that sparse
    does not like WRITE_ONCE accessing elements from the (sparse)
    rcu address space.
    
    fs/afs/inode.c:448:9: sparse: incorrect type in initializer (different address spaces)
    fs/afs/inode.c:448:9:    expected struct afs_permits *__val
    fs/afs/inode.c:448:9:    got void [noderef] <asn:4>*<noident>
    
    Solution is to force cast away the sparse attributes for the initializer
    of the union in WRITE_SAME. As this now gets too long, lets split
    the macro.
    
    Signed-off-by: Christian Borntraeger <[email protected]>

commit 6b1621c4a15b9110cda7cc2e2eb3e8e1a0c2bcfc
Author: Chanwoo Choi <[email protected]>
Date:   Fri Jul 24 12:58:41 2015 +0900

    ARM: EXYNOS: Add exynos3250 compatible to use generic cpufreq driver
    
    This patch add exynos3250 compatible string to exynos_cpufreq_matches
    for supporting generic cpufreq driver on Exynos3250.
    
    Signed-off-by: Chanwoo Choi <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit d4f279f154138d252854a21d34626f1c7ca85b60
Author: Thomas Abraham <[email protected]>
Date:   Wed Jul 1 15:10:37 2015 +0200

    ARM: EXYNOS: switch to using generic cpufreq driver for exynos5250
    
    The new CPU clock type allows the use of generic CPUfreq driver.
    Switch Exynos5250 to using generic cpufreq driver.
    
    Cc: Tomasz Figa <[email protected]>
    Signed-off-by: Thomas Abraham <[email protected]>
    [b.zolnierkie: split Exynos5250 support from the original patch]
    Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Tested-by: Javier Martinez Canillas <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit a6affd24f439feddec04bab4d1e3ad6579868367
Author: Robert Shearman <[email protected]>
Date:   Mon Aug 3 17:50:04 2015 +0100

    mpls: Use definition for reserved label checks
    
    In multiple locations there are checks for whether the label in hand
    is a reserved label or not using the arbritray value of 16. Factor
    this out into a #define for better maintainability and for
    documentation.
    
    Signed-off-by: Robert Shearman <[email protected]>
    Acked-by: Roopa Prabhu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 0335f5b500adcc28bc3fd5d8a1e4482c348cff4a
Author: Robert Shearman <[email protected]>
Date:   Mon Aug 3 17:39:21 2015 +0100

    ipv4: apply lwtunnel encap for locally-generated packets
    
    lwtunnel encap is applied for forwarded packets, but not for
    locally-generated packets. This is because the output function is not
    overridden in __mkroute_output, unlike it is in __mkroute_input.
    
    The lwtunnel state is correctly set on the rth through the call to
    rt_set_nexthop, so all that needs to be done is to override the dst
    output function to be lwtunnel_output if there is lwtunnel state
    present and it requires output redirection.
    
    Signed-off-by: Robert Shearman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit abf7c1c540f8330fead5d50730d92606dcbe7a7e
Author: Robert Shearman <[email protected]>
Date:   Mon Aug 3 17:39:20 2015 +0100

    lwtunnel: set skb protocol and dev
    
    In the locally-generated packet path skb->protocol may not be set and
    this is required for the lwtunnel encap in order to get the lwtstate.
    
    This would otherwise have been set by ip_output or ip6_output so set
    skb->protocol prior to calling the lwtunnel encap
    function. Additionally set skb->dev in case it is needed further down
    the transmit path.
    
    Signed-off-by: Robert Shearman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 2475b22526d70234ecfe4a1ff88aed69badefba9
Author: Ross Lagerwall <[email protected]>
Date:   Mon Aug 3 15:38:03 2015 +0100

    xen-netback: Allocate fraglist early to avoid complex rollback
    
    Determine if a fraglist is needed in the tx path, and allocate it if
    necessary before setting up the copy and map operations.
    Otherwise, undoing the copy and map operations is tricky.
    
    This fixes a use-after-free: if allocating the fraglist failed, the copy
    and map operations that had been set up were still executed, writing
    over the data area of a freed skb.
    
    Signed-off-by: Ross Lagerwall <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 10e2eb878f3ca07ac2f05fa5ca5e6c4c9174a27a
Author: Eric Dumazet <[email protected]>
Date:   Sat Aug 1 12:14:33 2015 +0200

    udp: fix dst races with multicast early demux
    
    Multicast dst are not cached. They carry DST_NOCACHE.
    
    As mentioned in commit f8864972126899 ("ipv4: fix dst race in
    sk_dst_get()"), these dst need special care before caching them
    into a socket.
    
    Caching them is allowed only if their refcnt was not 0, ie we
    must use atomic_inc_not_ze…
diaevd referenced this pull request in diaevd/zen-kernel Dec 30, 2015
@dorimanx
Merge pull request zen-kernel#62 from wzhy90/master
63964d3 
fixes installing to wrong kernel version path
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jan 5, 2016
Revert "ASoC: Intel: Skylake: fix memory leak"
3774f57 
This reverts commit 87b5ed8 ("ASoC: Intel:
Skylake: fix memory leak") as it causes regression on Skylake devices

The SKL drivers can be deferred probe. The topology file based widgets can
have references to topology file so this can't be freed until card is fully
created, so revert this patch for now

[   66.682767] BUG: unable to handle kernel paging request at ffffc900001363fc
[   66.690735] IP: [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.696509] PGD 16e035067 PUD 16e036067 PMD 16e038067 PTE 0
[   66.702925] Oops: 0000 [#1] PREEMPT SMP
[   66.768390] CPU: 3 PID: 57 Comm: kworker/u16:3 Tainted: G O 4.4.0-rc7-skl torvalds#62
[   66.778869] Hardware name: Intel Corporation Skylake Client platform
[   66.793201] Workqueue: deferwq deferred_probe_work_func
[   66.799173] task: ffff88008b700f40 ti: ffff88008b704000 task.ti: ffff88008b704000
[   66.807692] RIP: 0010:[<ffffffff806c94dd>]  [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.816243] RSP: 0018:ffff88008b707878  EFLAGS: 00010286
[   66.822293] RAX: ffffffff80e60a82 RBX: 000000000000000e RCX: fffffffffffffffe
[   66.830406] RDX: ffffc900001363fc RSI: ffffffffffffffff RDI: ffffc900001363fc
[   66.838520] RBP: ffff88008b707878 R08: 000000000000ffff R09: 000000000000ffff
[   66.846649] R10: 0000000000000001 R11: ffffffffa01c6368 R12: ffffc900001363fc
[   66.854765] R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000
[   66.862910] FS:  0000000000000000(0000) GS:ffff88016ecc0000(0000) knlGS:0000000000000000
[   66.872150] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   66.878696] CR2: ffffc900001363fc CR3: 0000000002c09000 CR4: 00000000003406e0
[   66.886820] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   66.894938] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   66.903052] Stack:
[   66.905346]  ffff88008b7078b0 ffffffff806cb1db 000000000000000e 0000000000000000
[   66.913854]  ffff88008b707928 ffffffffa00d1050 ffffffffa00d104e ffff88008b707918
[   66.922353]  ffffffff806ccbd6 ffff88008b707948 0000000000000046 ffff88008b707940
[   66.930855] Call Trace:
[   66.933646]  [<ffffffff806cb1db>] string.isra.4+0x3b/0xd0
[   66.939793]  [<ffffffff806ccbd6>] vsnprintf+0x116/0x540
[   66.945742]  [<ffffffff806d02f0>] kvasprintf+0x40/0x80
[   66.951591]  [<ffffffff806d0370>] kasprintf+0x40/0x50
[   66.957359]  [<ffffffffa00c085f>] dapm_create_or_share_kcontrol+0x1cf/0x300 [snd_soc_core]
[   66.966771]  [<ffffffff8057dd1e>] ? __kmalloc+0x16e/0x2a0
[   66.972931]  [<ffffffffa00c0dab>] snd_soc_dapm_new_widgets+0x41b/0x4b0 [snd_soc_core]
[   66.981857]  [<ffffffffa00be8c0>] ? snd_soc_dapm_add_routes+0xb0/0xd0 [snd_soc_core]
[   67.007828]  [<ffffffffa00b92ed>] soc_probe_component+0x23d/0x360 [snd_soc_core]
[   67.016244]  [<ffffffff80b14e69>] ? mutex_unlock+0x9/0x10
[   67.022405]  [<ffffffffa00ba02f>] snd_soc_instantiate_card+0x47f/0xd10 [snd_soc_core]
[   67.031329]  [<ffffffff8049eeb2>] ? debug_mutex_init+0x32/0x40
[   67.037973]  [<ffffffffa00baa92>] snd_soc_register_card+0x1d2/0x2b0 [snd_soc_core]
[   67.046619]  [<ffffffffa00c8b54>] devm_snd_soc_register_card+0x44/0x80 [snd_soc_core]
[   67.055539]  [<ffffffffa01c303b>] skylake_audio_probe+0x1b/0x20 [snd_soc_skl_rt286]
[   67.064292]  [<ffffffff808aa887>] platform_drv_probe+0x37/0x90

Signed-off-by: Vinod Koul <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jan 6, 2016
@broonie
ASoC: Intel: Skylake: Revert previous broken fix memory leak fix
fb203ad 
This reverts commit 87b5ed8 ("ASoC: Intel:
Skylake: fix memory leak") as it causes regression on Skylake devices

The SKL drivers can be deferred probe. The topology file based widgets can
have references to topology file so this can't be freed until card is fully
created, so revert this patch for now

[   66.682767] BUG: unable to handle kernel paging request at ffffc900001363fc
[   66.690735] IP: [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.696509] PGD 16e035067 PUD 16e036067 PMD 16e038067 PTE 0
[   66.702925] Oops: 0000 [#1] PREEMPT SMP
[   66.768390] CPU: 3 PID: 57 Comm: kworker/u16:3 Tainted: G O 4.4.0-rc7-skl torvalds#62
[   66.778869] Hardware name: Intel Corporation Skylake Client platform
[   66.793201] Workqueue: deferwq deferred_probe_work_func
[   66.799173] task: ffff88008b700f40 ti: ffff88008b704000 task.ti: ffff88008b704000
[   66.807692] RIP: 0010:[<ffffffff806c94dd>]  [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.816243] RSP: 0018:ffff88008b707878  EFLAGS: 00010286
[   66.822293] RAX: ffffffff80e60a82 RBX: 000000000000000e RCX: fffffffffffffffe
[   66.830406] RDX: ffffc900001363fc RSI: ffffffffffffffff RDI: ffffc900001363fc
[   66.838520] RBP: ffff88008b707878 R08: 000000000000ffff R09: 000000000000ffff
[   66.846649] R10: 0000000000000001 R11: ffffffffa01c6368 R12: ffffc900001363fc
[   66.854765] R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000
[   66.862910] FS:  0000000000000000(0000) GS:ffff88016ecc0000(0000) knlGS:0000000000000000
[   66.872150] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   66.878696] CR2: ffffc900001363fc CR3: 0000000002c09000 CR4: 00000000003406e0
[   66.886820] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   66.894938] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   66.903052] Stack:
[   66.905346]  ffff88008b7078b0 ffffffff806cb1db 000000000000000e 0000000000000000
[   66.913854]  ffff88008b707928 ffffffffa00d1050 ffffffffa00d104e ffff88008b707918
[   66.922353]  ffffffff806ccbd6 ffff88008b707948 0000000000000046 ffff88008b707940
[   66.930855] Call Trace:
[   66.933646]  [<ffffffff806cb1db>] string.isra.4+0x3b/0xd0
[   66.939793]  [<ffffffff806ccbd6>] vsnprintf+0x116/0x540
[   66.945742]  [<ffffffff806d02f0>] kvasprintf+0x40/0x80
[   66.951591]  [<ffffffff806d0370>] kasprintf+0x40/0x50
[   66.957359]  [<ffffffffa00c085f>] dapm_create_or_share_kcontrol+0x1cf/0x300 [snd_soc_core]
[   66.966771]  [<ffffffff8057dd1e>] ? __kmalloc+0x16e/0x2a0
[   66.972931]  [<ffffffffa00c0dab>] snd_soc_dapm_new_widgets+0x41b/0x4b0 [snd_soc_core]
[   66.981857]  [<ffffffffa00be8c0>] ? snd_soc_dapm_add_routes+0xb0/0xd0 [snd_soc_core]
[   67.007828]  [<ffffffffa00b92ed>] soc_probe_component+0x23d/0x360 [snd_soc_core]
[   67.016244]  [<ffffffff80b14e69>] ? mutex_unlock+0x9/0x10
[   67.022405]  [<ffffffffa00ba02f>] snd_soc_instantiate_card+0x47f/0xd10 [snd_soc_core]
[   67.031329]  [<ffffffff8049eeb2>] ? debug_mutex_init+0x32/0x40
[   67.037973]  [<ffffffffa00baa92>] snd_soc_register_card+0x1d2/0x2b0 [snd_soc_core]
[   67.046619]  [<ffffffffa00c8b54>] devm_snd_soc_register_card+0x44/0x80 [snd_soc_core]
[   67.055539]  [<ffffffffa01c303b>] skylake_audio_probe+0x1b/0x20 [snd_soc_skl_rt286]
[   67.064292]  [<ffffffff808aa887>] platform_drv_probe+0x37/0x90

Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
umakrishn pushed a commit to surelock/linux that referenced this pull request Jan 12, 2016
@umakrishn
ASoC: Intel: Skylake: Revert previous broken fix memory leak fix
3dee662 
This reverts commit 87b5ed8 ("ASoC: Intel:
Skylake: fix memory leak") as it causes regression on Skylake devices

The SKL drivers can be deferred probe. The topology file based widgets can
have references to topology file so this can't be freed until card is fully
created, so revert this patch for now

[   66.682767] BUG: unable to handle kernel paging request at ffffc900001363fc
[   66.690735] IP: [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.696509] PGD 16e035067 PUD 16e036067 PMD 16e038067 PTE 0
[   66.702925] Oops: 0000 [#1] PREEMPT SMP
[   66.768390] CPU: 3 PID: 57 Comm: kworker/u16:3 Tainted: G O 4.4.0-rc7-skl torvalds#62
[   66.778869] Hardware name: Intel Corporation Skylake Client platform
[   66.793201] Workqueue: deferwq deferred_probe_work_func
[   66.799173] task: ffff88008b700f40 ti: ffff88008b704000 task.ti: ffff88008b704000
[   66.807692] RIP: 0010:[<ffffffff806c94dd>]  [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.816243] RSP: 0018:ffff88008b707878  EFLAGS: 00010286
[   66.822293] RAX: ffffffff80e60a82 RBX: 000000000000000e RCX: fffffffffffffffe
[   66.830406] RDX: ffffc900001363fc RSI: ffffffffffffffff RDI: ffffc900001363fc
[   66.838520] RBP: ffff88008b707878 R08: 000000000000ffff R09: 000000000000ffff
[   66.846649] R10: 0000000000000001 R11: ffffffffa01c6368 R12: ffffc900001363fc
[   66.854765] R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000
[   66.862910] FS:  0000000000000000(0000) GS:ffff88016ecc0000(0000) knlGS:0000000000000000
[   66.872150] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   66.878696] CR2: ffffc900001363fc CR3: 0000000002c09000 CR4: 00000000003406e0
[   66.886820] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   66.894938] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   66.903052] Stack:
[   66.905346]  ffff88008b7078b0 ffffffff806cb1db 000000000000000e 0000000000000000
[   66.913854]  ffff88008b707928 ffffffffa00d1050 ffffffffa00d104e ffff88008b707918
[   66.922353]  ffffffff806ccbd6 ffff88008b707948 0000000000000046 ffff88008b707940
[   66.930855] Call Trace:
[   66.933646]  [<ffffffff806cb1db>] string.isra.4+0x3b/0xd0
[   66.939793]  [<ffffffff806ccbd6>] vsnprintf+0x116/0x540
[   66.945742]  [<ffffffff806d02f0>] kvasprintf+0x40/0x80
[   66.951591]  [<ffffffff806d0370>] kasprintf+0x40/0x50
[   66.957359]  [<ffffffffa00c085f>] dapm_create_or_share_kcontrol+0x1cf/0x300 [snd_soc_core]
[   66.966771]  [<ffffffff8057dd1e>] ? __kmalloc+0x16e/0x2a0
[   66.972931]  [<ffffffffa00c0dab>] snd_soc_dapm_new_widgets+0x41b/0x4b0 [snd_soc_core]
[   66.981857]  [<ffffffffa00be8c0>] ? snd_soc_dapm_add_routes+0xb0/0xd0 [snd_soc_core]
[   67.007828]  [<ffffffffa00b92ed>] soc_probe_component+0x23d/0x360 [snd_soc_core]
[   67.016244]  [<ffffffff80b14e69>] ? mutex_unlock+0x9/0x10
[   67.022405]  [<ffffffffa00ba02f>] snd_soc_instantiate_card+0x47f/0xd10 [snd_soc_core]
[   67.031329]  [<ffffffff8049eeb2>] ? debug_mutex_init+0x32/0x40
[   67.037973]  [<ffffffffa00baa92>] snd_soc_register_card+0x1d2/0x2b0 [snd_soc_core]
[   67.046619]  [<ffffffffa00c8b54>] devm_snd_soc_register_card+0x44/0x80 [snd_soc_core]
[   67.055539]  [<ffffffffa01c303b>] skylake_audio_probe+0x1b/0x20 [snd_soc_skl_rt286]
[   67.064292]  [<ffffffff808aa887>] platform_drv_probe+0x37/0x90

Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
imikushin pushed a commit to rancher/linux that referenced this pull request Feb 10, 2016
ASoC: Intel: Skylake: Revert previous broken fix memory leak fix
c3f3657 
This reverts commit 87b5ed8 ("ASoC: Intel:
Skylake: fix memory leak") as it causes regression on Skylake devices

The SKL drivers can be deferred probe. The topology file based widgets can
have references to topology file so this can't be freed until card is fully
created, so revert this patch for now

[   66.682767] BUG: unable to handle kernel paging request at ffffc900001363fc
[   66.690735] IP: [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.696509] PGD 16e035067 PUD 16e036067 PMD 16e038067 PTE 0
[   66.702925] Oops: 0000 [#1] PREEMPT SMP
[   66.768390] CPU: 3 PID: 57 Comm: kworker/u16:3 Tainted: G O 4.4.0-rc7-skl torvalds#62
[   66.778869] Hardware name: Intel Corporation Skylake Client platform
[   66.793201] Workqueue: deferwq deferred_probe_work_func
[   66.799173] task: ffff88008b700f40 ti: ffff88008b704000 task.ti: ffff88008b704000
[   66.807692] RIP: 0010:[<ffffffff806c94dd>]  [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.816243] RSP: 0018:ffff88008b707878  EFLAGS: 00010286
[   66.822293] RAX: ffffffff80e60a82 RBX: 000000000000000e RCX: fffffffffffffffe
[   66.830406] RDX: ffffc900001363fc RSI: ffffffffffffffff RDI: ffffc900001363fc
[   66.838520] RBP: ffff88008b707878 R08: 000000000000ffff R09: 000000000000ffff
[   66.846649] R10: 0000000000000001 R11: ffffffffa01c6368 R12: ffffc900001363fc
[   66.854765] R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000
[   66.862910] FS:  0000000000000000(0000) GS:ffff88016ecc0000(0000) knlGS:0000000000000000
[   66.872150] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   66.878696] CR2: ffffc900001363fc CR3: 0000000002c09000 CR4: 00000000003406e0
[   66.886820] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   66.894938] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   66.903052] Stack:
[   66.905346]  ffff88008b7078b0 ffffffff806cb1db 000000000000000e 0000000000000000
[   66.913854]  ffff88008b707928 ffffffffa00d1050 ffffffffa00d104e ffff88008b707918
[   66.922353]  ffffffff806ccbd6 ffff88008b707948 0000000000000046 ffff88008b707940
[   66.930855] Call Trace:
[   66.933646]  [<ffffffff806cb1db>] string.isra.4+0x3b/0xd0
[   66.939793]  [<ffffffff806ccbd6>] vsnprintf+0x116/0x540
[   66.945742]  [<ffffffff806d02f0>] kvasprintf+0x40/0x80
[   66.951591]  [<ffffffff806d0370>] kasprintf+0x40/0x50
[   66.957359]  [<ffffffffa00c085f>] dapm_create_or_share_kcontrol+0x1cf/0x300 [snd_soc_core]
[   66.966771]  [<ffffffff8057dd1e>] ? __kmalloc+0x16e/0x2a0
[   66.972931]  [<ffffffffa00c0dab>] snd_soc_dapm_new_widgets+0x41b/0x4b0 [snd_soc_core]
[   66.981857]  [<ffffffffa00be8c0>] ? snd_soc_dapm_add_routes+0xb0/0xd0 [snd_soc_core]
[   67.007828]  [<ffffffffa00b92ed>] soc_probe_component+0x23d/0x360 [snd_soc_core]
[   67.016244]  [<ffffffff80b14e69>] ? mutex_unlock+0x9/0x10
[   67.022405]  [<ffffffffa00ba02f>] snd_soc_instantiate_card+0x47f/0xd10 [snd_soc_core]
[   67.031329]  [<ffffffff8049eeb2>] ? debug_mutex_init+0x32/0x40
[   67.037973]  [<ffffffffa00baa92>] snd_soc_register_card+0x1d2/0x2b0 [snd_soc_core]
[   67.046619]  [<ffffffffa00c8b54>] devm_snd_soc_register_card+0x44/0x80 [snd_soc_core]
[   67.055539]  [<ffffffffa01c303b>] skylake_audio_probe+0x1b/0x20 [snd_soc_skl_rt286]
[   67.064292]  [<ffffffff808aa887>] platform_drv_probe+0x37/0x90

Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jul 29, 2016
@vegard
block: fix use-after-free in seq file
b8b9730 
I got a KASAN report of use-after-free:

    ==================================================================
    BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
    Read of size 8 by task trinity-c1/315
    =============================================================================
    BUG kmalloc-32 (Not tainted): kasan: bad access detected
    -----------------------------------------------------------------------------

    Disabling lock debugging due to kernel taint
    INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
            ___slab_alloc+0x4f1/0x520
            __slab_alloc.isra.58+0x56/0x80
            kmem_cache_alloc_trace+0x260/0x2a0
            disk_seqf_start+0x66/0x110
            traverse+0x176/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a
    INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315
            __slab_free+0x17a/0x2c0
            kfree+0x20a/0x220
            disk_seqf_stop+0x42/0x50
            traverse+0x3b5/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a

    CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ torvalds#62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
     ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
     ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
     ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
    Call Trace:
     [<ffffffff81d6ce81>] dump_stack+0x65/0x84
     [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0
     [<ffffffff814704ff>] object_err+0x2f/0x40
     [<ffffffff814754d1>] kasan_report_error+0x221/0x520
     [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40
     [<ffffffff83888161>] klist_iter_exit+0x61/0x70
     [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10
     [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50
     [<ffffffff8151f812>] seq_read+0x4b2/0x11a0
     [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180
     [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210
     [<ffffffff814b4c45>] do_readv_writev+0x565/0x660
     [<ffffffff814b8a17>] vfs_readv+0x67/0xa0
     [<ffffffff814b8de6>] do_preadv+0x126/0x170
     [<ffffffff814b92ec>] SyS_preadv+0xc/0x10

This problem can occur in the following situation:

open()
 - pread()
    - .seq_start()
       - iter = kmalloc() // succeeds
       - seqf->private = iter
    - .seq_stop()
       - kfree(seqf->private)
 - pread()
    - .seq_start()
       - iter = kmalloc() // fails
    - .seq_stop()
       - class_dev_iter_exit(seqf->private) // boom! old pointer

As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.

An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.

Cc: Tejun Heo <[email protected]>
Cc: [email protected]
Signed-off-by: Vegard Nossum <[email protected]>
torvalds pushed a commit that referenced this pull request Aug 6, 2016
@vegard @axboe
block: fix use-after-free in seq file
77da160 
I got a KASAN report of use-after-free:

    ==================================================================
    BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
    Read of size 8 by task trinity-c1/315
    =============================================================================
    BUG kmalloc-32 (Not tainted): kasan: bad access detected
    -----------------------------------------------------------------------------

    Disabling lock debugging due to kernel taint
    INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
            ___slab_alloc+0x4f1/0x520
            __slab_alloc.isra.58+0x56/0x80
            kmem_cache_alloc_trace+0x260/0x2a0
            disk_seqf_start+0x66/0x110
            traverse+0x176/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a
    INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315
            __slab_free+0x17a/0x2c0
            kfree+0x20a/0x220
            disk_seqf_stop+0x42/0x50
            traverse+0x3b5/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a

    CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ #62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
     ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
     ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
     ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
    Call Trace:
     [<ffffffff81d6ce81>] dump_stack+0x65/0x84
     [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0
     [<ffffffff814704ff>] object_err+0x2f/0x40
     [<ffffffff814754d1>] kasan_report_error+0x221/0x520
     [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40
     [<ffffffff83888161>] klist_iter_exit+0x61/0x70
     [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10
     [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50
     [<ffffffff8151f812>] seq_read+0x4b2/0x11a0
     [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180
     [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210
     [<ffffffff814b4c45>] do_readv_writev+0x565/0x660
     [<ffffffff814b8a17>] vfs_readv+0x67/0xa0
     [<ffffffff814b8de6>] do_preadv+0x126/0x170
     [<ffffffff814b92ec>] SyS_preadv+0xc/0x10

This problem can occur in the following situation:

open()
 - pread()
    - .seq_start()
       - iter = kmalloc() // succeeds
       - seqf->private = iter
    - .seq_stop()
       - kfree(seqf->private)
 - pread()
    - .seq_start()
       - iter = kmalloc() // fails
    - .seq_stop()
       - class_dev_iter_exit(seqf->private) // boom! old pointer

As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.

An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.

Cc: [email protected]
Signed-off-by: Vegard Nossum <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Noltari pushed a commit to Noltari/linux that referenced this pull request Aug 16, 2016
@vegard @gregkh
block: fix use-after-free in seq file
9a95c0c 
commit 77da160 upstream.

I got a KASAN report of use-after-free:

    ==================================================================
    BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
    Read of size 8 by task trinity-c1/315
    =============================================================================
    BUG kmalloc-32 (Not tainted): kasan: bad access detected
    -----------------------------------------------------------------------------

    Disabling lock debugging due to kernel taint
    INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
            ___slab_alloc+0x4f1/0x520
            __slab_alloc.isra.58+0x56/0x80
            kmem_cache_alloc_trace+0x260/0x2a0
            disk_seqf_start+0x66/0x110
            traverse+0x176/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a
    INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315
            __slab_free+0x17a/0x2c0
            kfree+0x20a/0x220
            disk_seqf_stop+0x42/0x50
            traverse+0x3b5/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a

    CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ torvalds#62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
     ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
     ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
     ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
    Call Trace:
     [<ffffffff81d6ce81>] dump_stack+0x65/0x84
     [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0
     [<ffffffff814704ff>] object_err+0x2f/0x40
     [<ffffffff814754d1>] kasan_report_error+0x221/0x520
     [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40
     [<ffffffff83888161>] klist_iter_exit+0x61/0x70
     [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10
     [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50
     [<ffffffff8151f812>] seq_read+0x4b2/0x11a0
     [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180
     [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210
     [<ffffffff814b4c45>] do_readv_writev+0x565/0x660
     [<ffffffff814b8a17>] vfs_readv+0x67/0xa0
     [<ffffffff814b8de6>] do_preadv+0x126/0x170
     [<ffffffff814b92ec>] SyS_preadv+0xc/0x10

This problem can occur in the following situation:

open()
 - pread()
    - .seq_start()
       - iter = kmalloc() // succeeds
       - seqf->private = iter
    - .seq_stop()
       - kfree(seqf->private)
 - pread()
    - .seq_start()
       - iter = kmalloc() // fails
    - .seq_stop()
       - class_dev_iter_exit(seqf->private) // boom! old pointer

As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.

An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.

Signed-off-by: Vegard Nossum <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Noltari pushed a commit to Noltari/linux that referenced this pull request Aug 16, 2016
@vegard @gregkh
block: fix use-after-free in seq file
8cb3a41 
commit 77da160 upstream.

I got a KASAN report of use-after-free:

    ==================================================================
    BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
    Read of size 8 by task trinity-c1/315
    =============================================================================
    BUG kmalloc-32 (Not tainted): kasan: bad access detected
    -----------------------------------------------------------------------------

    Disabling lock debugging due to kernel taint
    INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
            ___slab_alloc+0x4f1/0x520
            __slab_alloc.isra.58+0x56/0x80
            kmem_cache_alloc_trace+0x260/0x2a0
            disk_seqf_start+0x66/0x110
            traverse+0x176/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a
    INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315
            __slab_free+0x17a/0x2c0
            kfree+0x20a/0x220
            disk_seqf_stop+0x42/0x50
            traverse+0x3b5/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a

    CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ torvalds#62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
     ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
     ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
     ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
    Call Trace:
     [<ffffffff81d6ce81>] dump_stack+0x65/0x84
     [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0
     [<ffffffff814704ff>] object_err+0x2f/0x40
     [<ffffffff814754d1>] kasan_report_error+0x221/0x520
     [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40
     [<ffffffff83888161>] klist_iter_exit+0x61/0x70
     [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10
     [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50
     [<ffffffff8151f812>] seq_read+0x4b2/0x11a0
     [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180
     [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210
     [<ffffffff814b4c45>] do_readv_writev+0x565/0x660
     [<ffffffff814b8a17>] vfs_readv+0x67/0xa0
     [<ffffffff814b8de6>] do_preadv+0x126/0x170
     [<ffffffff814b92ec>] SyS_preadv+0xc/0x10

This problem can occur in the following situation:

open()
 - pread()
    - .seq_start()
       - iter = kmalloc() // succeeds
       - seqf->private = iter
    - .seq_stop()
       - kfree(seqf->private)
 - pread()
    - .seq_start()
       - iter = kmalloc() // fails
    - .seq_stop()
       - class_dev_iter_exit(seqf->private) // boom! old pointer

As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.

An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.

Signed-off-by: Vegard Nossum <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
kernelOfTruth pushed a commit to kernelOfTruth/linux that referenced this pull request Aug 16, 2016
@vegard @gregkh
block: fix use-after-free in seq file
aa56f0b 
commit 77da160 upstream.

I got a KASAN report of use-after-free:

    ==================================================================
    BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
    Read of size 8 by task trinity-c1/315
    =============================================================================
    BUG kmalloc-32 (Not tainted): kasan: bad access detected
    -----------------------------------------------------------------------------

    Disabling lock debugging due to kernel taint
    INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
            ___slab_alloc+0x4f1/0x520
            __slab_alloc.isra.58+0x56/0x80
            kmem_cache_alloc_trace+0x260/0x2a0
            disk_seqf_start+0x66/0x110
            traverse+0x176/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a
    INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315
            __slab_free+0x17a/0x2c0
            kfree+0x20a/0x220
            disk_seqf_stop+0x42/0x50
            traverse+0x3b5/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a

    CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ torvalds#62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
     ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
     ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
     ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
    Call Trace:
     [<ffffffff81d6ce81>] dump_stack+0x65/0x84
     [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0
     [<ffffffff814704ff>] object_err+0x2f/0x40
     [<ffffffff814754d1>] kasan_report_error+0x221/0x520
     [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40
     [<ffffffff83888161>] klist_iter_exit+0x61/0x70
     [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10
     [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50
     [<ffffffff8151f812>] seq_read+0x4b2/0x11a0
     [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180
     [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210
     [<ffffffff814b4c45>] do_readv_writev+0x565/0x660
     [<ffffffff814b8a17>] vfs_readv+0x67/0xa0
     [<ffffffff814b8de6>] do_preadv+0x126/0x170
     [<ffffffff814b92ec>] SyS_preadv+0xc/0x10

This problem can occur in the following situation:

open()
 - pread()
    - .seq_start()
       - iter = kmalloc() // succeeds
       - seqf->private = iter
    - .seq_stop()
       - kfree(seqf->private)
 - pread()
    - .seq_start()
       - iter = kmalloc() // fails
    - .seq_stop()
       - class_dev_iter_exit(seqf->private) // boom! old pointer

As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.

An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.

Signed-off-by: Vegard Nossum <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request May 25, 2023
@junxiaoc @Kaz205
mm: fix hugetlb page unmap count balance issue
5864d40 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request May 25, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
eb6f62d 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request May 26, 2023
@junxiaoc @Kaz205
mm: fix hugetlb page unmap count balance issue
f57e64c 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request May 27, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
a056418 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
davidhildenbrand pushed a commit to davidhildenbrand/linux that referenced this pull request May 30, 2023
@junxiaoc @davidhildenbrand
mm: fix hugetlb page unmap count balance issue
baa1176 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request May 30, 2023
@junxiaoc @Kaz205
mm: fix hugetlb page unmap count balance issue
d53fca6 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request May 31, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
4d86fc9 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 1, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
3eb4f2a 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 2, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
52da73e 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 2, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
db8814a 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 6, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
a76ef5d 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 7, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
97cff1e 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 7, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
446ec98 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 8, 2023
@junxiaoc @intel-lab-lkp
mm: fix hugetlb page unmap count balance issue
6245bfc 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte. QEMU can use udma-buf to create host dmabufs for guest
framebuffers. When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.
Call chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In function page_add_file_rmap, compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request Jun 9, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
64a2c49 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 9, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
4ffdcd0 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 10, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
fe9af9b 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 12, 2023
@kawasaki @intel-lab-lkp
RDMA/cma: prevent rdma id destroy during cma_iw_handler
528d964 
When rdma_destroy_id() and cma_iw_handler() race, struct rdma_id_private
*id_priv can be destroyed during cma_iw_handler call. This causes "BUG:
KASAN: slab-use-after-free" at mutex_lock() in cma_iw_handler() [1].
To prevent the destroy of id_priv, keep its reference count by calling
cma_id_get() and cma_id_put() at start and end of cma_iw_handler().

[1]

==================================================================
BUG: KASAN: slab-use-after-free in __mutex_lock+0x1324/0x18f0
Read of size 8 at addr ffff888197b37418 by task kworker/u8:0/9

CPU: 0 PID: 9 Comm: kworker/u8:0 Not tainted 6.3.0 torvalds#62
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014
Workqueue: iw_cm_wq cm_work_handler [iw_cm]
Call Trace:
 <TASK>
 dump_stack_lvl+0x57/0x90
 print_report+0xcf/0x660
 ? __mutex_lock+0x1324/0x18f0
 kasan_report+0xa4/0xe0
 ? __mutex_lock+0x1324/0x18f0
 __mutex_lock+0x1324/0x18f0
 ? cma_iw_handler+0xac/0x4f0 [rdma_cm]
 ? _raw_spin_unlock_irqrestore+0x30/0x60
 ? rcu_is_watching+0x11/0xb0
 ? _raw_spin_unlock_irqrestore+0x30/0x60
 ? trace_hardirqs_on+0x12/0x100
 ? __pfx___mutex_lock+0x10/0x10
 ? __percpu_counter_sum+0x147/0x1e0
 ? domain_dirty_limits+0x246/0x390
 ? wb_over_bg_thresh+0x4d5/0x610
 ? rcu_is_watching+0x11/0xb0
 ? cma_iw_handler+0xac/0x4f0 [rdma_cm]
 cma_iw_handler+0xac/0x4f0 [rdma_cm]
 ? rcu_is_watching+0x11/0xb0
 ? __pfx_cma_iw_handler+0x10/0x10 [rdma_cm]
 ? attach_entity_load_avg+0x4e2/0x920
 ? _raw_spin_unlock_irqrestore+0x30/0x60
 ? rcu_is_watching+0x11/0xb0
 cm_work_handler+0x139e/0x1c50 [iw_cm]
 ? __pfx_cm_work_handler+0x10/0x10 [iw_cm]
 ? rcu_is_watching+0x11/0xb0
 ? __pfx_try_to_wake_up+0x10/0x10
 ? __pfx_do_raw_spin_lock+0x10/0x10
 ? __pfx___might_resched+0x10/0x10
 ? _raw_spin_unlock_irq+0x24/0x50
 process_one_work+0x843/0x1350
 ? __pfx_lock_acquire+0x10/0x10
 ? __pfx_process_one_work+0x10/0x10
 ? __pfx_do_raw_spin_lock+0x10/0x10
 worker_thread+0xfc/0x1260
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x29e/0x340
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2c/0x50
 </TASK>

Allocated by task 4225:
 kasan_save_stack+0x2f/0x50
 kasan_set_track+0x21/0x30
 __kasan_kmalloc+0xa6/0xb0
 __rdma_create_id+0x5b/0x5d0 [rdma_cm]
 __rdma_create_kernel_id+0x12/0x40 [rdma_cm]
 nvme_rdma_alloc_queue+0x26a/0x5f0 [nvme_rdma]
 nvme_rdma_setup_ctrl+0xb84/0x1d90 [nvme_rdma]
 nvme_rdma_create_ctrl+0x7b5/0xd20 [nvme_rdma]
 nvmf_dev_write+0xddd/0x22b0 [nvme_fabrics]
 vfs_write+0x211/0xd50
 ksys_write+0x100/0x1e0
 do_syscall_64+0x5b/0x80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Freed by task 4227:
 kasan_save_stack+0x2f/0x50
 kasan_set_track+0x21/0x30
 kasan_save_free_info+0x2a/0x50
 ____kasan_slab_free+0x169/0x1c0
 slab_free_freelist_hook+0xdb/0x1b0
 __kmem_cache_free+0xb8/0x2e0
 nvme_rdma_free_queue+0x4a/0x70 [nvme_rdma]
 nvme_rdma_teardown_io_queues.part.0+0x14a/0x1e0 [nvme_rdma]
 nvme_rdma_delete_ctrl+0x4f/0x100 [nvme_rdma]
 nvme_do_delete_ctrl+0x14e/0x240 [nvme_core]
 nvme_sysfs_delete+0xcb/0x100 [nvme_core]
 kernfs_fop_write_iter+0x359/0x530
 vfs_write+0x58f/0xd50
 ksys_write+0x100/0x1e0
 do_syscall_64+0x5b/0x80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

The buggy address belongs to the object at ffff888197b37000
        which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1048 bytes inside of
        freed 2048-byte region [ffff888197b37000, ffff888197b37800)

The buggy address belongs to the physical page:
page:00000000fbe33a6e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x197b30
head:00000000fbe33a6e order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0010200 ffff888100042f00 0000000000000000 dead000000000001
raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff888197b37300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888197b37380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888197b37400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
 ffff888197b37480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888197b37500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Fixes: de910bd ("RDMA/cma: Simplify locking needed for serialization of callbacks")
Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
Cc: [email protected]
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 13, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
2273706 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 13, 2023
@kawasaki @rleon
RDMA/cma: prevent rdma id destroy during cma_iw_handler
fd06a59 
When rdma_destroy_id() and cma_iw_handler() race, struct rdma_id_private
*id_priv can be destroyed during cma_iw_handler call. This causes "BUG:
KASAN: slab-use-after-free" at mutex_lock() in cma_iw_handler() [1].
To prevent the destroy of id_priv, keep its reference count by calling
cma_id_get() and cma_id_put() at start and end of cma_iw_handler().

[1]

==================================================================
BUG: KASAN: slab-use-after-free in __mutex_lock+0x1324/0x18f0
Read of size 8 at addr ffff888197b37418 by task kworker/u8:0/9

CPU: 0 PID: 9 Comm: kworker/u8:0 Not tainted 6.3.0 torvalds#62
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014
Workqueue: iw_cm_wq cm_work_handler [iw_cm]
Call Trace:
 <TASK>
 dump_stack_lvl+0x57/0x90
 print_report+0xcf/0x660
 ? __mutex_lock+0x1324/0x18f0
 kasan_report+0xa4/0xe0
 ? __mutex_lock+0x1324/0x18f0
 __mutex_lock+0x1324/0x18f0
 ? cma_iw_handler+0xac/0x4f0 [rdma_cm]
 ? _raw_spin_unlock_irqrestore+0x30/0x60
 ? rcu_is_watching+0x11/0xb0
 ? _raw_spin_unlock_irqrestore+0x30/0x60
 ? trace_hardirqs_on+0x12/0x100
 ? __pfx___mutex_lock+0x10/0x10
 ? __percpu_counter_sum+0x147/0x1e0
 ? domain_dirty_limits+0x246/0x390
 ? wb_over_bg_thresh+0x4d5/0x610
 ? rcu_is_watching+0x11/0xb0
 ? cma_iw_handler+0xac/0x4f0 [rdma_cm]
 cma_iw_handler+0xac/0x4f0 [rdma_cm]
 ? rcu_is_watching+0x11/0xb0
 ? __pfx_cma_iw_handler+0x10/0x10 [rdma_cm]
 ? attach_entity_load_avg+0x4e2/0x920
 ? _raw_spin_unlock_irqrestore+0x30/0x60
 ? rcu_is_watching+0x11/0xb0
 cm_work_handler+0x139e/0x1c50 [iw_cm]
 ? __pfx_cm_work_handler+0x10/0x10 [iw_cm]
 ? rcu_is_watching+0x11/0xb0
 ? __pfx_try_to_wake_up+0x10/0x10
 ? __pfx_do_raw_spin_lock+0x10/0x10
 ? __pfx___might_resched+0x10/0x10
 ? _raw_spin_unlock_irq+0x24/0x50
 process_one_work+0x843/0x1350
 ? __pfx_lock_acquire+0x10/0x10
 ? __pfx_process_one_work+0x10/0x10
 ? __pfx_do_raw_spin_lock+0x10/0x10
 worker_thread+0xfc/0x1260
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x29e/0x340
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2c/0x50
 </TASK>

Allocated by task 4225:
 kasan_save_stack+0x2f/0x50
 kasan_set_track+0x21/0x30
 __kasan_kmalloc+0xa6/0xb0
 __rdma_create_id+0x5b/0x5d0 [rdma_cm]
 __rdma_create_kernel_id+0x12/0x40 [rdma_cm]
 nvme_rdma_alloc_queue+0x26a/0x5f0 [nvme_rdma]
 nvme_rdma_setup_ctrl+0xb84/0x1d90 [nvme_rdma]
 nvme_rdma_create_ctrl+0x7b5/0xd20 [nvme_rdma]
 nvmf_dev_write+0xddd/0x22b0 [nvme_fabrics]
 vfs_write+0x211/0xd50
 ksys_write+0x100/0x1e0
 do_syscall_64+0x5b/0x80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Freed by task 4227:
 kasan_save_stack+0x2f/0x50
 kasan_set_track+0x21/0x30
 kasan_save_free_info+0x2a/0x50
 ____kasan_slab_free+0x169/0x1c0
 slab_free_freelist_hook+0xdb/0x1b0
 __kmem_cache_free+0xb8/0x2e0
 nvme_rdma_free_queue+0x4a/0x70 [nvme_rdma]
 nvme_rdma_teardown_io_queues.part.0+0x14a/0x1e0 [nvme_rdma]
 nvme_rdma_delete_ctrl+0x4f/0x100 [nvme_rdma]
 nvme_do_delete_ctrl+0x14e/0x240 [nvme_core]
 nvme_sysfs_delete+0xcb/0x100 [nvme_core]
 kernfs_fop_write_iter+0x359/0x530
 vfs_write+0x58f/0xd50
 ksys_write+0x100/0x1e0
 do_syscall_64+0x5b/0x80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

The buggy address belongs to the object at ffff888197b37000
        which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1048 bytes inside of
        freed 2048-byte region [ffff888197b37000, ffff888197b37800)

The buggy address belongs to the physical page:
page:00000000fbe33a6e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x197b30
head:00000000fbe33a6e order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0010200 ffff888100042f00 0000000000000000 dead000000000001
raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff888197b37300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888197b37380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888197b37400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
 ffff888197b37480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888197b37500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Fixes: de910bd ("RDMA/cma: Simplify locking needed for serialization of callbacks")
Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Leon Romanovsky <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 13, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
3dbcb8b 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 16, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
d3492ba 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 17, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
cd64611 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 19, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
c7f0f5a 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 20, 2023
@junxiaoc @akpm00
mm: fix hugetlb page unmap count balance issue
5d945f0 
hugetlb page usually is mapped with pmd, but occasionally it might be
mapped with pte.  QEMU can use udma-buf to create host dmabufs for guest
framebuffers.  When QEMU is launched with parameter "hugetlb=on",
udmabuffer driver maps hugetlb page with pte in page fault handler.  Call
chain looks like:

page_add_file_rmap
do_set_pte
finish_fault
__do_fault -> udmabuf_vm_fault, it maps hugetlb page here.
do_read_fault

In page_add_file_rmap(), compound is false since it is pte mapping.

When qemu exits and page is unmapped in function page_remove_rmap, the
hugetlb page should not be handled in pmd way.

This change is to check compound parameter as well as hugetlb flag. It
fixes below kernel bug which is reproduced with 6.3 kernel:

[  114.027754] BUG: Bad page cache in process qemu-system-x86  pfn:37aa00
[  114.034288] page:000000000dd2153b refcount:514 mapcount:-4 mapping:000000004b01ca30 index:0x13800 pfn:0x37aa00
[  114.044277] head:000000000dd2153b order:9 entire_mapcount:-4 nr_pages_mapped:4 pincount:512
[  114.052623] aops:hugetlbfs_aops ino:6f93
[  114.056552] flags: 0x17ffffc0010001(locked|head|node=0|zone=2|lastcpupid=0x1fffff)
[  114.064115] raw: 0017ffffc0010001 fffff7338deb0008 fffff7338dea0008 ffff98dc855ea870
[  114.071847] raw: 000000000000009c 0000000000000002 00000202ffffffff 0000000000000000
[  114.079572] page dumped because: still mapped when deleted
[  114.085048] CPU: 0 PID: 3122 Comm: qemu-system-x86 Tainted: G    BU  W   E      6.3.0-v3+ torvalds#62
[  114.093566] Hardware name: Intel Corporation Alder Lake Client Platform DDR5 SODIMM SBS RVP, BIOS ADLPFWI1.R00.3084.D89.2303211034 03/21/2023
[  114.106839] Call Trace:
[  114.109291]  <TASK>
[  114.111405]  dump_stack_lvl+0x4c/0x70
[  114.115073]  dump_stack+0x14/0x20
[  114.118395]  filemap_unaccount_folio+0x159/0x220
[  114.123021]  filemap_remove_folio+0x54/0x110
[  114.127295]  remove_inode_hugepages+0x111/0x5b0
[  114.131834]  hugetlbfs_evict_inode+0x23/0x50
[  114.136111]  evict+0xcd/0x1e0
[  114.139083]  iput.part.0+0x183/0x1e0
[  114.142663]  iput+0x20/0x30
[  114.145466]  dentry_unlink_inode+0xcc/0x130
[  114.149655]  __dentry_kill+0xec/0x1a0
[  114.153325]  dput+0x1ca/0x3c0
[  114.156293]  __fput+0xf4/0x280
[  114.159357]  ____fput+0x12/0x20
[  114.162502]  task_work_run+0x62/0xa0
[  114.166088]  do_exit+0x352/0xae0
[  114.169321]  do_group_exit+0x39/0x90
[  114.172892]  get_signal+0xa09/0xa30
[  114.176391]  arch_do_signal_or_restart+0x33/0x280
[  114.181098]  exit_to_user_mode_prepare+0x11f/0x190
[  114.185893]  syscall_exit_to_user_mode+0x2a/0x50
[  114.190509]  do_syscall_64+0x4c/0x90
[  114.194095]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 53f9263 ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Signed-off-by: Junxiao Chang <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: James Houghton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Dec 22, 2023
@laoar @intel-lab-lkp
selftests/bpf: Add selftests for cpumask iter
3e80327 
Within the BPF program, we leverage the cgroup iterator to iterate through
percpu runqueue data, specifically the 'nr_running' metric. Subsequently
 we expose this data to userspace by means of a sequence file.

The CPU affinity for the cpumask is determined by the PID of a task:

- PID of the init task (PID 1)
  We typically don't set CPU affinity for init task and thus we can iterate
  across all possible CPUs. However, in scenarios where you've set CPU
  affinity for the init task, you should set the cpumask of your current
  task to full-F. Then proceed to iterate through all possible CPUs using
  the current task.
- PID of a task with defined CPU affinity
  The aim here is to iterate through a specific cpumask. This scenario
  aligns with tasks residing within a cpuset cgroup.
- Invalid PID (e.g., PID -1)
  No cpumask is available in this case.

The result as follows,
  torvalds#62/1    cpumask_iter/init_pid:OK
  torvalds#62/2    cpumask_iter/invalid_pid:OK
  torvalds#62/3    cpumask_iter/self_pid_one_cpu:OK
  torvalds#62/4    cpumask_iter/self_pid_multi_cpus:OK
  torvalds#62      cpumask_iter:OK
  Summary: 1/4 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Yafang Shao <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jan 10, 2024
@laoar @intel-lab-lkp
selftests/bpf: Add selftests for cpumask iter
909bb53 
Within the BPF program, we leverage the cgroup iterator to iterate through
percpu runqueue data, specifically the 'nr_running' metric. Subsequently
 we expose this data to userspace by means of a sequence file.

The CPU affinity for the cpumask is determined by the PID of a task:

- PID of the init task (PID 1)
  We typically don't set CPU affinity for init task and thus we can iterate
  across all possible CPUs. However, in scenarios where you've set CPU
  affinity for the init task, you should set the cpumask of your current
  task to full-F. Then proceed to iterate through all possible CPUs using
  the current task.
- PID of a task with defined CPU affinity
  The aim here is to iterate through a specific cpumask. This scenario
  aligns with tasks residing within a cpuset cgroup.
- Invalid PID (e.g., PID -1)
  No cpumask is available in this case.

The result as follows,
  torvalds#62/1    cpumask_iter/init_pid:OK
  torvalds#62/2    cpumask_iter/invalid_pid:OK
  torvalds#62/3    cpumask_iter/self_pid_one_cpu:OK
  torvalds#62/4    cpumask_iter/self_pid_multi_cpus:OK
  torvalds#62      cpumask_iter:OK
  Summary: 1/4 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Yafang Shao <[email protected]>
logic10492 pushed a commit to logic10492/linux-amd-zen2 that referenced this pull request Jan 18, 2024
@DaanDeMeyer
Merge pull request torvalds#62 from sched-ext/rusty_offline
52911e1 
rusty: Further tweak build system
gyroninja added a commit to gyroninja/linux that referenced this pull request Jan 28, 2024
@gyroninja
[WIP] Fix infinite recursion during KMSAN initialization
498e53b 
KSAN calls into rcu code which then triggers a write that reenters into KSAN
getting the system stuck doing infinite recursion.

#0  kmsan_get_context () at mm/kmsan/kmsan.h:106
#1  __msan_get_context_state () at mm/kmsan/instrumentation.c:331
#2  0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42
#3  rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
#4  __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
#5  0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#6  pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#7  kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#8  virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#9  0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
#52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
#53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
#58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
#70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82
torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75
torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97
torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36
torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:92
torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397
torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task+1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500
torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285
torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324
torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296
torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262
torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932
torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555
torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536
torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461
torvalds#93 0x0000000000000000 in ??
gyroninja added a commit to gyroninja/linux that referenced this pull request Jan 28, 2024
@gyroninja
[WIP] Disable KMSAN for kernel/rcu/tree
00c2e46 
As of 5ec8e8e(mm/sparsemem: fix race in accessing memory_section->usage) KMSAN
now calls into RCU tree code during kmsan_get_metadata. This will trigger a
write that will reenter into KMSAN getting the system stuck doing infinite
recursion.

#0  kmsan_get_context () at mm/kmsan/kmsan.h:106
#1  __msan_get_context_state () at mm/kmsan/instrumentation.c:331
#2  0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42
#3  rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
#4  __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
#5  0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#6  pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#7  kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#8  virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#9  0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
#52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
#53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
#58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75
torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143
#70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91
torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82
torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75
torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97
torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36
torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:92
torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397
torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task+1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500
torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285
torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324
torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296
torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262
torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932
torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555
torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536
torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461
torvalds#93 0x0000000000000000 in ??
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@badbadc0ffee @marcoms @ngbatnicdotmil