criar uma documentação em português do Brasil #45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
What's the point of this patch? |
|
Translation file "READEME" for Portuguese and encouraging others to do the 2013/8/29 Jesus Ramos [email protected]
Evandro Bruno Zanatta |
|
How does your patch accomplish anything though? It's just a file with the word start in it, maybe if it was actually a translation of the README it might make sense but this is useless really. |
|
ok.. |
heftig
referenced
this pull request
in zen-kernel/zen-kernel
Sep 3, 2013
In this case, the original author did not provide the related reason string for die_if_kernel(), so the 'buf' is not initialized. The original author wants to generic a 'SIGSEGV' and 'return', not want to 'break' to fall to die. [Probably irrelevent since we no longer support IA-32 execution. -Tony] Signed-off-by: Chen Gang <[email protected]> Signed-off-by: Tony Luck <[email protected]>
heftig
referenced
this pull request
in zen-kernel/zen-kernel
Sep 3, 2013
…ux/kernel/git/aegl/linux Pull misc ia64 updates from Tony Luck: "Miscellaneous ia64 changes for 3.11 merge window" * tag 'please-pull-misc-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux: [IA64] Delete __cpuinit usage from all ia64 users [IA64] hpsim: Fix check for overlong simscsi prefix. [IA64] pci: Remove unused fallback_dev [IA64] perfmon: Use %*phD specifier to dump small buffers [IA64] Fix trap #45 handling
psanford
pushed a commit
to retailnext/linux
that referenced
this pull request
Sep 9, 2013
I enable CONFIG_DEBUG_VIRTUAL and CONFIG_SPARSEMEM_VMEMMAP, when doing memory hotremove, there is a kernel BUG at arch/x86/mm/physaddr.c:20. It is caused by free_section_usemap()->virt_to_page(), virt_to_page() is only used for kernel direct mapping address, but sparse-vmemmap uses vmemmap address, so it is going wrong here. ------------[ cut here ]------------ kernel BUG at arch/x86/mm/physaddr.c:20! invalid opcode: 0000 [#1] SMP Modules linked in: acpihp_drv acpihp_slot edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm crc32c_intel ipv6 ixgbe igb iTCO_wdt i7core_edac edac_core pcspkr iTCO_vendor_support ioatdma microcode joydev sr_mod i2c_i801 dca lpc_ich mfd_core mdio tpm_tis i2c_core hid_generic tpm cdrom sg tpm_bios rtc_cmos button ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys hwmon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod CPU 39 Pid: 6454, comm: sh Not tainted 3.7.0-rc1-acpihp-final+ torvalds#45 QCI QSSC-S4R/QSSC-S4R RIP: 0010:[<ffffffff8103c908>] [<ffffffff8103c908>] __phys_addr+0x88/0x90 RSP: 0018:ffff8804440d7c08 EFLAGS: 00010006 RAX: 0000000000000006 RBX: ffffea0012000000 RCX: 000000000000002c ... Signed-off-by: Jianguo Wu <[email protected]> Signed-off-by: Jiang Liu <[email protected]> Reviewd-by: Wen Congyang <[email protected]> Acked-by: Johannes Weiner <[email protected]> Reviewed-by: Yasuaki Ishimatsu <[email protected]> Reviewed-by: Michal Hocko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
psanford
pushed a commit
to retailnext/linux
that referenced
this pull request
Sep 9, 2013
Fix the following sparse warnings in the OMAP3/4 CPUIdle code: arch/arm/mach-omap2/cpuidle34xx.c:272:1: warning: symbol 'omap3_idle_dev' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle34xx.c:274:23: warning: symbol 'omap3_idle_driver' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle44xx.c:164:1: warning: symbol 'omap4_idle_dev' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle44xx.c:166:23: warning: symbol 'omap4_idle_driver' was not declared. Should it be static? Also fix the following checkpatch warnings: WARNING: please, no space before tabs torvalds#44: FILE: arch/arm/mach-omap2/cpuidle34xx.c:105: +^I.name = ^I"omap3_idle",$ WARNING: please, no space before tabs torvalds#45: FILE: arch/arm/mach-omap2/cpuidle34xx.c:106: +^I.owner = ^ITHIS_MODULE,$ ERROR: code indent should use tabs where possible torvalds#211: FILE: arch/arm/mach-omap2/cpuidle44xx.c:74: + /* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */$ Signed-off-by: Paul Walmsley <[email protected]> Cc: Kevin Hilman <[email protected]> Acked-by: Santosh Shilimkar <[email protected]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Oct 14, 2013
As the new x86 CPU bootup printout format code maintainer, I am taking immediate action to improve and clean (and thus indulge my OCD) the reporting of the cores when coming up online. Fix padding to a right-hand alignment, cleanup code and bind reporting width to the max number of supported CPUs on the system, like this: [ 0.074509] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK [ 0.644008] smpboot: Booting Node 1, Processors: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 OK [ 1.245006] smpboot: Booting Node 2, Processors: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 OK [ 1.864005] smpboot: Booting Node 3, Processors: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 OK [ 2.489005] smpboot: Booting Node 4, Processors: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 OK [ 3.093005] smpboot: Booting Node 5, Processors: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 OK [ 3.698005] smpboot: Booting Node 6, Processors: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 OK [ 4.304005] smpboot: Booting Node 7, Processors: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 OK [ 4.961413] Brought up 64 CPUs and this: [ 0.072367] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK [ 0.686329] Brought up 8 CPUs Signed-off-by: Borislav Petkov <[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]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Oct 14, 2013
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node #1, CPUs: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node torvalds#6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node torvalds#7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node torvalds#8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <[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]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Oct 14, 2013
on x86 system with net.core.bpf_jit_enable = 1
sudo tcpdump -i eth1 'tcp port 22'
causes the warning:
[ 56.766097] Possible unsafe locking scenario:
[ 56.766097]
[ 56.780146] CPU0
[ 56.786807] ----
[ 56.793188] lock(&(&vb->lock)->rlock);
[ 56.799593] <Interrupt>
[ 56.805889] lock(&(&vb->lock)->rlock);
[ 56.812266]
[ 56.812266] *** DEADLOCK ***
[ 56.812266]
[ 56.830670] 1 lock held by ksoftirqd/1/13:
[ 56.836838] #0: (rcu_read_lock){.+.+..}, at: [<ffffffff8118f44c>] vm_unmap_aliases+0x8c/0x380
[ 56.849757]
[ 56.849757] stack backtrace:
[ 56.862194] CPU: 1 PID: 13 Comm: ksoftirqd/1 Not tainted 3.12.0-rc3+ torvalds#45
[ 56.868721] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[ 56.882004] ffffffff821944c0 ffff88080bbdb8c8 ffffffff8175a145 0000000000000007
[ 56.895630] ffff88080bbd5f40 ffff88080bbdb928 ffffffff81755b14 0000000000000001
[ 56.909313] ffff880800000001 ffff880800000000 ffffffff8101178f 0000000000000001
[ 56.923006] Call Trace:
[ 56.929532] [<ffffffff8175a145>] dump_stack+0x55/0x76
[ 56.936067] [<ffffffff81755b14>] print_usage_bug+0x1f7/0x208
[ 56.942445] [<ffffffff8101178f>] ? save_stack_trace+0x2f/0x50
[ 56.948932] [<ffffffff810cc0a0>] ? check_usage_backwards+0x150/0x150
[ 56.955470] [<ffffffff810ccb52>] mark_lock+0x282/0x2c0
[ 56.961945] [<ffffffff810ccfed>] __lock_acquire+0x45d/0x1d50
[ 56.968474] [<ffffffff810cce6e>] ? __lock_acquire+0x2de/0x1d50
[ 56.975140] [<ffffffff81393bf5>] ? cpumask_next_and+0x55/0x90
[ 56.981942] [<ffffffff810cef72>] lock_acquire+0x92/0x1d0
[ 56.988745] [<ffffffff8118f52a>] ? vm_unmap_aliases+0x16a/0x380
[ 56.995619] [<ffffffff817628f1>] _raw_spin_lock+0x41/0x50
[ 57.002493] [<ffffffff8118f52a>] ? vm_unmap_aliases+0x16a/0x380
[ 57.009447] [<ffffffff8118f52a>] vm_unmap_aliases+0x16a/0x380
[ 57.016477] [<ffffffff8118f44c>] ? vm_unmap_aliases+0x8c/0x380
[ 57.023607] [<ffffffff810436b0>] change_page_attr_set_clr+0xc0/0x460
[ 57.030818] [<ffffffff810cfb8d>] ? trace_hardirqs_on+0xd/0x10
[ 57.037896] [<ffffffff811a8330>] ? kmem_cache_free+0xb0/0x2b0
[ 57.044789] [<ffffffff811b59c3>] ? free_object_rcu+0x93/0xa0
[ 57.051720] [<ffffffff81043d9f>] set_memory_rw+0x2f/0x40
[ 57.058727] [<ffffffff8104e17c>] bpf_jit_free+0x2c/0x40
[ 57.065577] [<ffffffff81642cba>] sk_filter_release_rcu+0x1a/0x30
[ 57.072338] [<ffffffff811108e2>] rcu_process_callbacks+0x202/0x7c0
[ 57.078962] [<ffffffff81057f17>] __do_softirq+0xf7/0x3f0
[ 57.085373] [<ffffffff81058245>] run_ksoftirqd+0x35/0x70
cannot reuse jited filter memory, since it's readonly,
so use original bpf insns memory to hold work_struct
defer kfree of sk_filter until jit completed freeing
tested on x86_64 and i386
Signed-off-by: Alexei Starovoitov <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
shr-buildhost
pushed a commit
to shr-distribution/linux
that referenced
this pull request
Nov 4, 2013
commit ae64ffc upstream. I enable CONFIG_DEBUG_VIRTUAL and CONFIG_SPARSEMEM_VMEMMAP, when doing memory hotremove, there is a kernel BUG at arch/x86/mm/physaddr.c:20. It is caused by free_section_usemap()->virt_to_page(), virt_to_page() is only used for kernel direct mapping address, but sparse-vmemmap uses vmemmap address, so it is going wrong here. ------------[ cut here ]------------ kernel BUG at arch/x86/mm/physaddr.c:20! invalid opcode: 0000 [#1] SMP Modules linked in: acpihp_drv acpihp_slot edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm crc32c_intel ipv6 ixgbe igb iTCO_wdt i7core_edac edac_core pcspkr iTCO_vendor_support ioatdma microcode joydev sr_mod i2c_i801 dca lpc_ich mfd_core mdio tpm_tis i2c_core hid_generic tpm cdrom sg tpm_bios rtc_cmos button ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys hwmon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod CPU 39 Pid: 6454, comm: sh Not tainted 3.7.0-rc1-acpihp-final+ torvalds#45 QCI QSSC-S4R/QSSC-S4R RIP: 0010:[<ffffffff8103c908>] [<ffffffff8103c908>] __phys_addr+0x88/0x90 RSP: 0018:ffff8804440d7c08 EFLAGS: 00010006 RAX: 0000000000000006 RBX: ffffea0012000000 RCX: 000000000000002c ... Signed-off-by: Jianguo Wu <[email protected]> Signed-off-by: Jiang Liu <[email protected]> Reviewd-by: Wen Congyang <[email protected]> Acked-by: Johannes Weiner <[email protected]> Reviewed-by: Yasuaki Ishimatsu <[email protected]> Reviewed-by: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
kees
pushed a commit
to kees/linux
that referenced
this pull request
Nov 8, 2013
BugLink: http://bugs.launchpad.net/bugs/1087865 commit ae64ffc upstream. I enable CONFIG_DEBUG_VIRTUAL and CONFIG_SPARSEMEM_VMEMMAP, when doing memory hotremove, there is a kernel BUG at arch/x86/mm/physaddr.c:20. It is caused by free_section_usemap()->virt_to_page(), virt_to_page() is only used for kernel direct mapping address, but sparse-vmemmap uses vmemmap address, so it is going wrong here. ------------[ cut here ]------------ kernel BUG at arch/x86/mm/physaddr.c:20! invalid opcode: 0000 [#1] SMP Modules linked in: acpihp_drv acpihp_slot edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm crc32c_intel ipv6 ixgbe igb iTCO_wdt i7core_edac edac_core pcspkr iTCO_vendor_support ioatdma microcode joydev sr_mod i2c_i801 dca lpc_ich mfd_core mdio tpm_tis i2c_core hid_generic tpm cdrom sg tpm_bios rtc_cmos button ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys hwmon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod CPU 39 Pid: 6454, comm: sh Not tainted 3.7.0-rc1-acpihp-final+ torvalds#45 QCI QSSC-S4R/QSSC-S4R RIP: 0010:[<ffffffff8103c908>] [<ffffffff8103c908>] __phys_addr+0x88/0x90 RSP: 0018:ffff8804440d7c08 EFLAGS: 00010006 RAX: 0000000000000006 RBX: ffffea0012000000 RCX: 000000000000002c ... Signed-off-by: Jianguo Wu <[email protected]> Signed-off-by: Jiang Liu <[email protected]> Reviewd-by: Wen Congyang <[email protected]> Acked-by: Johannes Weiner <[email protected]> Reviewed-by: Yasuaki Ishimatsu <[email protected]> Reviewed-by: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Herton Ronaldo Krzesinski <[email protected]>
astarasikov
pushed a commit
to astarasikov/linux
that referenced
this pull request
Nov 25, 2013
Fix the following sparse warnings in the OMAP3/4 CPUIdle code: arch/arm/mach-omap2/cpuidle34xx.c:272:1: warning: symbol 'omap3_idle_dev' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle34xx.c:274:23: warning: symbol 'omap3_idle_driver' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle44xx.c:164:1: warning: symbol 'omap4_idle_dev' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle44xx.c:166:23: warning: symbol 'omap4_idle_driver' was not declared. Should it be static? Also fix the following checkpatch warnings: WARNING: please, no space before tabs torvalds#44: FILE: arch/arm/mach-omap2/cpuidle34xx.c:105: +^I.name = ^I"omap3_idle",$ WARNING: please, no space before tabs torvalds#45: FILE: arch/arm/mach-omap2/cpuidle34xx.c:106: +^I.owner = ^ITHIS_MODULE,$ ERROR: code indent should use tabs where possible torvalds#211: FILE: arch/arm/mach-omap2/cpuidle44xx.c:74: + /* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */$ Signed-off-by: Paul Walmsley <[email protected]> Cc: Kevin Hilman <[email protected]>
shr-buildhost
pushed a commit
to shr-distribution/linux
that referenced
this pull request
Nov 30, 2013
commit ae64ffc upstream. I enable CONFIG_DEBUG_VIRTUAL and CONFIG_SPARSEMEM_VMEMMAP, when doing memory hotremove, there is a kernel BUG at arch/x86/mm/physaddr.c:20. It is caused by free_section_usemap()->virt_to_page(), virt_to_page() is only used for kernel direct mapping address, but sparse-vmemmap uses vmemmap address, so it is going wrong here. ------------[ cut here ]------------ kernel BUG at arch/x86/mm/physaddr.c:20! invalid opcode: 0000 [#1] SMP Modules linked in: acpihp_drv acpihp_slot edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm crc32c_intel ipv6 ixgbe igb iTCO_wdt i7core_edac edac_core pcspkr iTCO_vendor_support ioatdma microcode joydev sr_mod i2c_i801 dca lpc_ich mfd_core mdio tpm_tis i2c_core hid_generic tpm cdrom sg tpm_bios rtc_cmos button ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys hwmon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod CPU 39 Pid: 6454, comm: sh Not tainted 3.7.0-rc1-acpihp-final+ torvalds#45 QCI QSSC-S4R/QSSC-S4R RIP: 0010:[<ffffffff8103c908>] [<ffffffff8103c908>] __phys_addr+0x88/0x90 RSP: 0018:ffff8804440d7c08 EFLAGS: 00010006 RAX: 0000000000000006 RBX: ffffea0012000000 RCX: 000000000000002c ... Signed-off-by: Jianguo Wu <[email protected]> Signed-off-by: Jiang Liu <[email protected]> Reviewd-by: Wen Congyang <[email protected]> Acked-by: Johannes Weiner <[email protected]> Reviewed-by: Yasuaki Ishimatsu <[email protected]> Reviewed-by: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>
JoonsooKim
pushed a commit
to JoonsooKim/linux
that referenced
this pull request
May 7, 2014
Add the mailbox device DT node for OMAP5 SoC. The OMAP5 mailbox IP is identical to that used in OMAP4. The OMAP5 hwmod data no longer publishes the module address space, so this patch fixes the WARN_ON backtrace associated with the following trace during the kernel boot: "omap_hwmod: mailbox: doesn't have mpu register target base". Otherwise we get a warning like this: WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() omap_hwmod: mailbox: doesn't have mpu register target base Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-00001-gb5e85a0 torvalds#45 [<c0015724>] (unwind_backtrace) from [<c00120f4>] (show_stack+0x10/0x14) [<c00120f4>] (show_stack) from [<c05a1ccc>] (dump_stack+0x78/0x94) [<c05a1ccc>] (dump_stack) from [<c0042a74>] (warn_slowpath_common+0x6c/0x8c) [<c0042a74>] (warn_slowpath_common) from [<c0042b28>] (warn_slowpath_fmt+0x30/0x40) [<c0042b28>] (warn_slowpath_fmt) from [<c0803b40>] (_init+0x1c0/0x3dc) [<c0803b40>] (_init) from [<c0029c8c>] (omap_hwmod_for_each+0x34/0x5c) [<c0029c8c>] (omap_hwmod_for_each) from [<c08042b0>] (__omap_hwmod_setup_all+0x24/0x40) [<c08042b0>] (__omap_hwmod_setup_all) from [<c00088b8>] (do_one_initcall+0x34/0x160) [<c00088b8>] (do_one_initcall) from [<c07f7bf4>] (kernel_init_freeable+0xfc/0x1c8) [<c07f7bf4>] (kernel_init_freeable) from [<c059c4f4>] (kernel_init+0x8/0xe4) [<c059c4f4>] (kernel_init) from [<c000eaa8>] (ret_from_fork+0x14/0x2c) Signed-off-by: Suman Anna <[email protected]> [[email protected]: updated description to for the warning] Signed-off-by: Tony Lindgren <[email protected]>
ddstreet
referenced
this pull request
in ddstreet/linux
May 12, 2014
GIT 1297af7d710acda27fb289277866e0bcd81c72c8 commit 10d4c6736ea6e6ff293dd588551270bca00ca45d Author: Petri Gynther <[email protected]> Date: Thu May 8 15:50:01 2014 -0700 Bluetooth: btusb: Add Broadcom patch RAM support After hardware reset, some BCM Bluetooth adapters obtain their initial firmware from OTPROM chip. Once this initial firmware is running, the firmware can be further upgraded over HCI interface with .hcd files provided by Broadcom. This is also known as "patch RAM" support. This change implements that. If the .hcd file is not found in /lib/firmware, BCM Bluetooth adapter continues to operate with the initial firmware. Sample kernel log: hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=... Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-22be.hcd not found If the .hcd file is found, btusb driver pushes it to the BCM Bluetooth adapter and it starts using the new firmware. Sample kernel log: hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=... Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=1000 lmp_ver=06 lmp_subver=220e Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=1389 lmp_ver=06 lmp_subver=220e Above, we can see that hci_rev goes from 1000 to 1389 as a result of the upgrade. Signed-off-by: Petri Gynther <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> commit 79bc7681c2880e57f07556263b862bbf383ad209 Author: Seungwon Jeon <[email protected]> Date: Fri May 9 07:02:33 2014 +0900 ARM: dts: disable MDMA1 node for exynos5420 This change places MDMA1 in disabled node for Exynos5420. If MDMA1 region is configured with secure mode, it makes the boot failure with the following on smdk5420 board. ("Unhandled fault: imprecise external abort (0x1406) at 0x00000000") Thus, arndale-octa board don't need to do the same thing anymore. Signed-off-by: Seungwon Jeon <[email protected]> Tested-by: Javi Merino <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 88072246315301323b777465f5c9b643db87aff7 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:57:35 2014 +0900 ARM: EXYNOS: Move the driver to drivers/cpuidle directory Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 5695f45e38ec1a861551f7d1cd177b5e81984b83 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:57:30 2014 +0900 ARM: EXYNOS: Cleanup all unneeded headers from cpuidle.c Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 17c643ecf1219cf8d3b375bdfdc377b9cbc372ae Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:56:29 2014 +0900 ARM: EXYNOS: Pass the AFTR callback to the platform_data No more dependency on the arch code. The platform_data field is used to set the PM callback as the other cpuidle drivers. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 7e4401689ed8c63cfb3f063107b1a07c58bb5830 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:56:24 2014 +0900 ARM: EXYNOS: Move S5P_CHECK_SLEEP into pm.c This macro is only used there. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit f75751d7a1ddf0c3ccc71e0a7117a4be823303d1 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:55:12 2014 +0900 ARM: EXYNOS: Move the power sequence call in the cpu_pm notifier The code to initiate and exit the powerdown sequence is the same in pm.c and cpuidle.c. Let's split the common part in the pm.c and reuse it from the cpu_pm notifier. That is one more step forward to make the cpuidle driver arch indenpendant. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 7ef8dd93099a531fc579648c17125d623e727262 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:53:00 2014 +0900 ARM: EXYNOS: Move the AFTR state function into pm.c In order to remove depedency on pm code, let's move the 'exynos_enter_aftr' function into the pm.c file as well as the other helper functions. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 9c63359488c69a2ab5e0077baa747a9a03eeb909 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:52:59 2014 +0900 ARM: EXYNOS: Encapsulate the AFTR code into a function Let's encapsulate the AFTR state specific call into a single function. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit d9679e49311b7138fa1cbcb20f6c8c3675cc6c1f Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:52:59 2014 +0900 ARM: EXYNOS: Disable cpuidle for exynos5440 There is no point to register the cpuidle driver for the 5440 as it has only one WFI state which is the default idle function when the cpuidle driver is disabled. By disabling cpuidle we prevent to enter to the governor computation for nothing, thus saving a lot of processing time. The only drawback is the statistic via sysfs on this state which is lost but it is meaningless and it could be retrieved from the ftrace easily. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Acked-by: Amit Kucheria <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 63f3ab27db4312c903bc268ac1f5a20a0a28119c Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:52:59 2014 +0900 ARM: EXYNOS: Encapsulate boot vector code into a function for cpuidle Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit b00ca44f02e46a638a92608f257dceeefea1d54f Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:52:59 2014 +0900 ARM: EXYNOS: Pass wakeup mask parameter to function for cpuidle Pass the wakeup mask to 'exynos_set_wakeupmask' as this function could be used for different idle states with different mask. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit ac5369f51081126692fc44ab637ed3c3681ea79a Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:53:26 2014 +0900 ARM: EXYNOS: Remove ifdef for scu_enable in pm The scu_enable function is already a noop in the scu's header file is CONFIG_SMP=n, so no need to use these macros in the code. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit efb148f681d8376122ff60d5c36aa3592d4c2c0d Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:50:16 2014 +0900 ARM: EXYNOS: Move scu_enable in the cpu_pm notifier We make the cpuidle code less arch dependent. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 5e5ee768f80860605ec66fe9e4052db82a7166c5 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:43:27 2014 +0900 ARM: EXYNOS: Use the cpu_pm notifier for pm Use the cpu_pm_enter/exit notifier to group some pm code inside the pm file. The save and restore code is duplicated across pm.c and cpuidle.c. By using the cpu_pm notifier, we can factor out the routine. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 04d2981f15dc93bd52a2c8431afb1456dae7c8fc Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:43:27 2014 +0900 ARM: EXYNOS: Fix S5P_WAKEUP_STAT call for cpuidle This function should be called only when the powerdown sequence fails. Even if the current code does not hurt, by moving this line, we have the same code than the one in pm.c. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit ff15bf49dcce85acd4220512dc30523a12e3bb81 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:43:27 2014 +0900 ARM: EXYNOS: Move some code inside the idle_finisher for cpuidle Move the code around to differentiate different section of code and prepare it to be factored out in the next patches. The call order changed but hat doesn't have a side effect because they are independent. The important call is cpu_do_idle() which must be done the last. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit e102ca61840e80ef6e347e81b17b2eff088290e9 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:43:27 2014 +0900 ARM: EXYNOS: Encapsulate register access inside a function for pm That makes the code cleaner and encapsulted. The function will be reused in the next patch. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 905e625e9411841cfc1ede8886f8df6153babd19 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:43:26 2014 +0900 ARM: EXYNOS: Change function name prefix for cpuidle The driver was initially written for exynos4 but the driver is used also for exynos5. Change the function prefix name exynos4 -> exynos Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit c60cdc63176588a0e715e4da3984a3ea0efc5858 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:43:26 2014 +0900 ARM: EXYNOS: Use cpuidle_register Use the cpuidle generic function 'cpuidle_register'. That saves us from some extra lines of code and unneeded variables. A side effect of this change is a bug fix where before the cpuidle driver was registered for each_online_cpu and now it is for each_possible_cpu. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 59b52960dac2e4d35959a459f5ef2895927e95c1 Author: Daniel Lezcano <[email protected]> Date: Fri May 9 06:43:26 2014 +0900 ARM: EXYNOS: Prevent forward declaration for cpuidle Move the structure below the 'exynos4_enter_lowpower' function so no more need of forward declaration. Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit cfbad697765dea7eb0478ae4234dd3a35cbb8f16 Author: Amit Daniel Kachhap <[email protected]> Date: Fri May 9 06:43:26 2014 +0900 ARM: EXYNOS: Move arm core power down clock to exynos5250 common clock Now with common clock support added for exynos5250 it is necessary to move this code to exynos5250 common clock driver as clock registers should be handled there. This change is tested in exynos5250 based arndale platform. Cc: Abhilash Kesavan <[email protected]> Cc: Thomas Abraham <[email protected]> Acked-by: Kukjin Kim <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Signed-off-by: Amit Daniel Kachhap <[email protected]> [t.figa: Rebased onto current kernel sources.] Signed-off-by: Tomasz Figa <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 9c88669c2cfc91158f157b5584103ff7e5b6bedb Author: Axel Lin <[email protected]> Date: Wed Apr 9 17:21:26 2014 +0800 pwm: twl: Really disable twl6030 PWMs Current twl6030_pwm_disable() implementation writes TWL6030_TOGGLE3_REG twice, the second write sets TWL6030_PWMXEN bits so the PWM clock does not disable. Signed-off-by: Axel Lin <[email protected]> Acked-by: Peter Ujfalusi <[email protected]> Signed-off-by: Thierry Reding <[email protected]> commit 29a61d83ad2da88bbbadb554b72fdd2c3bb36c63 Author: Ivan Khoronzhuk <[email protected]> Date: Thu May 8 17:31:01 2014 -0400 ARM: dts: k2l-evm: add AEMIF/NAND device entry Add AEMIF/NAND device entry. Signed-off-by: Ivan Khoronzhuk <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 81141a027c5d0c49373e4af7d068b0ca5ad6442a Author: Rahul Sharma <[email protected]> Date: Fri May 9 06:26:44 2014 +0900 ARM: dts: add dts files for exynos5260-xyref5260 board The patch adds the dts files for xyref5260 board which is based on exynos5260 SoC. Signed-off-by: Rahul Sharma <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit af6cf11c31763c49c8f0a64e4be23fab58bb019e Author: Rahul Sharma <[email protected]> Date: Fri May 9 06:26:41 2014 +0900 ARM: dts: add dts files for exynos5260 SoC The patch adds the dts files for exynos5260. Signed-off-by: Pankaj Dubey <[email protected]> Signed-off-by: Rahul Sharma <[email protected]> Signed-off-by: Arun Kumar K <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Reviewed-by: Sachin Kamat <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 95711059c5286b320ca08ebc33966994ac26d5aa Author: Jens Axboe <[email protected]> Date: Thu May 8 15:26:30 2014 -0600 blk-mq: cleanup some leftover code from the double tagging scheme Don't need ->use_bitmap_tags anymore, and we need not print what kind of tagging type we selected. Signed-off-by: Jens Axboe <[email protected]> commit 8b144ffd7b6c8edbdc881b0a32858e1447fa441f Author: Ivan Khoronzhuk <[email protected]> Date: Thu May 8 17:19:08 2014 -0400 ARM: dts: k2e-evm: add AEMIF/NAND device entry Add AEMIF/NAND device entry. Signed-off-by: Ivan Khoronzhuk <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 4bfb5edef0cc4387d0760f5eb2d0dcfabc237b95 Author: Kyungmin Park <[email protected]> Date: Fri May 9 06:19:18 2014 +0900 ARM: EXYNOS: Support secondary CPU boot of exynos4212 This patch fix the offset of CPU boot address and change parameter of smc call of SMC_CMD_CPU1BOOT command for Exynos4212. Signed-off-by: Kyungmin Park <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit b10fd728b985ae2d18ce9bf4c2161a6eb002683c Author: Jens Axboe <[email protected]> Date: Thu May 8 15:12:07 2014 -0600 mtip32xx: convert to use blk-mq This rips out timeout handling, requeueing, etc in converting it to use blk-mq instead. Signed-off-by: Jens Axboe <[email protected]> commit 437ec65fa3c937b5f8b9c0573f60a327320937e3 Author: Jens Axboe <[email protected]> Date: Thu May 8 15:05:12 2014 -0600 blk-mq: implement new and more efficient tagging scheme blk-mq currently uses percpu_ida for tag allocation. But that only works well if the ratio between tag space and number of CPUs is sufficiently high. For most devices and systems, that is not the case. The end result if that we either only utilize the tag space partially, or we end up attempting to fully exhaust it and run into lots of lock contention with stealing between CPUs. This is not optimal. This new tagging scheme is a hybrid bitmap allocator. It uses two tricks to both be SMP friendly and allow full exhaustion of the space: 1) We cache the last allocated (or freed) tag on a per blk-mq software context basis. This allows us to limit the space we have to search. The key element here is not caching it in the shared tag structure, otherwise we end up dirtying more shared cache lines on each allocate/free operation. 2) The tag space is split into cache line sized groups, and each context will start off randomly in that space. Even up to full utilization of the space, this divides the tag users efficiently into cache line groups, avoiding dirtying the same one both between allocators and between allocator and freeer. This scheme shows drastically better behaviour, both on small tag spaces but on large ones as well. It has been tested extensively to show better performance for all the cases blk-mq cares about. Signed-off-by: Jens Axboe <[email protected]> commit 78bb0b8c61ab00fb1c61653464ab6c26e8b47558 Author: Jens Axboe <[email protected]> Date: Thu May 8 15:03:42 2014 -0600 wait: make prepare_to_wait() return if it added task to wait queue The caller can make some decisions based on whether or not the task was already on the waitqueue. blk-mq will use this for batched wakeups on tag frees. Signed-off-by: Jens Axboe <[email protected]> commit 3528dd34b2d3dc642669fd12399e18a16e3aacc8 Author: Arun Kumar K <[email protected]> Date: Fri May 9 06:06:25 2014 +0900 ARM: dts: Add exynos5420 peach-pit board support Adds the google peach-pit board dts file which uses exynos5420 SoC. Signed-off-by: Arun Kumar K <[email protected]> Signed-off-by: Doug Anderson <[email protected]> Reviewed-by: Doug Anderson <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 8e371a91d98e8d8d032c6032eb0ac6e2bbcb231f Author: Arun Kumar K <[email protected]> Date: Fri May 9 06:06:24 2014 +0900 ARM: dts: Add node labels to exynos5420 Adding labels to nodes which do not have it yet in exynos5420. This is done so as to use reference based node updation in board files. Signed-off-by: Arun Kumar K <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Reviewed-by: Doug Anderson <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit c4539e88e758901c298ee1f6c0e19471be693f54 Author: Arun Kumar K <[email protected]> Date: Fri May 9 06:06:10 2014 +0900 ARM: dts: Add pwmX_out pinctrl nodes to exynos5420 Adds the PWM nodes to 5420 pinctrl dtsi file. Signed-off-by: Arun Kumar K <[email protected]> Reviewed-by: Doug Anderson <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 4cb378646ef85e76745225912025871f3dc93ca3 Author: Sylwester Nawrocki <[email protected]> Date: Fri May 9 06:01:40 2014 +0900 ARM: dts: Add rear camera nodes for exynos4412-trats2 This patch enables the rear facing camera (s5c73m3) on TRATS2 board by adding the I2C0 bus controller, s5c73m3 sensor, MIPI CSI-2 receiver and the sensor's voltage regulator supply nodes. Signed-off-by: Andrzej Hajda <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Sylwester Nawrocki <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit ee5eda64af051097c00534db7c5432c4a061d355 Author: Sylwester Nawrocki <[email protected]> Date: Fri May 9 06:00:35 2014 +0900 ARM: dts: Update camera nodes for exynos4 and exynos4412-trats2 Remove unused /camera/clock-controller node and add required clock properties to the camera node. This is required for a clock provider that will be referenced by image sensor devices. Also add required clock related changes to s5k6a3 device node and afvdd regulator supply. Signed-off-by: Sylwester Nawrocki <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 6af2ba90818f9e9c4b8711e1f896e797c5da151c Author: Tomasz Stanislawski <[email protected]> Date: Fri May 9 05:58:59 2014 +0900 ARM: dts: rename alias for i2c_ak8975 label for exynos4412-trats2 The i2c_ak8975 controller uses label i2c8. This alias is already used for I2C controller 8 defined in file arch/arm/boot/dts/exynos4.dtsi. This patch renames a label for i2c_ak8975 to i2c9. Signed-off-by: Tomasz Stanislawski <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 9c869d1f07852b47ae8578c14161ec2821682464 Author: Tomasz Stanislawski <[email protected]> Date: Fri May 9 05:55:42 2014 +0900 ARM: dts: add missing pinctrls for I2C of exynos4 This patch adds missing pinctrls for I2C controllers 2-7. Signed-off-by: Tomasz Stanislawski <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit c92ecf94d3156f79825a994e509aa070ceebae88 Author: Christoph Hellwig <[email protected]> Date: Tue May 6 12:12:45 2014 +0200 blk-mq: initialize struct request fields individually This allows us to avoid a non-atomic memset over ->atomic_flags as well as killing lots of duplicate initializations. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit face4c34519c38eda4020ab9964e5b55fcfbaa4a Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:51:43 2014 +0900 ARM: S3C24XX: remove SAMSUNG_CLOCK remnants after ccf conversion This finally removes all remaining SAMSUNG_CLOCK conditional code from s3c24xx architectures. Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 8fb211f9c6c32e938ebbc03e6de6300156f911d7 Author: Jens Axboe <[email protected]> Date: Thu May 8 14:50:19 2014 -0600 blk-mq: update a hotplug comment for grammar Signed-off-by: Jens Axboe <[email protected]> commit 597000cf07742cd218d1c16bc7600fa2a6a884cd Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:49:36 2014 +0900 ARM: S3C24XX: remove legacy clock code With the move to the common clock framework completed for s3c2410, s3c2440 and s3c2442, the legacy clock code for these machines can go away too. This also includes the legacy dclk code, as all legacy users are converted. Signed-off-by: Heiko Stuebner <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 355c9f77a6d9f41f390bb776b7e561458afbcf39 Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:49:29 2014 +0900 ARM: S3C24XX: convert s3c2410 to common clock framework Convert the machines using the s3c2410 to use the new driver based on the common clock framework instead of the legacy Samsung clock driver. As with the s3c244x, machines using the clkout output will need a fixup from someone with the hardware. Signed-off-by: Heiko Stuebner <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit abe9f29b0471d1e7ff1ef4ae94bcc6b1525e15f9 Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:49:19 2014 +0900 ARM: S3C24XX: convert s3c2440 and s3c2442 to common clock framework Convert all machines using these cpus to use the ccf clock driver instead of the legacy Samsung clock implementation. Some of the more esotheric machines will probably need a fixup, as they do strange things to the clkout outputs, that I did not really understand nor have the hardware to check. Signed-off-by: Heiko Stuebner <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 1a54e4342c42e01f0117c05d8bb2c9309cc435e8 Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:49:14 2014 +0900 ARM: S3C24XX: add platform code for conversion to the common clock framework This adds the necessary init functions to init the clocks from the common clock framework and necessary CONFIG_SAMSUNG_CLOCK ifdefs around the legacy clock code. This also includes empty stubs for the *_setup_clocks functions that are called from the cpufreq driver on resume. Signed-off-by: Heiko Stuebner <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 6dc8f9c7783546483d0b86e18e78896c2d31ae86 Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:49:10 2014 +0900 clk: samsung: add clock controller driver for s3c2410, s3c2440 and s3c2442 This driver can handle the clock controllers of the socs mentioned above, as they share a common clock tree with only small differences. The clock structure is built according to the manuals of the included SoCs and might include changes in comparison to the previous clock structure. As pll-rate-tables only the 12mhz variants are currently included. The original code was wrongly checking for 169mhz xti values [a 0 to much at the end], so the original 16mhz pll table would have never been included and its values are so obscure that I have no possibility to at least check their sane-ness. When using the formula from the manual the resulting frequency is near the table value but still slightly off. Signed-off-by: Heiko Stuebner <[email protected]> Acked-by: Mike Turquette <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 639335c0f488b948c8946f2ba421113544905587 Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:49:05 2014 +0900 dt-bindings: add documentation for s3c2410 clock controller Describe the clock controller of s3c2410, s3c2440 and s3c2442. Signed-off-by: Heiko Stuebner <[email protected]> Acked-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 4d4cfe75853f61219b08244748d1d4f9634726db Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:48:57 2014 +0900 ARM: S3C24XX: enable usage of common dclk if common clock framework is enabled Add platform device and select the correct implementation automatically depending on wether the old samsung_clock or the common clock framework is enabled. This is only done for machines already using the old dclk implementation, as everybody else should move to use dt anyway. The machine-specific settings for the external clocks will have to be set by somebody with knowledge about the specific hardware. Signed-off-by: Heiko Stuebner <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 5799ea12a41286d9588155a1abd828f43bc63d6b Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:48:51 2014 +0900 clk: samsung: add clock driver for external clock outputs This adds a driver for controlling the external clock outputs of s3c24xx architectures including the dclk muxes and dividers. The driver at the moment only supports the legacy non-dt boards using these clock outputs. The clock-output control itself is part of the system-controller mainly controlled by the pinctrl drivers. So it should most likely be integrated there for dt platforms. Signed-off-by: Heiko Stuebner <[email protected]> Acked-by: Mike Turquette <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit d8b532578f39fdec159105bc415938910351a699 Author: Heiko Stuebner <[email protected]> Date: Fri May 9 05:48:44 2014 +0900 ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf The s3c24xx cpufreq driver needs to change the mpll speed and was doing this by writing raw values from a translation table into the MPLLCON register. Change this to use a regular clk_set_rate call when using the common clock framework and only write the raw value in the samsung_clock case. The s3c cpufreq driver does already aquire the mpll, so simply add a reference to struct s3c_cpufreq_config to let set_fvco access it. While struct clk is opaque the differenciation between samsung clock and common clock is kept, as the samsung-clock mpll clk does not implement a real set_rate. Signed-off-by: Heiko Stuebner <[email protected]> Acked-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 1eaade629f5c479f5f043c8c24e5daa7029b5e2e Author: Jens Axboe <[email protected]> Date: Thu May 8 14:46:27 2014 -0600 blk-mq: track software context online status seperately By separating it from the system notion of a specific CPU being online or not, we get away from problems with ordering of the CPU hotplug notifiers. Signed-off-by: Jens Axboe <[email protected]> commit 14f3791439b5a6cf12127fb80204265533d92664 Author: Santosh Shilimkar <[email protected]> Date: Mon Feb 24 17:32:59 2014 +0200 ARM: keystone: Update the dma offset for non-dt platform devices Tested-by: Grygorii Strashko <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 5eb3da7246a5b2dfac9f38a7be62b1a0295584c7 Author: Santosh Shilimkar <[email protected]> Date: Thu Jun 13 19:24:39 2013 -0400 ARM: keystone: Switch over to coherent memory address space With late code patching updates for LPAE machines has merged now and memblock conversion from bootmem is on its way, Keystone can switch to the coherent memory address space which starts beyond 4GB boundary. The idmap alias needs are managed via virt_to_idmap() for boot purpose. Tested-by: Grygorii Strashko <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 27379350a9cb6f39e136325d33b9cc9357da263e Author: Brian Norris <[email protected]> Date: Thu May 8 15:34:28 2014 -0400 ARM: configs: keystone: add MTD_SPI_NOR (new dependency for M25P80) This defconfig contains the CONFIG_M25P80 symbol, which is now dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to satisfy the new dependency. Signed-off-by: Brian Norris <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit efdd1946c44e0d5fdf36e03176705260145d122b Author: Lad Prabhakar <[email protected]> Date: Thu May 8 15:32:46 2014 -0400 ARM: configs: keystone: drop CONFIG_COMMON_CLK_DEBUG this patch removes COMMON_CLK_DEBUG config option from defconfig file as this config option is obsolete. Signed-off-by: Lad, Prabhakar <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 86156978a398dfc92294653c49c9374aaa6e5316 Author: Santosh Shilimkar <[email protected]> Date: Mon Feb 24 16:42:19 2014 -0500 ARM: dts: keystone: Update USB node for dma properties Keystone supports dma-coherent on USB master and also needs dma-ranges to specify the hardware alias memory range in which DMA can be operational. Cc: Russell King <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Olof Johansson <[email protected]> Cc: Grant Likely <[email protected]> Cc: Rob Herring <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 4d46596d789d86441eeb1f02bb6d9ea10215fa5d Author: Grygorii Strashko <[email protected]> Date: Wed Feb 12 19:20:16 2014 +0200 ARM: dts: keystone: Use dma-ranges property The dma-ranges property has to be specified per bus and has format: < DMA addr > - Base DMA address for Bus (Bus format 32-bits) < CPU addr > - Corresponding base CPU address (CPU format 64-bits) < DMA range size > - Size of supported DMA range Cc: Russell King <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Olof Johansson <[email protected]> Cc: Grant Likely <[email protected]> Cc: Rob Herring <[email protected]> Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 509046a7b00cf540e49d3072b1efe7cb0b1bdc20 Author: Grygorii Strashko <[email protected]> Date: Mon Apr 28 15:20:22 2014 +0300 ARM: dts: keystone: add cell's information to spi nodes SPI nodes should always have #address-cells and #size-cells defined, otherwise warnings will be produced in case of adding any child nodes to the SPI bus in DT: Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/spi@21000400/n25q128a11@0 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/spi@21000400/n25q128a11@0 Hence, ensure that all SPIx nodes have #address-cells and #size-cells properties defined. Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit e42d8a7f966b7b3b817adece0573d07754a647d2 Author: Grygorii Strashko <[email protected]> Date: Tue Apr 8 14:46:07 2014 +0300 ARM: dts: keystone: move i2c0 device node from SoC to board files I2C devices are not the part of Keystone SoC and have to be defined in board DTS files. Hence, move i2c0 EEPROM device node from Keystone SoC to k2hk, k2e, k2l EVM files as they all have similar EEPROM SoCs installed. Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 3953505afbb80bfcf0e9dc2ba7199e63b0fef69f Author: Grygorii Strashko <[email protected]> Date: Tue Apr 8 14:46:06 2014 +0300 ARM: dts: keystone: add cell's information to i2c nodes I2C nodes should always have #address-cells and #size-cells defined, otherwise warnings will be produced in case of adding child nodes to the I2C bus in DT: Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/i2c@2530800/pca@20 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/i2c@2530800/pca@20 Hence, ensure that all i2cX nodes have #address-cells and #size-cells properties defined. Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 5e014d0c020d37af897a0867bc1840f098bf3cee Author: Lucas Stach <[email protected]> Date: Mon Apr 14 16:18:13 2014 +0200 ARM: dts: keystone: drop address and size cells from GIC node This is likely a copy-and-paste error from the ARM GIC documentation, that has already been fixed. address-cells should have been set to 0, as with the size cells. As having those properties set to 0 is the same thing as not specifying them, drop them completely. Signed-off-by: Lucas Stach <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> commit 9fa1959e976f7a6ae84f616ca669359028070c61 Author: Kinglong Mee <[email protected]> Date: Tue Apr 8 13:06:28 2014 +0800 NFSD: Get rid of empty function nfs4_state_init Signed-off-by: Kinglong Mee <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> commit f3e41ec5ef0f5d2e10b6bfd3a13dc29f6d260d79 Author: Kinglong Mee <[email protected]> Date: Tue Apr 8 13:04:01 2014 +0800 NFSD: Use simple_read_from_buffer for coping data to userspace Signed-off-by: Kinglong Mee <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> commit ecca063b31b88d31ee79e9d958ea78023659554e Author: Kinglong Mee <[email protected]> Date: Tue Apr 15 17:13:56 2014 +0800 SUNRPC: Fix printk that is not only for nfsd Signed-off-by: Kinglong Mee <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> commit c5c0903b2cda930c76d296419d290137294779f2 Author: Borislav Petkov <[email protected]> Date: Thu May 8 20:37:07 2014 +0200 EDAC, MCE, AMD: Remove leftover unused mask 295d8cda2689 ("EDAC, MCE, AMD: Drop local coreid reporting") removed the code snippet which used that mask but forgot to drop the mask itself. Do that now. Signed-off-by: Borislav Petkov <[email protected]> commit 0cac6fc3eb5218fe40d1c2910abc643ab21d9f19 Author: Vinod Koul <[email protected]> Date: Mon May 5 14:27:52 2014 +0530 ASoC: Intel: rename pcm dias to media dai this is for further updates to driver which supports DPCM :) Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 6f46c0d33e76db2c820c47e9af61e0e3dba10a68 Author: Vinod Koul <[email protected]> Date: Mon May 5 14:27:51 2014 +0530 ASoC: Intel: remove unused sst-mfld platform dais With DPCM we have media dai used and no seperate headset and speaker dai so remove the speaker dai The vibra is no longer supported thru audio, so remove Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 4b68b4e1c564f32e4eb18186749b29c9a78772f4 Author: Vinod Koul <[email protected]> Date: Mon May 5 14:27:50 2014 +0530 ASoC: Intel: split the pcm and compress to different files For manging them and adding support for more platforms Code move only Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 4496ffab7dade2206f3d5dea86b9928a5f173de2 Author: Vinod Koul <[email protected]> Date: Mon May 5 14:27:49 2014 +0530 ASoC: Intel: mark sst_set_stream_status as non static as this will be used in compressed split file in subsequent patch Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit e11fd7c3ac49e2294f9562b6329ca50923e56fa7 Author: Vinod Koul <[email protected]> Date: Mon May 5 14:27:48 2014 +0530 ASoc: Intel: rename sst-mfld-platform.c to sst-mfld-platform-pcm.c so that we can split pcm and compress to different files for upcoming changes to support more platforms Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 300f53bf199f660bea3ed7afe9fd938064f19c15 Author: Vinod Koul <[email protected]> Date: Mon May 5 14:27:47 2014 +0530 ASoC: Intel: remove FSF snail mail address As this address can move Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 2b4c78df056a7231635cf629380486a074daf56b Author: Vinod Koul <[email protected]> Date: Mon May 5 22:19:25 2014 +0530 ASoC: Intel: move component registration blob to the place near it is used Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 555f8a80c397b1a6ffccb294525df6ca2d721585 Author: Liam Girdwood <[email protected]> Date: Mon May 5 17:31:37 2014 +0100 ASoC: Intel: Add support to unload/reload firmware modules. Add some SST API calls to unload and reload firmware modules. This can be used by PM code to restore state and also allow modular FW to unload and release memory blocks. Signed-off-by: Liam Girdwood <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 6f1c9c57b4e0783acca9c0fe53850f24d30785a3 Author: Charles Keepax <[email protected]> Date: Thu May 8 17:17:38 2014 +0100 regulator: arizona-micsupp: Add missing #include of.h is presently being included through asm-generic/gpio.h so will not be included on some architectures, causing implicit declaration errors for of_get_child_by_name, of_parse_phandle and of_node_put. This patch adds the direct include that should be there. Reported-by: Arnd Bergmann <[email protected]> Signed-off-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 9f0affcf3e21fc56d8bce625bb3d5800b7a7d284 Author: Vincent Stehlé <[email protected]> Date: Tue May 6 22:23:02 2014 +0200 ARM: mvebu: Fix pmsu compilation when ARMv6 is selected When compiling for multiplatform for both ARMv6 and ARMv7, the default compiler flags are for ARMv6, and we will get: /tmp/ccwDEzd0.s: Assembler messages: /tmp/ccwDEzd0.s:639: Error: selected processor does not support ARM mode `isb ' /tmp/ccwDEzd0.s:645: Error: selected processor does not support ARM mode `isb ' /tmp/ccwDEzd0.s:646: Error: selected processor does not support ARM mode `dsb ' /tmp/ccwDEzd0.s:695: Error: selected processor does not support ARM mode `isb ' make[1]: *** [arch/arm/mach-mvebu/pmsu.o] Error 1 Fix this in a similar manner than done previously in commit 72533b77d30c2be02672e26b5dde1263d7b4c2be, by specifying ARMv7 flags for pmsu.o. Signed-off-by: Vincent Stehlé <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Cc: Jason Cooper <[email protected]> Cc: Andrew Lunn <[email protected]> Cc: Gregory Clement <[email protected]> Cc: Sebastian Hesselbarth <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit 5409e46f1bcf960c651f3fff35f2f25e539655cf Author: Christoph Hellwig <[email protected]> Date: Wed May 7 13:49:44 2014 +0200 nfsd: clean up fh_auth usage Use fh_fsid when reffering to the fsid part of the filehandle. The variable length auth field envisioned in nfsfh wasn't ever implemented. Also clean up some lose ends around this and document the file handle format better. Btw, why do we even export nfsfh.h to userspace? The file handle very much is kernel private, and nothing in nfs-utils include the header either. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> commit ecc7455d8eb1860f5aa6b9ad82a9a81f93eb11d1 Author: Kinglong Mee <[email protected]> Date: Wed May 7 23:08:04 2014 +0800 NFSD: cleanup unneeded including linux/export.h commit 4ac7249ea5a0ceef9f8269f63f33cc873c3fac61 have remove all EXPORT_SYMBOL, linux/export.h is not needed, just clean it. Signed-off-by: Kinglong Mee <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> commit aa07c713ecfc0522916f3cd57ac628ea6127c0ec Author: Kinglong Mee <[email protected]> Date: Fri Apr 18 20:49:04 2014 +0800 NFSD: Call ->set_acl with a NULL ACL structure if no entries After setting ACL for directory, I got two problems that caused by the cached zero-length default posix acl. This patch make sure nfsd4_set_nfs4_acl calls ->set_acl with a NULL ACL structure if there are no entries. Thanks for Christoph Hellwig's advice. First problem: ............ hang ........... Second problem: [ 1610.167668] ------------[ cut here ]------------ [ 1610.168320] kernel BUG at /root/nfs/linux/fs/nfsd/nfs4acl.c:239! [ 1610.168320] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC [ 1610.168320] Modules linked in: nfsv4(OE) nfs(OE) nfsd(OE) rpcsec_gss_krb5 fscache ip6t_rpfilter ip6t_REJECT cfg80211 xt_conntrack rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw auth_rpcgss nfs_acl snd_intel8x0 ppdev lockd snd_ac97_codec ac97_bus snd_pcm snd_timer e1000 pcspkr parport_pc snd parport serio_raw joydev i2c_piix4 sunrpc(OE) microcode soundcore i2c_core ata_generic pata_acpi [last unloaded: nfsd] [ 1610.168320] CPU: 0 PID: 27397 Comm: nfsd Tainted: G OE 3.15.0-rc1+ #15 [ 1610.168320] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 1610.168320] task: ffff88005ab653d0 ti: ffff88005a944000 task.ti: ffff88005a944000 [ 1610.168320] RIP: 0010:[<ffffffffa034d5ed>] [<ffffffffa034d5ed>] _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd] [ 1610.168320] RSP: 0018:ffff88005a945b00 EFLAGS: 00010293 [ 1610.168320] RAX: 0000000000000001 RBX: ffff88006700bac0 RCX: 0000000000000000 [ 1610.168320] RDX: 0000000000000000 RSI: ffff880067c83f00 RDI: ffff880068233300 [ 1610.168320] RBP: ffff88005a945b48 R08: ffffffff81c64830 R09: 0000000000000000 [ 1610.168320] R10: ffff88004ea85be0 R11: 000000000000f475 R12: ffff880068233300 [ 1610.168320] R13: 0000000000000003 R14: 0000000000000002 R15: ffff880068233300 [ 1610.168320] FS: 0000000000000000(0000) GS:ffff880077800000(0000) knlGS:0000000000000000 [ 1610.168320] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1610.168320] CR2: 00007f5bcbd3b0b9 CR3: 0000000001c0f000 CR4: 00000000000006f0 [ 1610.168320] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1610.168320] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1610.168320] Stack: [ 1610.168320] ffffffff00000000 0000000b67c83500 000000076700bac0 0000000000000000 [ 1610.168320] ffff88006700bac0 ffff880068233300 ffff88005a945c08 0000000000000002 [ 1610.168320] 0000000000000000 ffff88005a945b88 ffffffffa034e2d5 000000065a945b68 [ 1610.168320] Call Trace: [ 1610.168320] [<ffffffffa034e2d5>] nfsd4_get_nfs4_acl+0x95/0x150 [nfsd] [ 1610.168320] [<ffffffffa03400d6>] nfsd4_encode_fattr+0x646/0x1e70 [nfsd] [ 1610.168320] [<ffffffff816a6e6e>] ? kmemleak_alloc+0x4e/0xb0 [ 1610.168320] [<ffffffffa0327962>] ? nfsd_setuser_and_check_port+0x52/0x80 [nfsd] [ 1610.168320] [<ffffffff812cd4bb>] ? selinux_cred_prepare+0x1b/0x30 [ 1610.168320] [<ffffffffa0341caa>] nfsd4_encode_getattr+0x5a/0x60 [nfsd] [ 1610.168320] [<ffffffffa0341e07>] nfsd4_encode_operation+0x67/0x110 [nfsd] [ 1610.168320] [<ffffffffa033844d>] nfsd4_proc_compound+0x21d/0x810 [nfsd] [ 1610.168320] [<ffffffffa0324d9b>] nfsd_dispatch+0xbb/0x200 [nfsd] [ 1610.168320] [<ffffffffa00850cd>] svc_process_common+0x46d/0x6d0 [sunrpc] [ 1610.168320] [<ffffffffa0085433>] svc_process+0x103/0x170 [sunrpc] [ 1610.168320] [<ffffffffa032472f>] nfsd+0xbf/0x130 [nfsd] [ 1610.168320] [<ffffffffa0324670>] ? nfsd_destroy+0x80/0x80 [nfsd] [ 1610.168320] [<ffffffff810a5202>] kthread+0xd2/0xf0 [ 1610.168320] [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40 [ 1610.168320] [<ffffffff816c1ebc>] ret_from_fork+0x7c/0xb0 [ 1610.168320] [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40 [ 1610.168320] Code: 78 02 e9 e7 fc ff ff 31 c0 31 d2 31 c9 66 89 45 ce 41 8b 04 24 66 89 55 d0 66 89 4d d2 48 8d 04 80 49 8d 5c 84 04 e9 37 fd ff ff <0f> 0b 90 0f 1f 44 00 00 55 8b 56 08 c7 07 00 00 00 00 8b 46 0c [ 1610.168320] RIP [<ffffffffa034d5ed>] _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd] [ 1610.168320] RSP <ffff88005a945b00> [ 1610.257313] ---[ end trace 838254e3e352285b ]--- Signed-off-by: Kinglong Mee <[email protected]> Cc: [email protected] Signed-off-by: J. Bruce Fields <[email protected]> commit 39438567179536c9f32e85d19586a11aebe1f860 Author: Thomas Petazzoni <[email protected]> Date: Mon May 5 17:05:26 2014 +0200 ARM: mvebu: conditionalize Armada 375 coherency workaround The Armada 375 coherency workaround only needs to be applied to the Z1 revision of the SoC. The A0 and later revisions have been fixed, and no longer need this workaround. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1399302326-6917-6-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit a58d5af7d992a5e6dd8e55b3e618bd77f0368b57 Author: Thomas Petazzoni <[email protected]> Date: Mon May 5 17:05:25 2014 +0200 ARM: mvebu: conditionalize Armada 375 SMP workaround The Armada 375 SMP workaround only needs to be applied to the Z1 revision of the SoC. The A0 and later revisions have been fixed, and no longer need this workaround. Note that the initialization of the SMP workaround is delayed from ->smp_prepare_cpus() to ->smp_boot_secondary() because when ->smp_prepare_cpus() is called, the early initcalls have not be called, so the mvebu-soc-id mechanism is not operational. Since the workaround is anyway not needed before the secondary CPU is started, we can delay its implementation until the ->smp_boot_secondary() call. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1399302326-6917-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit 5093dcfb422d212ccdd22450bd986a2fb03cfb9f Author: Thomas Petazzoni <[email protected]> Date: Mon May 5 17:05:24 2014 +0200 ARM: mvebu: add Armada 375 A0 revision definition Now that we have access to Armada 375 A0 platforms, we can add the corresponding revision definition in mvebu-soc-id.h. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1399302326-6917-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit 73c3c79137f05de2ffcfec3469e4110e40dd1522 Author: Thomas Petazzoni <[email protected]> Date: Mon May 5 17:05:23 2014 +0200 ARM: mvebu: initialize mvebu-soc-id earlier Currently, the mvebu-soc-id logic is initialized through a core_initcall(). However, we will soon need to know the SoC revision before booting secondary CPUs, because a workaround affects Armada 375 Z1 steppings, but should not be applied on Armada 375 A0 steppings. Unfortunately, core_initcall() are called way too late compared to the SMP initialization. Therefore, the mvebu-soc-id initialization is move to an early_initcall(), which is called before the SMP initialization. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1399302326-6917-3-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit c1a01a0360f6744c9c1735e5db7b208df819156e Author: Thomas Petazzoni <[email protected]> Date: Mon May 5 17:05:22 2014 +0200 ARM: mvebu: fix thermal quirk SoC revision check In commit 54fe26a900bc528f3df1e4235cb6b9ca5c6d4dc2 ('ARM: mvebu: Add thermal quirk for the Armada 375 DB board'), a check on the Armada SoC revision was added to decide whether a quirk for the thermal device should be applied or not. However, the quirk implementation has a bug: it assumes mvebu_get_soc_id() returns true on success, but it returns 0. Therefore, the condition: if (mvebu_get_soc_id(&dev, &rev) && rev > ARMADA_375_Z1_REV) is always false (as long as mvebu-soc-id is properly initialized). As a consequence, the quirk is always applied, even on A0 steppings, for which the quirk should not be applied. This was spotted by testing the thermal driver on Armada 375 A0, which Ezequiel could not do since he does not have access to the A0 revision of the SoC for the moment. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1399302326-6917-2-git-send-email-thomas.petazzoni@free-electrons.com Fixes: 54fe26a900bc528f3df1e4235cb6b9ca5c6d4dc2 ('ARM: mvebu: Add thermal quirk for the Armada 375 DB board') Acked-by: Ezequiel Garcia <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit efdf811d82b8001781087fd9174bb90a9530e578 Author: Andrew Lunn <[email protected]> Date: Sat May 3 20:30:16 2014 +0200 ARM: Kirkwood: t5325: Remove platform device to instantiate audio Remove platform device instantiating of the audio, which results in board-t5325.c being removed. A DT node will be added to take its place. Signed-off-by: Andrew Lunn <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jason Cooper <[email protected]> commit 7745b2512898e23507753513f7b5262ea1458135 Author: Andrew Lunn <[email protected]> Date: Sat May 3 20:30:12 2014 +0200 ARM: Kirkwood: Remove platform driver for codec Remove the platform driver and platform data for the audio codec. A DT node will replace it. Signed-off-by: Andrew Lunn <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jason Cooper <[email protected]> commit 5fd62066d2900b25a4fb3295ad13e3ee31474a51 Author: Ezequiel Garcia <[email protected]> Date: Thu Apr 24 17:23:22 2014 -0300 ARM: mvebu: Add thermal quirk for the Armada 375 DB board The initial release of the Armada 375 DB board has an Armada 375 Z1 stepping silicon. This commit introduces a quirk that allows to workaround a series of issues with the thermal sensor in this stepping, but updating the devicetree: * Updates the compatible string for the thermal, so the driver can perform a specific initialization of the sensor. * Moves the offset of the thermal control register. This quirk allows to specifiy the correct (A0 stepping) offset in the devicetree. Signed-off-by: Ezequiel Garcia <[email protected]> Link: https://lkml.kernel.org/r/1398371004-15807-9-git-send-email-ezequiel.garcia@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit e9d3c849a8dc92e1019a6c7ced98f6ac231a2703 Author: Ezequiel Garcia <[email protected]> Date: Thu Apr 24 08:34:36 2014 -0300 ARM: mvebu: Select HAVE_ARM_TWD only if SMP is enabled HAVE_ARM_TWD depends on SMP, so we should only select it if SMP is enabled, as the others platforms do. Signed-off-by: Ezequiel Garcia <[email protected]> Link: https://lkml.kernel.org/r/1398339276-5754-1-git-send-email-ezequiel.garcia@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit 8eee0f81cdaafb2fc78dcd5087a15c7f428d7751 Author: Gregory CLEMENT <[email protected]> Date: Sat Apr 19 18:32:50 2014 +0200 ARM: mvebu: fix the name of the parameter used in mvebu_get_soc_id The name of the two parameters of mvebu_get_soc_id were inverted. This patch fix it in order to have a more readable code. Reported-by: Ezequiel Garcia <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Link: https://lkml.kernel.org/r/1397925170-8202-3-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit c42e1ffa269f098133629adf54cabe242596b647 Author: Gregory CLEMENT <[email protected]> Date: Sat Apr 19 18:32:49 2014 +0200 ARM: mvebu: remove unnecessary ifdef around l2x0_of_init l2x0_of_init function is always defined arch/arm/include/asm/hardware/cache-l2x0.h: in case of CONFIG_CACHE_L2X0 is not selected then a placeholder is defined. Then there is no need to have ifdef around l2x0_of_init. Signed-off-by: Gregory CLEMENT <[email protected]> Reviewed-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1397925170-8202-2-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit 8c16babc6476111efabafbb262b47f8309942403 Author: Gregory CLEMENT <[email protected]> Date: Mon Apr 14 17:10:14 2014 +0200 ARM: mvebu: register the cpuidle driver for the Armada XP SoCs The cpuidle is a platform driver so we register the device just after the initialization of the board in an arch_initcall. Signed-off-by: Gregory CLEMENT <[email protected]> Link: https://lkml.kernel.org/r/1397488214-20685-12-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit b858fbc1919720f7f54360098ece03b383e961fa Author: Gregory CLEMENT <[email protected]> Date: Mon Apr 14 17:10:13 2014 +0200 cpuidle: mvebu: Add initial CPU idle support for Armada 370/XP SoC Add the wfi, cpu idle and cpu deep idle power states support for the Armada XP SoCs. All the latencies and the power consumption values used at the "armada_370_xp_idle_driver" structure are preliminary and will be modified in the future after running some measurements and analysis. Based on the work of Nadav Haklai. Signed-off-by: Nadav Haklai <[email protected]> Link: https://lkml.kernel.org/r/1397488214-20685-11-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Gregory CLEMENT <[email protected]> Link: https://lkml.kernel.org/r/1397488214-20685-11-git-send-email-gregory.clement@free-electrons.com Acked-by: Daniel Lezcano <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit d163ee165bd49a51f77bae632ebf37eda4899d0e Author: Gregory CLEMENT <[email protected]> Date: Mon Apr 14 17:10:12 2014 +0200 ARM: mvebu: Register notifier callback for the cpuidle transition In order to have well encapsulated code, we use notifier callbacks for CPU_PM_ENTER and CPU_PM_EXIT inside the mvebu power management code. Signed-off-by: Gregory CLEMENT <[email protected]> Link: https://lkml.kernel.org/r/1397488214-20685-10-git-send-email-gregory.clement@free-electrons.com Acked-by: Daniel Lezcano <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit 0041464ceeccd4718de228141438335e2d92f91b Author: Thomas Petazzoni <[email protected]> Date: Mon Apr 28 20:20:39 2014 +0200 ARM: mvebu: refine which files are build in mach-mvebu Following the integration into mach-mvebu of the Kirkwood ARMv5 support, we need to be more careful about which files get built. For example, the pmsu.c file now calls wfi(), which only exists on ARMv7 platforms. Therefore, this commit changes mach-mvebu/Makefile to build the Armada 370/XP/375/38x specific files only when CONFIG_MACH_MVEBU_V7 is enabled. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1398709239-6126-1-git-send-email-thomas.petazzoni@free-electrons.com Acked-by: Gregory CLEMENT <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit c3e04cabb135625df8ff4b71ef4130f0ccbcc669 Author: Gregory CLEMENT <[email protected]> Date: Mon Apr 14 17:10:11 2014 +0200 ARM: mvebu: Add the PMSU related part of the cpu idle functions The cpu idle support will need to access to Power Management Service Unit. This commit adds the architecture related functions that will be used in the idle path of the cpuidle driver. Signed-off-by: Gregory CLEMENT <[email protected]> Link: https://lkml.kernel.org/r/1397488214-20685-9-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit f713c7e7421d6945c977c8d8813e8089f925de41 Author: Gregory CLEMENT <[email protected]> Date: Mon Apr 14 17:10:10 2014 +0200 ARM: mvebu: Allow to power down L2 cache controller in idle mode This commit adds a function which adjusts the PMSU configuration to automatically power down the L2 and coherency fabric when we enter a certain idle state. This feature is part of the Power Management Service Unit of the Armada 370 and Armada XP SoCs. Signed-off-by: Gregory CLEMENT <[email protected]> Link: https://lkml.kernel.org/r/1397488214-20685-8-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit 1a6bfbc339b6a2b59a8f88fa494fe70073cdb85a Author: Gregory CLEMENT <[email protected]> Date: Mon Apr 14 17:10:09 2014 +0200 ARM: mvebu: Low level function to disable HW coherency support When going to deep idle we need to disable the SoC snooping (aka hardware coherency support). Playing with the coherency fabric requires to use assembly code to be sure that the compiler doesn't reorder the instructions nor do wrong optimization. Signed-off-by: Gregory CLEMENT <[email protected]> Link: https://lkml.kernel.org/r/1397488214-20685-7-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit 2e8a5942f8751c03fdd50228a02909654d13f01d Author: Gregory CLEMENT <[email protected]> Date: Mon Apr 14 17:10:08 2014 +0200 ARM: mvebu: Split low level functions to manipulate HW coherency Actually enabling coherency and adding a CPU on a SMP group are two different operations…
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
May 19, 2014
GIT 14186fea0cb06bc43181ce239efe0df6f1af260a commit 3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 Author: Josef Gajdusek <[email protected]> Date: Mon May 12 13:48:26 2014 +0200 hwmon: (emc1403) Support full range of known chip revision numbers The datasheet for EMC1413/EMC1414, which is fully compatible to EMC1403/1404 and uses the same chip identification, references revision numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers from 0x01 to 0x04 to make sure none are missed. Signed-off-by: Josef Gajdusek <[email protected]> Cc: [email protected] [Guenter Roeck: Updated headline and description] Signed-off-by: Guenter Roeck <[email protected]> commit 8759f9046550f463098148bf577ccd32cdb895e3 Author: Jean Delvare <[email protected]> Date: Mon May 12 11:44:51 2014 +0200 hwmon: (emc1403) Fix resource leak on module unload Commit 454aee17f claims to convert driver emc1403 to use devm_hwmon_device_register_with_groups, however the patch itself makes use of hwmon_device_register_with_groups instead. As the driver remove function was still dropped, the hwmon device is no longer unregistered on driver removal, leading to a resource leak. Signed-off-by: Jean Delvare <[email protected]> Fixes: 454aee17f hwmon: (emc1403) Convert to use devm_hwmon_device_register_with_groups Cc: Guenter Roeck <[email protected]> Cc: [email protected] [3.13+] Signed-off-by: Guenter Roeck <[email protected]> commit 17c048fc4bd95efea208a1920f169547d8588f1f Author: Josef Gajdusek <[email protected]> Date: Sun May 11 14:40:44 2014 +0200 hwmon: (emc1403) fix inverted store_hyst() Attempts to set the hysteresis value to a temperature below the target limit fails with "write error: Numerical result out of range" due to an inverted comparison. Signed-off-by: Josef Gajdusek <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Cc: [email protected] [Guenter Roeck: Updated headline and description] Signed-off-by: Guenter Roeck <[email protected]> commit 1f53ba6e81749a420226e5502c49ab83ba85c81d Author: Stefano Stabellini <[email protected]> Date: Thu May 8 15:48:13 2014 +0000 arm64: introduce virt_to_pfn virt_to_pfn has been defined in arch/arm/include/asm/memory.h by commit e26a9e0 "ARM: Better virt_to_page() handling" and Xen has come to rely on it. Introduce virt_to_pfn on arm64 too. Signed-off-by: Stefano Stabellini <[email protected]> Acked-by: Catalin Marinas <[email protected]> commit dd18dbc2d42af75fffa60c77e0f02220bc329829 Author: Kirill A. Shutemov <[email protected]> Date: Fri May 9 15:37:00 2014 -0700 mm, thp: close race between mremap() and split_huge_page() It's critical for split_huge_page() (and migration) to catch and freeze all PMDs on rmap walk. It gets tricky if there's concurrent fork() or mremap() since usually we copy/move page table entries on dup_mm() or move_page_tables() without rmap lock taken. To get it work we rely on rmap walk order to not miss any entry. We expect to see destination VMA after source one to work correctly. But after switching rmap implementation to interval tree it's not always possible to preserve expected walk order. It works fine for dup_mm() since new VMA has the same vma_start_pgoff() / vma_last_pgoff() and explicitly insert dst VMA after src one with vma_interval_tree_insert_after(). But on move_vma() destination VMA can be merged into adjacent one and as result shifted left in interval tree. Fortunately, we can detect the situation and prevent race with rmap walk by moving page table entries under rmap lock. See commit 38a76013ad80. Problem is that we miss the lock when we move transhuge PMD. Most likely this bug caused the crash[1]. [1] http://thread.gmane.org/gmane.linux.kernel.mm/96473 Fixes: 108d6642ad81 ("mm anon rmap: remove anon_vma_moveto_tail") Signed-off-by: Kirill A. Shutemov <[email protected]> Reviewed-by: Andrea Arcangeli <[email protected]> Cc: Rik van Riel <[email protected]> Acked-by: Michel Lespinasse <[email protected]> Cc: Dave Jones <[email protected]> Cc: David Miller <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: <[email protected]> [3.7+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 3551a9280bcb728980a13783ff295e9f0bdedd9a Author: Catalin Marinas <[email protected]> Date: Fri May 9 15:36:59 2014 -0700 mm: postpone the disabling of kmemleak early logging Commit 8910ae896c8c ("kmemleak: change some global variables to int"), in addition to the atomic -> int conversion, moved the disabling of kmemleak_early_log to the beginning of the kmemleak_init() function, before the full kmemleak tracing is actually enabled. In this small window, kmem_cache_create() is called by kmemleak which triggers additional memory allocation that are not traced. This patch restores the original logic with kmemleak_early_log disabling when kmemleak is fully functional. Fixes: 8910ae896c8c (kmemleak: change some global variables to int) Signed-off-by: Catalin Marinas <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Li Zefan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit f2eb7f6f7a18fc2eff2f74d2bfa12758c0449f12 Author: Cyril Hrubis <[email protected]> Date: Fri May 9 15:36:58 2014 -0700 MAINTAINERS: update maintainership of LTP Also remove sf.net git repo which is no longer available and update link to LTP web pages. Signed-off-by: Cyril Hrubis <[email protected]> Signed-off-by: Caspar Zhang <[email protected]> Signed-off-by: Wanlong Gao <[email protected]> Signed-off-by: Jan Stancek <[email protected]> Signed-off-by: Alexey Kodanev <[email protected]> Signed-off-by: Stanislav Kholmanskikh <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 282cba6b00a95f0277ed71551e3f6b0477e8836b Author: Heiko Stuebner <[email protected]> Date: Fri May 9 15:36:57 2014 -0700 drivers/rtc/rtc-hym8563.c: set uie_unsupported The alarm of the hym8563 only supports a minute accuracy, while the uie wants an alarm one second in the future. Therefore things like the select() syscall will fail with a timeout, because the next alarm will happen in a worst case of 60 seconds. Signed-off-by: Heiko Stuebner <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 90f4c5944b38b4647373db7a57a2dda1e0c5566a Author: Matt Porter <[email protected]> Date: Tue May 6 12:09:45 2014 -0400 MAINTAINERS: update Broadcom ARM tree location and add an SoC family The Broadcom ARM tree location has changed names to reflect other SoC families that are queued here. Also add the 216xx family as maintained. Signed-off-by: Matt Porter <[email protected]> Signed-off-by: Olof Johansson <[email protected]> commit 6d66da89bf4422c0a0693627fb3e25f74af50f92 Author: Sascha Hauer <[email protected]> Date: Tue May 6 13:01:34 2014 +0200 ARM: dts: i.MX53: Fix ipu register space size The IPU register space is 128MB, not 2GB. Fixes: abed9a6bf2bb 'ARM i.MX53: Add IPU support' Signed-off-by: Sascha Hauer <[email protected]> Acked-by: Shawn Guo <[email protected]> Cc: <[email protected]> Signed-off-by: Olof Johansson <[email protected]> commit cf01f4eef9fe367ec0d85b38dd7214e29e376cdb Author: Jeff Layton <[email protected]> Date: Fri May 9 11:41:54 2014 -0400 locks: only validate the lock vs. f_mode in F_SETLK codepaths v2: replace missing break in switch statement (as pointed out by Dave Jones) commit bce7560d4946 (locks: consolidate checks for compatible filp->f_mode values in setlk handlers) introduced a regression in the F_GETLK handler. flock64_to_posix_lock is a shared codepath between F_GETLK and F_SETLK, but the f_mode checks should only be applicable to the F_SETLK codepaths according to POSIX. Instead of just reverting the patch, add a new function to do this checking and have the F_SETLK handlers call it. Cc: Dave Jones <[email protected]> Reported-and-Tested-by: Reuben Farrelly <[email protected]> Signed-off-by: Jeff Layton <[email protected]> commit aa07c713ecfc0522916f3cd57ac628ea6127c0ec Author: Kinglong Mee <[email protected]> Date: Fri Apr 18 20:49:04 2014 +0800 NFSD: Call ->set_acl with a NULL ACL structure if no entries After setting ACL for directory, I got two problems that caused by the cached zero-length default posix acl. This patch make sure nfsd4_set_nfs4_acl calls ->set_acl with a NULL ACL structure if there are no entries. Thanks for Christoph Hellwig's advice. First problem: ............ hang ........... Second problem: [ 1610.167668] ------------[ cut here ]------------ [ 1610.168320] kernel BUG at /root/nfs/linux/fs/nfsd/nfs4acl.c:239! [ 1610.168320] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC [ 1610.168320] Modules linked in: nfsv4(OE) nfs(OE) nfsd(OE) rpcsec_gss_krb5 fscache ip6t_rpfilter ip6t_REJECT cfg80211 xt_conntrack rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw auth_rpcgss nfs_acl snd_intel8x0 ppdev lockd snd_ac97_codec ac97_bus snd_pcm snd_timer e1000 pcspkr parport_pc snd parport serio_raw joydev i2c_piix4 sunrpc(OE) microcode soundcore i2c_core ata_generic pata_acpi [last unloaded: nfsd] [ 1610.168320] CPU: 0 PID: 27397 Comm: nfsd Tainted: G OE 3.15.0-rc1+ #15 [ 1610.168320] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 1610.168320] task: ffff88005ab653d0 ti: ffff88005a944000 task.ti: ffff88005a944000 [ 1610.168320] RIP: 0010:[<ffffffffa034d5ed>] [<ffffffffa034d5ed>] _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd] [ 1610.168320] RSP: 0018:ffff88005a945b00 EFLAGS: 00010293 [ 1610.168320] RAX: 0000000000000001 RBX: ffff88006700bac0 RCX: 0000000000000000 [ 1610.168320] RDX: 0000000000000000 RSI: ffff880067c83f00 RDI: ffff880068233300 [ 1610.168320] RBP: ffff88005a945b48 R08: ffffffff81c64830 R09: 0000000000000000 [ 1610.168320] R10: ffff88004ea85be0 R11: 000000000000f475 R12: ffff880068233300 [ 1610.168320] R13: 0000000000000003 R14: 0000000000000002 R15: ffff880068233300 [ 1610.168320] FS: 0000000000000000(0000) GS:ffff880077800000(0000) knlGS:0000000000000000 [ 1610.168320] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1610.168320] CR2: 00007f5bcbd3b0b9 CR3: 0000000001c0f000 CR4: 00000000000006f0 [ 1610.168320] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1610.168320] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1610.168320] Stack: [ 1610.168320] ffffffff00000000 0000000b67c83500 000000076700bac0 0000000000000000 [ 1610.168320] ffff88006700bac0 ffff880068233300 ffff88005a945c08 0000000000000002 [ 1610.168320] 0000000000000000 ffff88005a945b88 ffffffffa034e2d5 000000065a945b68 [ 1610.168320] Call Trace: [ 1610.168320] [<ffffffffa034e2d5>] nfsd4_get_nfs4_acl+0x95/0x150 [nfsd] [ 1610.168320] [<ffffffffa03400d6>] nfsd4_encode_fattr+0x646/0x1e70 [nfsd] [ 1610.168320] [<ffffffff816a6e6e>] ? kmemleak_alloc+0x4e/0xb0 [ 1610.168320] [<ffffffffa0327962>] ? nfsd_setuser_and_check_port+0x52/0x80 [nfsd] [ 1610.168320] [<ffffffff812cd4bb>] ? selinux_cred_prepare+0x1b/0x30 [ 1610.168320] [<ffffffffa0341caa>] nfsd4_encode_getattr+0x5a/0x60 [nfsd] [ 1610.168320] [<ffffffffa0341e07>] nfsd4_encode_operation+0x67/0x110 [nfsd] [ 1610.168320] [<ffffffffa033844d>] nfsd4_proc_compound+0x21d/0x810 [nfsd] [ 1610.168320] [<ffffffffa0324d9b>] nfsd_dispatch+0xbb/0x200 [nfsd] [ 1610.168320] [<ffffffffa00850cd>] svc_process_common+0x46d/0x6d0 [sunrpc] [ 1610.168320] [<ffffffffa0085433>] svc_process+0x103/0x170 [sunrpc] [ 1610.168320] [<ffffffffa032472f>] nfsd+0xbf/0x130 [nfsd] [ 1610.168320] [<ffffffffa0324670>] ? nfsd_destroy+0x80/0x80 [nfsd] [ 1610.168320] [<ffffffff810a5202>] kthread+0xd2/0xf0 [ 1610.168320] [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40 [ 1610.168320] [<ffffffff816c1ebc>] ret_from_fork+0x7c/0xb0 [ 1610.168320] [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40 [ 1610.168320] Code: 78 02 e9 e7 fc ff ff 31 c0 31 d2 31 c9 66 89 45 ce 41 8b 04 24 66 89 55 d0 66 89 4d d2 48 8d 04 80 49 8d 5c 84 04 e9 37 fd ff ff <0f> 0b 90 0f 1f 44 00 00 55 8b 56 08 c7 07 00 00 00 00 8b 46 0c [ 1610.168320] RIP [<ffffffffa034d5ed>] _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd] [ 1610.168320] RSP <ffff88005a945b00> [ 1610.257313] ---[ end trace 838254e3e352285b ]--- Signed-off-by: Kinglong Mee <[email protected]> Cc: [email protected] Signed-off-by: J. Bruce Fields <[email protected]> commit 4cb57e3032d4e4bf5e97780e9907da7282b02b0c Author: Trond Myklebust <[email protected]> Date: Fri Apr 18 14:43:57 2014 -0400 NFSd: call rpc_destroy_wait_queue() from free_client() Mainly to ensure that we don't leave any hanging timers. Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected] Signed-off-by: J. Bruce Fields <[email protected]> commit 5694c93e6c4954fa9424c215f75eeb919bddad64 Author: Trond Myklebust <[email protected]> Date: Fri Apr 18 14:43:56 2014 -0400 NFSd: Move default initialisers from create_client() to alloc_client() Aside from making it clearer what is non-trivial in create_client(), it also fixes a bug whereby we can call free_client() before idr_init() has been called. Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected] Signed-off-by: J. Bruce Fields <[email protected]> commit 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 Author: NeilBrown <[email protected]> Date: Tue May 6 09:36:08 2014 +1000 md: avoid possible spinning md thread at shutdown. If an md array with externally managed metadata (e.g. DDF or IMSM) is in use, then we should not set safemode==2 at shutdown because: 1/ this is ineffective: user-space need to be involved in any 'safemode' handling, 2/ The safemode management code doesn't cope with safemode==2 on external metadata and md_check_recover enters an infinite loop. Even at shutdown, an infinite-looping process can be problematic, so this could cause shutdown to hang. Cc: [email protected] (any kernel) Signed-off-by: NeilBrown <[email protected]> commit cc13b1d1500656a20e41960668f3392dda9fa6e2 Author: NeilBrown <[email protected]> Date: Mon May 5 13:34:37 2014 +1000 md/raid10: call wait_barrier() for each request submitted. wait_barrier() includes a counter, so we must call it precisely once (unless balanced by allow_barrier()) for each request submitted. Since commit 20d0189b1012a37d2533a87fb451f7852f2418d1 block: Introduce new bio_split() in 3.14-rc1, we don't call it for the extra requests generated when we need to split a bio. When this happens the counter goes negative, any resync/recovery will never start, and "mdadm --stop" will hang. Reported-by: Chris Murphy <[email protected]> Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1 Cc: [email protected] (3.14+) Cc: Kent Overstreet <[email protected]> Signed-off-by: NeilBrown <[email protected]> commit 36c38fb7144aa941dc072ba8f58b2dbe509c0345 Author: Tejun Heo <[email protected]> Date: Mon May 5 12:37:30 2014 -0400 blkcg: use trylock on blkcg_pol_mutex in blkcg_reset_stats() During the recent conversion of cgroup to kernfs, cgroup_tree_mutex which nests above both the kernfs s_active protection and cgroup_mutex is added to synchronize cgroup file type operations as cgroup_mutex needed to be grabbed from some file operations and thus can't be put above s_active protection. While this arrangement mostly worked for cgroup, this triggered the following lockdep warning. ====================================================== [ INFO: possible circular locking dependency detected ] 3.15.0-rc3-next-20140430-sasha-00016-g4e281fa-dirty #429 Tainted: G W ------------------------------------------------------- trinity-c173/9024 is trying to acquire lock: (blkcg_pol_mutex){+.+.+.}, at: blkcg_reset_stats (include/linux/spinlock.h:328 block/blk-cgroup.c:455) but task is already holding lock: (s_active#89){++++.+}, at: kernfs_fop_write (fs/kernfs/file.c:283) which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (s_active#89){++++.+}: lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) __kernfs_remove (arch/x86/include/asm/atomic.h:27 fs/kernfs/dir.c:352 fs/kernfs/dir.c:1024) kernfs_remove_by_name_ns (fs/kernfs/dir.c:1219) cgroup_addrm_files (include/linux/kernfs.h:427 kernel/cgroup.c:1074 kernel/cgroup.c:2899) cgroup_clear_dir (kernel/cgroup.c:1092 (discriminator 2)) rebind_subsystems (kernel/cgroup.c:1144) cgroup_setup_root (kernel/cgroup.c:1568) cgroup_mount (kernel/cgroup.c:1716) mount_fs (fs/super.c:1094) vfs_kern_mount (fs/namespace.c:899) do_mount (fs/namespace.c:2238 fs/namespace.c:2561) SyS_mount (fs/namespace.c:2758 fs/namespace.c:2729) tracesys (arch/x86/kernel/entry_64.S:746) -> #1 (cgroup_tree_mutex){+.+.+.}: lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) mutex_lock_nested (kernel/locking/mutex.c:486 kernel/locking/mutex.c:587) cgroup_add_cftypes (include/linux/list.h:76 kernel/cgroup.c:3040) blkcg_policy_register (block/blk-cgroup.c:1106) throtl_init (block/blk-throttle.c:1694) do_one_initcall (init/main.c:789) kernel_init_freeable (init/main.c:854 init/main.c:863 init/main.c:882 init/main.c:1003) kernel_init (init/main.c:935) ret_from_fork (arch/x86/kernel/entry_64.S:552) -> #0 (blkcg_pol_mutex){+.+.+.}: __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182) lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) mutex_lock_nested (kernel/locking/mutex.c:486 kernel/locking/mutex.c:587) blkcg_reset_stats (include/linux/spinlock.h:328 block/blk-cgroup.c:455) cgroup_file_write (kernel/cgroup.c:2714) kernfs_fop_write (fs/kernfs/file.c:295) vfs_write (fs/read_write.c:532) SyS_write (fs/read_write.c:584 fs/read_write.c:576) tracesys (arch/x86/kernel/entry_64.S:746) other info that might help us debug this: Chain exists of: blkcg_pol_mutex --> cgroup_tree_mutex --> s_active#89 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(s_active#89); lock(cgroup_tree_mutex); lock(s_active#89); lock(blkcg_pol_mutex); *** DEADLOCK *** 4 locks held by trinity-c173/9024: #0: (&f->f_pos_lock){+.+.+.}, at: __fdget_pos (fs/file.c:714) #1: (sb_writers#18){.+.+.+}, at: vfs_write (include/linux/fs.h:2255 fs/read_write.c:530) #2: (&of->mutex){+.+.+.}, at: kernfs_fop_write (fs/kernfs/file.c:283) #3: (s_active#89){++++.+}, at: kernfs_fop_write (fs/kernfs/file.c:283) stack backtrace: CPU: 3 PID: 9024 Comm: trinity-c173 Tainted: G W 3.15.0-rc3-next-20140430-sasha-00016-g4e281fa-dirty #429 ffffffff919687b0 ffff8805f6373bb8 ffffffff8e52cdbb 0000000000000002 ffffffff919d8400 ffff8805f6373c08 ffffffff8e51fb88 0000000000000004 ffff8805f6373c98 ffff8805f6373c08 ffff88061be70d98 ffff88061be70dd0 Call Trace: dump_stack (lib/dump_stack.c:52) print_circular_bug (kernel/locking/lockdep.c:1216) __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182) lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) mutex_lock_nested (kernel/locking/mutex.c:486 kernel/locking/mutex.c:587) blkcg_reset_stats (include/linux/spinlock.h:328 block/blk-cgroup.c:455) cgroup_file_write (kernel/cgroup.c:2714) kernfs_fop_write (fs/kernfs/file.c:295) vfs_write (fs/read_write.c:532) SyS_write (fs/read_write.c:584 fs/read_write.c:576) This is a highly unlikely but valid circular dependency between "echo 1 > blkcg.reset_stats" and cfq module [un]loading. cgroup is going through further locking update which will remove this complication but for now let's use trylock on blkcg_pol_mutex and retry the file operation if the trylock fails. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Sasha Levin <[email protected]> References: http://lkml.kernel.org/g/[email protected] commit d2c2b11cfa134f4fbdcc34088824da26a084d8de Author: Aristeu Rozanski <[email protected]> Date: Mon May 5 11:18:59 2014 -0400 device_cgroup: check if exception removal is allowed [PATCH v3 1/2] device_cgroup: check if exception removal is allowed When the device cgroup hierarchy was introduced in bd2953ebbb53 - devcg: propagate local changes down the hierarchy a specific case was overlooked. Consider the hierarchy bellow: A default policy: ALLOW, exceptions will deny access \ B default policy: ALLOW, exceptions will deny access There's no need to verify when an new exception is added to B because in this case exceptions will deny access to further devices, which is always fine. Hierarchy in device cgroup only makes sure B won't have more access than A. But when an exception is removed (by writing devices.allow), it isn't checked if the user is in fact removing an inherited exception from A, thus giving more access to B. Example: # echo 'a' >A/devices.allow # echo 'c 1:3 rw' >A/devices.deny # echo $$ >A/B/tasks # echo >/dev/null -bash: /dev/null: Operation not permitted # echo 'c 1:3 w' >A/B/devices.allow # echo >/dev/null # This shouldn't be allowed and this patch fixes it by making sure to never allow exceptions in this case to be removed if the exception is partially or fully present on the parent. v3: missing '*' in function description v2: improved log message and formatting fixes Cc: [email protected] Cc: Li Zefan <[email protected]> Cc: [email protected] Signed-off-by: Aristeu Rozanski <[email protected]> Acked-by: Serge Hallyn <[email protected]> Signed-off-by: Tejun Heo <[email protected]> commit 788296b2d19d16ec33aba0a5ad1544d50bb58601 Author: Sebastian Hesselbarth <[email protected]> Date: Wed Apr 30 14:56:28 2014 +0200 ARM: dts: kirkwood: fix mislocated pcie-controller nodes Commit 54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes") moved the pcie-controller nodes for the Kirkwood SoCs to the mbus bus node. For some reason, two boards were not properly converted and have their pci-controller nodes still in the ocp bus node. As the corresponding SoC pcie-controller does not exist anymore, it is likely that pcie is broken on those boards since above commit. Fix it by moving the pcie related nodes to the correct location. Signed-off-by: Sebastian Hesselbarth <[email protected]> Fixes: 54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes") Cc: <[email protected]> # v3.12+ Acked-by: Andrew Lunn <[email protected]> Link: https://lkml.kernel.org/r/1398862602-29595-2-git-send-email-sebastian.hesselbarth@gmail.com Signed-off-by: Jason Cooper <[email protected]> commit f5f3cf6f7e49b9529fc00a2c4629fa92cf2755fe Author: Aristeu Rozanski <[email protected]> Date: Thu Apr 24 15:33:21 2014 -0400 device_cgroup: fix the comment format for recently added functions Moving more extensive explanations to the end of the comment. Cc: Li Zefan <[email protected]> Signed-off-by: Aristeu Rozanski <[email protected]> Acked-by: Serge Hallyn <[email protected]> Signed-off-by: Tejun Heo <[email protected]> commit 84e108fc7b23310fb6d93a657e47181d64ab6e93 Author: Maxime Ripard <[email protected]> Date: Mon Apr 28 11:44:36 2014 -0700 ARM: sunxi: Enable GMAC in sunxi_defconfig Since the support of the GMAC has been merged, we're using it as the ethernet controller on the A20 devices. However, sunxi_defconfig wasn't selecting it hence breaking the NFS boot. Signed-off-by: Maxime Ripard <[email protected]> commit cf7eb979116c2568e8bc3b6a7269c7a359864ace Author: Thomas Gleixner <[email protected]> Date: Sun Apr 13 20:44:46 2014 +0200 ARM: common: edma: Fix xbar mapping This is another great example of trainwreck engineering: commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support) added support for using EDMA on peripherals which have no direct EDMA event mapping. The code compiles and does not explode in your face, but that's it. 1) Reading an u16 array from an u32 device tree array simply does not work. Even if the function is named "edma_of_read_u32_to_s16_array". It merily calls of_property_read_u16_array. So the resulting 16bit array will have every other entry = 0. 2) The DT entry for the xbar registers related to xbar has length 0x10 instead of the real length: 0xfd0 - 0xf90 = 0x40. Not a real problem as it does not cross a page boundary, but wrong nevertheless. 3) But none of this matters as the mapping never happens: After reading nonsense edma_of_read_u32_to_s16_array() invalidates the first array entry pair, so nobody can ever notice the braindamage by immediate explosion. Seems the QA criteria for this code was solely not to explode when someone adds edma-xbar-event-map entries to the DT. Goal achieved, congratulations! Not really helpful if someone wants to use edma on a device which requires a xbar mapping. Fix the issues by: - annotating the device tree entry with "/bits/ 16" as documented in the of_property_read_u16_array kernel doc - make the size of the xbar register mapping correct - invalidating the end of the array and not the start This convoluted mess wants to be completely rewritten as there is no point to keep the xbar_chan array memory and the iomapping of the xbar regs around forever. Marking the xbar mapped channels as used should be done right there. But that's a different issue and this patch is small enough to make it work and allows a simple backport for stable. Cc: [email protected] # v3.12+ Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Sekhar Nori <[email protected]> commit a38670459d6883582bc360ee480f9fcec4900162 Author: Maxime Ripard <[email protected]> Date: Fri Apr 18 21:13:08 2014 +0200 ARM: sun7i: Fix i2c4 base address For some reason, the base address of the fifth I2C adapter in the A20 was incorrect. Change this to the actual base address. Reported-by: Marcus Cooper <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Hans de Goede <[email protected]> commit 05a812ac474d0d6aef6d54b66bb08b81abde79c6 Author: Vladimir Murzin <[email protected]> Date: Sun Apr 27 10:09:12 2014 +0100 xen/events/fifo: correctly align bitops FIFO event channels require bitops on 32-bit aligned values (the event words). Linux's bitops require unsigned long alignment which may be 64-bits. On arm64 an incorrectly unaligned access will fault. Fix this by aligning the bitops along with an adjustment for bit position and using an unsigned long for the local copy of the ready word. Cc: [email protected] Signed-off-by: Vladimir Murzin <[email protected]> Tested-by: Pranavkumar Sawargaonkar <[email protected]> Reviewed-by: Ian Campbell <[email protected]> Signed-off-by: David Vrabel <[email protected]> commit 063aa8e68e53cc0d0961ea90c12cea40c6b94828 Author: Julien Grall <[email protected]> Date: Fri Apr 18 16:54:34 2014 +0100 arm/xen: Remove definiition of virt_to_pfn in asm/xen/page.h virt_to_pfn has been defined in asm/memory.h by the commit e26a9e0 "ARM: Better virt_to_page() handling" This will result of a compilation warning when CONFIG_XEN is enabled. arch/arm/include/asm/xen/page.h:80:0: warning: "virt_to_pfn" redefined [enabled by default] #define virt_to_pfn(v) (PFN_DOWN(__pa(v))) ^ In file included from arch/arm/include/asm/page.h:163:0, from arch/arm/include/asm/xen/page.h:4, from include/xen/page.h:4, from arch/arm/xen/grant-table.c:33: The definition in memory.h is nearly the same (it directly expand PFN_DOWN), so we can safely drop virt_to_pfn in xen include. Signed-off-by: Julien Grall <[email protected]> Signed-off-by: David Vrabel <[email protected]> commit e247686085f71e9c25e3488ce83d5d0f77023438 Author: Andrew Lunn <[email protected]> Date: Tue Apr 15 14:40:08 2014 +0200 ARM: Kirkwood: T5325: Fix double probe of Codec The codec is defined both in DT and the board file. The board file however contains platform data which is required in order that the codec works. When the DT instantiates the codec before the board files does, it is missing the platform data and so fails. Remove the DT node until we have a binding which can pass the additional data. Signed-off-by: Andrew Lunn <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jason Cooper <[email protected]> commit d685058f5b878a71f99c8e2fd9707b3f49510b94 Author: Thomas Petazzoni <[email protected]> Date: Fri Apr 18 09:41:45 2014 +0200 ARM: mvebu: enable the SATA interface on Armada 375 DB The Armada 375 SoC has a dual-port SATA interface, which is exposed on the Armada 375 DB board. This commit therefore enables this interface on the Armada 375 DB board. Signed-off-by: Thomas Petazzoni <[email protected]> Acked-by: Gregory CLEMENT <[email protected]> Link: https://lkml.kernel.org/r/1397806908-7550-3-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit ac164d1144f1a699d307bb05095e352ed6de236f Author: Thomas Petazzoni <[email protected]> Date: Fri Apr 18 09:41:44 2014 +0200 ARM: mvebu: specify I2C bus frequency on Armada 370 DB In commit 249f3822509b74f8c8d0731aeb7ccea065376c9b ('ARM: mvebu: add audio support to Armada 370 DB'), the I2C bus 0 was enabled on the Armada 370 DB board, and an I2C codec was described as being connected on this bus. However, this commit forgot to define the I2C bus frequency, which leads the i2c-mv64xxx to fail probing, as it cannot calculate the baud rate multiplier/divisor to derive the I2C bus frequency from the core SoC frequency. It makes audio completely unusable, as the I2C bus is not probed, and therefore the audio codec is not probed either. Signed-off-by: Thomas Petazzoni <[email protected]> Acked-by: Gregory CLEMENT <[email protected]> Link: https://lkml.kernel.org/r/1397806908-7550-2-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit 80fa10f4e9278c4df1636a26025b12588078ad61 Author: Thomas Petazzoni <[email protected]> Date: Tue Apr 15 15:50:21 2014 +0200 ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces The Armada XP GP isn't using rgmii-id connections between the MAC and PHY, but instead a single QSGMII connection, which is a quad-SGMII connection: a double pair of differential lines that are multiplexed to convey the traffic of four network interfaces between a MAC and a PHY. Until now, the Armada XP GP was relying on the bootloader setting the correct values in various configuration registers. With this change, the mvneta driver can be used as a module on this platform. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1397569821-5530-4-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Arnaud Ebalard <[email protected]> Tested-by: Willy Tarreau <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit 6e20bae8a39c40d4e03698e4160bad2d2629062b Author: Thomas Petazzoni <[email protected]> Date: Mon Apr 14 17:29:21 2014 +0200 ARM: mvebu: fix NOR bus-width in Armada XP OpenBlocks AX3 Device Tree The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP OpenBlocks AX3 Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit a7d4f81821f7eec3175f8e23dd6949c71ab2da43 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board') which was merged in v3.10. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com Fixes: a7d4f81821f7 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board') Cc: [email protected] # v3.10+ Acked-by: Ezequiel Garcia <[email protected]> Acked-by: Gregory CLEMENT <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit f3aec8f3f05025e7b450102dae0759375346706e Author: Thomas Petazzoni <[email protected]> Date: Mon Apr 14 17:29:20 2014 +0200 ARM: mvebu: fix NOR bus-width in Armada XP DB Device Tree The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP DB Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit b484ff42df475c5087d614c4d477273e1906bcb9 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board') which was merged in v3.11. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1397489361-5833-4-git-send-email-thomas.petazzoni@free-electrons.com Fixes: b484ff42df47 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board') Cc: [email protected] # v3.11+ Acked-by: Ezequiel Garcia <[email protected]> Acked-by: Gregory CLEMENT <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit 1a88f809ccb5db1509a7514b187c00b3a995fc82 Author: Thomas Petazzoni <[email protected]> Date: Mon Apr 14 17:29:19 2014 +0200 ARM: mvebu: fix NOR bus-width in Armada XP GP Device Tree The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP GP Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit da8d1b38356853c37116f9afa29f15648d7fb159 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board') which was merged in v3.10. Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com Fixes: da8d1b383568 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board') Cc: [email protected] # v3.10+ Acked-by: Ezequiel Garcia <[email protected]> Acked-by: Gregory CLEMENT <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit 4c05160342f16361fc37ae34dcae9210306a83e9 Author: Suman Anna <[email protected]> Date: Tue Apr 22 17:23:37 2014 -0500 ARM: dts: AM3517: Disable absent IPs inherited from OMAP3 AM3517 inherits OMAP3 dts file, but does not have all the IPs that are present on OMAP3. This patch disables the following absent IPs for AM3517: Mailbox, IVA, MMU_ISP, MPU_IVA SmartReflex. A label had to be added for IVA node in omap3.dtsi to be able to get a reference to the node for disabling. Otherwise we get the following warnings during booting: platform iva.2: Cannot lookup hwmod 'iva' platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva' Signed-off-by: Suman Anna <[email protected]> [[email protected]: updated description for the warnings] Signed-off-by: Tony Lindgren <[email protected]> commit 4fe5bd5da2ea7b1b8c9455246ddcdb39ab734487 Author: Suman Anna <[email protected]> Date: Tue Apr 22 17:23:36 2014 -0500 ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox The mailbox module is capable of generating two interrupts to MPU in OMAP2420, compared to one in OMAP2430. The second interrupt is to handle interrupts from the additional IVA processor present only on OMAP2420. Move the current common mailbox DT node into the SoC specific files to allow the above differentiation. Also, added back the interrupt-names on OMAP2420, that were previously defined in hwmod data. This fixes regression caused by the recent dropping of hwmod data in favor for defining it in the .dts files. Signed-off-by: Suman Anna <[email protected]> [[email protected]: updated description] Signed-off-by: Tony Lindgren <[email protected]> commit 84d89c3123bf4c3145f7b19fca36dba612a69807 Author: Suman Anna <[email protected]> Date: Tue Apr 22 17:23:35 2014 -0500 ARM: dts: OMAP5: Add mailbox dt node to fix boot warning Add the mailbox device DT node for OMAP5 SoC. The OMAP5 mailbox IP is identical to that used in OMAP4. The OMAP5 hwmod data no longer publishes the module address space, so this patch fixes the WARN_ON backtrace associated with the following trace during the kernel boot: "omap_hwmod: mailbox: doesn't have mpu register target base". Otherwise we get a warning like this: WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() omap_hwmod: mailbox: doesn't have mpu register target base Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-00001-gb5e85a0 #45 [<c0015724>] (unwind_backtrace) from [<c00120f4>] (show_stack+0x10/0x14) [<c00120f4>] (show_stack) from [<c05a1ccc>] (dump_stack+0x78/0x94) [<c05a1ccc>] (dump_stack) from [<c0042a74>] (warn_slowpath_common+0x6c/0x8c) [<c0042a74>] (warn_slowpath_common) from [<c0042b28>] (warn_slowpath_fmt+0x30/0x40) [<c0042b28>] (warn_slowpath_fmt) from [<c0803b40>] (_init+0x1c0/0x3dc) [<c0803b40>] (_init) from [<c0029c8c>] (omap_hwmod_for_each+0x34/0x5c) [<c0029c8c>] (omap_hwmod_for_each) from [<c08042b0>] (__omap_hwmod_setup_all+0x24/0x40) [<c08042b0>] (__omap_hwmod_setup_all) from [<c00088b8>] (do_one_initcall+0x34/0x160) [<c00088b8>] (do_one_initcall) from [<c07f7bf4>] (kernel_init_freeable+0xfc/0x1c8) [<c07f7bf4>] (kernel_init_freeable) from [<c059c4f4>] (kernel_init+0x8/0xe4) [<c059c4f4>] (kernel_init) from [<c000eaa8>] (ret_from_fork+0x14/0x2c) Signed-off-by: Suman Anna <[email protected]> [[email protected]: updated description to for the warning] Signed-off-by: Tony Lindgren <[email protected]> commit da0159fdb57d6fab54ce3179659a1f9e5b593752 Author: Joel Fernandes <[email protected]> Date: Tue Apr 22 14:40:39 2014 -0500 ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU On my DRA7 system, when the kernel is built in Thumb-2 mode, the secondary CPU (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to Thumb-2 mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in Thumb-2 mode on entry so this is not required and SMP boot works as is. Also corrected a spurious '+' and updated copyright information. Cc: Santosh Shilimkar <[email protected]> Cc: Russell King <[email protected]> Cc: Nishanth Menon <[email protected]> Tested-by: Nishanth Menon <[email protected]> Acked-by: Santosh Shilimkar <[email protected]> Signed-off-by: Joel Fernandes <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> commit 1ff3859e7ea134c09512498aa2251fd3a57d250d Author: Dave Gerlach <[email protected]> Date: Fri Mar 21 10:50:13 2014 +0530 ARM: dts: am437x-gp-evm: Do not reset gpio5 Do not reset GPIO5 at boot-up because GPIO5_7 is used on AM437x GP-EVM to control VTT regulators on DDR3. Without this some GP-EVM boards will fail to boot because of DDR3 corruption. Reported-by: Nishanth Menon <[email protected]> Tested-by: Nishanth Menon <[email protected]> Signed-off-by: Dave Gerlach <[email protected]> Signed-off-by: Lokesh Vutla <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> commit ef139e130c8a18cc6cdaa2d98899f74e14389bd4 Author: Javier Martinez Canillas <[email protected]> Date: Thu Apr 24 18:53:50 2014 +0200 ARM: dts: omap3-igep0020: use SMSC9221 timings The IGEPv2 board has a SMSC LAN9221i ethernet chip and not a SMSC LAN911x connected to the GPMC. Each chip needs different timings in order to operate correctly so is wrong to include omap-gpmc-smsc911x.dtsi instead of omap-gpmc-smsc9221.dtsi. Signed-off-by: Javier Martinez Canillas <[email protected]> [[email protected]: this is needed to avoid potential memory corruption] Signed-off-by: Tony Lindgren <[email protected]> commit a87c9ad956676d84d459739fc14ec5a3c3565717 Author: Jeff Layton <[email protected]> Date: Wed Mar 26 07:24:23 2014 -0700 cifs: fix actimeo=0 corner case when cifs_i->time == jiffies actimeo=0 is supposed to be a special case that ensures that inode attributes are always refetched from the server instead of trusting the cache. The cifs code however uses time_in_range() to determine whether the attributes have timed out. In the case where cifs_i->time equals jiffies, this leads to the cifs code not refetching the inode attributes when it should. Fix this by explicitly testing for actimeo=0, and handling it as a special case. Reported-and-tested-by: Tetsuo Handa <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Steve French <[email protected]> commit 398f5d5e10b6b917cd9d35ef21d545b0afbada22 Author: Thomas Petazzoni <[email protected]> Date: Fri Apr 18 14:19:53 2014 +0200 PCI: mvebu: split PCIe BARs into multiple MBus windows when needed MBus windows are used on Marvell platforms to map certain peripherals in the physical address space. In the PCIe context, MBus windows are needed to map PCIe I/O and memory regions in the physical address. However, those MBus windows can only have power of two sizes, while PCIe BAR do not necessarily guarantee this. For this reason, the current pci-mvebu breaks on platforms where PCIe devices have BARs that don't sum up to a power of two size at the emulated bridge level. This commit fixes this by allowing the pci-mvebu driver to create multiple contiguous MBus windows (each having a power of two size) to cover a given PCIe BAR. To achieve this, two functions are added: mvebu_pcie_add_windows() and mvebu_pcie_del_windows() to respectively add and remove all the MBus windows that are needed to map the provided PCIe region base and size. The emulated PCI bridge code now calls those functions, instead of directly calling the mvebu-mbus driver functions. Fixes: 45361a4fe446 ('pci: PCIe driver for Marvell Armada 370/XP systems') Cc: <[email protected]> # v3.11+ Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1397823593-1932-8-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit b566e782be32145664d96ada3e389f17d32742e5 Author: Thomas Petazzoni <[email protected]> Date: Fri Apr 18 14:19:52 2014 +0200 bus: mvebu-mbus: allow several windows with the same target/attribute Having multiple windows with the same target and attribute is actually legal, and can be useful for PCIe windows, when PCIe BARs have a size that isn't a power of two, and we therefore need to create several MBus windows to cover the PCIe BAR for a given PCIe interface. Fixes: fddddb52a6c4 ('bus: introduce an Marvell EBU MBus driver') Cc: <[email protected]> # v3.10+ Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1397823593-1932-7-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit 09752a12f430f58523fb6f435f5e30e4048fcfb2 Author: Jason Gunthorpe <[email protected]> Date: Fri Apr 18 14:19:51 2014 +0200 bus: mvebu-mbus: Avoid setting an undefined window size The mbus hardware requires a power of two size, and size aligned base. Currently, if a non-power of two is passed in to the low level routines they configure the register in a way that results in undefined behaviour. Call WARN and return EINVAL instead. Also, update the debugfs routines to show a message if there is an invalid register setting. All together this makes the recent problems with silent failure of PCI very obvious, noisy and debuggable. Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1397823593-1932-6-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <[email protected]> commit b6d07e0273d3296cfbdc88145b8a00ddbefb310a Author: Willy Tarreau <[email protected]> Date: Fri Apr 18 14:19:50 2014 +0200 PCI: mvebu: fix off-by-one in the computed size of the mbus windows mvebu_pcie_handle_membase_change() and mvebu_pcie_handle_iobase_change() do not correctly compute the window size. PCI uses an inclusive start/end address pair, which requires a +1 when converting to size. This only worked because a bug in the mbus driver allowed it to silently accept and round up bogus sizes. Fix this by adding one to the computed size. Fixes: 45361a4fe446 ('PCIe driver for Marvell Armada 370/XP systems') Cc: <[email protected]> # v3.11+ Signed-off-by: Willy Tarreau <[email protected]> Reviewed-By: Jason Gunthorpe <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]> Link: https://lkml.kernel.org/r/1397823593-1932-5-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Jason Cooper <[email protected]> commit dcf2191933c4d3b3d1fcd8b6f5818cc913baa8b2 Author: Tony Lindgren <[email protected]> Date: Wed Apr 23 11:04:42 2014 -0700 ARM: dts: Fix GPMC timings for LAN9220 I've noticed occasional random oopsing on my gateway machine since I upgraded it to use device tree based booting. As this machine has worked reliably before that for a few years, pretty much the only difference was narrowed down to the GPMC timings. Turns out that for legacy based booting we are using bootloader timings for GPMC for smsc911x. With device tree we are passing the timings in the .dts file, and the device tree timings are not quite suitable for LAN9920. Enabling DEBUG in gpmc.c I noticed that the device tree configured timings are different from the the known working bootloader timings. So let's fix the timings to match the bootloader timings when looked at the gpmc dmesg output with DEBUG enabled. The changes were done by multiplying the bootloader tick values by six to get the nanosecond value for device tree. This is not generic from the device point of view as the calculations should be based on the device timings. Anyways, further improvments can be done based on the timings documentation for LAN9220. But let's first get things to a known good working state. Note that we still need to change the timings also for sb-t35 also as it has two LAN9220 instances on GPMC and we can currently include the generic timings only once. Also note that any boards that have LAN9221 instead of LAN9220 should be updated to use omap-gpmc-smsc9221.dtsi instead of omap-gpmc-smsc911x.dtsi. The LAN9221 timings are different from LAN9220 timings. Cc: Christoph Fritz <[email protected]> Cc: Dmitry Lifshitz <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> commit de9949a45ec05a9cd5b98eb0a5b5a65db252f1f3 Author: Tony Lindgren <[email protected]> Date: Wed Apr 23 11:04:30 2014 -0700 ARM: dts: Fix GPMC Ethernet timings for omap cm-t sbc-t boards for device tree Looks like we have wrong GPMC timings we have for the cm-t and sbc-t boards. This can cause occasional strange errors with at least doing an rsync of large files or doing apt-get dist-upgrade. Let's fix the issue in two phases. First let's simplify cm-t and sbc-t to use the shared omap-gpmc-smsc911x.dtsi to avoid fixing the issue in multiple places. Then we can fix the timings in a single place with a follow-up patch. Cc: Dmitry Lifshitz <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> commit 20f670dcc08682e478770b48bd5fe09f19351674 Author: Tony Lindgren <[email protected]> Date: Wed Apr 23 11:04:29 2014 -0700 ARM: dts: Fix bad OTG muxing for cm-t boards Looks like the OTG pins are off by 2 and we get this: pinctrl-single 48002030.pinmux: pin 480021a0.0 already requested by 49020000.serial; cannot claim for 480ab000.usb_otg_hs pinctrl-single 48002030.pinmux: pin-184 (480ab000.usb_otg_hs) status -22 pinctrl-single 48002030.pinmux: could not request pin 184 (480021a0.0) from group pinmux_hsusb0_pins on device pinctrl-single musb-omap2430 480ab000.usb_otg_hs: Error applying setting, reverse things back That's probably because the TRM lists the values as 32-bit registers so every second needs 2 added to the address. The OTG pin start range must start from 0x21a2, not 0x21a0. Cc: Dmitry Lifshitz <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> commit 79d719749d23234e9b725098aa49133f3ef7299d Author: Aristeu Rozanski <[email protected]> Date: Mon Apr 21 12:13:03 2014 -0400 device_cgroup: rework device access check and exception checking Whenever a device file is opened and checked against current device cgroup rules, it uses the same function (may_access()) as when a new exception rule is added by writing devices.{allow,deny}. And in both cases, the algorithm is the same, doesn't matter the behavior. First problem is having device access to be considered the same as rule checking. Consider the following structure: A (default behavior: allow, exceptions disallow access) \ B (default behavior: allow, exceptions disallow access) A new exception is added to B by writing devices.deny: c 12:34 rw When checking if that exception is allowed in may_access(): if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) { if (behavior == DEVCG_DEFAULT_ALLOW) { /* the exception will deny access to certain devices */ return true; Which is ok, since B is not getting more privileges than A, it doesn't matter and the rule is accepted Now, consider it's a device file open check and the process belongs to cgroup B. The access will be generated as: behavior: allow exception: c 12:34 rw The very same chunk of code will allow it, even if there's an explicit exception telling to do otherwise. A simple test case: # mkdir new_group # cd new_group # echo $$ >tasks # echo "c 1:3 w" >devices.deny # echo >/dev/null # echo $? 0 This is a serious bug and was introduced on c39a2a3018f8 devcg: prepare may_access() for hierarchy support To solve this problem, the device file open function was split from the new exception check. Second problem is how exceptions are processed by may_access(). The first part of the said function tries to match fully with an existing exception: list_for_each_entry_rcu(ex, &dev_cgroup->exceptions, list) { if ((refex->type & DEV_BLOCK) && !(ex->type & DEV_BLOCK)) continue; if ((refex->type & DEV_CHAR) && !(ex->type & DEV_CHAR)) continue; if (ex->major != ~0 && ex->major != refex->major) continue; if (ex->minor != ~0 && ex->minor != refex->minor) continue; if (refex->access & (~ex->access)) continue; match = true; break; } That means the new exception should be contained into an existing one to be considered a match: New exception Existing match? notes b 12:34 rwm b 12:34 rwm yes b 12:34 r b *:34 rw yes b 12:34 rw b 12:34 w no extra "r" b *:34 rw b 12:34 rw no too broad "*" b *:34 rw b *:34 rwm yes Which is fine in some cases. Consider: A (default behavior: deny, exceptions allow access) \ B (default behavior: deny, exceptions allow access) In this case the full match makes sense, the new exception cannot add more access than the parent allows But this doesn't always work, consider: A (default behavior: allow, exceptions disallow access) \ B (default behavior: deny, exceptions allow access) In this case, a new exception in B shouldn't match any of the exceptions in A, after all you can't allow something that was forbidden by A. But consider this scenario: New exception Existing in A match? outcome b 12:34 rw b 12:34 r no exception is accepted Because the new exception has "w" as extra, it doesn't match, so it'll be added to B's exception list. The same problem can happen during a file access check. Consider a cgroup with allow as default behavior: Access Exception match? b 12:34 rw b 12:34 r no In this case, the access didn't match any of the exceptions in the cgroup, which is required since exceptions will disallow access. To solve this problem, two new functions were created to match an exception either fully or partially. In the example above, a partial check will be performed and it'll produce a match since at least "b 12:34 r" from "b 12:34 rw" access matches. Cc: [email protected] Cc: Tejun Heo <[email protected]> Cc: Serge Hallyn <[email protected]> Cc: Li Zefan <[email protected]> Cc: [email protected] Signed-off-by: Aristeu Rozanski <[email protected]> Signed-off-by: Tejun Heo <[email protected]> commit 35d35aae817706800a4913711d563a99e1dc380a Author: Tushar Behera <[email protected]> Date: Thu Mar 6 11:34:43 2014 +0530 dt-bindings: clock: Move at91.h to dt-bindigs/clock Most of the clock related dt-binding header files are located in dt-bindings/clock folder. It would be good to keep all the similar header files at a single location. Signed-off-by: Tushar Behera <[email protected]> CC: Rob Landley <[email protected]> CC: Andrew Victor <[email protected]> CC: Jean-Christophe Plagniol-Villard <[email protected]> Acked-by: Boris BREZILLON <[email protected]> [[email protected]: add new at91sam9261 & at91sam9rl] Signed-off-by: Nicolas Ferre <[email protected]> commit d44db494a8d5aa2060240e7a770bbb8fefa2d2b1 Author: Bo Shen <[email protected]> Date: Tue Apr 1 15:12:43 2014 +0800 ARM: at91: fix spi cs on sama5d3 Xplained board The PD16 is the CS3 for SPI0 while not SPI1. Signed-off-by: Bo Shen <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> commit 77668c8b559e4fe2acf2a0749c7c83cde49a5025 Author: Lai Jiangshan <[email protected]> Date: Fri Apr 18 11:04:16 2014 -0400 workqueue: fix a possible race condition between rescuer and pwq-release There is a race condition between rescuer_thread() and pwq_unbound_release_workfn(). Even after a pwq is scheduled for rescue, the associated work items may be consumed by any worker. If all of them are consumed before the rescuer gets to them and the pwq's base ref was put due to attribute change, the pwq may be released while still being linked on @wq->maydays list making the rescuer dereference already freed pwq later. Make send_mayday() pin the target pwq until the rescuer is done with it. tj: Updated comment and patch description. Signed-off-by: Lai Jiangshan <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Cc: [email protected] # v3.10+ commit 4d595b866d2c653dc90a492b9973a834eabfa354 Author: Lai Jiangshan <[email protected]> Date: Fri Apr 18 11:04:16 2014 -0400 workqueue: make rescuer_thread() empty wq->maydays list before exiting After a @pwq is scheduled for emergency execution, other workers may consume the affectd work items before the rescuer gets to them. This means that a workqueue many have pwqs queued on @wq->maydays list while not having any work item pending or in-flight. If destroy_workqueue() executes in such condition, the rescuer may exit without emptying @wq->maydays. This currently doesn't cause any actual harm. destroy_workqueue() can safely destroy all the involved data structures whether @wq->maydays is populated or not as nobody access the list once the rescuer exits. However, this is nasty and makes future development difficult. Let's update rescuer_thread() so that it empties @wq->maydays after seeing should_stop to guarantee that the list is empty on rescuer exit. tj: Updated comment and patch description. Signed-off-by: Lai Jiangshan <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Cc: [email protected] # v3.10+ commit e37a06f10994c2ba86f54d8f96734f2483a869b8 Author: Li Zefan <[email protected]> Date: Thu Apr 17 13:53:08 2014 +0800 cgroup: fix the retry path of cgroup_mount() If we hit the retry path, we'll call parse_cgroupfs_options() again, but the string we pass to it has been modified by the previous call to this function. This bug can be observed by: # mount -t cgroup -o name=foo,cpuset xxx /mnt && umount /mnt && \ mount -t cgroup -o name=foo,cpuset xxx /mnt mount: wrong fs type, bad option, bad superblock on xxx, missing codepage or helper program, or other error ... The second mount passed "name=foo,cpuset" to the parser, and then it hit the retry path and call the parser again, but this time the string passed to the parser is "name=foo". To fix this, we avoid calling parse_cgroupfs_options() again in this case. Signed-off-by: Li Zefan <[email protected]> Signed-off-by: Tejun Heo <[email protected]> commit 1cc9d48145b81e307fab94a5cf6ee66ec2f0de60 Author: Thomas Petazzoni <[email protected]> Date: Sun Apr 13 16:39:38 2014 +0200 ARM: orion5x: fix target ID for crypto SRAM window In commit 4ca2c04085a1caa903e92a5fc0da25362150aac2 ('ARM: orion5x: Move to ID based window creation'), the mach-orion5x code was changed to use the new mvebu-mbus API. However, in the process, a mistake was made on the crypto SRAM window target ID: it should have been 0x9 (verified in the datasheet) and not 0x0. Signed-off-by: Thomas Petazzoni <[email protected]> Acked-by: Sebastian Hesselbarth <[email protected]> Link: https://lkml.kernel.org/r/1397400006-4315-2-git-send-email-thomas.petazzoni@free-electrons.com Fixes: 4ca2c04085a1 ('ARM: orion5x: Move to ID based window creation') Cc: [email protected] # v3.12+ Signed-off-by: Jason Cooper <[email protected]> commit ce965c3d2e68c5325dd5624eb101d70423022fef Author: Thomas Petazzoni <[email protected]> Date: Mon Apr 14 17:29:18 2014 +0200 memory: mvebu-devbus: fix the conversion of the bus width According to the Armada 370 and Armada XP datasheets, the part of the Device Bus register that configure the bus width should contain 0 for a 8 bits bus width, and 1 for a 16 bits bus width (other valu…
ddstreet
referenced
this pull request
in ddstreet/linux
May 28, 2014
GIT fba69f042ad99f68c0268ef1c012f3199f898fac commit f5c16f29bf5e57ba4051fc7785ba7f035f798c71 Author: Tejun Heo <[email protected]> Date: Mon May 19 15:52:10 2014 -0400 sysfs: make sure read buffer is zeroed 13c589d5b0ac ("sysfs: use seq_file when reading regular files") switched sysfs from custom read implementation to seq_file to enable later transition to kernfs. After the change, the buffer passed to ->show() is acquired through seq_get_buf(); unfortunately, this introduces a subtle behavior change. Before the commit, the buffer passed to ->show() was always zero as it was allocated using get_zeroed_page(). Because seq_file doesn't clear buffers on allocation and neither does seq_get_buf(), after the commit, depending on the behavior of ->show(), we may end up exposing uninitialized data to userland thus possibly altering userland visible behavior and leaking information. Fix it by explicitly clearing the buffer. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Ron <[email protected]> Fixes: 13c589d5b0ac ("sysfs: use seq_file when reading regular files") Cc: stable <[email protected]> # 3.13+ Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3685f2516116c5f3b9d498d531955ad70216ad84 Author: Shawn Guo <[email protected]> Date: Sat May 17 20:46:01 2014 +0800 ahci: imx: PLL clock needs 100us to settle down The commit e783c51 (ahci: imx: software workaround for phy reset issue in resume) calls imx_sata_phy_reset() to reset phy immediately after SATA MPLL is enabled. It seems working fine mostly, but fails in some case as below. ... ahci-imx 2200000.sata: failed to reset phy: -110 ahci-imx: probe of 2200000.sata failed with error -110 After talking to the designer, we learnt that when enabling i.MX6Q SATA MPLL, we need to wait 100us for it to settle down for safety. Add this required delay to fix above failure. Signed-off-by: Shawn Guo <[email protected]> Tested-by: Fabio Estevam <[email protected]> Signed-off-by: Tejun Heo <[email protected]> commit d0b4cc4e32705ff00d90d32da7783c266c702c04 Author: Gavin Shan <[email protected]> Date: Mon May 19 13:06:46 2014 +1000 PCI: Wrong register used to check pending traffic The incorrect register offset is passed to pci_wait_for_pending(), which is caused by commit 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())"). Fixes: 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) Signed-off-by: Gavin Shan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Alex Williamson <[email protected]> CC: [email protected] # v3.14+ commit 1e1110c43b1cda9fe77fc4a04835e460550e6b3c Author: Mikulas Patocka <[email protected]> Date: Sat May 17 06:49:22 2014 -0400 target: fix memory leak on XCOPY On each processed XCOPY command, two "kmalloc-512" memory objects are leaked. These represent two allocations of struct xcopy_pt_cmd in target_core_xcopy.c. The reason for the memory leak is that the cmd_kref field is not initialized (thus, it is zero because the allocations were done with kzalloc). When we decrement zero kref in target_put_sess_cmd, the result is not zero, thus target_release_cmd_kref is not called. This patch fixes the bug by moving kref initialization from target_get_sess_cmd to transport_init_se_cmd (this function is called from target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be easily verified that all code that calls target_get_sess_cmd also calls transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce any new problems. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] # 3.12+ Signed-off-by: Nicholas Bellinger <[email protected]> commit f9c6d4987b23e0a514464bae6771933a48e4cd01 Author: Theodore Ts'o <[email protected]> Date: Fri May 16 21:40:41 2014 -0400 random: fix BUG_ON caused by accounting simplification Commit ee1de406ba6eb1 ("random: simplify accounting logic") simplified things too much, in that it allows the following to trigger an overflow that results in a BUG_ON crash: dd if=/dev/urandom of=/dev/zero bs=67108707 count=1 Thanks to Peter Zihlstra for discovering the crash, and Hannes Frederic for analyizing the root cause. Signed-off-by: "Theodore Ts'o" <[email protected]> Reported-by: Peter Zijlstra <[email protected]> Reported-by: Hannes Frederic Sowa <[email protected]> Cc: Greg Price <[email protected]> commit d2c834abe2b39a2d5a6c38ef44de87c97cbb34b4 Author: Tuomas Tynkkynen <[email protected]> Date: Fri May 16 16:50:20 2014 +0300 clk: tegra: Fix wrong value written to PLLE_AUX The value written to PLLE_AUX was incorrect due to a wrong variable being used. Without this fix SATA does not work. Cc: [email protected] Signed-off-by: Tuomas Tynkkynen <[email protected]> Tested-by: Mikko Perttunen <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Tested-by: Thierry Reding <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Mike Turquette <[email protected]> [[email protected]: improved changelog] commit bb4e506565cfc0a2f534dfda1fb7ca5c26f7a604 Author: Jes Sorensen <[email protected]> Date: Fri May 16 22:59:18 2014 +0200 staging: rtl8723au: Do not reset wdev->iftype in netdev_close() wdev->ifdev should be set by .change_virtual_intf(). This solves the problem of WARN() messages on module unload. Signed-off-by: Jes Sorensen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 07d1d29ee1e194b932328ad2dc1d40297062ab7f Author: Hans de Goede <[email protected]> Date: Fri May 16 21:10:41 2014 +0200 ACPI / video: Revert native brightness quirk for ThinkPad T530 Seems it helps some users, but causes issues for other users: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 So lets drop it for now until we've figured out a better fix. Fixes: 43d949024425 (ACPI / video: Add use_native_backlight quirks for more systems) References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 Cc: All applicable <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> commit be02f259fda66bcfc60ecd78a819e1ce28c8bfb9 Author: Jes Sorensen <[email protected]> Date: Fri May 16 10:05:04 2014 +0200 staging: rtl8723au: Use correct pipe type for USB interrupts Use a correct pipe type when filling un interrupt urbs. This should finally take care of the WARN() messages on the console when USB urbs are submitted. Signed-off-by: Jes Sorensen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4797ec2dc83a43be35bad56037d1b53db9e2b5d5 Author: Mark Salter <[email protected]> Date: Thu May 15 15:19:22 2014 +0100 arm64: fix pud_huge() for 2-level pagetables The following happens when trying to run a kvm guest on a kernel configured for 64k pages. This doesn't happen with 4k pages: BUG: failure at include/linux/mm.h:297/put_page_testzero()! Kernel panic - not syncing: BUG! CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF 3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1 Call trace: [<fffffe0000096034>] dump_backtrace+0x0/0x16c [<fffffe00000961b4>] show_stack+0x14/0x1c [<fffffe000066e648>] dump_stack+0x84/0xb0 [<fffffe0000668678>] panic+0xf4/0x220 [<fffffe000018ec78>] free_reserved_area+0x0/0x110 [<fffffe000018edd8>] free_pages+0x50/0x88 [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40 [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44 [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184 [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c [<fffffe00001edc1c>] __fput+0xb0/0x288 [<fffffe00001ede4c>] ____fput+0xc/0x14 [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c [<fffffe0000095c14>] do_notify_resume+0x54/0x58 In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page() on the stage2 pgd which leads to the BUG in put_page_testzero(). This happens because a pud_huge() test in unmap_range() returns true when it should always be false with 2-level pages tables used by 64k pages. This patch removes support for huge puds if 2-level pagetables are being used. Signed-off-by: Mark Salter <[email protected]> [[email protected]: removed #ifndef around PUD_SIZE check] Signed-off-by: Catalin Marinas <[email protected]> Cc: <[email protected]> # v3.11+ commit dfc44f8030653b345fc6fb337558c3a07536823f Author: Leif Lindholm <[email protected]> Date: Thu Apr 17 18:42:00 2014 +0100 mips: dts: Fix missing device_type="memory" property in memory nodes A few platforms lack a 'device_type = "memory"' for their memory nodes, relying on an old ppc quirk in order to discover its memory. Add the missing data so that all parsing code can find memory nodes correctly. Signed-off-by: Leif Lindholm <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: <[email protected]> Acked-by: John Crispin <[email protected]> Signed-off-by: Grant Likely <[email protected]> commit bfaed5abad998bfc88a66e6e71c7b08dcf82f04e Author: Leif Lindholm <[email protected]> Date: Thu Apr 17 18:41:59 2014 +0100 arm: dts: Fix missing device_type="memory" for ste-ccu8540 The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for its memory node, relying on an old ppc quirk in order to discover its memory. Fix the data so that all parsing code can handle it correctly. Signed-off-by: Leif Lindholm <[email protected]> Acked-by: Lee Jones <[email protected]> Acked-by: Linus Walleij <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: <[email protected]> Signed-off-by: Grant Likely <[email protected]> commit 07b8dae38b09bcfede7e726f172e39b5ce8390d9 Author: Andy Grover <[email protected]> Date: Wed May 14 15:48:06 2014 -0700 target: Don't allow setting WC emulation if device doesn't support Just like for pSCSI, if the transport sets get_write_cache, then it is not valid to enable write cache emulation for it. Return an error. see https://bugzilla.redhat.com/show_bug.cgi?id=1082675 Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Andy Grover <[email protected]> Cc: [email protected] # 3.10+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 52d0aa7980cfee85c831b2969e659055395386d4 Author: Nicholas Bellinger <[email protected]> Date: Wed May 14 20:54:26 2014 +0000 iscsi-target: Disable Immediate + Unsolicited Data with ISER Protection This patch explicitly disables Immediate + Unsolicited Data for ISER connections during login in iscsi_login_zero_tsih_s2() when protection has been enabled for the session by the underlying hardware. This is currently required because protection / signature memory regions (MRs) expect T10 PI to occur on RDMA READs + RDMA WRITEs transfers, and not on a immediate data payload associated with ISCSI_OP_SCSI_CMD, or unsolicited data-out associated with a ISCSI_OP_SCSI_DATA_OUT. v2 changes: - Add TARGET_PROT_DOUT_INSERT check (Sagi) - Add pr_debug noisemaker (Sagi) - Add goto to avoid early return from MRDSL check (nab) Cc: Sagi Grimberg <[email protected]> Cc: Or Gerlitz <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]> commit ed8ec8f707ed4760c124d47b27c93df8ec5b1eba Author: Nicholas Bellinger <[email protected]> Date: Mon May 12 12:18:32 2014 -0700 tcm_fc: Fix free-after-use regression in ft_free_cmd This patch fixes a free-after-use regression in ft_free_cmd(), where ft_sess_put() is called with cmd->sess after percpu_ida_free() has already released the tag. Fix this bug by saving the ft_sess pointer ahead of percpu_ida_free(), and pass it directly to ft_sess_put(). The regression was originally introduced in v3.13-rc1 commit: commit 5f544cfac956971099e906f94568bc3fd1a7108a Author: Nicholas Bellinger <[email protected]> Date: Mon Sep 23 12:12:42 2013 -0700 tcm_fc: Convert to per-cpu command map pre-allocation of ft_cmd Reported-by: Jun Wu <[email protected]> Cc: Mark Rustad <[email protected]> Cc: Robert Love <[email protected]> Cc: <[email protected]> #3.13+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 7cbfcc953789ff864c2bf8365a82a3fba4869649 Author: Nicholas Bellinger <[email protected]> Date: Thu May 1 13:44:56 2014 -0700 iscsi-target: Change BUG_ON to REJECT in iscsit_process_nop_out This patch changes an incorrect use of BUG_ON to instead generate a REJECT + PROTOCOL_ERROR in iscsit_process_nop_out() code. This case can occur with traditional TCP where a flood of zeros in the data stream can reach this block for what is presumed to be a NOP-OUT with a solicited reply, but without a valid iscsi_cmd pointer. This incorrect BUG_ON was introduced during the v3.11-rc timeframe with the following commit: commit 778de368964c5b7e8100cde9f549992d521e9c89 Author: Nicholas Bellinger <[email protected]> Date: Fri Jun 14 16:07:47 2013 -0700 iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling Reported-by: Arshad Hussain <[email protected]> Cc: [email protected] # 3.11+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 14f4b54fe38f3a8f8392a50b951c8aa43b63687a Author: Sagi Grimberg <[email protected]> Date: Tue Apr 29 13:13:47 2014 +0300 Target/iscsi,iser: Avoid accepting transport connections during stop stage When the target is in stop stage, iSER transport initiates RDMA disconnects. The iSER initiator may wish to establish a new connection over the still existing network portal. In this case iSER transport should not accept and resume new RDMA connections. In order to learn that, iscsi_np is added with enabled flag so the iSER transport can check when deciding weather to accept and resume a new connection request. The iscsi_np is enabled after successful transport setup, and disabled before iscsi_np login threads are cleaned up. Signed-off-by: Sagi Grimberg <[email protected]> Cc: [email protected] # 3.10+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 531b7bf4bd795d9a09eac92504322a472c010bc8 Author: Sagi Grimberg <[email protected]> Date: Tue Apr 29 13:13:45 2014 +0300 Target/iser: Fix iscsit_accept_np and rdma_cm racy flow RDMA CM and iSCSI target flows are asynchronous and completely uncorrelated. Relying on the fact that iscsi_accept_np will be called after CM connection request event and will wait for it is a mistake. When attempting to login to a few targets this flow is racy and unpredictable, but for parallel login to dozens of targets will race and hang every time. The correct synchronizing mechanism in this case is pending on a semaphore rather than a wait_for_event. We keep the pending interruptible for iscsi_np cleanup stage. (Squash patch to remove dead code into parent - nab) Reported-by: Slava Shwartsman <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Cc: [email protected] # 3.10+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 9fe63c88b1d59f1ce054d6948ccd3096496ecedb Author: Sagi Grimberg <[email protected]> Date: Tue Apr 29 13:13:44 2014 +0300 Target/iser: Fix wrong connection requests list addition Should be adding list_add_tail($new, $head) and not the other way around. Signed-off-by: Sagi Grimberg <[email protected]> Cc: [email protected] # 3.10+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 448ba904160f9d8f69217c28a1692cee5afbff88 Author: Andy Grover <[email protected]> Date: Tue Apr 15 14:13:12 2014 -0700 target: Allow non-supporting backends to set pi_prot_type to 0 Userspace tools assume if a value is read from configfs, it is valid and will not cause an error if the same value is written back. The only valid value for pi_prot_type for backends not supporting DIF is 0, so allow this particular value to be set without returning an error. Reported-by: Krzysztof Chojnowski <[email protected]> Signed-off-by: Andy Grover <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Cc: [email protected] # 3.14+ Signed-off-by: Nicholas Bellinger <[email protected]> commit c776cd89fc705fc8b5c2e5ad906bf5d791620fed Author: John David Anglin <[email protected]> Date: Sun May 11 18:40:50 2014 -0400 parisc: Improve LWS-CAS performance The attached change significantly improves the performance of the LWS-CAS code in syscall.S. This allows a number of packages to build (e.g., zeromq3, gtest and libxs) that previously failed because slow LWS-CAS performance under contention. In particular, interrupts taken while the lock was taken degraded performance significantly. The change does the following: 1) Disables interrupts around the CAS operation, and 2) Changes the loads and stores to use the ordered completer, "o", on PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is accepted on both PA 1.X and 2.0. The use of ordered loads and stores probably makes no difference on all existing hardware, but it seemed pedantically correct. In particular, the CAS operation must complete before LDCW lock is released. As written before, a processor could reorder the operations. I don't believe the period interrupts are disabled is long enough to significantly increase interrupt latency. For example, the TLB insert code is longer. Worst case is a memory fault in the CAS operation. Signed-off-by: John David Anglin <[email protected]> Cc: [email protected] # 3.13+ Signed-off-by: Helge Deller <[email protected]> commit fef47e2a2e1e75fe50a10f634a80f16808348cc6 Author: Helge Deller <[email protected]> Date: Mon May 5 18:07:12 2014 +0200 parisc: ratelimit userspace segfault printing Ratelimit printing of userspace segfaults and make it runtime configurable via the /proc/sys/debug/exception-trace variable. This should resolve syslog from growing way too fast and thus prevents possible system service attacks. Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # 3.13+ commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc Author: Marcel Apfelbaum <[email protected]> Date: Thu May 15 12:42:49 2014 -0600 PCI: shpchp: Check bridge's secondary (not primary) bus speed When a new device is added below a hotplug bridge, the bridge's secondary bus speed and the device's bus speed must match. The shpchp driver previously checked the bridge's *primary* bus speed, not the secondary bus speed. This caused hot-add errors like: shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch Check the secondary bus speed instead. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251 Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core") Signed-off-by: Marcel Apfelbaum <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> CC: [email protected] # v2.6.34+ commit 4c358e15553ed88bf2ddae422624624e1dd663d1 Author: Stephen Rothwell <[email protected]> Date: Thu May 15 14:44:30 2014 +1000 of: fix CONFIG_OF=n prototype of of_node_full_name() Make the CONFIG_OF=n prototpe of of_node_full_name() mateh the CONFIG_OF=y version. Fixes compile warnings like this: sound/soc/soc-core.c: In function 'soc_check_aux_dev': sound/soc/soc-core.c:1667:3: warning: passing argument 1 of 'of_node_full_name' discards 'const' qualifier from pointer target type [enabled by default] codecname = of_node_full_name(aux_dev->codec_of_node); when CONFIG_OF is not defined. Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Grant Likely <[email protected]> commit e95a2f7509f5219177d6821a0a8754f93892ca56 Author: Ville Syrjälä <[email protected]> Date: Thu May 8 15:09:19 2014 +0300 drm/i915: Increase WM memory latency values on SNB On SNB the BIOS provided WM memory latency values seem insufficient to handle high resolution displays. In this particular case the display mode was a 2560x1440@60Hz, which makes the pixel clock 241.5 MHz. It was empirically found that a memory latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec is what the typical BIOS provided values are on IVB systems. Increase the WM memory latency values to at least 1.2 usec on SNB. Hopefully this won't have a significant effect on power consumption. v2: Increase the latency values regardless of the pixel clock Cc: Robert N <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254 Tested-by: Robert Navarro <[email protected]> Tested-by: Vitaly Minko <[email protected]> Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> commit 721e82c08c1afd6b47367b0e0c4a62140b0667f3 Author: Aaron Lu <[email protected]> Date: Mon May 12 16:55:45 2014 +0800 drm/i915: restore backlight precision when converting from ACPI When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491 Reported-by: Nico Schottelius <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Aaron Lu <[email protected]> Signed-off-by: Jani Nikula <[email protected]> commit afba0b5a221c0dacbbdf3a778d539fbc90fc6191 Author: Chris Wilson <[email protected]> Date: Tue May 13 16:07:37 2014 +0100 drm/i915: Use the first mode if there is no preferred mode in the EDID This matches the algorithm used by earlier kernels when selecting the mode for the fbcon. And only if there is no modes at all, do we fall back to using the BIOS configuration. Seamless transition is still preserved (from the BIOS configuration to ours) so long as the BIOS has also chosen what we hope is the native configuration. Reported-by: Knut Petersen <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655 Reviewed-by: Jesse Barnes <[email protected]> Tested-by: Knut Petersen <[email protected]> Signed-off-by: Chris Wilson <[email protected]> [Jani: applied Chris' "Please imagine that I wrote this correctly."] Signed-off-by: Jani Nikula <[email protected]> commit f4cdbc21444a45d207a8dc175f44d2facfbd0845 Author: Jani Nikula <[email protected]> Date: Wed May 14 13:02:19 2014 +0300 drm/i915/dp: force eDP lane count to max available lanes on BDW There are certain BDW high res eDP machines that regressed due to commit 38aecea0ccbb909d635619cba22f1891e589b434 Author: Daniel Vetter <[email protected]> Date: Mon Mar 3 11:18:10 2014 +0100 drm/i915: reverse dp link param selection, prefer fast over wide again The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at 2.7 Gbps on the affected machines. Link training succeeded for both, but the screen remained blank with the former config. Further investigation showed that 4 lanes at 5.4 Gbps worked also. The root cause for the blank screen using 2 lanes remains unknown, but apparently the driver for a certain other operating system by default uses the max available lanes. Follow suit on Broadwell eDP, for at least until we figure out what is going on. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711 Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Tested-by: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> commit fa81511bb0bbb2b1aace3695ce869da9762624ff Author: Linus Torvalds <[email protected]> Date: Wed May 14 16:33:54 2014 -0700 x86-64, modify_ldt: Make support for 16-bit segments a runtime option Checkin: b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels disabled 16-bit segments on 64-bit kernels due to an information leak. However, it does seem that people are genuinely using Wine to run old 16-bit Windows programs on Linux. A proper fix for this ("espfix64") is coming in the upcoming merge window, but as a temporary fix, create a sysctl to allow the administrator to re-enable support for 16-bit segments. It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If you hit this issue and care about your old Windows program more than you care about a kernel stack address information leak, you can do echo 1 > /proc/sys/abi/ldt16 as root (add it to your startup scripts), and you should be ok. The sysctl table is only added if you have COMPAT support enabled on x86-64, but I assume anybody who runs old windows binaries very much does that ;) Signed-off-by: H. Peter Anvin <[email protected]> Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com Cc: <[email protected]> commit ffe6902b66aaa4ca6694bc19639259c16d84ddb1 Author: James Hogan <[email protected]> Date: Thu May 1 15:05:07 2014 +0100 asm-generic: remove _STK_LIM_MAX _STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from an arch's include/uapi/asm-generic/resource.h file, but is no longer used since both parisc and metag removed the override. Therefore remove it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY directly in include/asm-generic/resource.h. Signed-off-by: James Hogan <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: [email protected] Cc: Helge Deller <[email protected]> Cc: John David Anglin <[email protected]> commit c70458f50cd4271410aa75011f56ffabc0e2d34a Author: James Hogan <[email protected]> Date: Thu May 1 12:31:14 2014 +0100 metag: Remove _STK_LIM_MAX override Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to 256MB, apparently in an attempt to prevent setup_arg_pages's STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is far too large for Meta's limited virtual address space and hits a BUG_ON (stack_top is usually 0x3ffff000). However the commit "metag: Reduce maximum stack size to 256MB" reduces the absolute stack size limit to a safe value for metag. This allows the default _STK_LIM_MAX override to be removed, bringing the default behaviour in line with all other architectures. Parisc in particular recently removed their override of _STK_LIMT_MAX in commit e0d8898d76a7 (parisc: remove _STK_LIM_MAX override) since it subtly affects stack allocation semantics in userland. Meta's uapi/asm/resource.h can now be removed and switch to using generic-y. Suggested-by: Helge Deller <[email protected]> Signed-off-by: James Hogan <[email protected]> Cc: [email protected] Cc: John David Anglin <[email protected]> commit 042d27acb64924a0e8a43e972485913a32407beb Author: Helge Deller <[email protected]> Date: Wed Apr 30 23:26:02 2014 +0200 parisc,metag: Do not hardcode maximum userspace stack size This patch affects only architectures where the stack grows upwards (currently parisc and metag only). On those do not hardcode the maximum initial stack size to 1GB for 32-bit processes, but make it configurable via a config option. The main problem with the hardcoded stack size is, that we have two memory regions which grow upwards: stack and heap. To keep most of the memory available for heap in a flexmap memory layout, it makes no sense to hard allocate up to 1GB of the memory for stack which can't be used as heap then. This patch makes the stack size for 32-bit processes configurable and uses 80MB as default value which has been in use during the last few years on parisc and which hasn't showed any problems yet. Signed-off-by: Helge Deller <[email protected]> Signed-off-by: James Hogan <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: John David Anglin <[email protected]> commit d71f290b4e98a39f49f2595a13be3b4d5ce8e1f1 Author: James Hogan <[email protected]> Date: Tue May 13 23:58:24 2014 +0100 metag: Reduce maximum stack size to 256MB Specify the maximum stack size for arches where the stack grows upward (parisc and metag) in asm/processor.h rather than hard coding in fs/exec.c so that metag can specify a smaller value of 256MB rather than 1GB. This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased beyond a safe value by root. E.g. when starting a process after running "ulimit -H -s unlimited" it will then attempt to use a stack size of the maximum 1GB which is far too big for metag's limited user virtual address space (stack_top is usually 0x3ffff000): BUG: failure at fs/exec.c:589/shift_arg_pages()! Signed-off-by: James Hogan <[email protected]> Cc: Helge Deller <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: John David Anglin <[email protected]> Cc: [email protected] # only needed for >= v3.9 (arch/metag) commit 2425ce84026c385b73ae72039f90d042d49e0394 Author: Mikulas Patocka <[email protected]> Date: Thu May 8 15:51:37 2014 -0400 metag: fix memory barriers Volatile access doesn't really imply the compiler barrier. Volatile access is only ordered with respect to other volatile accesses, it isn't ordered with respect to general memory accesses. Gcc may reorder memory accesses around volatile access, as we can see in this simple example (if we compile it with optimization, both increments of *b will be collapsed to just one): void fn(volatile int *a, long *b) { (*b)++; *a = 10; (*b)++; } Consequently, we need the compiler barrier after a write to the volatile variable, to make sure that the compiler doesn't reorder the volatile write with something else. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Acked-by: Peter Zijlstra <[email protected]> Signed-off-by: James Hogan <[email protected]> commit 4cdd2ad78098244c1bc9ec4374ea1c225fd1cd6f Author: Mike Snitzer <[email protected]> Date: Tue May 13 13:49:39 2014 -0400 dm mpath: fix lock order inconsistency in multipath_ioctl Commit 3e9f1be1b40 ("dm mpath: remove process_queued_ios()") did not consistently take the multipath device's spinlock (m->lock) before calling dm_table_run_md_queue_async() -- which takes the q->queue_lock. Found with code inspection using hint from reported lockdep warning. Reported-by: Bart Van Assche <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> commit 85ad643b7e7e52d37620fb272a9fd577a8095647 Author: Joe Thornber <[email protected]> Date: Fri May 9 15:59:38 2014 +0100 dm thin: add timeout to stop out-of-data-space mode holding IO forever If the pool runs out of data space, dm-thin can be configured to either error IOs that would trigger provisioning, or hold those IOs until the pool is resized. Unfortunately, holding IOs until the pool is resized can result in a cascade of tasks hitting the hung_task_timeout, which may render the system unavailable. Add a fixed timeout so IOs can only be held for a maximum of 60 seconds. If LVM is going to resize a thin-pool that is out of data space it needs to be prompt about it. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected] # 3.14+ commit 8d07e8a5f5bc7b90f755d9b427ea930024f4c986 Author: Joe Thornber <[email protected]> Date: Tue May 6 16:28:14 2014 +0100 dm thin: allow metadata commit if pool is in PM_OUT_OF_DATA_SPACE mode Commit 3e1a0699 ("dm thin: fix out of data space handling") introduced a regression in the metadata commit() method by returning an error if the pool is in PM_OUT_OF_DATA_SPACE mode. This oversight caused a thin device to return errors even if the default queue_if_no_space ENOSPC handling mode is used. Fix commit() to only fail if pool is in PM_READ_ONLY or PM_FAIL mode. Reported-by: [email protected] Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected] # 3.14+ commit 610f2de3559c383caf8fbbf91e9968102dff7ca0 Author: Mikulas Patocka <[email protected]> Date: Thu Feb 20 18:01:01 2014 -0500 dm crypt: fix cpu hotplug crash by removing per-cpu structure The DM crypt target used per-cpu structures to hold pointers to a ablkcipher_request structure. The code assumed that the work item keeps executing on a single CPU, so it didn't use synchronization when accessing this structure. If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online, the work item could be moved to another CPU. This causes dm-crypt crashes, like the following, because the code starts using an incorrect ablkcipher_request: smpboot: CPU 7 is now offline BUG: unable to handle kernel NULL pointer dereference at 0000000000000130 IP: [<ffffffffa1862b3d>] crypt_convert+0x12d/0x3c0 [dm_crypt] ... Call Trace: [<ffffffffa1864415>] ? kcryptd_crypt+0x305/0x470 [dm_crypt] [<ffffffff81062060>] ? finish_task_switch+0x40/0xc0 [<ffffffff81052a28>] ? process_one_work+0x168/0x470 [<ffffffff8105366b>] ? worker_thread+0x10b/0x390 [<ffffffff81053560>] ? manage_workers.isra.26+0x290/0x290 [<ffffffff81058d9f>] ? kthread+0xaf/0xc0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 [<ffffffff813464ac>] ? ret_from_fork+0x7c/0xb0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 Fix this bug by removing the per-cpu definition. The structure ablkcipher_request is accessed via a pointer from convert_context. Consequently, if the work item is rescheduled to a different CPU, the thread still uses the same ablkcipher_request. This change may undermine performance improvements intended by commit c0297721 ("dm crypt: scale to multiple cpus") on select hardware. In practice no performance difference was observed on recent hardware. But regardless, correctness is more important than performance. Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected] commit d7653964c590ba846aa11a8f6edf409773cbc492 Author: Wolfram Sang <[email protected]> Date: Mon May 5 18:36:21 2014 +0200 i2c: rcar: bail out on zero length transfers This hardware does not support zero length transfers. Instead, the driver does one (random) byte transfers currently with undefined results for the slaves. We now bail out. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] commit fa01d096bfcfd89398b1f3a3f91805dab76f7fe5 Author: Andy Gross <[email protected]> Date: Fri May 2 20:54:29 2014 -0500 i2c: qup: Fix pm_runtime_get_sync usage This patch corrects the error check on the call to pm_runtime_get_sync. Signed-off-by: Andy Gross <[email protected]> Reviewed-by: Ivan T. Ivanov <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> commit ce78cc071f5f541480e381cc0241d37590041a9d Author: Olof Johansson <[email protected]> Date: Fri Apr 11 15:19:41 2014 -0700 i2c: s3c2410: resume race fix Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Doug Anderson <[email protected]> Acked-by: Kukjin Kim <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] commit 37e5eb0bae7bb4d98c2153c3c3400b5c00c3cad1 Author: Ulf Hansson <[email protected]> Date: Thu Apr 10 16:19:29 2014 +0200 i2c: nomadik: Don't use IS_ERR for devm_ioremap devm_ioremap() returns NULL on error, not an error. Signed-off-by: Ulf Hansson <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] commit 47bb27e78867997040a228328f2a631c3c7f2c82 Author: Du, Wenkai <[email protected]> Date: Thu Apr 10 23:03:19 2014 +0000 i2c: designware: Mask all interrupts during i2c controller enable There have been "i2c_designware 80860F41:00: controller timed out" errors on a number of Baytrail platforms. The issue is caused by incorrect value in Interrupt Mask Register (DW_IC_INTR_MASK) when i2c core is being enabled. This causes call to __i2c_dw_enable() to immediately start the transfer which leads to timeout. There are 3 failure modes observed: 1. Failure in S0 to S3 resume path The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start the first transaction after resuming from system sleep, TX_EMPTY interrupt is already unmasked because of the hardware default. 2. Failure in normal operational path This failure happens rarely and is hard to reproduce. Debug trace showed that DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant TX_EMPTY was unmasked. 3. Failure in S3 to S0 suspend path This failure also happens rarely and is hard to reproduce. Adding debug trace that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR call trace we could conclude TX_EMPTY was unmasked when problem occurred. The patch masks all interrupts before the controller is enabled to resolve the faulty DW_IC_INTR_MASK conditions. Signed-off-by: Wenkai Du <[email protected]> Acked-by: Mika Westerberg <[email protected]> [wsa: improved the comment and removed typo in commit msg] Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] commit 7bb394094080a26de06efcd6a870cb2ba21cfb16 Author: Steven J. Hill <[email protected]> Date: Thu Apr 10 14:06:17 2014 -0500 MIPS: mm: Fix broken microMIPS kernel regression. Commit f4ae17aa0f2122b52f642985b46210a1f2eceb0a [MIPS: mm: Use scratch for PGD when !CONFIG_MIPS_PGD_C0_CONTEXT] broke microMIPS kernel builds. This patch refactors that code similar to what was done for the 'clear_page' and 'copy_page' functions. Signed-off-by: Steven J. Hill <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/6744/ Signed-off-by: Ralf Baechle <[email protected]> commit 665ebe926e7b714369b5329d48745bfef17db512 Author: Dan Carpenter <[email protected]> Date: Wed May 14 16:32:21 2014 +0300 ALSA: sb_mixer: missing return statement The if condition here was supposed to return on error but the return statement is missing. The effect is that the ->mixername is set to "???" instead of "DT019X". Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> commit 582da6527da30f6e21a95c9f3f2810d46a8f406e Author: Thomas Petazzoni <[email protected]> Date: Wed May 14 13:36:36 2014 +0200 of: make of_update_property() usable earlier in the boot process Commit 75b57ecf9d1d1e17d099ab13b8f48e6e038676be ('of: Make device nodes kobjects so they show up in sysfs') has turned Device Tree nodes in kobjects and added a sysfs based representation for Device Tree nodes. Since the sysfs logic is only available after the execution of a core_initcall(), the patch took precautions in of_add_property() and of_remove_property() to not do any sysfs related manipulation early in the boot process. However, it forgot to do the same for of_update_property(), which if used early in the boot process (before core_initcalls have been called), tries to call sysfs_remove_bin_file(), and crashes: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at /home/thomas/projets/linux-2.6/fs/kernfs/dir.c:1216 kernfs_remove_by_name_ns+0x80/0x88() kernfs: can not remove '(null)', no directory Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1-00127-g1d7e7b2-dirty #423 [<c0014910>] (unwind_backtrace) from [<c00110ec>] (show_stack+0x10/0x14) [<c00110ec>] (show_stack) from [<c04c84b8>] (dump_stack+0x84/0x94) [<c04c84b8>] (dump_stack) from [<c001d8c0>] (warn_slowpath_common+0x6c/0x88) [<c001d8c0>] (warn_slowpath_common) from [<c001d90c>] (warn_slowpath_fmt+0x30/0x40) [<c001d90c>] (warn_slowpath_fmt) from [<c0104468>] (kernfs_remove_by_name_ns+0x80/0x88) [<c0104468>] (kernfs_remove_by_name_ns) from [<c0394d98>] (of_update_property+0xc0/0xf0) [<c0394d98>] (of_update_property) from [<c0647248>] (mvebu_timer_and_clk_init+0xfc/0x194) [<c0647248>] (mvebu_timer_and_clk_init) from [<c0640934>] (start_kernel+0x218/0x350) [<c0640934>] (start_kernel) from [<00008070>] (0x8070) ---[ end trace 3406ff24bd97382e ]--- Unable to handle kernel NULL pointer dereference at virtual address 0000003c pgd = c0004000 [0000003c] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.15.0-rc1-00127-g1d7e7b2-dirty #423 task: c10ad4d8 ti: c10a2000 task.ti: c10a2000 PC is at kernfs_find_ns+0x8/0xf0 LR is at kernfs_find_and_get_ns+0x30/0x48 pc : [<c0103834>] lr : [<c010394c>] psr: 600001d3 sp : c10a3f34 ip : 00000073 fp : 00000000 r10: 00000000 r9 : cfffc240 r8 : cfdf2980 r7 : cf812c00 r6 : 00000000 r5 : 00000000 r4 : c10b45e0 r3 : c10ad4d8 r2 : 00000000 r1 : cf812c00 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 0000404a DAC: 00000015 Process swapper/0 (pid: 0, stack limit = 0xc10a2240) Stack: (0xc10a3f34 to 0xc10a4000) 3f20: c10b45e0 00000000 00000000 3f40: cf812c00 c010394c 00000063 cf812c00 00000001 cf812c00 cfdf29ac c03932cc 3f60: 00000063 cf812bc0 cfdf29ac cf812c00 ffffffff c03943f8 cfdf2980 c0104468 3f80: cfdf2a04 cfdf2980 cf812bc0 c06634b0 c10aa3c0 c0394da4 c10f74dc cfdf2980 3fa0: cf812bc0 c0647248 c10aa3c0 ffffffff c10de940 c10aa3c0 ffffffff c0640934 3fc0: ffffffff ffffffff c06404ec 00000000 00000000 c06634b0 00000000 10c53c7d 3fe0: c10aa434 c06634ac c10ae4c8 0000406a 414fc091 00008070 00000000 00000000 [<c0103834>] (kernfs_find_ns) from [<00000001>] (0x1) Code: e5c89001 eaffffcf e92d40f0 e1a06002 (e1d023bc) ---[ end trace 3406ff24bd97382f ]--- Kernel panic - not syncing: Attempted to kill the idle task! ---[ end Kernel panic - not syncing: Attempted to kill the idle task! To fix this problem, we simply skip the sysfs related calls in of_update_property(), and rely on of_init() to fix up things when it will be called, exactly as is done in of_add_property() and of_remove_property(). Signed-off-by: Thomas Petazzoni <[email protected]> Fixes: 75b57ecf9d1d ("of: Make device nodes kobjects so they show up in sysfs") Signed-off-by: Grant Likely <[email protected]> commit f2d0801f00b7aff0ac6b3666cbcdab499267418a Author: Markos Chandras <[email protected]> Date: Tue Apr 22 15:40:36 2014 +0100 MIPS: Add new AUDIT_ARCH token for the N32 ABI on MIPS64 A MIPS64 kernel may support ELF files for all 3 MIPS ABIs (O32, N32, N64). Furthermore, the AUDIT_ARCH_MIPS{,EL}64 token does not provide enough information about the ABI for the 64-bit process. As a result of which, userland needs to use complex seccomp filters to decide whether a syscall belongs to the o32 or n32 or n64 ABI. Therefore, a new arch token for MIPS64/n32 is added so it can be used by seccomp to explicitely set syscall filters for this ABI. Signed-off-by: Markos Chandras <[email protected]> Acked-by: Eric Paris <[email protected]> Acked-by: Paul Moore <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: [email protected] Link: http://sourceforge.net/p/libseccomp/mailman/message/32239040/ Patchwork: https://patchwork.linux-mips.org/patch/6818/ Signed-off-by: Ralf Baechle <[email protected]> commit 9844f5462392b53824e8b86726e7c33b5ecbb676 Author: Anthony Iliopoulos <[email protected]> Date: Wed May 14 11:29:48 2014 +0200 x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow() The invalidation is required in order to maintain proper semantics under CoW conditions. In scenarios where a process clones several threads, a thread operating on a core whose DTLB entry for a particular hugepage has not been invalidated, will be reading from the hugepage that belongs to the forked child process, even after hugetlb_cow(). The thread will not see the updated page as long as the stale DTLB entry remains cached, the thread attempts to write into the page, the child process exits, or the thread gets migrated to a different processor. Signed-off-by: Anthony Iliopoulos <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Suggested-by: Shay Goikhman <[email protected]> Acked-by: Dave Hansen <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Cc: <[email protected]> # v2.6.16+ (!) commit 97d9d23dda6f37d90aefeec4ed619d52df525382 Author: Guennadi Liakhovetski <[email protected]> Date: Sat Apr 26 12:51:31 2014 -0300 [media] V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode If a struct contains 64-bit fields, it is aligned on 64-bit boundaries within containing structs in 64-bit compilations. This is the case with struct v4l2_window, which contains pointers and is embedded into struct v4l2_format, and that one is embedded into struct v4l2_create_buffers. Unlike some other structs, used as a part of the kernel ABI as ioctl() arguments, that are packed, these structs aren't packed. This isn't a problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains a bug, that triggers in such 64-bit builds. That code wrongly assumes, that in struct v4l2_create_buffers, struct v4l2_format immediately follows the __u32 memory field, which in fact isn't the case. This bug wasn't visible until now, because until recently hardly any applications used this ioctl() and mostly embedded 32-bit only drivers implemented it. This is changing now with addition of this ioctl() to some USB drivers, e.g. UVC. This patch fixes the bug by copying parts of struct v4l2_create_buffers separately. Signed-off-by: Guennadi Liakhovetski <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Cc: [email protected] commit cfece5857ca51d1dcdb157017aba226f594e9dcf Author: Guennadi Liakhovetski <[email protected]> Date: Mon Apr 14 10:49:34 2014 -0300 [media] V4L2: ov7670: fix a wrong index, potentially Oopsing the kernel from user-space Commit 75e2bdad8901a0b599e01a96229be922eef1e488 "ov7670: allow configuration of image size, clock speed, and I/O method" uses a wrong index to iterate an array. Apart from being wrong, it also uses an unchecked value from user-space, which can cause access to unmapped memory in the kernel, triggered by a normal desktop user with rights to use V4L2 devices. Signed-off-by: Guennadi Liakhovetski <[email protected]> Acked-by: Jonathan Corbet <[email protected]> Cc: [email protected] Signed-off-by: Mauro Carvalho Chehab <[email protected]> commit 2ed9fd28c2884e9f41c133f86a7e377d7c0a96bf Author: Jason Cooper <[email protected]> Date: Tue May 13 18:47:01 2014 +0000 MAINTAINERS: Add co-maintainer for drivers/irqchip Thomas Gleixner has asked me to assist with the review and merging of patches for the irqchip subsystem. Signed-off-by: Jason Cooper <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> commit 44330ab516c15dda8a1e660eeaf0003f84e43e3f Author: Charles Keepax <[email protected]> Date: Tue May 13 13:45:15 2014 +0100 ASoC: wm8962: Update register CLASS_D_CONTROL_1 to be non-volatile The register CLASS_D_CONTROL_1 is marked as volatile because it contains a bit, DAC_MUTE, which is also mirrored in the ADC_DAC_CONTROL_1 register. This causes problems for the "Speaker Switch" control, which will report an error if the CODEC is suspended because it relies on a volatile register. To resolve this issue mark CLASS_D_CONTROL_1 as non-volatile and manually keep the register cache in sync by updating both bits when changing the mute status. Reported-by: Shawn Guo <[email protected]> Signed-off-by: Charles Keepax <[email protected]> Tested-by: Shawn Guo <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: [email protected] commit cffd6665f57ed18f4be9185c4330c8c98c22e201 Author: Jarkko Nikula <[email protected]> Date: Tue May 13 15:46:06 2014 +0300 ASoC: Intel: Fix Baytrail SST DSP firmware loading Commit 10df350977b1 ("ASoC: Intel: Fix Audio DSP usage when IOMMU is enabled.") caused following regression in Baytrail SST: baytrail-pcm-audio baytrail-pcm-audio: error: DMA alloc failed baytrail-pcm-audio baytrail-pcm-audio: error: failed to load firmware Fix this by calling dma_coerce_mask_and_coherent() in sst_byt_init() with the same dma_dev device what is now used in sst_fw_new() when allocating the DMA buffer. Signed-off-by: Jarkko Nikula <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 367f0b50e502d2c384277ba2ed43b04add2b8b6f Author: Ralf Baechle <[email protected]> Date: Tue May 13 17:56:41 2014 +0200 MIPS: Wire up renameat2 syscall. Signed-off-by: Ralf Baechle <[email protected]> commit d40a63c45b506b0681918d7c62a15cc9d48c8681 Author: Dirk Brandewie <[email protected]> Date: Thu May 8 12:57:24 2014 -0700 intel_pstate: remove setting P state to MAX on init Setting the P state of the core to max at init time is a hold over from early implementation of intel_pstate where intel_pstate disabled cpufreq and loaded VERY early in the boot sequence. This was to ensure that intel_pstate did not affect boot time. This in not needed now that intel_pstate is a cpufreq driver. Removing this covers the case where a CPU has gone through a manual CPU offline/online cycle and the P state is set to MAX on init and the CPU immediately goes idle. Due to HW coordination the P state request on the idle CPU will drag all cores to MAX P state until the load is reevaluated when to core goes non-idle. Reported-by: Patrick Marlier <[email protected]> Signed-off-by: Dirk Brandewie <[email protected]> Cc: 3.14+ <[email protected]> # 3.14+ Signed-off-by: Rafael J. Wysocki <[email protected]> commit 36e9d2ebcc15d029b33f42a36146ab5a5bcfcfe7 Author: Tejun Heo <[email protected]> Date: Tue May 13 11:28:30 2014 -0400 cgroup: fix rcu_read_lock() leak in update_if_frozen() While updating cgroup_freezer locking, 68fafb77d827 ("cgroup_freezer: replace freezer->lock with freezer_mutex") introduced a bug in update_if_frozen() where it returns with rcu_read_lock() held. Fix it by adding rcu_read_unlock() before returning. Signed-off-by: Tejun Heo <[email protected]> Reported-by: kbuild test robot <[email protected]> commit e5ced8ebb10c20a3b349bd798b69ccabd3b25d21 Author: Tejun Heo <[email protected]> Date: Wed May 7 21:31:17 2014 -0400 cgroup_freezer: replace freezer->lock with freezer_mutex After 96d365e0b86e ("cgroup: make css_set_lock a rwsem and rename it to css_set_rwsem"), css task iterators requires sleepable context as it may block on css_set_rwsem. I missed that cgroup_freezer was iterating tasks under IRQ-safe spinlock freezer->lock. This leads to errors like the following on freezer state reads and transitions. BUG: sleeping function called from invalid context at /work /os/work/kernel/locking/rwsem.c:20 in_atomic(): 0, irqs_disabled(): 0, pid: 462, name: bash 5 locks held by bash/462: #0: (sb_writers#7){.+.+.+}, at: [<ffffffff811f0843>] vfs_write+0x1a3/0x1c0 #1: (&of->mutex){+.+.+.}, at: [<ffffffff8126d78b>] kernfs_fop_write+0xbb/0x170 #2: (s_active#70){.+.+.+}, at: [<ffffffff8126d793>] kernfs_fop_write+0xc3/0x170 #3: (freezer_mutex){+.+...}, at: [<ffffffff81135981>] freezer_write+0x61/0x1e0 #4: (rcu_read_lock){......}, at: [<ffffffff81135973>] freezer_write+0x53/0x1e0 Preemption disabled at:[<ffffffff81104404>] console_unlock+0x1e4/0x460 CPU: 3 PID: 462 Comm: bash Not tainted 3.15.0-rc1-work+ #10 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 ffff88000916a6d0 ffff88000e0a3da0 ffffffff81cf8c96 0000000000000000 ffff88000e0a3dc8 ffffffff810cf4f2 ffffffff82388040 ffff880013aaf740 0000000000000002 ffff88000e0a3de8 ffffffff81d05974 0000000000000246 Call Trace: [<ffffffff81cf8c96>] dump_stack+0x4e/0x7a [<ffffffff810cf4f2>] __might_sleep+0x162/0x260 [<ffffffff81d05974>] down_read+0x24/0x60 [<ffffffff81133e87>] css_task_iter_start+0x27/0x70 [<ffffffff8113584d>] freezer_apply_state+0x5d/0x130 [<ffffffff81135a16>] freezer_write+0xf6/0x1e0 [<ffffffff8112eb88>] cgroup_file_write+0xd8/0x230 [<ffffffff8126d7b7>] kernfs_fop_write+0xe7/0x170 [<ffffffff811f0756>] vfs_write+0xb6/0x1c0 [<ffffffff811f121d>] SyS_write+0x4d/0xc0 [<ffffffff81d08292>] system_call_fastpath+0x16/0x1b freezer->lock used to be used in hot paths but that time is long gone and there's no reason for the lock to be IRQ-safe spinlock or even per-cgroup. In fact, given the fact that a cgroup may contain large number of tasks, it's not a good idea to iterate over them while holding IRQ-safe spinlock. Let's simplify locking by replacing per-cgroup freezer->lock with global freezer_mutex. This also makes the comments explaining the intricacies of policy inheritance and the locking around it as the states are protected by a common mutex. The conversion is mostly straight-forward. The followings are worth mentioning. * freezer_css_online() no longer needs double locking. * freezer_attach() now performs propagation simply while holding freezer_mutex. update_if_frozen() race no longer exists and the comment is removed. * freezer_fork() now tests whether the task is in root cgroup using the new task_css_is_root() without doing rcu_read_lock/unlock(). If not, it grabs freezer_mutex and performs the operation. * freezer_read() and freezer_change_state() grab freezer_mutex across the whole operation and pin the css while iterating so that each descendant processing happens in sleepable context. Fixes: 96d365e0b86e ("cgroup: make css_set_lock a rwsem and rename it to css_set_rwsem") Signed-off-by: Tejun Heo <[email protected]> Acked-by: Li Zefan <[email protected]> commit 5024ae29cd285ce9e736776414da645d3a91828c Author: Tejun Heo <[email protected]> Date: Wed May 7 21:31:17 2014 -0400 cgroup: introduce task_css_is_root() Determining the css of a task usually requires RCU read lock as that's the only thing which keeps the returned css accessible till its reference is acquired; however, testing whether a task belongs to the root can be performed without dereferencing the returned css by comparing the returned pointer against the root one in init_css_set[] which never changes. Implement task_css_is_root() which can be invoked in any context. This will be used by the scheduled cgroup_freezer change. v2: cgroup no longer supports modular controllers. No need to export init_css_set. Pointed out by Li. Signed-off-by: Tejun Heo <[email protected]> Acked-by: Li Zefan <[email protected]> commit 85dbd5801f62b66e2aa7826aaefcaebead44c8a6 Author: Lv Zheng <[email protected]> Date: Tue May 13 16:50:30 2014 +0800 ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses. We need to find a smarter way to switch to 64-bit FADT addresses according to the bug report. This patch reverts Linux to the original behavior. Fixes: 0249ed2444d6 (ACPICA: Add option to favor 32-bit FADT addresses.) References: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Reported-and-tested-by: Oswald Buddenhagen <[email protected]> Signed-off-by: Lv Zheng <[email protected]> Cc: 3.14+ <[email protected]> # 3.14+ Signed-off-by: Rafael J. Wysocki <[email protected]> commit 5ff365fb6aed4c7ee5aae7b0239ce0b514aefabc Author: Aaron Lu <[email protected]> Date: Tue May 13 09:51:50 2014 +0800 ACPI / video: correct DMI tag for Dell Inspiron 7520 The DMI tag used to identify Dell Inspiron 7520 should be product name instead of product version. Fixes: 0e9f81d3b7cd (ACPI / video: Add systems that should favour native backlight interface) Reported-and-tested-by: Téo Mazars <[email protected]> References: https://bugzilla.redhat.com/show_bug.cgi?id=909552 Cc: All applicable <[email protected]> Signed-off-by: Aaron Lu <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> commit 555724a831b4a146e7bdf16ecc989cda032b076d Author: Tejun Heo <[email protected]> Date: Mon May 12 13:56:27 2014 -0400 kernfs, sysfs, cgroup: restrict extra perm check on open to sysfs The kernfs open method - kernfs_fop_open() - inherited extra permission checks from sysfs. While the vfs layer allows ignoring the read/write permissions checks if the issuer has CAP_DAC_OVERRIDE, sysfs explicitly denied open regardless of the cap if the file doesn't have any of the UGO perms of the requested access or doesn't implement the requested operation. It can be debated whether this was a good idea or not but the behavior is too subtle and dangerous to change at this point. After cgroup got converted to kernfs, this extra perm check also got applied to cgroup breaking libcgroup which opens write-only files with O_RDWR as root. This patch gates the extra open permission check with a new flag KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK and enables it for sysfs. For sysfs, nothing changes. For cgroup, root now can perform any operation regardless of the permissions as it was before kernfs conversion. Note that kernfs still fails unimplemented operations with -EINVAL. While at it, add comments explaining KERNFS_ROOT flags. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Andrey Wagin <[email protected]> Tested-by: Andrey Wagin <[email protected]> Cc: Li Zefan <[email protected]> References: http://lkml.kernel.org/g/CANaxB-xUm3rJ-Cbp72q-rQJO5mZe1qK6qXsQM=vh0U8upJ44+A@mail.gmail.com Fixes: 2bd59d48ebfb ("cgroup: convert to kernfs") Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7189eb9b8f7962474956196c301676470542f253 Author: Mengdong Lin <[email protected]> Date: Tue May 13 16:57:08 2014 +0800 ALSA: hda - mask buggy stream DMA0 for Broadwell display controller Broadwell display controller has 3 stream DMA engines. DMA0 cannot update DMA postion buffer properly while DMA1 and DMA2 can work well. So this patch masks the buggy DMA0 by keeping it as opened. This is a tentative workaround, so keep the change small as Takashi suggested. Signed-off-by: Mengdong Lin <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> commit ec5fe98886b686f065ef29d8dee1b3ca66f5fd48 Author: Aaron Plattner <[email protected]> Date: Mon May 12 20:05:02 2014 -0700 ALSA: hda - Add new GPU codec ID to snd-hda Vendor ID 0x10de0071 is used by a yet-to-be-named GPU chip. Signed-off-by: Aaron Plattner <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> commit 8e33f91a0b84ae1964bef77cb92f5d41d97530c8 Author: Ben Dooks <[email protected]> Date: Tue Apr 15 17:06:34 2014 +0100 clk: shmobile: clk-mstp: change to using clock-indices With the addition of clock-indices, we need to change the renesas clock implementation to use these instead of the local definition of "renesas,clock-indices". Since this will break booting with older device trees, we add a simple auto-detection of which properties are present. Signed-off-by: Ben Dooks <ben.dooks@codethin…
rogerq
pushed a commit
to rogerq/linux
that referenced
this pull request
Jun 12, 2014
[ Upstream commit 84d89c3 ] Add the mailbox device DT node for OMAP5 SoC. The OMAP5 mailbox IP is identical to that used in OMAP4. The OMAP5 hwmod data no longer publishes the module address space, so this patch fixes the WARN_ON backtrace associated with the following trace during the kernel boot: "omap_hwmod: mailbox: doesn't have mpu register target base". Otherwise we get a warning like this: WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() omap_hwmod: mailbox: doesn't have mpu register target base Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-00001-gb5e85a0 torvalds#45 [<c0015724>] (unwind_backtrace) from [<c00120f4>] (show_stack+0x10/0x14) [<c00120f4>] (show_stack) from [<c05a1ccc>] (dump_stack+0x78/0x94) [<c05a1ccc>] (dump_stack) from [<c0042a74>] (warn_slowpath_common+0x6c/0x8c) [<c0042a74>] (warn_slowpath_common) from [<c0042b28>] (warn_slowpath_fmt+0x30/0x40) [<c0042b28>] (warn_slowpath_fmt) from [<c0803b40>] (_init+0x1c0/0x3dc) [<c0803b40>] (_init) from [<c0029c8c>] (omap_hwmod_for_each+0x34/0x5c) [<c0029c8c>] (omap_hwmod_for_each) from [<c08042b0>] (__omap_hwmod_setup_all+0x24/0x40) [<c08042b0>] (__omap_hwmod_setup_all) from [<c00088b8>] (do_one_initcall+0x34/0x160) [<c00088b8>] (do_one_initcall) from [<c07f7bf4>] (kernel_init_freeable+0xfc/0x1c8) [<c07f7bf4>] (kernel_init_freeable) from [<c059c4f4>] (kernel_init+0x8/0xe4) [<c059c4f4>] (kernel_init) from [<c000eaa8>] (ret_from_fork+0x14/0x2c) Signed-off-by: Suman Anna <[email protected]> [[email protected]: updated description to for the warning] Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Dan Murphy <[email protected]>
pstglia
pushed a commit
to pstglia/linux
that referenced
this pull request
Oct 6, 2014
Add the mailbox device DT node for OMAP5 SoC. The OMAP5 mailbox IP is identical to that used in OMAP4. The OMAP5 hwmod data no longer publishes the module address space, so this patch fixes the WARN_ON backtrace associated with the following trace during the kernel boot: "omap_hwmod: mailbox: doesn't have mpu register target base". Otherwise we get a warning like this: WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() omap_hwmod: mailbox: doesn't have mpu register target base Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-00001-gb5e85a0 torvalds#45 [<c0015724>] (unwind_backtrace) from [<c00120f4>] (show_stack+0x10/0x14) [<c00120f4>] (show_stack) from [<c05a1ccc>] (dump_stack+0x78/0x94) [<c05a1ccc>] (dump_stack) from [<c0042a74>] (warn_slowpath_common+0x6c/0x8c) [<c0042a74>] (warn_slowpath_common) from [<c0042b28>] (warn_slowpath_fmt+0x30/0x40) [<c0042b28>] (warn_slowpath_fmt) from [<c0803b40>] (_init+0x1c0/0x3dc) [<c0803b40>] (_init) from [<c0029c8c>] (omap_hwmod_for_each+0x34/0x5c) [<c0029c8c>] (omap_hwmod_for_each) from [<c08042b0>] (__omap_hwmod_setup_all+0x24/0x40) [<c08042b0>] (__omap_hwmod_setup_all) from [<c00088b8>] (do_one_initcall+0x34/0x160) [<c00088b8>] (do_one_initcall) from [<c07f7bf4>] (kernel_init_freeable+0xfc/0x1c8) [<c07f7bf4>] (kernel_init_freeable) from [<c059c4f4>] (kernel_init+0x8/0xe4) [<c059c4f4>] (kernel_init) from [<c000eaa8>] (ret_from_fork+0x14/0x2c) Signed-off-by: Suman Anna <[email protected]> [[email protected]: updated description to for the warning] Signed-off-by: Tony Lindgren <[email protected]>
martinezjavier
pushed a commit
to martinezjavier/linux
that referenced
this pull request
Jul 30, 2015
ERROR: need consistent spacing around '+' (ctx:VxW) torvalds#35: FILE: fs/coda/upcall.c:356: + INSIZE(readlink), OUTSIZE(readlink)+ *length); ^ ERROR: space prohibited after that open parenthesis '(' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) ERROR: space prohibited before that close parenthesis ')' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) total: 3 errors, 0 warnings, 18 lines checked ./patches/fs-coda-fix-readlink-buffer-overflow.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jan Harkes <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Jul 31, 2015
ERROR: need consistent spacing around '+' (ctx:VxW) torvalds#35: FILE: fs/coda/upcall.c:356: + INSIZE(readlink), OUTSIZE(readlink)+ *length); ^ ERROR: space prohibited after that open parenthesis '(' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) ERROR: space prohibited before that close parenthesis ')' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) total: 3 errors, 0 warnings, 18 lines checked ./patches/fs-coda-fix-readlink-buffer-overflow.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jan Harkes <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Aug 6, 2015
ERROR: need consistent spacing around '+' (ctx:VxW) torvalds#35: FILE: fs/coda/upcall.c:356: + INSIZE(readlink), OUTSIZE(readlink)+ *length); ^ ERROR: space prohibited after that open parenthesis '(' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) ERROR: space prohibited before that close parenthesis ')' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) total: 3 errors, 0 warnings, 18 lines checked ./patches/fs-coda-fix-readlink-buffer-overflow.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jan Harkes <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
nhoriguchi
pushed a commit
to nhoriguchi/linux
that referenced
this pull request
Aug 14, 2015
ERROR: need consistent spacing around '+' (ctx:VxW) torvalds#35: FILE: fs/coda/upcall.c:356: + INSIZE(readlink), OUTSIZE(readlink)+ *length); ^ ERROR: space prohibited after that open parenthesis '(' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) ERROR: space prohibited before that close parenthesis ')' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) total: 3 errors, 0 warnings, 18 lines checked ./patches/fs-coda-fix-readlink-buffer-overflow.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jan Harkes <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
nhoriguchi
pushed a commit
to nhoriguchi/linux
that referenced
this pull request
Aug 14, 2015
Wanpeng Li reported a race between soft_offline_page() and unpoison_memory(), which causes the following kernel panic: [ 61.572584] BUG: Bad page state in process bash pfn:97000 [ 61.578106] page:ffffea00025c0000 count:0 mapcount:1 mapping: (null) index:0x7f4fdbe00 [ 61.586803] flags: 0x1fffff80080048(uptodate|active|swapbacked) [ 61.592809] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set [ 61.599250] bad because of flags: [ 61.602567] flags: 0x40(active) [ 61.605746] Modules linked in: snd_hda_codec_hdmi i915 rpcsec_gss_krb5 nfsv4 dns_resolver bnep rfcomm nfsd bluetooth auth_rpcgss nfs_acl nfs rfkill lockd grace sunrpc i2c_algo_bit drm_kms_helper snd_hda_codec_realtek snd_hda_codec_generic drm snd_hda_intel fscache snd_hda_codec x86_pkg_temp_thermal coretemp kvm_intel snd_hda_core snd_hwdep kvm snd_pcm snd_seq_dummy snd_seq_oss crct10dif_pclmul snd_seq_midi crc32_pclmul snd_seq_midi_event ghash_clmulni_intel snd_rawmidi aesni_intel lrw gf128mul snd_seq glue_helper ablk_helper snd_seq_device cryptd fuse snd_timer dcdbas serio_raw mei_me parport_pc snd mei ppdev i2c_core video lp soundcore parport lpc_ich shpchp mfd_core ext4 mbcache jbd2 sd_mod e1000e ahci ptp libahci crc32c_intel libata pps_core [ 61.605827] CPU: 3 PID: 2211 Comm: bash Not tainted 4.2.0-rc5-mm1+ torvalds#45 [ 61.605829] Hardware name: Dell Inc. OptiPlex 7020/0F5C5X, BIOS A03 01/08/2015 [ 61.605832] ffffffff818b3be8 ffff8800da373ad8 ffffffff8165ceb4 0000000001313ce1 [ 61.605837] ffffea00025c0000 ffff8800da373b08 ffffffff8117bdd6 ffff88021edd4b00 [ 61.605842] 0000000000000001 001fffff80080048 0000000000000000 ffff8800da373b88 [ 61.605847] Call Trace: [ 61.605858] [<ffffffff8165ceb4>] dump_stack+0x48/0x5c [ 61.605865] [<ffffffff8117bdd6>] bad_page+0xe6/0x140 [ 61.605870] [<ffffffff8117dfc9>] free_pages_prepare+0x2f9/0x320 [ 61.605876] [<ffffffff811e817d>] ? uncharge_list+0xdd/0x100 [ 61.605882] [<ffffffff8117ff20>] free_hot_cold_page+0x40/0x170 [ 61.605888] [<ffffffff81185dd0>] __put_single_page+0x20/0x30 [ 61.605892] [<ffffffff81186675>] put_page+0x25/0x40 [ 61.605897] [<ffffffff811dc276>] unmap_and_move+0x1a6/0x1f0 [ 61.605908] [<ffffffff811dc3c0>] migrate_pages+0x100/0x1d0 [ 61.605914] [<ffffffff811eb710>] ? kill_procs+0x100/0x100 [ 61.605918] [<ffffffff811764af>] ? unlock_page+0x6f/0x90 [ 61.605923] [<ffffffff811ecf37>] __soft_offline_page+0x127/0x2a0 [ 61.605928] [<ffffffff811ed156>] soft_offline_page+0xa6/0x200 This race is explained like below: CPU0 CPU1 soft_offline_page __soft_offline_page TestSetPageHWPoison unpoison_memory PageHWPoison check (true) TestClearPageHWPoison put_page -> release refcount held by get_hwpoison_page in unpoison_memory put_page -> release refcount held by isolate_lru_page in __soft_offline_page migrate_pages The second put_page() releases refcount held by isolate_lru_page() which will lead to unmap_and_move() releases the last refcount of page and w/ mapcount still 1 since try_to_unmap() is not called if there is only one user map the page. Anyway, the page refcount and mapcount will still mess if the page is mapped by multiple users. This race was introduced by commit 4491f71 ("mm/memory-failure: set PageHWPoison before migrate_pages()"), which focuses on preventing the reuse of successfully migrated page. Before this commit we prevent the reuse by changing the migratetype to MIGRATE_ISOLATE during soft offlining, which has the following problems, so simply reverting the commit is not a best option: 1) it doesn't eliminate the reuse completely, because set_migratetype_isolate() can fail to set MIGRATE_ISOLATE to the target page if the pageblock of the page contains one or more unmovable pages (i.e. has_unmovable_pages() returns true). 2) the original code changes migratetype to MIGRATE_ISOLATE forcibly, and sets it to MIGRATE_MOVABLE forcibly after soft offline, regardless of the original migratetype state, which could impact other subsystems like memory hotplug or compaction. , so fixing current code is preferable. This patch moves PageSetHWPoison just after put_page() in unmap_and_move(), which closes up the reported race window and minimizes the race window b/w SetPageHWPoison and reallocation (which causes the reuse of soft offlined page.) This minimized latter race window is acceptable, because it's rare and even if it happens that is effectively the same as "failure of page contaiment", which can happen as one of hwpoison's normal behaviors. And this patch also add some prechecks in unpoison_memory(), which ... it's justified ... Fixes: 4491f71 ("mm/memory-failure: set PageHWPoison before migrate_pages()") Reported-by: Wanpeng Li <[email protected]> Signed-off-by: Naoya Horiguchi <[email protected]>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Aug 16, 2015
ERROR: need consistent spacing around '+' (ctx:VxW) torvalds#35: FILE: fs/coda/upcall.c:356: + INSIZE(readlink), OUTSIZE(readlink)+ *length); ^ ERROR: space prohibited after that open parenthesis '(' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) ERROR: space prohibited before that close parenthesis ')' torvalds#45: FILE: fs/coda/upcall.c:364: + if ( retlen >= *length ) total: 3 errors, 0 warnings, 18 lines checked ./patches/fs-coda-fix-readlink-buffer-overflow.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jan Harkes <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Nov 26, 2023
commit 9fce92f upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#450 Fixes: 7c4e983 ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Nov 26, 2023
commit 9fce92f upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#450 Fixes: 7c4e983 ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Nov 27, 2023
commit 9fce92f upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#450 Fixes: 7c4e983 ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Nov 28, 2023
commit 9fce92f upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#450 Fixes: 7c4e983 ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
BoukeHaarsma23
pushed a commit
to ChimeraOS/linux
that referenced
this pull request
Nov 28, 2023
commit 9fce92f upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#450 Fixes: 7c4e983 ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Nov 28, 2023
commit 9fce92f upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#450 Fixes: 7c4e983 ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Nov 28, 2023
commit 9fce92f upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#450 Fixes: 7c4e983 ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Relms12345
added a commit
to Relms12345/linux
that referenced
this pull request
Nov 28, 2023
commit 6ac30d748bb080752d4078d482534b68d62f685f Author: Greg Kroah-Hartman <[email protected]> Date: Tue Nov 28 17:07:23 2023 +0000 Linux 6.1.64 Link: https://lore.kernel.org/r/[email protected] Tested-by: Salvatore Bonaccorso <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Ron Economos <[email protected]> Tested-by: SeongJae Park <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Florian Fainelli <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: SeongJae Park <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Nam Cao <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Guenter Roeck <[email protected]> Tested-by: Conor Dooley <[email protected]> Tested-by: Allen Pais <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 04ff8a5107a56ad6ba87c1e89c7c520e851e4ffa Author: Conor Dooley <[email protected]> Date: Thu Jun 29 12:33:34 2023 +0100 RISC-V: drop error print from riscv_hartid_to_cpuid() commit 52909f1768023656d5c429873e2246a134289a95 upstream. As of commit 2ac874343749 ("RISC-V: split early & late of_node to hartid mapping") my CI complains about newly added pr_err() messages during boot, for example: [ 0.000000] Couldn't find cpu id for hartid [0] [ 0.000000] riscv-intc: unable to find hart id for /cpus/cpu@0/interrupt-controller Before the split, riscv_of_processor_hartid() contained a check for whether the cpu was "available", before calling riscv_hartid_to_cpuid(), but after the split riscv_of_processor_hartid() can be called for cpus that are disabled. Most callers of riscv_hartid_to_cpuid() already report custom errors where it falls, making this print superfluous in those case. In other places, the print adds nothing - see riscv_intc_init() for example. Fixes: 2ac874343749 ("RISC-V: split early & late of_node to hartid mapping") Signed-off-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/20230629-paternity-grafted-b901b76d04a0@wendy Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9e1e0887ea21e9fef0f1a2a3ad715f9a3aa9535d Author: Robert Richter <[email protected]> Date: Fri May 19 23:54:35 2023 +0200 cxl/port: Fix NULL pointer access in devm_cxl_add_port() commit a70fc4ed20a6118837b0aecbbf789074935f473b upstream. In devm_cxl_add_port() the port creation may fail and its associated pointer does not contain a valid address. During error message generation this invalid port address is used. Fix that wrong address access. Fixes: f3cd264c4ec1 ("cxl: Unify debug messages when calling devm_cxl_add_port()") Signed-off-by: Robert Richter <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c88cfbb18a5e498f405836b11f1dd31c54d7a7de Author: Victor Shih <[email protected]> Date: Tue Nov 7 17:57:41 2023 +0800 mmc: sdhci-pci-gli: GL9755: Mask the replay timer timeout of AER commit 85dd3af64965c1c0eb7373b340a1b1f7773586b0 upstream. Due to a flaw in the hardware design, the GL9755 replay timer frequently times out when ASPM is enabled. As a result, the warning messages will often appear in the system log when the system accesses the GL9755 PCI config. Therefore, the replay timer timeout must be masked. Fixes: 36ed2fd32b2c ("mmc: sdhci-pci-gli: A workaround to allow GL9755 to enter ASPM L1.2") Signed-off-by: Victor Shih <[email protected]> Acked-by: Adrian Hunter <[email protected]> Acked-by: Kai-Heng Feng <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Victor Shih <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2132941b453fc933dde89b8f96f0a4439ded5c74 Author: Vicki Pfau <[email protected]> Date: Thu Mar 23 18:32:43 2023 -0700 Input: xpad - add VID for Turtle Beach controllers commit 1999a6b12a3b5c8953fc9ec74863ebc75a1b851d upstream. This adds support for the Turtle Beach REACT-R and Recon Xbox controllers Signed-off-by: Vicki Pfau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2fa74d29fc1899c237d51bf9a6e132ea5c488976 Author: Steven Rostedt (Google) <[email protected]> Date: Tue Oct 31 12:24:53 2023 -0400 tracing: Have trace_event_file have ref counters commit bb32500fb9b78215e4ef6ee8b4345c5f5d7eafb4 upstream. The following can crash the kernel: # cd /sys/kernel/tracing # echo 'p:sched schedule' > kprobe_events # exec 5>>events/kprobes/sched/enable # > kprobe_events # exec 5>&- The above commands: 1. Change directory to the tracefs directory 2. Create a kprobe event (doesn't matter what one) 3. Open bash file descriptor 5 on the enable file of the kprobe event 4. Delete the kprobe event (removes the files too) 5. Close the bash file descriptor 5 The above causes a crash! BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:tracing_release_file_tr+0xc/0x50 What happens here is that the kprobe event creates a trace_event_file "file" descriptor that represents the file in tracefs to the event. It maintains state of the event (is it enabled for the given instance?). Opening the "enable" file gets a reference to the event "file" descriptor via the open file descriptor. When the kprobe event is deleted, the file is also deleted from the tracefs system which also frees the event "file" descriptor. But as the tracefs file is still opened by user space, it will not be totally removed until the final dput() is called on it. But this is not true with the event "file" descriptor that is already freed. If the user does a write to or simply closes the file descriptor it will reference the event "file" descriptor that was just freed, causing a use-after-free bug. To solve this, add a ref count to the event "file" descriptor as well as a new flag called "FREED". The "file" will not be freed until the last reference is released. But the FREE flag will be set when the event is removed to prevent any more modifications to that event from happening, even if there's still a reference to the event "file" descriptor. Link: https://lore.kernel.org/linux-trace-kernel/[email protected]/ Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: [email protected] Cc: Mark Rutland <[email protected]> Fixes: f5ca233e2e66d ("tracing: Increase trace array ref count on enable and filter files") Reported-by: Beau Belgrave <[email protected]> Tested-by: Beau Belgrave <[email protected]> Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6460508dce00f5438d95e3ee7096c925e30e72e2 Author: Michael Ellerman <[email protected]> Date: Tue Aug 22 00:28:19 2023 +1000 powerpc/powernv: Fix fortify source warnings in opal-prd.c commit feea65a338e52297b68ceb688eaf0ffc50310a83 upstream. As reported by Mahesh & Aneesh, opal_prd_msg_notifier() triggers a FORTIFY_SOURCE warning: memcpy: detected field-spanning write (size 32) of single field "&item->msg" at arch/powerpc/platforms/powernv/opal-prd.c:355 (size 4) WARNING: CPU: 9 PID: 660 at arch/powerpc/platforms/powernv/opal-prd.c:355 opal_prd_msg_notifier+0x174/0x188 [opal_prd] NIP opal_prd_msg_notifier+0x174/0x188 [opal_prd] LR opal_prd_msg_notifier+0x170/0x188 [opal_prd] Call Trace: opal_prd_msg_notifier+0x170/0x188 [opal_prd] (unreliable) notifier_call_chain+0xc0/0x1b0 atomic_notifier_call_chain+0x2c/0x40 opal_message_notify+0xf4/0x2c0 This happens because the copy is targeting item->msg, which is only 4 bytes in size, even though the enclosing item was allocated with extra space following the msg. To fix the warning define struct opal_prd_msg with a union of the header and a flex array, and have the memcpy target the flex array. Reported-by: "Aneesh Kumar K.V" <[email protected]> Reported-by: Mahesh Salgaonkar <[email protected]> Tested-by: Mahesh Salgaonkar <[email protected]> Reviewed-by: Mahesh Salgaonkar <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4c55be0855344187d0970874b6e1215b21a68b61 Author: Lewis Huang <[email protected]> Date: Thu Oct 19 17:22:21 2023 +0800 drm/amd/display: Change the DMCUB mailbox memory location from FB to inbox commit 5911d02cac70d7fb52009fbd37423e63f8f6f9bc upstream. [WHY] Flush command sent to DMCUB spends more time for execution on a dGPU than on an APU. This causes cursor lag when using high refresh rate mouses. [HOW] 1. Change the DMCUB mailbox memory location from FB to inbox. 2. Only change windows memory to inbox. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Alex Hung <[email protected]> Signed-off-by: Lewis Huang <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 68d774eb10e261ac6d176da2379f97a62878ef22 Author: Tianci Yin <[email protected]> Date: Wed Nov 1 09:47:13 2023 +0800 drm/amd/display: Enable fast plane updates on DCN3.2 and above commit 435f5b369657cffee4b04db1f5805b48599f4dbe upstream. [WHY] When cursor moves across screen boarder, lag cursor observed, since subvp settings need to sync up with vblank that causes cursor updates being delayed. [HOW] Enable fast plane updates on DCN3.2 to fix it. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Reviewed-by: Aurabindo Pillai <[email protected]> Acked-by: Alex Hung <[email protected]> Signed-off-by: Tianci Yin <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit fb5c134ca589fe670430acc9e7ebf2691ca2476d Author: Mario Limonciello <[email protected]> Date: Wed Nov 8 13:31:57 2023 -0600 drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer() commit b71f4ade1b8900d30c661d6c27f87c35214c398c upstream. When ddc_service_construct() is called, it explicitly checks both the link type and whether there is something on the link which will dictate whether the pin is marked as hw_supported. If the pin isn't set or the link is not set (such as from unloading/reloading amdgpu in an IGT test) then fail the amdgpu_dm_i2c_xfer() call. Cc: [email protected] Fixes: 22676bc500c2 ("drm/amd/display: Fix dmub soft hang for PSR 1") Link: https://github.com/fwupd/fwupd/issues/6327 Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 51ffa1a3792e3570ae2eb84d003c329b3d71da6c Author: Christian König <[email protected]> Date: Thu Nov 9 10:14:14 2023 +0100 drm/amdgpu: lower CS errors to debug severity commit 17daf01ab4e3e5a5929747aa05cc15eb2bad5438 upstream. Otherwise userspace can spam the logs by using incorrect input values. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c52aac5884bc58e304d4c9cb8441baf8443ea189 Author: Christian König <[email protected]> Date: Thu Nov 9 10:12:39 2023 +0100 drm/amdgpu: fix error handling in amdgpu_bo_list_get() commit 12f76050d8d4d10dab96333656b821bd4620d103 upstream. We should not leak the pointer where we couldn't grab the reference on to the caller because it can be that the error handling still tries to put the reference then. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2ab6c1237bd4a961b8d5032671510a028fb9f0f6 Author: Alex Deucher <[email protected]> Date: Tue Oct 17 15:40:01 2023 -0400 drm/amdgpu: don't use ATRM for external devices commit 432e664e7c98c243fab4c3c95bd463bea3aeed28 upstream. The ATRM ACPI method is for fetching the dGPU vbios rom image on laptops and all-in-one systems. It should not be used for external add in cards. If the dGPU is thunderbolt connected, don't try ATRM. v2: pci_is_thunderbolt_attached only works for Intel. Use pdev->external_facing instead. v3: dev_is_removable() seems to be what we want Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925 Reviewed-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 965dce07a4fc5b15c07c73124f5016240a7250ef Author: Alex Deucher <[email protected]> Date: Tue Oct 17 16:30:00 2023 -0400 drm/amdgpu: don't use pci_is_thunderbolt_attached() commit 7b1c6263eaf4fd64ffe1cafdc504a42ee4bfbb33 upstream. It's only valid on Intel systems with the Intel VSEC. Use dev_is_removable() instead. This should do the right thing regardless of the platform. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925 Reviewed-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8e54a91d3e66b9730861f10345238ff5ef979d3d Author: Alex Deucher <[email protected]> Date: Wed Nov 1 15:48:14 2023 -0400 drm/amdgpu/smu13: drop compute workload workaround commit 23170863ea0a0965d224342c0eb2ad8303b1f267 upstream. This was fixed in PMFW before launch and is no longer required. Reviewed-by: Yang Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 454d0cdd7c127bb0ad06b53c52e94ca2c9a83b20 Author: Ma Jun <[email protected]> Date: Tue Oct 31 11:11:04 2023 +0800 drm/amd/pm: Fix error of MACO flag setting code commit 7f3e6b840fa8b0889d776639310a5dc672c1e9e1 upstream. MACO only works if BACO is supported Signed-off-by: Ma Jun <[email protected]> Reviewed-by: Kenneth Feng <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 07e94f204f38b0d36eb377b3cda088b4a8b6f9a2 Author: Kunwu Chan <[email protected]> Date: Fri Nov 3 11:09:22 2023 +0000 drm/i915: Fix potential spectre vulnerability commit 1a8e9bad6ef563c28ab0f8619628d5511be55431 upstream. Fix smatch warning: drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu() warn: potential spectre issue 'pc->user_engines' [r] (local cap) Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Cc: <[email protected]> # v5.15+ Signed-off-by: Kunwu Chan <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 27b086382c22efb7e0a16442f7bdc2e120108ef3) Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9457636a49265bdec14f3b747a4911ea9b7d468c Author: Ville Syrjälä <[email protected]> Date: Tue Oct 31 18:08:00 2023 +0200 drm/i915: Bump GLK CDCLK frequency when driving multiple pipes commit 0cb89cd42fd22bbdec0b046c48f35775f5b88bdb upstream. On GLK CDCLK frequency needs to be at least 2*96 MHz when accessing the audio hardware. Currently we bump the CDCLK frequency up temporarily (if not high enough already) whenever audio hardware is being accessed, and drop it back down afterwards. With a single active pipe this works just fine as we can switch between all the valid CDCLK frequencies by changing the cd2x divider, which doesn't require a full modeset. However with multiple active pipes the cd2x divider trick no longer works, and thus we end up blinking all displays off and back on. To avoid this let's just bump the CDCLK frequency to >=2*96MHz whenever multiple pipes are active. The downside is slightly higher power consumption, but that seems like an acceptable tradeoff. With a single active pipe we can stick to the current more optiomal (from power comsumption POV) behaviour. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9599 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> (cherry picked from commit 451eaa1a614c911f5a51078dcb68022874e4cb12) Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e973f40de16125f3f85a07db68a2ad4a0aeb42c2 Author: Bas Nieuwenhuizen <[email protected]> Date: Tue Oct 17 16:01:35 2023 +0200 drm/amd/pm: Handle non-terminated overdrive commands. commit 08e9ebc75b5bcfec9d226f9e16bab2ab7b25a39a upstream. The incoming strings might not be terminated by a newline or a 0. (found while testing a program that just wrote the string itself, causing a crash) Cc: [email protected] Fixes: e3933f26b657 ("drm/amd/pp: Add edit/commit/show OD clock/voltage support in sysfs") Signed-off-by: Bas Nieuwenhuizen <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit dc4542861ec8dde92c3c8a5139bc412860aebe60 Author: Jan Kara <[email protected]> Date: Fri Oct 13 14:13:50 2023 +0200 ext4: properly sync file size update after O_SYNC direct IO commit 91562895f8030cb9a0470b1db49de79346a69f91 upstream. Gao Xiang has reported that on ext4 O_SYNC direct IO does not properly sync file size update and thus if we crash at unfortunate moment, the file can have smaller size although O_SYNC IO has reported successful completion. The problem happens because update of on-disk inode size is handled in ext4_dio_write_iter() *after* iomap_dio_rw() (and thus dio_complete() in particular) has returned and generic_file_sync() gets called by dio_complete(). Fix the problem by handling on-disk inode size update directly in our ->end_io completion handler. References: https://lore.kernel.org/all/[email protected] Reported-by: Gao Xiang <[email protected]> CC: [email protected] Fixes: 378f32bab371 ("ext4: introduce direct I/O write using iomap infrastructure") Signed-off-by: Jan Kara <[email protected]> Tested-by: Joseph Qi <[email protected]> Reviewed-by: "Ritesh Harjani (IBM)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e1d0f68bc07fee57d1855355dbb94092b895a9f4 Author: Kemeng Shi <[email protected]> Date: Sun Aug 27 01:47:01 2023 +0800 ext4: add missed brelse in update_backups commit 9adac8b01f4be28acd5838aade42b8daa4f0b642 upstream. add missed brelse in update_backups Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Theodore Ts'o <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1793dc461e5a081087ab4d34b39b838bdce3f7e9 Author: Kemeng Shi <[email protected]> Date: Sun Aug 27 01:47:03 2023 +0800 ext4: remove gdb backup copy for meta bg in setup_new_flex_group_blocks commit 40dd7953f4d606c280074f10d23046b6812708ce upstream. Wrong check of gdb backup in meta bg as following: first_group is the first group of meta_bg which contains target group, so target group is always >= first_group. We check if target group has gdb backup by comparing first_group with [group + 1] and [group + EXT4_DESC_PER_BLOCK(sb) - 1]. As group >= first_group, then [group + N] is > first_group. So no copy of gdb backup in meta bg is done in setup_new_flex_group_blocks. No need to do gdb backup copy in meta bg from setup_new_flex_group_blocks as we always copy updated gdb block to backups at end of ext4_flex_group_add as following: ext4_flex_group_add /* no gdb backup copy for meta bg any more */ setup_new_flex_group_blocks /* update current group number */ ext4_update_super sbi->s_groups_count += flex_gd->count; /* * if group in meta bg contains backup is added, the primary gdb block * of the meta bg will be copy to backup in new added group here. */ for (; gdb_num <= gdb_num_end; gdb_num++) update_backups(...) In summary, we can remove wrong gdb backup copy code in setup_new_flex_group_blocks. Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Theodore Ts'o <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 80ddcf21e7e022b392d9ae8363c0353251a95034 Author: Zhang Yi <[email protected]> Date: Thu Aug 24 17:26:04 2023 +0800 ext4: correct the start block of counting reserved clusters commit 40ea98396a3659062267d1fe5f99af4f7e4f05e3 upstream. When big allocate feature is enabled, we need to count and update reserved clusters before removing a delayed only extent_status entry. {init|count|get}_rsvd() have already done this, but the start block number of this counting isn't correct in the following case. lblk end | | v v ------------------------- | | orig_es ------------------------- ^ ^ len1 is 0 | len2 | If the start block of the orig_es entry founded is bigger than lblk, we passed lblk as start block to count_rsvd(), but the length is correct, finally, the range to be counted is offset. This patch fix this by passing the start blocks to 'orig_es->lblk + len1'. Signed-off-by: Zhang Yi <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ec4ba3d62f0fdde57cfaaeb7f1df85609b9a86ef Author: Kemeng Shi <[email protected]> Date: Sun Aug 27 01:47:02 2023 +0800 ext4: correct return value of ext4_convert_meta_bg commit 48f1551592c54f7d8e2befc72a99ff4e47f7dca0 upstream. Avoid to ignore error in "err". Signed-off-by: Kemeng Shi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 32b9fb9a67ec70bbe3afe931b0ea44203150a49a Author: Ojaswin Mujoo <[email protected]> Date: Mon Sep 18 16:15:50 2023 +0530 ext4: mark buffer new if it is unwritten to avoid stale data exposure commit 2cd8bdb5efc1e0d5b11a4b7ba6b922fd2736a87f upstream. ** Short Version ** In ext4 with dioread_nolock, we could have a scenario where the bh returned by get_blocks (ext4_get_block_unwritten()) in __block_write_begin_int() has UNWRITTEN and MAPPED flag set. Since such a bh does not have NEW flag set we never zero out the range of bh that is not under write, causing whatever stale data is present in the folio at that time to be written out to disk. To fix this mark the buffer as new, in case it is unwritten, in ext4_get_block_unwritten(). ** Long Version ** The issue mentioned above was resulting in two different bugs: 1. On block size < page size case in ext4, generic/269 was reliably failing with dioread_nolock. The state of the write was as follows: * The write was extending i_size. * The last block of the file was fallocated and had an unwritten extent * We were near ENOSPC and hence we were switching to non-delayed alloc allocation. In this case, the back trace that triggers the bug is as follows: ext4_da_write_begin() /* switch to nodelalloc due to low space */ ext4_write_begin() ext4_should_dioread_nolock() // true since mount flags still have delalloc __block_write_begin(..., ext4_get_block_unwritten) __block_write_begin_int() for(each buffer head in page) { /* first iteration, this is bh1 which contains i_size */ if (!buffer_mapped) get_block() /* returns bh with only UNWRITTEN and MAPPED */ /* second iteration, bh2 */ if (!buffer_mapped) get_block() /* we fail here, could be ENOSPC */ } if (err) /* * this would zero out all new buffers and mark them uptodate. * Since bh1 was never marked new, we skip it here which causes * the bug later. */ folio_zero_new_buffers(); /* ext4_wrte_begin() error handling */ ext4_truncate_failed_write() ext4_truncate() ext4_block_truncate_page() __ext4_block_zero_page_range() if(!buffer_uptodate()) ext4_read_bh_lock() ext4_read_bh() -> ... ext4_submit_bh_wbc() BUG_ON(buffer_unwritten(bh)); /* !!! */ 2. The second issue is stale data exposure with page size >= blocksize with dioread_nolock. The conditions needed for it to happen are same as the previous issue ie dioread_nolock around ENOSPC condition. The issue is also similar where in __block_write_begin_int() when we call ext4_get_block_unwritten() on the buffer_head and the underlying extent is unwritten, we get an unwritten and mapped buffer head. Since it is not new, we never zero out the partial range which is not under write, thus writing stale data to disk. This can be easily observed with the following reproducer: fallocate -l 4k testfile xfs_io -c "pwrite 2k 2k" testfile # hexdump output will have stale data in from byte 0 to 2k in testfile hexdump -C testfile NOTE: To trigger this, we need dioread_nolock enabled and write happening via ext4_write_begin(), which is usually used when we have -o nodealloc. Since dioread_nolock is disabled with nodelalloc, the only alternate way to call ext4_write_begin() is to ensure that delayed alloc switches to nodelalloc ie ext4_da_write_begin() calls ext4_write_begin(). This will usually happen when ext4 is almost full like the way generic/269 was triggering it in Issue 1 above. This might make the issue harder to hit. Hence, for reliable replication, I used the below patch to temporarily allow dioread_nolock with nodelalloc and then mount the disk with -o nodealloc,dioread_nolock. With this you can hit the stale data issue 100% of times: @@ -508,8 +508,8 @@ static inline int ext4_should_dioread_nolock(struct inode *inode) if (ext4_should_journal_data(inode)) return 0; /* temporary fix to prevent generic/422 test failures */ - if (!test_opt(inode->i_sb, DELALLOC)) - return 0; + // if (!test_opt(inode->i_sb, DELALLOC)) + // return 0; return 1; } After applying this patch to mark buffer as NEW, both the above issues are fixed. Signed-off-by: Ojaswin Mujoo <[email protected]> Cc: [email protected] Reviewed-by: Jan Kara <[email protected]> Reviewed-by: "Ritesh Harjani (IBM)" <[email protected]> Link: https://lore.kernel.org/r/d0ed09d70a9733fbb5349c5c7b125caac186ecdf.1695033645.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f0cc1368fafd2542f09d18a75aa32288bc49d11b Author: Kemeng Shi <[email protected]> Date: Sun Aug 27 01:47:00 2023 +0800 ext4: correct offset of gdb backup in non meta_bg group to update_backups commit 31f13421c004a420c0e9d288859c9ea9259ea0cc upstream. Commit 0aeaa2559d6d5 ("ext4: fix corruption when online resizing a 1K bigalloc fs") found that primary superblock's offset in its group is not equal to offset of backup superblock in its group when block size is 1K and bigalloc is enabled. As group descriptor blocks are right after superblock, we can't pass block number of gdb to update_backups for the same reason. The root casue of the issue above is that leading 1K padding block is count as data block offset for primary block while backup block has no padding block offset in its group. Remove padding data block count to fix the issue for gdb backups. For meta_bg case, update_backups treat blk_off as block number, do no conversion in this case. Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Theodore Ts'o <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit af075d06b34f79476bcd4e2b07c8632d206dad78 Author: Max Kellermann <[email protected]> Date: Tue Sep 19 10:18:23 2023 +0200 ext4: apply umask if ACL support is disabled commit 484fd6c1de13b336806a967908a927cc0356e312 upstream. The function ext4_init_acl() calls posix_acl_create() which is responsible for applying the umask. But without CONFIG_EXT4_FS_POSIX_ACL, ext4_init_acl() is an empty inline function, and nobody applies the umask. This fixes a bug which causes the umask to be ignored with O_TMPFILE on ext4: https://github.com/MusicPlayerDaemon/MPD/issues/558 https://bugs.gentoo.org/show_bug.cgi?id=686142#c3 https://bugzilla.kernel.org/show_bug.cgi?id=203625 Reviewed-by: "J. Bruce Fields" <[email protected]> Cc: [email protected] Signed-off-by: Max Kellermann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e795a56654fd6078cc6c8f88d6debebf511c21ae Author: Heiner Kallweit <[email protected]> Date: Tue Nov 21 09:09:33 2023 +0100 Revert "net: r8169: Disable multicast filter for RTL8168H and RTL8107E" commit 6a26310273c323380da21eb23fcfd50e31140913 upstream. This reverts commit efa5f1311c4998e9e6317c52bc5ee93b3a0f36df. I couldn't reproduce the reported issue. What I did, based on a pcap packet log provided by the reporter: - Used same chip version (RTL8168h) - Set MAC address to the one used on the reporters system - Replayed the EAPOL unicast packet that, according to the reporter, was filtered out by the mc filter. The packet was properly received. Therefore the root cause of the reported issue seems to be somewhere else. Disabling mc filtering completely for the most common chip version is a quite big hammer. Therefore revert the change and wait for further analysis results from the reporter. Cc: [email protected] Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit eb2f435be2c46eea47f60baca419b69f01abf6ad Author: Andrey Konovalov <[email protected]> Date: Wed Aug 30 16:16:15 2023 +0100 media: qcom: camss: Fix csid-gen2 for test pattern generator commit 87889f1b7ea40d2544b49c62092e6ef2792dced7 upstream. In the current driver csid Test Pattern Generator (TPG) doesn't work. This change: - fixes writing frame width and height values into CSID_TPG_DT_n_CFG_0 - fixes the shift by one between test_pattern control value and the actual pattern. - drops fixed VC of 0x0a which testing showed prohibited some test patterns in the CSID to produce output. So that TPG starts working, but with the below limitations: - only test_pattern=9 works as it should - test_pattern=8 and test_pattern=7 produce black frame (all zeroes) - the rest of test_pattern's don't work (yavta doesn't get the data) - regardless of the CFA pattern set by 'media-ctl -V' the actual pixel order is always the same (RGGB for any RAW8 or RAW10P format in 4608x2592 resolution). Tested with: RAW10P format, VC0: media-ctl -V '"msm_csid0":0[fmt:SRGGB10/4608x2592 field:none]' media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4608x2592 field:none]' media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]' v4l2-ctl -d /dev/v4l-subdev6 -c test_pattern=9 yavta -B capture-mplane --capture=3 -n 3 -f SRGGB10P -s 4608x2592 /dev/video0 RAW10P format, VC1: media-ctl -V '"msm_csid0":2[fmt:SRGGB10/4608x2592 field:none]' media-ctl -V '"msm_vfe0_rdi1":0[fmt:SRGGB10/4608x2592 field:none]' media-ctl -l '"msm_csid0":2->"msm_vfe0_rdi1":0[1]' v4l2-ctl -d /dev/v4l-subdev6 -c test_pattern=9 yavta -B capture-mplane --capture=3 -n 3 -f SRGGB10P -s 4608x2592 /dev/video1 RAW8 format, VC0: media-ctl --reset media-ctl -V '"msm_csid0":0[fmt:SRGGB8/4608x2592 field:none]' media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB8/4608x2592 field:none]' media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]' yavta -B capture-mplane --capture=3 -n 3 -f SRGGB8 -s 4608x2592 /dev/video0 Fixes: eebe6d00e9bf ("media: camss: Add support for CSID hardware version Titan 170") Cc: [email protected] Signed-off-by: Andrey Konovalov <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit eeab07ddd020e6990ba55b47721348beab5dcaaf Author: Bryan O'Donoghue <[email protected]> Date: Wed Aug 30 16:16:13 2023 +0100 media: qcom: camss: Fix invalid clock enable bit disjunction commit d8f7e1a60d01739a1d78db2b08603089c6cf7c8e upstream. define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7) disjunction for gen2 ? BIT(7) : is a nop we are setting the same bit either way. Fixes: 4abb21309fda ("media: camss: csiphy: Move to hardcode CSI Clock Lane number") Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 18a06f2eeb841185336da7fd3fd5dfd239f23014 Author: Bryan O'Donoghue <[email protected]> Date: Wed Aug 30 16:16:12 2023 +0100 media: qcom: camss: Fix missing vfe_lite clocks check commit b6e1bdca463a932c1ac02caa7d3e14bf39288e0c upstream. check_clock doesn't account for vfe_lite which means that vfe_lite will never get validated by this routine. Add the clock name to the expected set to remediate. Fixes: 7319cdf189bb ("media: camss: Add support for VFE hardware version Titan 170") Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ddc424aedbd379f277870db20883d38d34639e5a Author: Bryan O'Donoghue <[email protected]> Date: Wed Aug 30 16:16:11 2023 +0100 media: qcom: camss: Fix VFE-480 vfe_disable_output() commit 7f24d291350426d40b36dfbe6b3090617cdfd37a upstream. vfe-480 is copied from vfe-17x and has the same racy idle timeout bug as in 17x. Fix the vfe_disable_output() logic to no longer be racy and to conform to the 17x way of quiescing and then resetting the VFE. Fixes: 4edc8eae715c ("media: camss: Add initial support for VFE hardware version Titan 480") Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0f3e5f93fe77bc16e632686b7571d296f91a76be Author: Bryan O'Donoghue <[email protected]> Date: Wed Aug 30 16:16:10 2023 +0100 media: qcom: camss: Fix VFE-17x vfe_disable_output() commit 3143ad282fc08bf995ee73e32a9e40c527bf265d upstream. There are two problems with the current vfe_disable_output() routine. Firstly we rightly use a spinlock to protect output->gen2.active_num everywhere except for in the IDLE timeout path of vfe_disable_output(). Even if that is not racy "in practice" somehow it is by happenstance not by design. Secondly we do not get consistent behaviour from this routine. On sc8280xp 50% of the time I get "VFE idle timeout - resetting". In this case the subsequent capture will succeed. The other 50% of the time, we don't hit the idle timeout, never do the VFE reset and subsequent captures stall indefinitely. Rewrite the vfe_disable_output() routine to - Quiesce write masters with vfe_wm_stop() - Set active_num = 0 remembering to hold the spinlock when we do so followed by - Reset the VFE Testing on sc8280xp and sdm845 shows this to be a valid fix. Fixes: 7319cdf189bb ("media: camss: Add support for VFE hardware version Titan 170") Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 04ef31a3e38ad207aee87d8a89290152b9000074 Author: Bryan O'Donoghue <[email protected]> Date: Wed Aug 30 16:16:09 2023 +0100 media: qcom: camss: Fix vfe_get() error jump commit 26bda3da00c3edef727a6acb00ed2eb4b22f8723 upstream. Right now it is possible to do a vfe_get() with the internal reference count at 1. If vfe_check_clock_rates() returns non-zero then we will leave the reference count as-is and run: - pm_runtime_put_sync() - vfe->ops->pm_domain_off() skip: - camss_disable_clocks() Subsequent vfe_put() calls will when the ref-count is non-zero unconditionally run: - pm_runtime_put_sync() - vfe->ops->pm_domain_off() - camss_disable_clocks() vfe_get() should not attempt to roll-back on error when the ref-count is non-zero as the upper layers will still do their own vfe_put() operations. vfe_put() will drop the reference count and do the necessary power domain release, the cleanup jumps in vfe_get() should only be run when the ref-count is zero. [ 50.095796] CPU: 7 PID: 3075 Comm: cam Not tainted 6.3.2+ #80 [ 50.095798] Hardware name: LENOVO 21BXCTO1WW/21BXCTO1WW, BIOS N3HET82W (1.54 ) 05/26/2023 [ 50.095799] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 50.095802] pc : refcount_warn_saturate+0xf4/0x148 [ 50.095804] lr : refcount_warn_saturate+0xf4/0x148 [ 50.095805] sp : ffff80000c7cb8b0 [ 50.095806] x29: ffff80000c7cb8b0 x28: ffff16ecc0e3fc10 x27: 0000000000000000 [ 50.095810] x26: 0000000000000000 x25: 0000000000020802 x24: 0000000000000000 [ 50.095813] x23: ffff16ecc7360640 x22: 00000000ffffffff x21: 0000000000000005 [ 50.095815] x20: ffff16ed175f4400 x19: ffffb4d9852942a8 x18: ffffffffffffffff [ 50.095818] x17: ffffb4d9852d4a48 x16: ffffb4d983da5db8 x15: ffff80000c7cb320 [ 50.095821] x14: 0000000000000001 x13: 2e656572662d7265 x12: 7466612d65737520 [ 50.095823] x11: 00000000ffffefff x10: ffffb4d9850cebf0 x9 : ffffb4d9835cf954 [ 50.095826] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000057fa8 [ 50.095829] x5 : ffff16f813fe3d08 x4 : 0000000000000000 x3 : ffff621e8f4d2000 [ 50.095832] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff16ed32119040 [ 50.095835] Call trace: [ 50.095836] refcount_warn_saturate+0xf4/0x148 [ 50.095838] device_link_put_kref+0x84/0xc8 [ 50.095843] device_link_del+0x38/0x58 [ 50.095846] vfe_pm_domain_off+0x3c/0x50 [qcom_camss] [ 50.095860] vfe_put+0x114/0x140 [qcom_camss] [ 50.095869] csid_set_power+0x2c8/0x408 [qcom_camss] [ 50.095878] pipeline_pm_power_one+0x164/0x170 [videodev] [ 50.095896] pipeline_pm_power+0xc4/0x110 [videodev] [ 50.095909] v4l2_pipeline_pm_use+0x5c/0xa0 [videodev] [ 50.095923] v4l2_pipeline_pm_get+0x1c/0x30 [videodev] [ 50.095937] video_open+0x7c/0x100 [qcom_camss] [ 50.095945] v4l2_open+0x84/0x130 [videodev] [ 50.095960] chrdev_open+0xc8/0x250 [ 50.095964] do_dentry_open+0x1bc/0x498 [ 50.095966] vfs_open+0x34/0x40 [ 50.095968] path_openat+0xb44/0xf20 [ 50.095971] do_filp_open+0xa4/0x160 [ 50.095974] do_sys_openat2+0xc8/0x188 [ 50.095975] __arm64_sys_openat+0x6c/0xb8 [ 50.095977] invoke_syscall+0x50/0x128 [ 50.095982] el0_svc_common.constprop.0+0x4c/0x100 [ 50.095985] do_el0_svc+0x40/0xa8 [ 50.095988] el0_svc+0x2c/0x88 [ 50.095991] el0t_64_sync_handler+0xf4/0x120 [ 50.095994] el0t_64_sync+0x190/0x198 [ 50.095996] ---[ end trace 0000000000000000 ]--- Fixes: 779096916dae ("media: camss: vfe: Fix runtime PM imbalance on error") Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3166c3af55fe197f332d7cd83982e8b06dba5bd4 Author: Bryan O'Donoghue <[email protected]> Date: Wed Aug 30 16:16:06 2023 +0100 media: qcom: camss: Fix pm_domain_on sequence in probe commit 7405116519ad70b8c7340359bfac8db8279e7ce4 upstream. We need to make sure camss_configure_pd() happens before camss_register_entities() as the vfe_get() path relies on the pointer provided by camss_configure_pd(). Fix the ordering sequence in probe to ensure the pointers vfe_get() demands are present by the time camss_register_entities() runs. In order to facilitate backporting to stable kernels I've moved the configure_pd() call pretty early on the probe() function so that irrespective of the existence of the old error handling jump labels this patch should still apply to -next circa Aug 2023 to v5.13 inclusive. Fixes: 2f6f8af67203 ("media: camss: Refactor VFE power domain toggling") Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6dcb2605c284fbd54963547ab4df1c91e591a959 Author: Victor Shih <[email protected]> Date: Tue Nov 7 17:57:40 2023 +0800 mmc: sdhci-pci-gli: GL9750: Mask the replay timer timeout of AER commit 015c9cbcf0ad709079117d27c2094a46e0eadcdb upstream. Due to a flaw in the hardware design, the GL9750 replay timer frequently times out when ASPM is enabled. As a result, the warning messages will often appear in the system log when the system accesses the GL9750 PCI config. Therefore, the replay timer timeout must be masked. Fixes: d7133797e9e1 ("mmc: sdhci-pci-gli: A workaround to allow GL9750 to enter ASPM L1.2") Signed-off-by: Victor Shih <[email protected]> Acked-by: Adrian Hunter <[email protected]> Acked-by: Kai-Heng Feng <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f7164cb0371f194bb1ce6309897b58f6ad7e32b5 Author: ChunHao Lin <[email protected]> Date: Fri Nov 10 01:33:59 2023 +0800 r8169: add handling DASH when DASH is disabled commit 0ab0c45d8aaea5192328bfa6989673aceafc767c upstream. For devices that support DASH, even DASH is disabled, there may still exist a default firmware that will influence device behavior. So driver needs to handle DASH for devices that support DASH, no matter the DASH status is. This patch also prepares for "fix network lost after resume on DASH systems". Fixes: ee7a1beb9759 ("r8169:call "rtl8168_driver_start" "rtl8168_driver_stop" only when hardware dash function is enabled") Cc: [email protected] Signed-off-by: ChunHao Lin <[email protected]> Reviewed-by: Heiner Kallweit <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 862565f32494c7e8d88f49a02989c792c3926841 Author: ChunHao Lin <[email protected]> Date: Fri Nov 10 01:34:00 2023 +0800 r8169: fix network lost after resume on DASH systems commit 868c3b95afef4883bfb66c9397482da6840b5baf upstream. Device that support DASH may be reseted or powered off during suspend. So driver needs to handle DASH during system suspend and resume. Or DASH firmware will influence device behavior and causes network lost. Fixes: b646d90053f8 ("r8169: magic.") Cc: [email protected] Reviewed-by: Heiner Kallweit <[email protected]> Signed-off-by: ChunHao Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9e9e2107ae3637ed143d87f86025b47ddb502060 Author: Paolo Abeni <[email protected]> Date: Tue Nov 14 00:16:16 2023 +0100 mptcp: fix setsockopt(IP_TOS) subflow locking commit 7679d34f97b7a09fd565f5729f79fd61b7c55329 upstream. The MPTCP implementation of the IP_TOS socket option uses the lockless variant of the TOS manipulation helper and does not hold such lock at the helper invocation time. Add the required locking. Fixes: ffcacff87cd6 ("mptcp: Support for IP_TOS for MPTCP setsockopt()") Cc: [email protected] Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/457 Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-4-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit dba6f08cef1944116be7a480a4f8e51faca2a184 Author: Geliang Tang <[email protected]> Date: Tue Nov 14 00:16:15 2023 +0100 mptcp: add validity check for sending RM_ADDR commit 8df220b29282e8b450ea57be62e1eccd4996837c upstream. This patch adds the validity check for sending RM_ADDRs for userspace PM in mptcp_pm_remove_addrs(), only send a RM_ADDR when the address is in the anno_list or conn_list. Fixes: 8b1c94da1e48 ("mptcp: only send RM_ADDR in nl_cmd_remove") Cc: [email protected] Signed-off-by: Geliang Tang <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-3-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 70ff9b65a72885b3a2dfde6709da1f19b85fa696 Author: Paolo Abeni <[email protected]> Date: Tue Nov 14 00:16:13 2023 +0100 mptcp: deal with large GSO size commit 9fce92f050f448a0d1ddd9083ef967d9930f1e52 upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/450 Fixes: 7c4e983c4f3c ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 16fcda24b17507f2bb584e14dec5285301528f52 Author: Roman Gushchin <[email protected]> Date: Tue Nov 7 09:18:02 2023 -0800 mm: kmem: drop __GFP_NOFAIL when allocating objcg vectors commit 24948e3b7b12e0031a6edb4f49bbb9fb2ad1e4e9 upstream. Objcg vectors attached to slab pages to store slab object ownership information are allocated using gfp flags for the original slab allocation. Depending on slab page order and the size of slab objects, objcg vector can take several pages. If the original allocation was done with the __GFP_NOFAIL flag, it triggered a warning in the page allocation code. Indeed, order > 1 pages should not been allocated with the __GFP_NOFAIL flag. Fix this by simply dropping the __GFP_NOFAIL flag when allocating the objcg vector. It effectively allows to skip the accounting of a single slab object under a heavy memory pressure. An alternative would be to implement the mechanism to fallback to order-0 allocations for accounting metadata, which is also not perfect because it will increase performance penalty and memory footprint of the kernel memory accounting under memory pressure. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Roman Gushchin <[email protected]> Reported-by: Christoph Lameter <[email protected]> Closes: https://lkml.kernel.org/r/[email protected] Acked-by: Shakeel Butt <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a7fd033550271895e2a87ffc8303a03ffdeb9096 Author: Stefan Roesch <[email protected]> Date: Mon Nov 6 10:19:18 2023 -0800 mm: fix for negative counter: nr_file_hugepages commit a48d5bdc877b85201e42cef9c2fdf5378164c23a upstream. While qualifiying the 6.4 release, the following warning was detected in messages: vmstat_refresh: nr_file_hugepages -15664 The warning is caused by the incorrect updating of the NR_FILE_THPS counter in the function split_huge_page_to_list. The if case is checking for folio_test_swapbacked, but the else case is missing the check for folio_test_pmd_mappable. The other functions that manipulate the counter like __filemap_add_folio and filemap_unaccount_folio have the corresponding check. I have a test case, which reproduces the problem. It can be found here: https://github.com/sroeschus/testcase/blob/main/vmstat_refresh/madv.c The test case reproduces on an XFS filesystem. Running the same test case on a BTRFS filesystem does not reproduce the problem. AFAIK version 6.1 until 6.6 are affected by this problem. [[email protected]: whitespace fix] [[email protected]: test for folio_test_pmd_mappable()] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Stefan Roesch <[email protected]> Co-debugged-by: Johannes Weiner <[email protected]> Acked-by: Johannes Weiner <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Yang Shi <[email protected]> Cc: Rik van Riel <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2594bdaa16b47d304cbe3f3438632b7175b3d747 Author: Victor Shih <[email protected]> Date: Tue Sep 12 17:17:10 2023 +0800 mmc: sdhci-pci-gli: A workaround to allow GL9750 to enter ASPM L1.2 commit d7133797e9e1b72fd89237f68cb36d745599ed86 upstream. When GL9750 enters ASPM L1 sub-states, it will stay at L1.1 and will not enter L1.2. The workaround is to toggle PM state to allow GL9750 to enter ASPM L1.2. Signed-off-by: Victor Shih <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 97fb6013f318d77077413376d61691e930c2226c Author: Nam Cao <[email protected]> Date: Tue Aug 29 20:25:00 2023 +0200 riscv: kprobes: allow writing to x0 commit 8cb22bec142624d21bc85ff96b7bad10b6220e6a upstream. Instructions can write to x0, so we should simulate these instructions normally. Currently, the kernel hangs if an instruction who writes to x0 is simulated. Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported") Cc: [email protected] Signed-off-by: Nam Cao <[email protected]> Reviewed-by: Charlie Jenkins <[email protected]> Acked-by: Guo Ren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 645257ad8d307f7f11984a1e7ca713349ef12944 Author: Song Shuai <[email protected]> Date: Tue Aug 29 21:39:20 2023 -0700 riscv: correct pt_level name via pgtable_l5/4_enabled commit e59e5e2754bf983fc58ad18f99b5eec01f1a0745 upstream. The pt_level uses CONFIG_PGTABLE_LEVELS to display page table names. But if page mode is downgraded from kernel cmdline or restricted by the hardware in 64BIT, it will give a wrong name. Like, using no4lvl for sv39, ptdump named the 1G-mapping as "PUD" that should be "PGD": 0xffffffd840000000-0xffffffd900000000 0x00000000c0000000 3G PUD D A G . . W R V So select "P4D/PUD" or "PGD" via pgtable_l5/4_enabled to correct it. Fixes: e8a62cc26ddf ("riscv: Implement sv48 support") Reviewed-by: Alexandre Ghiti <[email protected]> Signed-off-by: Song Shuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit fb1b16f04135b50a577370f3ac00f7e8e402a3bd Author: Song Shuai <[email protected]> Date: Wed Aug 9 11:10:23 2023 +0800 riscv: mm: Update the comment of CONFIG_PAGE_OFFSET commit 559fe94a449cba5b50a7cffea60474b385598c00 upstream. Since the commit 011f09d12052 set sv57 as default for CONFIG_64BIT, the comment of CONFIG_PAGE_OFFSET should be updated too. Fixes: 011f09d12052 ("riscv: mm: Set sv57 on defaultly") Signed-off-by: Song Shuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9f74b261e4e2c39168b3e10743b9e606b2521422 Author: Nathan Chancellor <[email protected]> Date: Wed Nov 8 14:12:15 2023 +0800 LoongArch: Mark __percpu functions as always inline commit 71945968d8b128c955204baa33ec03bdd91bdc26 upstream. A recent change to the optimization pipeline in LLVM reveals some fragility around the inlining of LoongArch's __percpu functions, which manifests as a BUILD_BUG() failure: In file included from kernel/sched/build_policy.c:17: In file included from include/linux/sched/cputime.h:5: In file included from include/linux/sched/signal.h:5: In file included from include/linux/rculist.h:11: In file included from include/linux/rcupdate.h:26: In file included from include/linux/irqflags.h:18: arch/loongarch/include/asm/percpu.h:97:3: error: call to '__compiletime_assert_51' declared with 'error' attribute: BUILD_BUG failed 97 | BUILD_BUG(); | ^ include/linux/build_bug.h:59:21: note: expanded from macro 'BUILD_BUG' 59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") | ^ include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^ include/linux/compiler_types.h:425:2: note: expanded from macro 'compiletime_assert' 425 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ include/linux/compiler_types.h:413:2: note: expanded from macro '_compiletime_assert' 413 | __compiletime_assert(condition, msg, prefix, suffix) | ^ include/linux/compiler_types.h:406:4: note: expanded from macro '__compiletime_assert' 406 | prefix ## suffix(); \ | ^ <scratch space>:86:1: note: expanded from here 86 | __compiletime_assert_51 | ^ 1 error generated. If these functions are not inlined (which the compiler is free to do even with functions marked with the standard 'inline' keyword), the BUILD_BUG() in the default case cannot be eliminated since the compiler cannot prove it is never used, resulting in a build failure due to the error attribute. Mark these functions as __always_inline to guarantee inlining so that the BUILD_BUG() only triggers when the default case genuinely cannot be eliminated due to an unexpected size. Cc: <[email protected]> Closes: https://github.com/ClangBuiltLinux/linux/…
gyroninja
added a commit
to gyroninja/linux
that referenced
this pull request
Jan 28, 2024
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
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 ??
snajpa
pushed a commit
to vpsfreecz/linux
that referenced
this pull request
Mar 2, 2024
commit 9fce92f upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#450 Fixes: 7c4e983 ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
snajpa
pushed a commit
to vpsfreecz/linux
that referenced
this pull request
Mar 2, 2024
commit 9fce92f upstream. After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#450 Fixes: 7c4e983 ("net: allow gso_max_size to exceed 65536") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
May 2, 2024
[ Upstream commit 27de77c ] syzbot wrote: | ============================= | WARNING: suspicious RCU usage | 5.7.0-rc1+ torvalds#45 Not tainted | ----------------------------- | net/openvswitch/conntrack.c:1898 RCU-list traversed in non-reader section!! | | other info that might help us debug this: | rcu_scheduler_active = 2, debug_locks = 1 | ... | | stack backtrace: | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 | Workqueue: netns cleanup_net | Call Trace: | ... | ovs_ct_exit | ovs_exit_net | ops_exit_list.isra.7 | cleanup_net | process_one_work | worker_thread To avoid that warning, invoke the ovs_ct_exit under ovs_lock and add lockdep_ovsl_is_held as optional lockdep expression. Link: https://lore.kernel.org/lkml/[email protected] Fixes: 11efd5c ("openvswitch: Support conntrack zone limit") Cc: Pravin B Shelar <[email protected]> Cc: Yi-Hung Wei <[email protected]> Reported-by: [email protected] Signed-off-by: Tonghao Zhang <[email protected]> Acked-by: Pravin B Shelar <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: 5ea7b72 ("net: openvswitch: Fix Use-After-Free in ovs_ct_exit") Signed-off-by: Sasha Levin <[email protected]>
torvalds
pushed a commit
that referenced
this pull request
Oct 4, 2024
There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Oct 8, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Oct 8, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Oct 8, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Oct 8, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Oct 8, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Oct 8, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
KexyBiscuit
pushed a commit
to AOSC-Tracking/linux
that referenced
this pull request
Oct 8, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
intersectRaven
pushed a commit
to intersectRaven/linux
that referenced
this pull request
Oct 10, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
riccardv
pushed a commit
to riccardv/linux
that referenced
this pull request
Oct 10, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Oct 10, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Oct 14, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Oct 15, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
staging-kernelci-org
pushed a commit
to kernelci/linux
that referenced
this pull request
Oct 17, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Oct 17, 2024
commit 829e0c9 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ torvalds#45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c8895e2 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Dec 1, 2024
…_direct_reclaim-checkpatch-fixes ERROR: trailing whitespace torvalds#40: FILE: mm/vmscan.c:378: +^I * If there are no reclaimable file-backed or anonymous pages, $ ERROR: trailing whitespace torvalds#41: FILE: mm/vmscan.c:379: +^I * ensure zones with sufficient free pages are not skipped. $ ERROR: trailing whitespace torvalds#42: FILE: mm/vmscan.c:380: +^I * This prevents zones like DMA32 from being ignored in reclaim $ WARNING: suspect code indent for conditional statements (8, 12) torvalds#45: FILE: mm/vmscan.c:383: + if (nr == 0) + nr = zone_page_state_snapshot(zone, NR_FREE_PAGES); total: 3 errors, 1 warnings, 15 lines checked Cc: Mel Gorman <[email protected]> Cc: Seiji Nishikawa <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Dec 3, 2024
…_direct_reclaim-checkpatch-fixes ERROR: trailing whitespace torvalds#40: FILE: mm/vmscan.c:378: +^I * If there are no reclaimable file-backed or anonymous pages, $ ERROR: trailing whitespace torvalds#41: FILE: mm/vmscan.c:379: +^I * ensure zones with sufficient free pages are not skipped. $ ERROR: trailing whitespace torvalds#42: FILE: mm/vmscan.c:380: +^I * This prevents zones like DMA32 from being ignored in reclaim $ WARNING: suspect code indent for conditional statements (8, 12) torvalds#45: FILE: mm/vmscan.c:383: + if (nr == 0) + nr = zone_page_state_snapshot(zone, NR_FREE_PAGES); total: 3 errors, 1 warnings, 15 lines checked Cc: Mel Gorman <[email protected]> Cc: Seiji Nishikawa <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.