* Re: TK1: DRM, Nouveau and VIC
From: Marcel Ziswiler @ 2018-12-10 15:20 UTC (permalink / raw)
To: bskeggs@redhat.com, thierry.reding@gmail.com
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
mperttunen@nvidia.com, linux-tegra@vger.kernel.org,
jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210110056.GL15154@ulmo>
Hi Thierry
On Mon, 2018-12-10 at 12:00 +0100, Thierry Reding wrote:
> On Mon, Dec 10, 2018 at 11:21:47AM +0100, Thierry Reding wrote:
> > On Sat, Dec 08, 2018 at 02:54:45PM +0000, Marcel Ziswiler wrote:
> > > Hi Thierry et al.
> > >
> > > I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
> > > Tegra124") graphics on Apalis TK1 is broken. During boot it fails
> > > loading the vic firmware:
> > >
> > > [ 1.595824] tegra-vic 54340000.vic: Direct firmware load for
> > > nvidia/tegra124/vic03_ucode.bin failed with error -2
> > > [ 1.606140] tegra-vic: probe of 54340000.vic failed with error
> > > -2
> > >
> > > Subsequently Tegra HDMI seems to fail completely:
> > >
> > > [ 2.379860] tegra-hdmi 54280000.hdmi: failed to get PLL
> > > regulator
> > >
> > > And finally, Nouveau even crashes:
> > >
> > > [ 8.241115] nouveau 57000000.gpu: Linked as a consumer to
> > > regulator.31
> > > [ 8.247889] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1)
> > > [ 8.253396] nouveau 57000000.gpu: imem: using IOMMU
> > > [ 8.270210] Unable to handle kernel NULL pointer dereference
> > > at
> > > virtual address 0000006c
> > > [ 8.278340] pgd = (ptrval)
> > > [ 8.281250] [0000006c] *pgd=00000000
> > > [ 8.284944] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> > > [ 8.290260] Modules linked in: nouveau(+) ttm
> > > [ 8.294625] CPU: 2 PID: 203 Comm: systemd-udevd Not tainted
> > > 4.20.0-
> > > rc5-next-20181207-00008-g85b0f8e25f86-dirty #110
> > > [ 8.305055] Hardware name: NVIDIA Tegra SoC (Flattened Device
> > > Tree)
> > > [ 8.311331] PC is at drm_plane_register_all+0x18/0x50
> > > [ 8.316373] LR is at drm_modeset_register_all+0xc/0x70
> > > [ 8.321513] pc : [<c056200c>] lr : [<c0564cc8>] psr:
> > > a0060013
> > > [ 8.327768] sp : ed527c70 ip : ecc43ec0 fp : 00000000
> > > [ 8.332993] r10: 00000016 r9 : ecc43e80 r8 : 00000000
> > > [ 8.338209] r7 : bf182c80 r6 : 00000000 r5 : ed61b24c r4 :
> > > fffffffc
> > > [ 8.344735] r3 : 0002f000 r2 : ffffffff r1 : 2e124000 r0 :
> > > ed61b000
> > > [ 8.351260] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA
> > > ARM Segment none
> > > [ 8.358383] Control: 10c5387d Table: ad64c06a DAC: 00000051
> > > [ 8.364127] Process systemd-udevd (pid: 203, stack limit =
> > > 0x(ptrval))
> > > [ 8.370654] Stack: (0xed527c70 to 0xed528000)
> > > [ 8.375004] 7c60: ed61b000
> > > ed61b000 00000000 c0564cc8
> > > [ 8.383177] 7c80: ed61b000 00000000 00000000 c054b5b8 00000001
> > > 00000001 ffffffff ffffffff
> > > [ 8.391355] 7ca0: ed527cc0 c0f08c48 ed61b000 00000000 00000000
> > > 00000000 bf180c5c bf0dc900
> > > [ 8.399531] 7cc0: eda29208 5dfe844b 00000000 ee9f2a10 00000000
> > > bf180c5c 00000000 c05a9328
> > > [ 8.407695] 7ce0: c1006828 ee9f2a10 c100682c 00000000 00000000
> > > c05a744c ee9f2a10 bf180c5c
> > > [ 8.415871] 7d00: ee9f2a44 c05a77a8 00000000 c0f08c48 bf182980
> > > c05a769c eefd14d0 c05a77a8
> > > [ 8.424048] 7d20: 00000000 ee9f2a10 bf180c5c ee9f2a44 c05a77a8
> > > 00000000 c0f08c48 bf182980
> > > [ 8.432226] 7d40: 00000000 c05a7884 ee9ebfb4 c0f08c48 bf180c5c
> > > c05a5790 00000000 ee88135c
> > > [ 8.440405] 7d60: ee9ebfb4 5dfe844b c0f71168 bf180c5c ee379e80
> > > c0f71168 00000000 c05a692c
> > > [ 8.448570] 7d80: bf15dc00 bf180ac8 ffffe000 bf180c5c bf180ac8
> > > ffffe000 bf1aa000 c05a84a0
> > > [ 8.456746] 7da0: bf182b80 bf180ac8 ffffe000 bf1aa170 c0fbd220
> > > c0f08c48 ffffe000 c0102ed0
> > > [ 8.464924] 7dc0: ed53f4c0 006000c0 c01b3d98 0000000c 60000113
> > > bf182980 00000040 c02592d0
> > > [ 8.473102] 7de0: eda60200 2e124000 ee800000 006000c0 006000c0
> > > c01b3d98 0000000c c025a8cc
> > > [ 8.481281] 7e00: c024ce54 a0000113 bf182980 5dfe844b bf182980
> > > 00000002 ed53f4c0 00000002
> > > [ 8.489459] 7e20: eceba000 c01b3dd4 c0f08c48 bf182980 00000000
> > > ed527f40 00000002 eceb9fc0
> > > [ 8.497625] 7e40: 00000002 c01b61a4 bf18298c 00007fff bf182980
> > > c01b2f88 00000000 c01b279c
> > > [ 8.505800] 7e60: bf1829c8 bf182a80 bf182b6c bf182ab0 c0b03ab0
> > > c0d58964 c0ca726c c0ca7278
> > > [ 8.513978] 7e80: c0ca72d0 c0f08c48 00000000 c02654a0 00000000
> > > 00000000 ffffe000 bf000000
> > > [ 8.522157] 7ea0: 00000000 00000000 00000000 00000000 00000000
> > > 00000000 6e72656b 00006c65
> > > [ 8.530336] 7ec0: 00000000 00000000 00000000 00000000 00000000
> > > 00000000 00000000 00000000
> > > [ 8.538502] 7ee0: 00000000 00000000 00000000 00000000 00000000
> > > 5dfe844b 7fffffff c0f08c48
> > > [ 8.546677] 7f00: 00000000 0000000f b6f761cc c0101204 ed526000
> > > 0000017b 004a3270 c01b66a4
> > > [ 8.554855] 7f20: 7fffffff 00000000 00000003 00000001 004a3270
> > > f0ced000 06e8994c 00000000
> > > [ 8.563032] 7f40: f0e37f3a f0e50a40 f0ced000 06e8994c f7b75f9c
> > > f7b75d34 f63e62dc 0016b000
> > > [ 8.571209] 7f60: 0017f6f0 00000000 00000000 00000000 00050a48
> > > 0000003b 0000003c 00000023
> > > [ 8.579388] 7f80: 00000000 00000014 00000000 5dfe844b 00000000
> > > 004c0ec0 00000000 00000001
> > > [ 8.587554] 7fa0: 0000017b c0101000 004c0ec0 00000000 0000000f
> > > b6f761cc 00000000 00020000
> > > [ 8.595730] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
> > > 00000000 00000000 004a3270
> > > [ 8.603908] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0 400d0010
> > > 0000000f 00000000 00000000
> > > [ 8.612096] [<c056200c>] (drm_plane_register_all) from
> > > [<c0564cc8>]
> > > (drm_modeset_register_all+0xc/0x70)
> > > [ 8.621499] [<c0564cc8>] (drm_modeset_register_all) from
> > > [<c054b5b8>] (drm_dev_register+0x168/0x1c4)
> > > [ 8.630855] [<c054b5b8>] (drm_dev_register) from [<bf0dc900>]
> > > (nouveau_platform_probe+0x6c/0x88 [nouveau])
> > > [ 8.640739] [<bf0dc900>] (nouveau_platform_probe [nouveau])
> > > from
> > > [<c05a9328>] (platform_drv_probe+0x48/0x98)
> > > [ 8.650574] [<c05a9328>] (platform_drv_probe) from
> > > [<c05a744c>]
> > > (really_probe+0x1e0/0x2cc)
> > > [ 8.658827] [<c05a744c>] (really_probe) from [<c05a769c>]
> > > (driver_probe_device+0x60/0x16c)
> > > [ 8.667096] [<c05a769c>] (driver_probe_device) from
> > > [<c05a7884>]
> > > (__driver_attach+0xdc/0xe0)
> > > [ 8.675543] [<c05a7884>] (__driver_attach) from [<c05a5790>]
> > > (bus_for_each_dev+0x74/0xb4)
> > > [ 8.683729] [<c05a5790>] (bus_for_each_dev) from [<c05a692c>]
> > > (bus_add_driver+0x1c0/0x204)
> > > [ 8.692004] [<c05a692c>] (bus_add_driver) from [<c05a84a0>]
> > > (driver_register+0x74/0x108)
> > > [ 8.700324] [<c05a84a0>] (driver_register) from [<bf1aa170>]
> > > (nouveau_drm_init+0x170/0x1000 [nouveau])
> > > [ 8.709857] [<bf1aa170>] (nouveau_drm_init [nouveau]) from
> > > [<c0102ed0>] (do_one_initcall+0x54/0x284)
> > > [ 8.718980] [<c0102ed0>] (do_one_initcall) from [<c01b3dd4>]
> > > (do_init_module+0x64/0x214)
> > > [ 8.727079] [<c01b3dd4>] (do_init_module) from [<c01b61a4>]
> > > (load_module+0x21b8/0x246c)
> > > [ 8.735094] [<c01b61a4>] (load_module) from [<c01b66a4>]
> > > (sys_finit_module+0xc4/0xdc)
> > > [ 8.742937] [<c01b66a4>] (sys_finit_module) from [<c0101000>]
> > > (ret_fast_syscall+0x0/0x54)
> > > [ 8.751114] Exception stack(0xed527fa8 to 0xed527ff0)
> > > [ 8.756157] 7fa0: 004c0ec0 00000000 0000000f
> > > b6f761cc 00000000 00020000
> > > [ 8.764333] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
> > > 00000000 00000000 004a3270
> > > [ 8.772510] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0
> > > [ 8.777556] Code: e5b5424c e1550004 0a00000c e2444004
> > > (e5943070)
> > > [ 8.784011] ---[ end trace ad8c21587c118655 ]---
> > >
> > > Of course my root file system does include resp. vic firmware:
> > >
> > > 7ef01d2e3f507c91ca79584e89edcc64 /lib/firmware/nvidia/tegra124/v
> > > ic03_u
> > > code.bin
> > >
> > > If I bake that one into the kernel binary, Nouveau still crashes
> > > like
> > > above albeit VIC loading and Tegra DRM now at least showing
> > > something
> > > on HDMI.
> >
> > Yeah, this is a fairly common pitfall. The general rule of thumb is
> > that
> > the firmware has to live on the same medium as the module. So if
> > you've
> > built Tegra DRM as a loadable kernel module and installed it in the
> > root
> > filesystem, then that's where your firmware file also needs to be.
> > If
> > the driver is built-in (or a loadable module installed in the
> > initial
> > ramdisk), then the firmware needs to be in the initial ramdisk (or
> > built
> > into the kernel image itself). That's somewhat annoying, but it is
> > what
> > it is. At least it's logical.
> >
> > > Just reverting above mentioned commit still leaves Nouveau
> > > crashing.
> > >
> > > This has been observed using latest next-20181207.
> > >
> > > Does anybody know what exactly is going on and how exactly one
> > > may get
> > > graphics working again as before?
> >
> > So this is something that should be fixed by this:
> >
> > https://patchwork.freedesktop.org/patch/260547/
> >
> > And there's another patch that fixes a subsequent crash when you
> > actually start to use the GPU:
> >
> > https://patchwork.freedesktop.org/patch/263588/
> >
> > It'd be great if you could apply both and verify that they fix the
> > crash
> > for you. If so, can you provide a Tested-by? Both were Cc'ed to
> > linux-tegra, so you should have a copy to reply to. If not, let me
> > know
> > and I can bounce it.
> >
> > Ben, can you pick up the two patches above? They're kind of high-
> > priority because they fix issues that crept into v4.20-rc1, so
> > should
> > ideally be fixed before v4.20 final.
>
> Actually, it looks as if only the last patch is needed, since it
> superseeds the first. The second one calls drm_mode_config_init() via
> nouveau_display_create() and nouveau_drm_device_init(), making the
> first patch obsolete.
>
> There's more confirmation here:
>
>
> https://lists.freedesktop.org/archives/nouveau/2018-December/031636.html
>
> So Ben, correction, please only apply:
>
> https://patchwork.freedesktop.org/patch/263587/
Yes, that fixes it and I sent my tested-by. Thanks!
> Preferably in time for v4.20 final.
BTW: During testing I was also brave enough to try rmmodding nouveau
which unfortunately also seems to fail:
root@apalis-tk1-mainline:~# rmmod nouveau
[ 3044.432527] [TTM] Finalizing pool allocator
[ 3044.440007] [TTM] Zone kernel: Used memory at exit: 0 kiB
[ 3044.445631] [TTM] Zone highmem: Used memory at exit: 0 kiB
[ 3044.452841] Unable to handle kernel NULL pointer dereference at
virtual address 0000038a
[ 3044.461167] pgd = 537c0ac4
[ 3044.463891] [0000038a] *pgd=fb95b835
[ 3044.467487] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 3044.472901] Modules linked in: nouveau(-) btusb btrtl btbcm btintel
tegra_drm xhci_tegra host1x iova ttm
[ 3044.482415] CPU: 3 PID: 616 Comm: rmmod Not tainted 4.20.0-rc6-next-
20181210-00001-gd70a977fd0d5-dirty #115
[ 3044.492176] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[ 3044.498455] PC is at pci_disable_device+0x8/0xd4
[ 3044.503165] LR is at nouveau_drm_device_remove+0x50/0x7c [nouveau]
[ 3044.509350] pc : [<c048d05c>] lr : [<bf254820>] psr: 60000113
[ 3044.515638] sp : ee3abedc ip : ed625000 fp : 00000001
[ 3044.520879] r10: 00000081 r9 : ee3aa000 r8 : ee9eb834
[ 3044.526107] r7 : ed624000 r6 : 00000000 r5 : c0f08c48 r4 :
00000000
[ 3044.532649] r3 : 5dfe844b r2 : 5dfe844b r1 : 2e135000 r0 :
00000000
[ 3044.539181] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA
ARM Segment none
[ 3044.546333] Control: 10c5387d Table: acbc006a DAC: 00000051
[ 3044.552098] Process rmmod (pid: 616, stack limit = 0xfc4e79a2)
[ 3044.557934] Stack: (0xee3abedc to 0xee3ac000)
[ 3044.562304]
bec0: ed
62d400
[ 3044.570503] bee0: c0f08c48 bf254820 eda76808 5dfe844b ee9f1c8c
ee9f1c10 ee9f1c10 bf2f9c5c
[ 3044.578701] bf00: ee9eb800 bf255914 ee9f1c10 c056aba8 ee9f1c10
ee9f1c44 bf2f9c5c c05693bc
[ 3044.587298] bf20: ee9f1c10 bf2f9c5c 0001f10c 00000800 c0101204
c05694cc bf2f9c5c bf2fb980
[ 3044.596316] bf40: 0001f10c c056829c c0f08c48 c01b3c34 76756f6e
00756165 00000000 00000000
[ 3044.605356] bf60: c0f08c48 ec415000 00000002 5dfe844b 00000001
c0141c10 ec415000 ec415000
[ 3044.614431] bf80: ed67c100 5dfe844b 00000000 5dfe844b 00000000
00000002 bebb5ba8 00000000
[ 3044.623529] bfa0: 00000081 c0101000 00000002 bebb5ba8 0001f10c
00000800 0000000a 00000000
[ 3044.632631] bfc0: 00000002 bebb5ba8 00000000 00000081 bebb5e9b
0001f0d0 bebb5d8c 00000001
[ 3044.641739] bfe0: b6e74730 bebb5b64 00012bdf b6e7473c 600d0010
0001f10c 00000000 00000000
[ 3044.650884] [<c048d05c>] (pci_disable_device) from [<ee9f1c8c>]
(0xee9f1c8c)
[ 3044.658410] Code: eafffff0 ebf25973 e92d4030 e1a04000 (e5d0338a)
[ 3044.665141] ---[ end trace 810af3dad648a902 ]---
Segmentation fault
Looks like with pci_disable_device() it may take a rather strange
path...
> Thanks,
> Thierry
Cheers
Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: TK1: DRM, Nouveau and VIC
From: Marcel Ziswiler @ 2018-12-10 15:17 UTC (permalink / raw)
To: bskeggs@redhat.com, thierry.reding@gmail.com
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
mperttunen@nvidia.com, linux-tegra@vger.kernel.org,
jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210102147.GF15154@ulmo>
Hi Thierry
On Mon, 2018-12-10 at 11:21 +0100, Thierry Reding wrote:
> On Sat, Dec 08, 2018 at 02:54:45PM +0000, Marcel Ziswiler wrote:
> > Hi Thierry et al.
> >
> > I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
> > Tegra124") graphics on Apalis TK1 is broken. During boot it fails
> > loading the vic firmware:
> >
> > [ 1.595824] tegra-vic 54340000.vic: Direct firmware load for
> > nvidia/tegra124/vic03_ucode.bin failed with error -2
> > [ 1.606140] tegra-vic: probe of 54340000.vic failed with error
> > -2
> >
> > Subsequently Tegra HDMI seems to fail completely:
> >
> > [ 2.379860] tegra-hdmi 54280000.hdmi: failed to get PLL
> > regulator
> >
> > And finally, Nouveau even crashes:
> >
> > [ 8.241115] nouveau 57000000.gpu: Linked as a consumer to
> > regulator.31
> > [ 8.247889] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1)
> > [ 8.253396] nouveau 57000000.gpu: imem: using IOMMU
> > [ 8.270210] Unable to handle kernel NULL pointer dereference at
> > virtual address 0000006c
> > [ 8.278340] pgd = (ptrval)
> > [ 8.281250] [0000006c] *pgd=00000000
> > [ 8.284944] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> > [ 8.290260] Modules linked in: nouveau(+) ttm
> > [ 8.294625] CPU: 2 PID: 203 Comm: systemd-udevd Not tainted
> > 4.20.0-
> > rc5-next-20181207-00008-g85b0f8e25f86-dirty #110
> > [ 8.305055] Hardware name: NVIDIA Tegra SoC (Flattened Device
> > Tree)
> > [ 8.311331] PC is at drm_plane_register_all+0x18/0x50
> > [ 8.316373] LR is at drm_modeset_register_all+0xc/0x70
> > [ 8.321513] pc : [<c056200c>] lr : [<c0564cc8>] psr:
> > a0060013
> > [ 8.327768] sp : ed527c70 ip : ecc43ec0 fp : 00000000
> > [ 8.332993] r10: 00000016 r9 : ecc43e80 r8 : 00000000
> > [ 8.338209] r7 : bf182c80 r6 : 00000000 r5 : ed61b24c r4 :
> > fffffffc
> > [ 8.344735] r3 : 0002f000 r2 : ffffffff r1 : 2e124000 r0 :
> > ed61b000
> > [ 8.351260] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA
> > ARM Segment none
> > [ 8.358383] Control: 10c5387d Table: ad64c06a DAC: 00000051
> > [ 8.364127] Process systemd-udevd (pid: 203, stack limit =
> > 0x(ptrval))
> > [ 8.370654] Stack: (0xed527c70 to 0xed528000)
> > [ 8.375004] 7c60: ed61b000
> > ed61b000 00000000 c0564cc8
> > [ 8.383177] 7c80: ed61b000 00000000 00000000 c054b5b8 00000001
> > 00000001 ffffffff ffffffff
> > [ 8.391355] 7ca0: ed527cc0 c0f08c48 ed61b000 00000000 00000000
> > 00000000 bf180c5c bf0dc900
> > [ 8.399531] 7cc0: eda29208 5dfe844b 00000000 ee9f2a10 00000000
> > bf180c5c 00000000 c05a9328
> > [ 8.407695] 7ce0: c1006828 ee9f2a10 c100682c 00000000 00000000
> > c05a744c ee9f2a10 bf180c5c
> > [ 8.415871] 7d00: ee9f2a44 c05a77a8 00000000 c0f08c48 bf182980
> > c05a769c eefd14d0 c05a77a8
> > [ 8.424048] 7d20: 00000000 ee9f2a10 bf180c5c ee9f2a44 c05a77a8
> > 00000000 c0f08c48 bf182980
> > [ 8.432226] 7d40: 00000000 c05a7884 ee9ebfb4 c0f08c48 bf180c5c
> > c05a5790 00000000 ee88135c
> > [ 8.440405] 7d60: ee9ebfb4 5dfe844b c0f71168 bf180c5c ee379e80
> > c0f71168 00000000 c05a692c
> > [ 8.448570] 7d80: bf15dc00 bf180ac8 ffffe000 bf180c5c bf180ac8
> > ffffe000 bf1aa000 c05a84a0
> > [ 8.456746] 7da0: bf182b80 bf180ac8 ffffe000 bf1aa170 c0fbd220
> > c0f08c48 ffffe000 c0102ed0
> > [ 8.464924] 7dc0: ed53f4c0 006000c0 c01b3d98 0000000c 60000113
> > bf182980 00000040 c02592d0
> > [ 8.473102] 7de0: eda60200 2e124000 ee800000 006000c0 006000c0
> > c01b3d98 0000000c c025a8cc
> > [ 8.481281] 7e00: c024ce54 a0000113 bf182980 5dfe844b bf182980
> > 00000002 ed53f4c0 00000002
> > [ 8.489459] 7e20: eceba000 c01b3dd4 c0f08c48 bf182980 00000000
> > ed527f40 00000002 eceb9fc0
> > [ 8.497625] 7e40: 00000002 c01b61a4 bf18298c 00007fff bf182980
> > c01b2f88 00000000 c01b279c
> > [ 8.505800] 7e60: bf1829c8 bf182a80 bf182b6c bf182ab0 c0b03ab0
> > c0d58964 c0ca726c c0ca7278
> > [ 8.513978] 7e80: c0ca72d0 c0f08c48 00000000 c02654a0 00000000
> > 00000000 ffffe000 bf000000
> > [ 8.522157] 7ea0: 00000000 00000000 00000000 00000000 00000000
> > 00000000 6e72656b 00006c65
> > [ 8.530336] 7ec0: 00000000 00000000 00000000 00000000 00000000
> > 00000000 00000000 00000000
> > [ 8.538502] 7ee0: 00000000 00000000 00000000 00000000 00000000
> > 5dfe844b 7fffffff c0f08c48
> > [ 8.546677] 7f00: 00000000 0000000f b6f761cc c0101204 ed526000
> > 0000017b 004a3270 c01b66a4
> > [ 8.554855] 7f20: 7fffffff 00000000 00000003 00000001 004a3270
> > f0ced000 06e8994c 00000000
> > [ 8.563032] 7f40: f0e37f3a f0e50a40 f0ced000 06e8994c f7b75f9c
> > f7b75d34 f63e62dc 0016b000
> > [ 8.571209] 7f60: 0017f6f0 00000000 00000000 00000000 00050a48
> > 0000003b 0000003c 00000023
> > [ 8.579388] 7f80: 00000000 00000014 00000000 5dfe844b 00000000
> > 004c0ec0 00000000 00000001
> > [ 8.587554] 7fa0: 0000017b c0101000 004c0ec0 00000000 0000000f
> > b6f761cc 00000000 00020000
> > [ 8.595730] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
> > 00000000 00000000 004a3270
> > [ 8.603908] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0 400d0010
> > 0000000f 00000000 00000000
> > [ 8.612096] [<c056200c>] (drm_plane_register_all) from
> > [<c0564cc8>]
> > (drm_modeset_register_all+0xc/0x70)
> > [ 8.621499] [<c0564cc8>] (drm_modeset_register_all) from
> > [<c054b5b8>] (drm_dev_register+0x168/0x1c4)
> > [ 8.630855] [<c054b5b8>] (drm_dev_register) from [<bf0dc900>]
> > (nouveau_platform_probe+0x6c/0x88 [nouveau])
> > [ 8.640739] [<bf0dc900>] (nouveau_platform_probe [nouveau]) from
> > [<c05a9328>] (platform_drv_probe+0x48/0x98)
> > [ 8.650574] [<c05a9328>] (platform_drv_probe) from [<c05a744c>]
> > (really_probe+0x1e0/0x2cc)
> > [ 8.658827] [<c05a744c>] (really_probe) from [<c05a769c>]
> > (driver_probe_device+0x60/0x16c)
> > [ 8.667096] [<c05a769c>] (driver_probe_device) from [<c05a7884>]
> > (__driver_attach+0xdc/0xe0)
> > [ 8.675543] [<c05a7884>] (__driver_attach) from [<c05a5790>]
> > (bus_for_each_dev+0x74/0xb4)
> > [ 8.683729] [<c05a5790>] (bus_for_each_dev) from [<c05a692c>]
> > (bus_add_driver+0x1c0/0x204)
> > [ 8.692004] [<c05a692c>] (bus_add_driver) from [<c05a84a0>]
> > (driver_register+0x74/0x108)
> > [ 8.700324] [<c05a84a0>] (driver_register) from [<bf1aa170>]
> > (nouveau_drm_init+0x170/0x1000 [nouveau])
> > [ 8.709857] [<bf1aa170>] (nouveau_drm_init [nouveau]) from
> > [<c0102ed0>] (do_one_initcall+0x54/0x284)
> > [ 8.718980] [<c0102ed0>] (do_one_initcall) from [<c01b3dd4>]
> > (do_init_module+0x64/0x214)
> > [ 8.727079] [<c01b3dd4>] (do_init_module) from [<c01b61a4>]
> > (load_module+0x21b8/0x246c)
> > [ 8.735094] [<c01b61a4>] (load_module) from [<c01b66a4>]
> > (sys_finit_module+0xc4/0xdc)
> > [ 8.742937] [<c01b66a4>] (sys_finit_module) from [<c0101000>]
> > (ret_fast_syscall+0x0/0x54)
> > [ 8.751114] Exception stack(0xed527fa8 to 0xed527ff0)
> > [ 8.756157] 7fa0: 004c0ec0 00000000 0000000f
> > b6f761cc 00000000 00020000
> > [ 8.764333] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
> > 00000000 00000000 004a3270
> > [ 8.772510] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0
> > [ 8.777556] Code: e5b5424c e1550004 0a00000c e2444004 (e5943070)
> > [ 8.784011] ---[ end trace ad8c21587c118655 ]---
> >
> > Of course my root file system does include resp. vic firmware:
> >
> > 7ef01d2e3f507c91ca79584e89edcc64 /lib/firmware/nvidia/tegra124/vic
> > 03_u
> > code.bin
> >
> > If I bake that one into the kernel binary, Nouveau still crashes
> > like
> > above albeit VIC loading and Tegra DRM now at least showing
> > something
> > on HDMI.
>
> Yeah, this is a fairly common pitfall. The general rule of thumb is
> that
> the firmware has to live on the same medium as the module. So if
> you've
> built Tegra DRM as a loadable kernel module and installed it in the
> root
> filesystem, then that's where your firmware file also needs to be. If
> the driver is built-in (or a loadable module installed in the initial
> ramdisk), then the firmware needs to be in the initial ramdisk (or
> built
> into the kernel image itself). That's somewhat annoying, but it is
> what
> it is. At least it's logical.
Yes, while not entirely convenient that was more or less obvious.
> > Just reverting above mentioned commit still leaves Nouveau
> > crashing.
> >
> > This has been observed using latest next-20181207.
> >
> > Does anybody know what exactly is going on and how exactly one may
> > get
> > graphics working again as before?
>
> So this is something that should be fixed by this:
>
> https://patchwork.freedesktop.org/patch/260547/
>
> And there's another patch that fixes a subsequent crash when you
> actually start to use the GPU:
>
> https://patchwork.freedesktop.org/patch/263588/
>
> It'd be great if you could apply both and verify that they fix the
> crash
> for you. If so, can you provide a Tested-by? Both were Cc'ed to
> linux-tegra, so you should have a copy to reply to. If not, let me
> know
> and I can bounce it.
>
> Ben, can you pick up the two patches above? They're kind of high-
> priority because they fix issues that crept into v4.20-rc1, so should
> ideally be fixed before v4.20 final.
>
> Thierry
Cheers
Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support
From: Kirill A. Shutemov @ 2018-12-10 15:15 UTC (permalink / raw)
To: Rafael David Tinoco
Cc: Rich Felker, linux-ia64, Sergey Senozhatsky, linux-sh,
Benjamin Herrenschmidt, Heiko Carstens, Ram Pai, linux-mips,
linux-mm, Khalid Aziz, Paul Mackerras, H . Peter Anvin,
sparclinux, linux-s390, Yoshinori Sato, Michael Ellerman, x86,
Russell King, Ingo Molnar, Catalin Marinas, James Hogan,
Anthony Yznaga, Nitin Gupta, Fenghua Yu, Joerg Roedel,
Juergen Gross, Vasily Gorbik, Will Deacon, Nicholas Piggin,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Christophe Leroy, Tony Luck, Jiri Kosina,
linux-kernel, Ralf Baechle, Minchan Kim, Paul Burton,
Aneesh Kumar K . V, Martin Schwidefsky, linuxppc-dev,
David S . Miller, Kirill A . Shutemov
In-Reply-To: <20181210142105.6750-1-rafael.tinoco@linaro.org>
On Mon, Dec 10, 2018 at 12:21:05PM -0200, Rafael David Tinoco wrote:
> diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
> index 84bd9bdc1987..d808cfde3d19 100644
> --- a/arch/x86/include/asm/pgtable_64_types.h
> +++ b/arch/x86/include/asm/pgtable_64_types.h
> @@ -64,8 +64,6 @@ extern unsigned int ptrs_per_p4d;
> #define P4D_SIZE (_AC(1, UL) << P4D_SHIFT)
> #define P4D_MASK (~(P4D_SIZE - 1))
>
> -#define MAX_POSSIBLE_PHYSMEM_BITS 52
> -
> #else /* CONFIG_X86_5LEVEL */
>
> /*
> @@ -154,4 +152,6 @@ extern unsigned int ptrs_per_p4d;
>
> #define PGD_KERNEL_START ((PAGE_SIZE / 2) / sizeof(pgd_t))
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS (pgtable_l5_enabled() ? 52 : 46)
> +
...
> #endif /* _ASM_X86_PGTABLE_64_DEFS_H */
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 0787d33b80d8..132c20b6fd4f 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
...
> @@ -116,6 +100,25 @@
> */
> #define OBJ_ALLOCATED_TAG 1
> #define OBJ_TAG_BITS 1
> +
> +/*
> + * MAX_POSSIBLE_PHYSMEM_BITS should be defined by all archs using zsmalloc:
> + * Trying to guess it from MAX_PHYSMEM_BITS, or considering it BITS_PER_LONG,
> + * proved to be wrong by not considering PAE capabilities, or using SPARSEMEM
> + * only headers, leading to bad object encoding due to object index overflow.
> + */
> +#ifndef MAX_POSSIBLE_PHYSMEM_BITS
> + #define MAX_POSSIBLE_PHYSMEM_BITS BITS_PER_LONG
> + #error "MAX_POSSIBLE_PHYSMEM_BITS HAS to be defined by arch using zsmalloc";
> +#else
> + #ifndef CONFIG_64BIT
> + #if (MAX_POSSIBLE_PHYSMEM_BITS >= (BITS_PER_LONG + PAGE_SHIFT - OBJ_TAG_BITS))
> + #error "MAX_POSSIBLE_PHYSMEM_BITS is wrong for this arch";
> + #endif
> + #endif
> +#endif
> +
> +#define _PFN_BITS (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)
> #define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
> #define OBJ_INDEX_MASK ((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
Have you tested it with CONFIG_X86_5LEVEL=y?
ASAICS, the patch makes OBJ_INDEX_BITS and what depends from it dynamic --
it depends what paging mode we are booting in. ZS_SIZE_CLASSES depends
indirectly on OBJ_INDEX_BITS and I don't see how struct zs_pool definition
can compile with dynamic ZS_SIZE_CLASSES.
Hm?
--
Kirill A. Shutemov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2.1 24/34] dt-bindings: arm: Convert Rockchip board/soc bindings to json-schema
From: Rob Herring @ 2018-12-10 15:13 UTC (permalink / raw)
To: heiko@sntech.de
Cc: Mark Rutland, devicetree, Kumar Gala, ARM-SoC Maintainers,
Sean Hudson, linuxppc-dev, linux-kernel@vger.kernel.org,
open list:ARM/Rockchip SoC..., Grant Likely, Matthias Brugger,
Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <2386212.ILKoqq0Ivo@phil>
On Sun, Dec 9, 2018 at 4:14 PM Heiko Stuebner <heiko@sntech.de> wrote:
>
> Convert Rockchip SoC bindings to DT schema format using json-schema.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-rockchip@lists.infradead.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> [move to per-board entries and added recently added boards]
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Hi Rob,
>
> there are boards where the description adds much value and on others
> it is maybe less, but personally I'd like to keep things uniform,
> as that makes reading these things easier if the format stays the
> same all the time, so I've gone forward and just did the conversion
>
> make dtbs_check did not complain about the schema it seems but I
> did end up with an error later on:
>
> FATAL ERROR: Unknown output format "yaml"
> make[2]: *** [scripts/Makefile.lib:313: arch/arm/boot/dts/rk3036-evb.dt.yaml] Fehler 1
You need libyaml and its headers installed so dtc can output yaml, but
that's not needed for checking the schema against the meta-schema.
> But I guess I did not mess up the schema yet.
>
> So does it look ok that way?
Yes, but one comment...
> + - description: Firefly Firefly-RK3288
> + items:
> + - const: firefly,firefly-rk3288
> + - const: rockchip,rk3288
> +
> + - description: Firefly Firefly-RK3288 (beta board)
> + items:
> + - const: firefly,firefly-rk3288-beta
> + - const: rockchip,rk3288
> +
> + - description: Firefly Firefly-RK3288 Reload
Seems like combining these 3 (or first 2?) would make sense if this is
just revs of the same board.
But either way is fine.
> + items:
> + - const: firefly,firefly-rk3288-reload
> + - const: rockchip,rk3288
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support
From: Russell King - ARM Linux @ 2018-12-10 15:05 UTC (permalink / raw)
To: Robin Murphy
Cc: Rich Felker, linux-ia64, Sergey Senozhatsky, linux-sh,
James Hogan, Heiko Carstens, linux-kernel, linux-mm, Khalid Aziz,
Paul Mackerras, H . Peter Anvin, sparclinux, Catalin Marinas,
linux-s390, Yoshinori Sato, Michael Ellerman, x86, Will Deacon,
Ingo Molnar, Benjamin Herrenschmidt, Anthony Yznaga, Nitin Gupta,
Fenghua Yu, Joerg Roedel, Rafael David Tinoco, Vasily Gorbik,
Ram Pai, Nicholas Piggin, Borislav Petkov, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Juergen Gross, Tony Luck,
Jiri Kosina, linux-mips, Ralf Baechle, Minchan Kim, Paul Burton,
Christophe Leroy, Aneesh Kumar K . V, Martin Schwidefsky,
linuxppc-dev, David S . Miller, Kirill A . Shutemov
In-Reply-To: <4da655ec-a1ac-c524-1eb4-5cbd18b265ef@arm.com>
On Mon, Dec 10, 2018 at 02:35:55PM +0000, Robin Murphy wrote:
> On 10/12/2018 14:21, Rafael David Tinoco wrote:
> >On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
> >physical frame number might be so big that zsmalloc obj encoding (to
> >location) will break, causing:
> >
> >BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
> >Read of size 4 at addr 00000000 by task mkfs.ext4/623
> >CPU: 2 PID: 623 Comm: mkfs.ext4 Not tainted 4.19.0-rc8-00017-g8239bc6d3307-dirty #15
> >Hardware name: Generic DT based system
> >[<c0418f7c>] (unwind_backtrace) from [<c0410ca4>] (show_stack+0x20/0x24)
> >[<c0410ca4>] (show_stack) from [<c16bd540>] (dump_stack+0xbc/0xe8)
> >[<c16bd540>] (dump_stack) from [<c06cab74>] (kasan_report+0x248/0x390)
> >[<c06cab74>] (kasan_report) from [<c06c94e8>] (__asan_load4+0x78/0xb4)
> >[<c06c94e8>] (__asan_load4) from [<c06ddc24>] (zs_map_object+0xa4/0x2bc)
> >[<c06ddc24>] (zs_map_object) from [<bf0bbbd8>] (zram_bvec_rw.constprop.2+0x324/0x8e4 [zram])
> >[<bf0bbbd8>] (zram_bvec_rw.constprop.2 [zram]) from [<bf0bc3cc>] (zram_make_request+0x234/0x46c [zram])
> >[<bf0bc3cc>] (zram_make_request [zram]) from [<c09aff9c>] (generic_make_request+0x304/0x63c)
> >[<c09aff9c>] (generic_make_request) from [<c09b0320>] (submit_bio+0x4c/0x1c8)
> >[<c09b0320>] (submit_bio) from [<c0743570>] (submit_bh_wbc.constprop.15+0x238/0x26c)
> >[<c0743570>] (submit_bh_wbc.constprop.15) from [<c0746cf8>] (__block_write_full_page+0x524/0x76c)
> >[<c0746cf8>] (__block_write_full_page) from [<c07472c4>] (block_write_full_page+0x1bc/0x1d4)
> >[<c07472c4>] (block_write_full_page) from [<c0748eb4>] (blkdev_writepage+0x24/0x28)
> >[<c0748eb4>] (blkdev_writepage) from [<c064a780>] (__writepage+0x44/0x78)
> >[<c064a780>] (__writepage) from [<c064b50c>] (write_cache_pages+0x3b8/0x800)
> >[<c064b50c>] (write_cache_pages) from [<c064dd78>] (generic_writepages+0x74/0xa0)
> >[<c064dd78>] (generic_writepages) from [<c0748e64>] (blkdev_writepages+0x18/0x1c)
> >[<c0748e64>] (blkdev_writepages) from [<c064e890>] (do_writepages+0x68/0x134)
> >[<c064e890>] (do_writepages) from [<c06368a4>] (__filemap_fdatawrite_range+0xb0/0xf4)
> >[<c06368a4>] (__filemap_fdatawrite_range) from [<c0636b68>] (file_write_and_wait_range+0x64/0xd0)
> >[<c0636b68>] (file_write_and_wait_range) from [<c0747af8>] (blkdev_fsync+0x54/0x84)
> >[<c0747af8>] (blkdev_fsync) from [<c0739dac>] (vfs_fsync_range+0x70/0xd4)
> >[<c0739dac>] (vfs_fsync_range) from [<c0739e98>] (do_fsync+0x4c/0x80)
> >[<c0739e98>] (do_fsync) from [<c073a26c>] (sys_fsync+0x1c/0x20)
> >[<c073a26c>] (sys_fsync) from [<c0401000>] (ret_fast_syscall+0x0/0x2c)
> >
> >when trying to decode (the pfn) and map the object.
> >
> >That happens because one architecture might not re-define
> >MAX_PHYSMEM_BITS, like in this ARM 32-bit w/ LPAE enabled example. For
> >32-bit systems, if not re-defined, MAX_POSSIBLE_PHYSMEM_BITS will
> >default to BITS_PER_LONG (32) in most cases, and, with PAE enabled,
> >_PFN_BITS might be wrong: which may cause obj variable to overflow if
> >frame number is in HIGHMEM and referencing a page above the 4GB
> >watermark.
> >
> >commit 6e00ec00b1a7 ("staging: zsmalloc: calculate MAX_PHYSMEM_BITS if
> >not defined") realized MAX_PHYSMEM_BITS depended on SPARSEMEM headers
> >and "fixed" it by calculating it using BITS_PER_LONG if SPARSEMEM wasn't
> >used, like in the example given above.
> >
> >Systems with potential for PAE exist for a long time and assuming
> >BITS_PER_LONG seems inadequate. Defining MAX_PHYSMEM_BITS looks better,
> >however it is NOT a constant anymore for x86.
> >
> >SO, instead, MAX_POSSIBLE_PHYSMEM_BITS should be defined by every
> >architecture using zsmalloc, together with a sanity check for
> >MAX_POSSIBLE_PHYSMEM_BITS being too big on 32-bit systems.
> >
> >Link: https://bugs.linaro.org/show_bug.cgi?id=3765#c17
> >Signed-off-by: Rafael David Tinoco <rafael.tinoco@linaro.org>
> >---
> > arch/arm/include/asm/pgtable-2level-types.h | 2 ++
> > arch/arm/include/asm/pgtable-3level-types.h | 2 ++
> > arch/arm64/include/asm/pgtable-types.h | 2 ++
> > arch/ia64/include/asm/page.h | 2 ++
> > arch/mips/include/asm/page.h | 2 ++
> > arch/powerpc/include/asm/mmu.h | 2 ++
> > arch/s390/include/asm/page.h | 2 ++
> > arch/sh/include/asm/page.h | 2 ++
> > arch/sparc/include/asm/page_32.h | 2 ++
> > arch/sparc/include/asm/page_64.h | 2 ++
> > arch/x86/include/asm/pgtable-2level_types.h | 2 ++
> > arch/x86/include/asm/pgtable-3level_types.h | 3 +-
> > arch/x86/include/asm/pgtable_64_types.h | 4 +--
> > mm/zsmalloc.c | 35 +++++++++++----------
> > 14 files changed, 45 insertions(+), 19 deletions(-)
> >
> >diff --git a/arch/arm/include/asm/pgtable-2level-types.h b/arch/arm/include/asm/pgtable-2level-types.h
> >index 66cb5b0e89c5..552dba411324 100644
> >--- a/arch/arm/include/asm/pgtable-2level-types.h
> >+++ b/arch/arm/include/asm/pgtable-2level-types.h
> >@@ -64,4 +64,6 @@ typedef pteval_t pgprot_t;
> > #endif /* STRICT_MM_TYPECHECKS */
> >+#define MAX_POSSIBLE_PHYSMEM_BITS 32
> >+
> > #endif /* _ASM_PGTABLE_2LEVEL_TYPES_H */
> >diff --git a/arch/arm/include/asm/pgtable-3level-types.h b/arch/arm/include/asm/pgtable-3level-types.h
> >index 921aa30259c4..664c39e6517c 100644
> >--- a/arch/arm/include/asm/pgtable-3level-types.h
> >+++ b/arch/arm/include/asm/pgtable-3level-types.h
> >@@ -67,4 +67,6 @@ typedef pteval_t pgprot_t;
> > #endif /* STRICT_MM_TYPECHECKS */
> >+#define MAX_POSSIBLE_PHYSMEM_BITS 36
>
> Nit: with LPAE, physical addresses go up to 40 bits, not just 36.
Right, with that set at 40, we get:
#define _PFN_BITS (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)
== 28
#define OBJ_TAG_BITS 1
#define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
== 3
#define ZS_MAX_ZSPAGE_ORDER 2
#define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER)
== 4
#define ZS_MIN_ALLOC_SIZE \
MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
== 4 << 12 >> 3 = 2048
or half-page allocations.
Given this in Documentation/vm/zsmalloc.rst:
On the other hand, if we just use single
(0-order) pages, it would suffer from very high fragmentation --
any object of size PAGE_SIZE/2 or larger would occupy an entire page.
This was one of the major issues with its predecessor (xvmalloc).
It seems that would not be acceptable, so I have to ask whether
using an unsigned long to store PFN + object ID is really acceptable.
Maybe the real solution to this problem is to stop using an
unsigned long to contain both the PFN and object ID?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: uaccess: Implement unsafe accessors
From: Catalin Marinas @ 2018-12-10 14:59 UTC (permalink / raw)
To: Julien Thierry
Cc: Suzuki K Poulose, peterz, will.deacon, linux-kernel, mingo,
james.morse, hpa, linux-arm-kernel
In-Reply-To: <6424e0f6-7755-c19a-5bc4-a70be5839644@arm.com>
On Fri, Dec 07, 2018 at 08:38:11AM +0000, Julien Thierry wrote:
>
>
> On 12/06/2018 06:25 PM, Catalin Marinas wrote:
> > On Mon, Dec 03, 2018 at 01:55:18PM +0000, Julien Thierry wrote:
> > > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > > index 07c3408..cabfcae 100644
> > > --- a/arch/arm64/include/asm/uaccess.h
> > > +++ b/arch/arm64/include/asm/uaccess.h
> > > @@ -233,6 +233,23 @@ static inline void uaccess_enable_not_uao(void)
> > > __uaccess_enable(ARM64_ALT_PAN_NOT_UAO);
> > > }
> > > +#define unsafe_user_region_active uaccess_region_active
> > > +static inline bool uaccess_region_active(void)
> > > +{
> > > + if (system_uses_ttbr0_pan()) {
> > > + u64 ttbr;
> > > +
> > > + ttbr = read_sysreg(ttbr1_el1);
> > > + return ttbr & TTBR_ASID_MASK;
> >
> > Nitpick: could write this in 1-2 lines.
>
> True, I can do that in 1 line.
>
> > > + } else if (cpus_have_const_cap(ARM64_ALT_PAN_NOT_UAO)) {
> > > + return (read_sysreg(sctlr_el1) & SCTLR_EL1_SPAN) ?
> > > + false :
> > > + !read_sysreg_s(SYS_PSTATE_PAN);
> > > + }
> >
> > ARM64_ALT_PAN_NOT_UAO implies ARM64_HAS_PAN which implies SCTLR_EL1.SPAN
> > is 0 at run-time. Is this to cope with the case of being called prior to
> > cpu_enable_pan()?
> >
>
> Yes, the issue I can into is that for cpufeatures, .cpu_enable() callbacks
> are called inside stop_machine() which obviously might_sleep and so attempts
> to check whether user_access is on. But for features that get enabled before
> PAN, the PAN bit will be set.
OK, so the PSTATE.PAN bit only makes sense when SCTLR_EL1.SPAN is 0, IOW
the PAN hardware feature has been enabled. Maybe you could write it
(together with some comment):
} else if (cpus_have_const_cap(ARM64_ALT_PAN_NOT_UAO) &&
!(read_sysreg(sctlr_el1) & SCTLR_EL1_SPAN)) {
/* only if PAN is present and enabled */
return !read_sysreg_s(SYS_PSTATE_PAN)
}
On the cpufeature.c side of things, it seems that we enable the
static_branch before calling the cpu_enable. I wonder whether changing
the order here would help with avoid the SCTLR_EL1 read (not sure what
else it would break; cc'ing Suzuki).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: ufs_qcom_dump_dbg_regs makes the kernel panic
From: Marc Gonzalez @ 2018-12-10 14:57 UTC (permalink / raw)
To: Robin Murphy, Jeffrey Hugo, Vivek Gautam, Bjorn Andersson,
Andy Gross, David Brown
Cc: MSM, Linux ARM
In-Reply-To: <338058cc-b040-3c9a-ec31-d15157535dcc@free.fr>
On 10/12/2018 15:07, Marc Gonzalez wrote:
> On 10/12/2018 14:34, Robin Murphy wrote:
>
>> On 10/12/2018 12:37, Marc Gonzalez wrote:
>>
>>> When the kernel fails to init the UFSHC, it calls ufshcd_print_host_regs()
>>> to help with debugging, which calls the dbg_register_dump hook.
>>>
>>> ufs_qcom_dump_dbg_regs makes the kernel panic:
>>>
>>> [ 3.715634] UFS_DBG_RD_REG_TXUC 000000a0: 00000000 00000000 00000000 00000000
>>> [ 3.722750] UFS_DBG_RD_REG_TXUC 000000b0: 00000001 00000000 00000000 00000004
>>> [ 3.729943] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
>>> [ 3.737000] Modules linked in:
>>> [ 3.744371] CPU: 2 PID: 1 Comm: swapper/0 Tainted: G S 4.20.0-rc4 #16
>>> [ 3.747413] Hardware name: Qualcomm Technologies, Inc. MSM8998 v1 MTP (DT)
>>> [ 3.755295] pstate: 00000005 (nzcv daif -PAN -UAO)
>>> [ 3.761978] pc : __memcpy_fromio+0x68/0x80
>>> [ 3.766718] lr : ufshcd_dump_regs+0x50/0xb0
>>> [ 3.770767] sp : ffff00000807ba00
>>> [ 3.774830] x29: ffff00000807ba00 x28: 00000000fffffffb
>>> [ 3.778344] x27: ffff0000089db068 x26: ffff8000f6e58000
>>> [ 3.783728] x25: 000000000000000e x24: 0000000000000800
>>> [ 3.789023] x23: ffff8000f6e587c8 x22: 0000000000000800
>>> [ 3.794319] x21: ffff000008908368 x20: ffff8000f6e1ab80
>>> [ 3.799615] x19: 000000000000006c x18: ffffffffffffffff
>>> [ 3.804910] x17: 0000000000000000 x16: 0000000000000000
>>> [ 3.810206] x15: ffff000009199648 x14: ffff000089244187
>>> [ 3.815502] x13: ffff000009244195 x12: ffff0000091ab000
>>> [ 3.820797] x11: 0000000005f5e0ff x10: ffff0000091998a0
>>> [ 3.826093] x9 : 0000000000000000 x8 : ffff8000f6e1ac00
>>> [ 3.831389] x7 : 0000000000000000 x6 : 0000000000000068
>>> [ 3.836676] x5 : ffff8000f6e1abe8 x4 : 0000000000000000
>>> [ 3.841971] x3 : ffff00000928c868 x2 : ffff8000f6e1abec
>>> [ 3.847267] x1 : ffff00000928c868 x0 : ffff8000f6e1abe8
>>> [ 3.852567] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
>>> [ 3.857900] Call trace:
>>> [ 3.864473] __memcpy_fromio+0x68/0x80
>>> [ 3.866683] ufs_qcom_dump_dbg_regs+0x1c0/0x370
>>> [ 3.870522] ufshcd_print_host_regs+0x168/0x190
>>> [ 3.874946] ufshcd_init+0xd4c/0xde0
>>> [ 3.879459] ufshcd_pltfrm_init+0x3c8/0x550
>>> [ 3.883264] ufs_qcom_probe+0x24/0x60
>>> [ 3.887188] platform_drv_probe+0x50/0xa0
>>> [ 3.890993] really_probe+0x1f0/0x2a0
>>> [ 3.894983] driver_probe_device+0x58/0x100
>>> [ 3.898628] __driver_attach+0xd4/0xe0
>>> [ 3.902617] bus_for_each_dev+0x74/0xd0
>>> [ 3.906436] driver_attach+0x20/0x30
>>> [ 3.910169] bus_add_driver+0x1ac/0x220
>>> [ 3.913992] driver_register+0x60/0x110
>>> [ 3.917540] __platform_driver_register+0x40/0x50
>>> [ 3.921413] ufs_qcom_pltform_init+0x18/0x20
>>> [ 3.926248] do_one_initcall+0x5c/0x180
>>> [ 3.930593] kernel_init_freeable+0x198/0x244
>>> [ 3.934156] kernel_init+0x10/0x110
>>> [ 3.938629] ret_from_fork+0x10/0x20
>>> [ 3.941940] Code: f2400842 54000100 8b020002 d503201f (39400023)
>>> [ 3.945875] ---[ end trace 2d10f654364744f5 ]---
>>> [ 3.951841] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>>> [ 3.956528] SMP: stopping secondary CPUs
>>> [ 5.005502] SMP: failed to stop secondary CPUs 2,7
>>> [ 5.005648] Kernel Offset: disabled
>>> [ 5.009292] CPU features: 0x2,21802008
>>> [ 5.012676] Memory Limit: none
>>> [ 5.016485] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>>>
>>>
>>> The problem appears to be on this line:
>>>
>>> reg = ufs_qcom_get_debug_reg_offset(host, UFS_DBG_RD_REG_RXUC);
>>> /* reg = 0x800 */
>>> print_fn(hba, reg, 27, "UFS_DBG_RD_REG_RXUC ", priv);
>>>
>>> I'm not sure what's going on, because the driver is supposed to map 0x2500 bytes.
>>> (reg = <0x1da4000 0x2500>;)
>>
>> It is mapped - you're not getting an MMU fault but an external abort,
>> which means the access has been translated and gone out, but the
>> peripheral (or possibly the interconnect in between) didn't like it and
>> sent some kind of decode error back. Given that you're faulting in
>> memcpy_from_io() that's not too surprising - using that on actual device
>> registers (rather than stuff like ioremap()ed SRAM) is generally a bad
>> idea, since you have no control over things like access size and
>> ordering that a typical device is sensitive to.
>
> Thanks Robin, your insight is always so very helpful. I do see that __memcpy_fromio
> reads in chunks of 8-bytes, using __raw_readq.
>
> The weird thing (to me) is that the kernel does not panic when I call
> the debug function a bit later (after sleeping for a second). Feels
> like there is a race somewhere, and the device is not happy if it
> accessed "too soon". The kernel still hangs though, which might be
> worse than a clear-cut panic...
>
>>> Commenting out the last 4 dumps of ufs_qcom_print_hw_debug_reg_all() makes
>>> the panic disappear, but the kernel just hangs after printing UFS_DBG_RD_REG_TXUC
>>
>> I'd recommend fixing the register dump code to use specific read*()
>> accesses of the appropriate sizes for each register.
>
> I don't have documentation for that memory region, but based on the source code,
> I would assume 32-bit registers. I'll try cooking up a small patch.
I applied the following patch:
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 3d4bdfab6c18..1fb74ce012e9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -111,13 +111,16 @@
int ufshcd_dump_regs(struct ufs_hba *hba, size_t offset, size_t len,
const char *prefix)
{
- u8 *regs;
+ u32 *regs;
+ size_t end;
regs = kzalloc(len, GFP_KERNEL);
if (!regs)
return -ENOMEM;
- memcpy_fromio(regs, hba->mmio_base + offset, len);
+ for (end = offset + len; offset < end; offset += 4)
+ regs[offset / 4] = ufshcd_readl(hba, offset);
+
ufshcd_hex_dump(prefix, regs, len);
kfree(regs);
That does seem to fix the "synchronous external abort", as can be
(not) seen in the following log:
[ 12.361219] ufshcd-qcom 1da4000.ufshc: dme-link-startup: error code 1
[ 12.473064] ufshcd-qcom 1da4000.ufshc: dme-link-startup: error code 1
[ 12.585057] ufshcd-qcom 1da4000.ufshc: dme-link-startup: error code 1
[ 12.697058] ufshcd-qcom 1da4000.ufshc: dme-link-startup: error code 1
[ 12.708104] ufshcd-qcom 1da4000.ufshc: link startup failed 1
[ 12.708265] ufshcd-qcom 1da4000.ufshc: UFS Host state=0
[ 12.712980] ufshcd-qcom 1da4000.ufshc: lrb in use=0x0, outstanding reqs=0x0 tasks=0x0
[ 12.717986] ufshcd-qcom 1da4000.ufshc: saved_err=0x0, saved_uic_err=0x0
[ 12.725945] ufshcd-qcom 1da4000.ufshc: Device power mode=1, UIC link state=0
[ 12.732374] ufshcd-qcom 1da4000.ufshc: PM in progress=0, sys. suspended=0
[ 12.739666] ufshcd-qcom 1da4000.ufshc: Auto BKOPS=0, Host self-block=0
[ 12.746331] ufshcd-qcom 1da4000.ufshc: Clk gate=1
[ 12.752722] ufshcd-qcom 1da4000.ufshc: error handling flags=0x0, req. abort count=0
[ 12.757556] ufshcd-qcom 1da4000.ufshc: Host capabilities=0x1587001f, caps=0xf
[ 12.765019] ufshcd-qcom 1da4000.ufshc: quirks=0x0, dev. quirks=0x0
[ 12.772285] ufshcd-qcom 1da4000.ufshc: ufshcd_print_pwr_info:[RX, TX]: gear=[0, 0], lane[0, 0], pwr[INVALID MODE, INVALID MODE], rate = 0
[ 12.778683] host_regs: 00000000: 1587001f 00000000 00000210 00000000
[ 12.790777] host_regs: 00000010: 01000000 00010217 00000000 00000000
[ 12.797209] host_regs: 00000020: 00000000 00000470 00000000 00000000
[ 12.803542] host_regs: 00000030: 00000008 00000001 00000000 00000000
[ 12.809880] host_regs: 00000040: 00000000 00000000 00000000 00000000
[ 12.816213] host_regs: 00000050: 00000000 00000000 00000000 00000000
[ 12.822558] host_regs: 00000060: 00000000 00000000 00000000 00000000
[ 12.828890] host_regs: 00000070: 00000000 00000000 00000000 00000000
[ 12.835237] host_regs: 00000080: 00000000 00000000 00000000 00000000
[ 12.841560] host_regs: 00000090: 00000001 00410000 00000000 00000001
[ 12.847906] ufshcd-qcom 1da4000.ufshc: hba->ufs_version = 0x210, hba->capabilities = 0x1587001f
[ 12.854281] ufshcd-qcom 1da4000.ufshc: hba->outstanding_reqs = 0x0, hba->outstanding_tasks = 0x0
[ 12.862717] ufshcd-qcom 1da4000.ufshc: last_hibern8_exit_tstamp at 0 us, hibern8_exit_cnt = 0
[ 12.871739] ufshcd-qcom 1da4000.ufshc: clk: core_clk, rate: 200000000
[ 12.880105] ufshcd-qcom 1da4000.ufshc: clk: core_clk_unipro, rate: 150000000
[ 12.886540] ufshcd-qcom 1da4000.ufshc: clk: core_clk_ice, rate: 300000000
[ 12.893730] HCI Vendor Specific Registers 00000000: 00000000 00000000 00000000 00000000
[ 12.900359] HCI Vendor Specific Registers 00000010: 00000000 00000000 00000000 00000000
[ 12.908182] HCI Vendor Specific Registers 00000020: 00000000 00000000 00000000 00000000
[ 12.916154] HCI Vendor Specific Registers 00000030: 00000000 00000000 00000000 00000000
[ 12.924310] UFS_UFS_DBG_RD_REG_OCSC 00000000: 00000000 00000000 00000000 00000000
[ 12.932122] UFS_UFS_DBG_RD_REG_OCSC 00000010: 00000000 00000000 00000000 00000000
[ 12.939767] UFS_UFS_DBG_RD_REG_OCSC 00000020: 00000000 00000000 00000000 00000000
[ 12.947225] UFS_UFS_DBG_RD_REG_OCSC 00000030: 00000000 00000000 00000000 00000000
[ 12.954691] UFS_UFS_DBG_RD_REG_OCSC 00000040: 00000000 00000000 00000000 00000000
[ 12.962156] UFS_UFS_DBG_RD_REG_OCSC 00000050: 00000000 00000000 00000000 00000000
[ 12.969632] UFS_UFS_DBG_RD_REG_OCSC 00000060: 00000000 00000000 00000000 00000000
[ 12.977094] UFS_UFS_DBG_RD_REG_OCSC 00000070: 00000000 00000000 00000000 00000000
[ 12.984559] UFS_UFS_DBG_RD_REG_OCSC 00000080: 00000000 00000000 00000000 00000000
[ 12.992017] UFS_UFS_DBG_RD_REG_OCSC 00000090: 00000000 00000000 00000000 00000000
[ 12.999488] UFS_UFS_DBG_RD_REG_OCSC 000000a0: 00000000 00000000 00000000 00000000
[ 13.007073] UFS_UFS_DBG_RD_EDTL_RAM 00000000: 00000000 00000000 00000000 00000000
[ 13.014421] UFS_UFS_DBG_RD_EDTL_RAM 00000010: 00000000 00000000 00000000 00000000
[ 13.021878] UFS_UFS_DBG_RD_EDTL_RAM 00000020: 00000000 00000000 00000000 00000000
[ 13.029346] UFS_UFS_DBG_RD_EDTL_RAM 00000030: 00000000 00000000 00000000 00000000
[ 13.036814] UFS_UFS_DBG_RD_EDTL_RAM 00000040: 00000000 00000000 00000000 00000000
[ 13.044288] UFS_UFS_DBG_RD_EDTL_RAM 00000050: 00000000 00000000 00000000 00000000
[ 13.051746] UFS_UFS_DBG_RD_EDTL_RAM 00000060: 00000000 00000000 00000000 00000000
[ 13.059212] UFS_UFS_DBG_RD_EDTL_RAM 00000070: 00000000 00000000 00000000 00000000
[ 13.067140] UFS_UFS_DBG_RD_DESC_RAM 00000000: 00000000 00000000 00000000 00000000
[ 13.074147] UFS_UFS_DBG_RD_DESC_RAM 00000010: 00000000 00000000 00000000 00000000
[ 13.081606] UFS_UFS_DBG_RD_DESC_RAM 00000020: 00000000 00000000 00000000 00000000
[ 13.089077] UFS_UFS_DBG_RD_DESC_RAM 00000030: 00000000 00000000 00000000 00000000
[ 13.096538] UFS_UFS_DBG_RD_DESC_RAM 00000040: 00000000 00000000 00000000 00000000
[ 13.104007] UFS_UFS_DBG_RD_DESC_RAM 00000050: 00000000 00000000 00000000 00000000
[ 13.111468] UFS_UFS_DBG_RD_DESC_RAM 00000060: 00000000 00000000 00000000 00000000
[ 13.118939] UFS_UFS_DBG_RD_DESC_RAM 00000070: 00000000 00000000 00000000 00000000
[ 13.126398] UFS_UFS_DBG_RD_DESC_RAM 00000080: 00000000 00000000 00000000 00000000
[ 13.133866] UFS_UFS_DBG_RD_DESC_RAM 00000090: 00000000 00000000 00000000 00000000
[ 13.141324] UFS_UFS_DBG_RD_DESC_RAM 000000a0: 00000000 00000000 00000000 00000000
[ 13.148797] UFS_UFS_DBG_RD_DESC_RAM 000000b0: 00000000 00000000 00000000 00000000
[ 13.156258] UFS_UFS_DBG_RD_DESC_RAM 000000c0: 00000000 00000000 00000000 00000000
[ 13.163726] UFS_UFS_DBG_RD_DESC_RAM 000000d0: 00000000 00000000 00000000 00000000
[ 13.171182] UFS_UFS_DBG_RD_DESC_RAM 000000e0: 00000000 00000000 00000000 00000000
[ 13.178654] UFS_UFS_DBG_RD_DESC_RAM 000000f0: 00000000 00000000 00000000 00000000
[ 13.186115] UFS_UFS_DBG_RD_DESC_RAM 00000100: 00000000 00000000 00000000 00000000
[ 13.193588] UFS_UFS_DBG_RD_DESC_RAM 00000110: 00000000 00000000 00000000 00000000
[ 13.201047] UFS_UFS_DBG_RD_DESC_RAM 00000120: 00000000 00000000 00000000 00000000
[ 13.208519] UFS_UFS_DBG_RD_DESC_RAM 00000130: 00000000 00000000 00000000 00000000
[ 13.215982] UFS_UFS_DBG_RD_DESC_RAM 00000140: 00000000 00000000 00000000 00000000
[ 13.223447] UFS_UFS_DBG_RD_DESC_RAM 00000150: 00000000 00000000 00000000 00000000
[ 13.230905] UFS_UFS_DBG_RD_DESC_RAM 00000160: 00000000 00000000 00000000 00000000
[ 13.238373] UFS_UFS_DBG_RD_DESC_RAM 00000170: 00000000 00000000 00000000 00000000
[ 13.245842] UFS_UFS_DBG_RD_DESC_RAM 00000180: 00000000 00000000 00000000 00000000
[ 13.253306] UFS_UFS_DBG_RD_DESC_RAM 00000190: 00000000 00000000 00000000 00000000
[ 13.260765] UFS_UFS_DBG_RD_DESC_RAM 000001a0: 00000000 00000000 00000000 00000000
[ 13.268233] UFS_UFS_DBG_RD_DESC_RAM 000001b0: 00000000 00000000 00000000 00000000
[ 13.275702] UFS_UFS_DBG_RD_DESC_RAM 000001c0: 00000000 00000000 00000000 00000000
[ 13.283174] UFS_UFS_DBG_RD_DESC_RAM 000001d0: 00000000 00000000 00000000 00000000
[ 13.290632] UFS_UFS_DBG_RD_DESC_RAM 000001e0: 00000000 00000000 00000000 00000000
[ 13.298104] UFS_UFS_DBG_RD_DESC_RAM 000001f0: 00000000 00000000 00000000 00000000
[ 13.305802] UFS_UFS_DBG_RD_PRDT_RAM 00000000: 00000000 00000000 00000000 00000000
[ 13.313036] UFS_UFS_DBG_RD_PRDT_RAM 00000010: 00000000 00000000 00000000 00000000
[ 13.320495] UFS_UFS_DBG_RD_PRDT_RAM 00000020: 00000000 00000000 00000000 00000000
[ 13.327959] UFS_UFS_DBG_RD_PRDT_RAM 00000030: 00000000 00000000 00000000 00000000
[ 13.335420] UFS_UFS_DBG_RD_PRDT_RAM 00000040: 00000000 00000000 00000000 00000000
[ 13.342894] UFS_UFS_DBG_RD_PRDT_RAM 00000050: 00000000 00000000 00000000 00000000
[ 13.350352] UFS_UFS_DBG_RD_PRDT_RAM 00000060: 00000000 00000000 00000000 00000000
[ 13.357823] UFS_UFS_DBG_RD_PRDT_RAM 00000070: 00000000 00000000 00000000 00000000
[ 13.365281] UFS_UFS_DBG_RD_PRDT_RAM 00000080: 00000000 00000000 00000000 00000000
[ 13.372747] UFS_UFS_DBG_RD_PRDT_RAM 00000090: 00000000 00000000 00000000 00000000
[ 13.380232] UFS_UFS_DBG_RD_PRDT_RAM 000000a0: 00000000 00000000 00000000 00000000
[ 13.387681] UFS_UFS_DBG_RD_PRDT_RAM 000000b0: 00000000 00000000 00000000 00000000
[ 13.395150] UFS_UFS_DBG_RD_PRDT_RAM 000000c0: 00000000 00000000 00000000 00000000
[ 13.402612] UFS_UFS_DBG_RD_PRDT_RAM 000000d0: 00000000 00000000 00000000 00000000
[ 13.410078] UFS_UFS_DBG_RD_PRDT_RAM 000000e0: 00000000 00000000 00000000 00000000
[ 13.417544] UFS_UFS_DBG_RD_PRDT_RAM 000000f0: 00000000 00000000 00000000 00000000
[ 13.425033] UFS_DBG_RD_REG_UAWM 00000000: 00000000 00000000 00000000 00000000
[ 13.432491] UFS_DBG_RD_REG_UARM 00000000: 00000000 00000000 00000000 00000000
[ 13.439762] UFS_DBG_RD_REG_TXUC 00000000: 00000000 00000000 00000000 00000000
[ 13.446706] UFS_DBG_RD_REG_TXUC 00000010: 00000000 00000000 00000000 00000000
[ 13.453811] UFS_DBG_RD_REG_TXUC 00000020: 00000000 00000000 00000000 00000000
[ 13.460937] UFS_DBG_RD_REG_TXUC 00000030: 00000000 00000000 00000000 00000000
[ 13.468055] UFS_DBG_RD_REG_TXUC 00000040: 00000000 00000000 00000000 00000000
[ 13.475173] UFS_DBG_RD_REG_TXUC 00000050: 00000000 00000000 00000000 00000000
[ 13.482291] UFS_DBG_RD_REG_TXUC 00000060: 00000000 00000000 00000000 00000000
[ 13.489411] UFS_DBG_RD_REG_TXUC 00000070: 00000000 00000000 00000000 00000000
[ 13.496528] UFS_DBG_RD_REG_TXUC 00000080: 00000000 00000000 00000000 00000000
[ 13.503646] UFS_DBG_RD_REG_TXUC 00000090: 00000000 00000000 00000000 00000000
[ 13.510763] UFS_DBG_RD_REG_TXUC 000000a0: 00000000 00000000 00000000 00000000
[ 13.517883] UFS_DBG_RD_REG_TXUC 000000b0: 00000000 00000000 00000000 00000000
[ 13.525099] UFS_DBG_RD_REG_RXUC 00000000: 00000000 00000000 00000000 00000000
[ 13.532119] UFS_DBG_RD_REG_RXUC 00000010: 00000000 00000000 00000000 00000000
[ 13.539237] UFS_DBG_RD_REG_RXUC 00000020: 00000000 00000000 00000000 00000000
[ 13.546356] UFS_DBG_RD_REG_RXUC 00000030: 00000000 00000000 00000000 00000000
[ 13.553474] UFS_DBG_RD_REG_RXUC 00000040: 00000000 00000000 00000000 00000000
[ 13.560591] UFS_DBG_RD_REG_RXUC 00000050: 00000000 00000000 00000000 00000000
[ 13.567706] UFS_DBG_RD_REG_RXUC 00000060: 00000000 00000000 00000000
[ 13.574883] UFS_DBG_RD_REG_DFC 00000000: 00000000 00000000 00000000 00000000
[ 13.581242] UFS_DBG_RD_REG_DFC 00000010: 00000000 00000000 00000000 00000000
[ 13.588283] UFS_DBG_RD_REG_DFC 00000020: 00000000 00000000 00000000 00000000
[ 13.595311] UFS_DBG_RD_REG_DFC 00000030: 00000000 00000000 00000000 00000000
[ 13.602341] UFS_DBG_RD_REG_DFC 00000040: 00000000 00000000 00000000
[ 13.609472] UFS_DBG_RD_REG_TRLUT 00000000: 00000000 00000000 00000000 00000000
[ 13.615365] UFS_DBG_RD_REG_TRLUT 00000010: 00000000 00000000 00000000 00000000
[ 13.622656] UFS_DBG_RD_REG_TRLUT 00000020: 00000000 00000000 00000000 00000000
[ 13.629862] UFS_DBG_RD_REG_TRLUT 00000030: 00000000 00000000 00000000 00000000
[ 13.637066] UFS_DBG_RD_REG_TRLUT 00000040: 00000000 00000000 00000000 00000000
[ 13.644274] UFS_DBG_RD_REG_TRLUT 00000050: 00000000 00000000 00000000 00000000
[ 13.651470] UFS_DBG_RD_REG_TRLUT 00000060: 00000000 00000000 00000000 00000000
[ 13.658676] UFS_DBG_RD_REG_TRLUT 00000070: 00000000 00000000 00000000 00000000
[ 13.665880] UFS_DBG_RD_REG_TRLUT 00000080: 00000000 00000000
[ 13.673097] UFS_DBG_RD_REG_TMRLUT 00000000: 00000000 00000000 00000000 00000000
[ 13.678908] UFS_DBG_RD_REG_TMRLUT 00000010: 00000000 00000000 00000000 00000000
[ 13.685938] UFS_DBG_RD_REG_TMRLUT 00000020: 00000000
[ 13.694307] UFS_TEST_BUS 00000000
[ 13.708230] UNIPRO_TEST_BUS 00000000: 00000000 00000000 00000000 00000000
[ 13.708410] UNIPRO_TEST_BUS 00000010: 00000000 00000000 00000000 00000000
[ 13.714181] UNIPRO_TEST_BUS 00000020: 00000000 00000000 00000000 00000000
[ 13.720950] UNIPRO_TEST_BUS 00000030: 00000000 80808080 80808080 00000000
[ 13.727725] UNIPRO_TEST_BUS 00000040: 00000000 00120002 0020000a 0020000a
[ 13.734485] UNIPRO_TEST_BUS 00000050: 78002800 78002800 00000200 00000200
[ 13.741264] UNIPRO_TEST_BUS 00000060: 201e0002 201e0002 00000002 00000002
[ 13.748035] UNIPRO_TEST_BUS 00000070: 00700001 00000000 00000001 00000001
[ 13.754810] UNIPRO_TEST_BUS 00000080: 00100000 00000100 1010101e 00000200
[ 13.761572] UNIPRO_TEST_BUS 00000090: 00000000 00000007 00000007 0ac0a007
[ 13.768340] UNIPRO_TEST_BUS 000000a0: 00000007 0b516a07 00205700 20000000
[ 13.775118] UNIPRO_TEST_BUS 000000b0: 00000040 00000020 00000040 00000040
[ 13.781892] UNIPRO_TEST_BUS 000000c0: 64fa3fc0 00020002 00000000 00000000
[ 13.788652] UNIPRO_TEST_BUS 000000d0: 00000000 00000000 00010000 b6825540
[ 13.795434] UNIPRO_TEST_BUS 000000e0: b6825540 0fffff82 fe001000 80000000
[ 13.802196] UNIPRO_TEST_BUS 000000f0: 00008000 7fff2000 00000000 128c01f4
[ 13.808965] UNIPRO_TEST_BUS 00000100: 00018160 00000800 00000070 003e1a7c
[ 13.815734] UNIPRO_TEST_BUS 00000110: 00000000 00000000 003e0000 003e0000
[ 13.822516] UNIPRO_TEST_BUS 00000120: 003e0000 003e0000 00000000 00000000
[ 13.829279] UNIPRO_TEST_BUS 00000130: 9f000000 9f000000 9f000000 9f000000
[ 13.836052] UNIPRO_TEST_BUS 00000140: 00000000 00000000 000d3e00 201ff940
[ 13.842821] UNIPRO_TEST_BUS 00000150: 03e00000 03e00000 03e00000 03e00000
[ 13.849595] UNIPRO_TEST_BUS 00000160: 00000000 00000000 00000000 00000000
[ 13.856366] UNIPRO_TEST_BUS 00000170: 00000000 00000000 00000000 00000000
[ 13.863139] UNIPRO_TEST_BUS 00000180: 00000000 00000000 00000000 00000000
[ 13.869900] UNIPRO_TEST_BUS 00000190: 00000000 00000000 00000000 00000000
[ 13.876680] UNIPRO_TEST_BUS 000001a0: 00000000 02006800 000007fe 00000000
[ 13.883450] UNIPRO_TEST_BUS 000001b0: 000007fe 10040000 04000000 00000000
[ 13.890224] UNIPRO_TEST_BUS 000001c0: 00000000 00000000 00600000 00000000
[ 13.896984] UNIPRO_TEST_BUS 000001d0: 00000000 00001e00 000000cf 00000000
[ 13.903767] UNIPRO_TEST_BUS 000001e0: 00000000 80000000 00003800 00000000
[ 13.910527] UNIPRO_TEST_BUS 000001f0: 94000000 01400000 01000000 00120000
[ 13.917304] UNIPRO_TEST_BUS 00000200: 00000000 00000008 00020000 00000208
[ 13.924073] UNIPRO_TEST_BUS 00000210: 80000208 80010000 20000000 00000000
[ 13.930847] UNIPRO_TEST_BUS 00000220: fff00000 06e40001 00008601 00000000
[ 13.937617] UNIPRO_TEST_BUS 00000230: 000ff000 00000000 00000000 00000000
[ 13.944385] UNIPRO_TEST_BUS 00000240: 000e0000 00054000 a8200000 00000104
[ 13.951152] UNIPRO_TEST_BUS 00000250: 03018000 0c000000 0000a2b0 00002001
[ 13.957935] UNIPRO_TEST_BUS 00000260: 00002001 00002001 00002001 00002001
[ 13.964696] UNIPRO_TEST_BUS 00000270: 00002001 00002001 00002001 00000201
[ 13.971469] UNIPRO_TEST_BUS 00000280: 00000201 00000201 00000201 00000000
[ 13.978238] UNIPRO_TEST_BUS 00000290: 00000000 00000000 00000000 00000000
[ 13.985007] UNIPRO_TEST_BUS 000002a0: 00000000 00000000 00000000 00000000
[ 13.991778] UNIPRO_TEST_BUS 000002b0: 00000000 00000000 00000000 00000000
[ 13.998559] UNIPRO_TEST_BUS 000002c0: 00000000 00000000 00000000 00000000
[ 14.005322] UNIPRO_TEST_BUS 000002d0: 00000000 00000000 00000000 00000000
[ 14.012098] UNIPRO_TEST_BUS 000002e0: 00000000 00000000 00000000 00000000
[ 14.018858] UNIPRO_TEST_BUS 000002f0: 00000000 00000000 00000000 00000000
[ 14.025640] UNIPRO_TEST_BUS 00000300: 00000000 00000000 00000000 00000000
[ 14.032400] UNIPRO_TEST_BUS 00000310: 00000000 00000000 00000000 00000000
[ 14.039182] UNIPRO_TEST_BUS 00000320: 00000000 00000000 00000000 00000000
[ 14.045943] UNIPRO_TEST_BUS 00000330: 00000000 00000000 00000000 00000000
[ 14.052722] UNIPRO_TEST_BUS 00000340: 00000000 00000000 00000000 00000000
[ 14.059491] UNIPRO_TEST_BUS 00000350: 00000000 00000000 00000000 00000000
[ 14.066264] UNIPRO_TEST_BUS 00000360: 00000000 00000000 00000000 00000000
[ 14.073033] UNIPRO_TEST_BUS 00000370: 00000000 00000000 00000000 00000000
[ 14.079806] UNIPRO_TEST_BUS 00000380: 00000000 00000000 00000000 00000000
[ 14.086573] UNIPRO_TEST_BUS 00000390: 00000000 00000000 00000000 00000000
[ 14.093342] UNIPRO_TEST_BUS 000003a0: 00000000 00000000 00000000 00000000
[ 14.100111] UNIPRO_TEST_BUS 000003b0: 00000000 00000000 00000000 00000000
[ 14.106892] UNIPRO_TEST_BUS 000003c0: 00000000 00000000 00000000 00000000
[ 14.113652] UNIPRO_TEST_BUS 000003d0: 00000000 00000000 00000000 00000000
[ 14.120429] UNIPRO_TEST_BUS 000003e0: 00000000 00000000 00000000 00000000
[ 14.127197] UNIPRO_TEST_BUS 000003f0: 00000000 00000000 00000000 00000000
[ 14.135960] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: core_clk disabled
[ 14.140789] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: bus_aggr_clk disabled
[ 14.148604] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: iface_clk disabled
[ 14.156687] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: core_clk_unipro disabled
[ 14.164398] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: core_clk_ice disabled
[ 14.172866] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: ref_clk disabled
[ 14.180878] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: tx_lane0_sync_clk disabled
[ 14.188272] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: rx_lane0_sync_clk disabled
[ 14.196958] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: rx_lane1_sync_clk disabled
/*** System hangs here ***/
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v7 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: Miquel Raynal @ 2018-12-10 14:50 UTC (permalink / raw)
To: Liang Yang
Cc: Rob Herring, Hanjie Lin, Victor Wan, Jianxin Pan, Marek Vasut,
Martin Blumenstingl, Richard Weinberger, Neil Armstrong,
Yixun Lan, linux-kernel, Boris Brezillon, Jian Hu, linux-mtd,
Kevin Hilman, Carlo Caione, linux-amlogic, Brian Norris,
David Woodhouse, linux-arm-kernel, Jerome Brunet
In-Reply-To: <79a797c2-f37f-7f7c-e907-2d3c2283ec2d@amlogic.com>
Hi Liang,
Liang Yang <liang.yang@amlogic.com> wrote on Mon, 10 Dec 2018 20:12:39
+0800:
> On 2018/12/10 19:38, Boris Brezillon wrote:
> > On Mon, 10 Dec 2018 19:23:46 +0800
> > Liang Yang <liang.yang@amlogic.com> wrote:
> >
> >>>> + mtd->ecc_stats.failed++;
> >>>> + continue;
> >>>> + }
> >>>> + mtd->ecc_stats.corrected += ECC_ERR_CNT(*info);
> >>>> + bitflips = max_t(u32, bitflips, ECC_ERR_CNT(*info));
> >>>> + }
> >>>
> >>> Are you sure you handle correctly empty pages with bf?
> >>> >> if scramble is enable, i would say yes here.
> >> when scramble is disabled, i am considering how to use the helper
> >> nand_check_erased_ecc_chunk, but it seems that i can't get the ecc
> >> bytes which is caculated by ecc engine.by the way, nfc dma doesn't send
> >> out the ecc parity bytes.
> >
> > Even if the ECC engine is disabled?
> >
> No.
> When ECC engine is disabled, it can read the ecc parity bytes ; but there is another problem that i need to consider how code struct looks better when reading error with ecc opened and then try to raw read.
> Is there a good idea?
When reading with ECC enabled, in case of uncorrectable error you
must re-read without ECC, then check if the page is empty or not with
the core helpers (nand_check_erased_*()).
Is this what you meant?
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 0/8] Introduce on-chip interconnect API
From: Georgi Djakov @ 2018-12-10 14:50 UTC (permalink / raw)
To: Rafael J. Wysocki, Greg Kroah-Hartman, Arnd Bergmann,
Olof Johansson
Cc: Mark Rutland, Doug Anderson, sanjayc, maxime.ripard,
Michael Turquette, daidavid1, bjorn.andersson, Saravana Kannan,
abailon, Lorenzo Pieralisi, Vincent Guittot, seansw, Kevin Hilman,
evgreen, ksitaraman, devicetree@vger.kernel.org, Linux PM,
linux-arm-msm, Andy Gross, Rob Herring, linux-tegra, Linux ARM,
Rafael J. Wysocki, Linux Kernel Mailing List, Amit Kucheria,
Thierry Reding
In-Reply-To: <CAJZ5v0jZMqFwYgnfRz04ELLRk=0U8Uv=acw0t9Azxk_HYL0gSQ@mail.gmail.com>
On 12/10/18 13:00, Rafael J. Wysocki wrote:
> On Mon, Dec 10, 2018 at 11:18 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>
>> Hi Rafael,
>>
>> On 12/10/18 11:04, Rafael J. Wysocki wrote:
>>> On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
>>>>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>>>
>>>>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
>>>>>> graphics, modem). These cores are talking to each other and can generate a
>>>>>> lot of data flowing through the on-chip interconnects. These interconnect
>>>>>> buses could form different topologies such as crossbar, point to point buses,
>>>>>> hierarchical buses or use the network-on-chip concept.
>>>>>>
>>>>>> These buses have been sized usually to handle use cases with high data
>>>>>> throughput but it is not necessary all the time and consume a lot of power.
>>>>>> Furthermore, the priority between masters can vary depending on the running
>>>>>> use case like video playback or CPU intensive tasks.
>>>>>>
>>>>>> Having an API to control the requirement of the system in terms of bandwidth
>>>>>> and QoS, so we can adapt the interconnect configuration to match those by
>>>>>> scaling the frequencies, setting link priority and tuning QoS parameters.
>>>>>> This configuration can be a static, one-time operation done at boot for some
>>>>>> platforms or a dynamic set of operations that happen at run-time.
>>>>>>
>>>>>> This patchset introduce a new API to get the requirement and configure the
>>>>>> interconnect buses across the entire chipset to fit with the current demand.
>>>>>> The API is NOT for changing the performance of the endpoint devices, but only
>>>>>> the interconnect path in between them.
>>>>>
>>>>> For what it's worth, we are ready to land this in Chrome OS. I think
>>>>> this series has been very well discussed and reviewed, hasn't changed
>>>>> much in the last few spins, and is in good enough shape to use as a
>>>>> base for future patches. Georgi's also done a great job reaching out
>>>>> to other SoC vendors, and there appears to be enough consensus that
>>>>> this framework will be usable by more than just Qualcomm. There are
>>>>> also several drivers out on the list trying to add patches to use this
>>>>> framework, with more to come, so it made sense (to us) to get this
>>>>> base framework nailed down. In my experiments this is an important
>>>>> piece of the overall power management story, especially on systems
>>>>> that are mostly idle.
>>>>>
>>>>> I'll continue to track changes to this series and we will ultimately
>>>>> reconcile with whatever happens upstream, but I thought it was worth
>>>>> sending this note to express our "thumbs up" towards this framework.
>>>>
>>>> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
>>>> it to the tree if all looks good.
>>>
>>> I'm honestly not sure if it is ready yet.
>>>
>>> New versions are coming on and on, which may make such an impression,
>>> but we had some discussion on it at the LPC and some serious questions
>>> were asked during it, for instance regarding the DT binding introduced
>>> here. I'm not sure how this particular issue has been addressed here,
>>> for example.
>>
>> There have been no changes in bindings since v4 (other than squashing
>> consumer and provider bindings into a single patch and fixing typos).
>>
>> The last DT comment was on v9 [1] where Rob wanted confirmation from
>> other SoC vendors that this works for them too. And now we have that
>> confirmation and there are patches posted on the list [2].
>
> OK
>
>> The second thing (also discussed at LPC) was about possible cases where
>> some consumer drivers can't calculate how much bandwidth they actually
>> need and how to address that. The proposal was to extend the OPP
>> bindings with one more property, but this is not part of this patchset.
>> It is a future step that needs more discussion on the mailing list. If a
>> driver really needs some bandwidth data now, it should be put into the
>> driver and not in DT. After we have enough consumers, we can discuss
>> again if it makes sense to extract something into DT or not.
>
> That's fine by me.
>
> Admittedly, I have some reservations regarding the extent to which
> this approach will turn out to be useful in practice, but I guess as
> long as there is enough traction, the best way to find out it to try
> and see. :-)
>
> From now on I will assume that this series is going to be applied by Greg.
That was the initial idea, but the problem is that there is a recent
change in the cmd_db API (needed by the sdm845 provider driver), which
is going through arm-soc/qcom/drivers. So either Greg pulls also the
qcom-drivers-for-4.21 tag from Andy or the whole series goes via Olof
and Arnd. Maybe there are other options. I don't have any preference and
don't want to put extra burden on any maintainers, so i am ok with what
they prefer.
Thanks,
Georgi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] arm64: assorted fixes for dcache_by_line_op
From: Robin Murphy @ 2018-12-10 14:50 UTC (permalink / raw)
To: Will Deacon, Ard Biesheuvel
Cc: Suzuki Poulose, Marc Zyngier, Catalin Marinas, linux-kernel,
Dave Martin, linux-arm-kernel
In-Reply-To: <20181207175326.GB11430@edgewater-inn.cambridge.arm.com>
Hi Will,
On 07/12/2018 17:53, Will Deacon wrote:
> Hi Ard,
>
> Cheers for looking at this.
>
> On Thu, Dec 06, 2018 at 04:57:34PM +0100, Ard Biesheuvel wrote:
>> This fixes two issues in dcache_by_line_op: patch #4 fixes the logic
>> that is applied when patching DC CVAP instructions, and patch #5 gets
>> rid of some unintended undefined symbols resulting from incorrect use
>> of conditional GAS directives.
>>
>> Patches #1 to #3 are groundwork for #4.
>>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
>> Cc: Dave Martin <Dave.Martin@arm.com>
>>
>> Ard Biesheuvel (5):
>> arm64/alternative_cb: move callback reference into replacements
>> section
>> arm64/alternative_cb: add nr_alts parameter to callback handlers
>> arm64/alternative_cb: add support for alternative sequences
>> arm64/assembler: use callback to 3-way alt-patch DC CVAP instructions
>> arm64/mm: use string comparisons in dcache_by_line_op
>>
>> arch/arm64/include/asm/alternative.h | 54 +++++++++++---------
>> arch/arm64/include/asm/assembler.h | 17 +++---
>> arch/arm64/include/asm/kvm_mmu.h | 4 +-
>> arch/arm64/kernel/alternative.c | 22 +++++---
>> arch/arm64/kernel/cpu_errata.c | 24 ++++++---
>> arch/arm64/kvm/va_layout.c | 8 +--
>> 6 files changed, 79 insertions(+), 50 deletions(-)
>
> Whilst I can see that this solves the problem, I do wonder whether the
> additional infrastructure is really worth it. Couldn't we just do something
> really simple like the diff below instead?
Given that there's really only one place we expect CVAP to be used, I
reckon we could factor that out beforehand to make life even simpler, as
below.
Robin.
----->8-----
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index 6142402c2eb4..8d88d3f1e90e 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -390,11 +390,7 @@ alternative_else
dc civac, \kaddr
alternative_endif
.elseif (\op == cvap)
-alternative_if ARM64_HAS_DCPOP
sys 3, c7, c12, 1, \kaddr // dc cvap
-alternative_else
- dc cvac, \kaddr
-alternative_endif
.else
dc \op, \kaddr
.endif
diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
index 0c22ede52f90..98b17bee4f9d 100644
--- a/arch/arm64/mm/cache.S
+++ b/arch/arm64/mm/cache.S
@@ -212,6 +212,9 @@ ENDPROC(__dma_clean_area)
* - size - size in question
*/
ENTRY(__clean_dcache_area_pop)
+ alternative_if_not ARM64_HAS_DCPOP
+ b __clean_dcache_area_poc
+ alternative_else_nop_endif
dcache_by_line_op cvap, sy, x0, x1, x2, x3
ret
ENDPIPROC(__clean_dcache_area_pop)
-----8<----
>
> Will
>
> --->8
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index 953208267252..8dea015b6599 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -390,27 +390,38 @@ alternative_endif
> * size: size of the region
> * Corrupts: kaddr, size, tmp1, tmp2
> */
> + .macro __dcache_op_workaround_clean_cache, op, kaddr
> +alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
> + dc \op, \kaddr
> +alternative_else
> + dc civac, \kaddr
> +alternative_endif
> + .endm
> +
> .macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
> dcache_line_size \tmp1, \tmp2
> add \size, \kaddr, \size
> sub \tmp2, \tmp1, #1
> bic \kaddr, \kaddr, \tmp2
> 9998:
> - .if (\op == cvau || \op == cvac)
> -alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
> - dc \op, \kaddr
> -alternative_else
> - dc civac, \kaddr
> -alternative_endif
> - .elseif (\op == cvap)
> + .ifc \op, cvau
> + __dcache_op_workaround_clean_cache \op, \kaddr
> + .else
> + .ifc \op, cvac
> + __dcache_op_workaround_clean_cache \op, \kaddr
> + .else
> + .ifc \op, cvap
> alternative_if ARM64_HAS_DCPOP
> sys 3, c7, c12, 1, \kaddr // dc cvap
> -alternative_else
> - dc cvac, \kaddr
> -alternative_endif
> + b 9996f
> +alternative_else_nop_endif
> + __dcache_op_workaround_clean_cache cvac, \kaddr
> +9996:
> .else
> dc \op, \kaddr
> .endif
> + .endif
> + .endif
> add \kaddr, \kaddr, \tmp1
> cmp \kaddr, \size
> b.lo 9998b
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RESEND PATCH v2] clocksource/arm_arch_timer: fix a lockdep warning
From: Marc Zyngier @ 2018-12-10 14:48 UTC (permalink / raw)
To: Qian Cai, akpm
Cc: mark.rutland, peterz, daniel.lezcano, linux-kernel, longman, tglx,
mingo, linux-arm-kernel
In-Reply-To: <20181210135228.49751-1-cai@lca.pw>
On 10/12/2018 13:52, Qian Cai wrote:
> Booting this Huawei TaiShan 2280 arm64 server generated this lockdep
> warning.
>
> [ 0.000000] lockdep_assert_cpus_held+0x50/0x60
> [ 0.000000] static_key_enable_cpuslocked+0x30/0xe8
> [ 0.000000] arch_timer_check_ool_workaround+0x128/0x2d0
> [ 0.000000] arch_timer_acpi_init+0x274/0x6ac
> [ 0.000000] acpi_table_parse+0x1ac/0x218
> [ 0.000000] __acpi_probe_device_table+0x164/0x1ec
> [ 0.000000] timer_probe+0x1bc/0x254
> [ 0.000000] time_init+0x44/0x98
> [ 0.000000] start_kernel+0x4ec/0x7d4
>
> This is due to the commit cb538267ea1e ("jump_label/lockdep: Assert we hold
> the hotplug lock for _cpuslocked() operations").
>
> Since it is applying a global workaround to all CPUs here, it did not hold
> any CPU locks in this path.
>
> arch_timer_acpi_init
> arch_timer_check_ool_workaround(ate_match_acpi_oem_info, table)
> arch_timer_enable_workaround(wa, local = false)
> for_each_possible_cpu()
> per_cpu()
>
> There is also another path did not have any CPU lock.
>
> time_init
> clocksource_probe
> arch_timer_of_init
> arch_timer_check_ool_workaround(ate_match_dt, np)
> arch_timer_enable_workaround(wa, local = false)
>
> When hot-adding a CPU, it will go with a slightly different route.
>
> arch_timer_starting_cpu
> __arch_timer_setup
> arch_timer_check_ool_workaround(ate_match_local_cap_id, NULL)
> arch_timer_enable_workaround(wa, local = true)
> __this_cpu_write()
>
> Hence, deal with them differently.
>
> Fixes: 450f9689f294 (clocksource/arm_arch_timer: Use
> static_branch_enable_cpuslocked())
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
>
> v2: fix the root cause instead of a workaround.
>
> drivers/clocksource/arm_arch_timer.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 9a7d4dc00b6e..81dca7d31d13 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -492,17 +492,20 @@ void arch_timer_enable_workaround(const struct arch_timer_erratum_workaround *wa
>
> if (local) {
> __this_cpu_write(timer_unstable_counter_workaround, wa);
> +
> + /*
> + * Use the locked version, as we're called from the CPU
> + * hotplug framework. Otherwise, we end-up in
> + * deadlock-land.
> + */
> + static_branch_enable_cpuslocked(&arch_timer_read_ool_enabled);
I have the ugly feeling that it breaks the (equally ugly) big-little
stuff where the boot CPU is affected. In this context, you'd end-up
without the lock being taken and you'll get the same splat.
We could start testing the CPU number, but Peter's approach seem much
more palatable to me.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH v2] clocksource/arm_arch_timer: fix a lockdep warning
From: Peter Zijlstra @ 2018-12-10 14:47 UTC (permalink / raw)
To: Valentin Schneider
Cc: mark.rutland, marc.zyngier, daniel.lezcano, linux-kernel, mingo,
Qian Cai, longman, akpm, tglx, linux-arm-kernel
In-Reply-To: <9303a6cf-24af-2f31-9fbd-8c1ecdd5e4f4@arm.com>
On Mon, Dec 10, 2018 at 02:19:53PM +0000, Valentin Schneider wrote:
> Hi,
>
> On 10/12/2018 14:07, Peter Zijlstra wrote:
> [...]
> > ---
> > kernel/cpu.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/kernel/cpu.c b/kernel/cpu.c
> > index 91d5c38eb7e5..e1ee8caf28b5 100644
> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
> > @@ -313,6 +313,8 @@ void cpus_write_unlock(void)
> >
> > void lockdep_assert_cpus_held(void)
> > {
> > + if (system_state < SYSTEM_RUNNING)
> > + return;
> > percpu_rwsem_assert_held(&cpu_hotplug_lock);
> > }
> >
>
> Kinda hijacking the thread here - is that something we'd want to replace
>
> 40fa3780bac2 ("sched/core: Take the hotplug lock in sched_init_smp()")
>
> with?
>
Possibly; and I have vague memories of other people running into this
same thing too.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 10/24] arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking
From: Catalin Marinas @ 2018-12-10 14:39 UTC (permalink / raw)
To: Julien Thierry
Cc: daniel.thompson, Ard Biesheuvel, marc.zyngier, will.deacon,
linux-kernel, christoffer.dall, james.morse, Oleg Nesterov, joel,
linux-arm-kernel
In-Reply-To: <b8bcfa89-8c57-6e16-1861-9379f6762584@arm.com>
On Thu, Dec 06, 2018 at 09:50:18AM +0000, Julien Thierry wrote:
> On 05/12/18 18:26, Catalin Marinas wrote:
> > On Wed, Dec 05, 2018 at 04:55:54PM +0000, Julien Thierry wrote:
> >> On 04/12/18 17:36, Catalin Marinas wrote:
> >>> On Mon, Nov 12, 2018 at 11:57:01AM +0000, Julien Thierry wrote:
> >>>> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
> >>>> index 24692ed..e0a32e4 100644
> >>>> --- a/arch/arm64/include/asm/irqflags.h
> >>>> +++ b/arch/arm64/include/asm/irqflags.h
> >>>> @@ -18,7 +18,27 @@
> >>>>
> >>>> #ifdef __KERNEL__
> >>>>
> >>>> +#include <asm/alternative.h>
> >>>> +#include <asm/cpufeature.h>
> >>>> #include <asm/ptrace.h>
> >>>> +#include <asm/sysreg.h>
> >>>> +
> >>>> +
> >>>> +/*
> >>>> + * When ICC_PMR_EL1 is used for interrupt masking, only the bit indicating
> >>>> + * whether the normal interrupts are masked is kept along with the daif
> >>>> + * flags.
> >>>> + */
> >>>> +#define ARCH_FLAG_PMR_EN 0x1
> >>>> +
> >>>> +#define MAKE_ARCH_FLAGS(daif, pmr) \
> >>>> + ((daif) | (((pmr) >> GIC_PRIO_STATUS_SHIFT) & ARCH_FLAG_PMR_EN))
> >>>> +
> >>>> +#define ARCH_FLAGS_GET_PMR(flags) \
> >>>> + ((((flags) & ARCH_FLAG_PMR_EN) << GIC_PRIO_STATUS_SHIFT) \
> >>>> + | GIC_PRIO_IRQOFF)
> >>>> +
> >>>> +#define ARCH_FLAGS_GET_DAIF(flags) ((flags) & ~ARCH_FLAG_PMR_EN)
> >>>
> >>> I wonder whether we could just use the PSR_I_BIT here to decide whether
> >>> to set the GIC_PRIO_IRQ{ON,OFF}. We could clear the PSR_I_BIT in
> >>> _restore_daif() with an alternative.
> >>
> >> So, the issue with it is that some contexts might be using PSR.I to
> >> disable interrupts (any contexts with async errors or debug exceptions
> >> disabled, kvm guest entry paths, pseudo-NMIs, ...).
> >>
> >> If any of these contexts calls local_irq_save()/local_irq_restore() or
> >> local_daif_save()/local_daif_restore(), by only relying on PSR_I_BIT to
> >> represent the PMR status, we might end up clearing PSR.I when we shouldn't.
> >>
> >> I'm not sure whether there are no callers of these functions in those
> >> context. But if that is the case, we could simplify things, yes.
> >
> > There are callers of local_daif_save() (3) and local_daif_mask() (7) but
> > do they all need to disable the pseudo-NMIs?
>
> Hmmm, I really think that both of those should be disabling NMIs.
> Otherwise, if we take an NMI, the first thing the el1_irq handler is
> going to do is "enable_da_f()" which could lead to potential issues.
>
> One thing that could be done is:
> - local_daif_save() and local_daif_mask() both mask all daif bits
> (taking care to represent PMR value in the I bit of the saved flags)
> - local_daif_restore() restores da_f as expected and decides values to
> put for PMR and PSR.I as follows:
> * do the da_f restore
> * if PSR.A bit is cleared in the saved flags, then we also do a start_nmi()
>
> However, this would not work with a local_daif_save()/restore() on the
> return path of an NMI because I think it is the only context with NMIs
> "stopped" that can take aborts. I can add a WARN_ON(in_nmi()) for
> local_daif_restore() if that doesn't affect performance too much.
FTR, as we discussed this in the office, the conclusion (IIUC) we got to
was: leave the *_daif_*() functions unchanged, touching all the
corresponding PSTATE bits, but change the arch_local_irq_*() macros to
only touch the PMR when the feature is enabled.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] arm: Convert arm boot_lock to raw
From: Sebastian Andrzej Siewior @ 2018-12-10 14:37 UTC (permalink / raw)
To: Russell King - ARM Linux, Arnd Bergmann, Thomas Gleixner
Cc: linux-arm-msm, Barry Song, linux-samsung-soc, ext Tony Lindgren,
Frank Rowand, Linus Walleij, Patrice CHOTARD, Krzysztof Kozlowski,
David Brown, Chen-Yu Tsai, Kukjin Kim, viresh kumar, Xu Wei,
Manivannan Sadhasivam, Andy Gross, Maxime Ripard, Linux-OMAP,
shiraz hashim, Andreas Färber, Linux ARM, Viresh Kumar
In-Reply-To: <20181209004138.GC9507@n2100.armlinux.org.uk>
On 2018-12-09 00:41:39 [+0000], Russell King - ARM Linux wrote:
> So, really _both_ these things are really really specific to ARM
> development platforms, and have nothing to do with modern production
> hardware.
>
> No one should _ever_ copy the ARM reference platform SMP hotplug
> code. Needing that code is quite simply a sign that the platform is
> quite simply not production hardware.
>
> I really don't get how we've ended up with so many copies of this.
> Maybe the code isn't being properly reviewed? Maybe the process for
> merging new platforms is way too lenient? Whatever, the fact that
> we're ending up with new copies of the pen release and boot lock
> stuff demonstrably illustrates that the review process for new
> platforms is very broken.
Okay. So the whole patch won't get applied, right? If so, may I please
get the
arch/arm/plat-versatile/platsmp.c
hunk applied? The remaining platforms would have then either justify why
they have the same problems like the ARM devel board or rework their
code.
Sebastian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support
From: Robin Murphy @ 2018-12-10 14:35 UTC (permalink / raw)
To: Rafael David Tinoco, Russell King
Cc: Rich Felker, linux-ia64, Sergey Senozhatsky, linux-sh,
James Hogan, Heiko Carstens, linux-kernel, linux-mm, Khalid Aziz,
Paul Mackerras, H . Peter Anvin, sparclinux, Catalin Marinas,
linux-s390, Yoshinori Sato, Michael Ellerman, x86, Will Deacon,
Ingo Molnar, Benjamin Herrenschmidt, Anthony Yznaga, Nitin Gupta,
Fenghua Yu, Joerg Roedel, Vasily Gorbik, Ram Pai, Nicholas Piggin,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Juergen Gross, Tony Luck, Jiri Kosina,
linux-mips, Ralf Baechle, Minchan Kim, Paul Burton,
Christophe Leroy, Aneesh Kumar K . V, Martin Schwidefsky,
linuxppc-dev, David S . Miller, Kirill A . Shutemov
In-Reply-To: <20181210142105.6750-1-rafael.tinoco@linaro.org>
On 10/12/2018 14:21, Rafael David Tinoco wrote:
> On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
> physical frame number might be so big that zsmalloc obj encoding (to
> location) will break, causing:
>
> BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
> Read of size 4 at addr 00000000 by task mkfs.ext4/623
> CPU: 2 PID: 623 Comm: mkfs.ext4 Not tainted 4.19.0-rc8-00017-g8239bc6d3307-dirty #15
> Hardware name: Generic DT based system
> [<c0418f7c>] (unwind_backtrace) from [<c0410ca4>] (show_stack+0x20/0x24)
> [<c0410ca4>] (show_stack) from [<c16bd540>] (dump_stack+0xbc/0xe8)
> [<c16bd540>] (dump_stack) from [<c06cab74>] (kasan_report+0x248/0x390)
> [<c06cab74>] (kasan_report) from [<c06c94e8>] (__asan_load4+0x78/0xb4)
> [<c06c94e8>] (__asan_load4) from [<c06ddc24>] (zs_map_object+0xa4/0x2bc)
> [<c06ddc24>] (zs_map_object) from [<bf0bbbd8>] (zram_bvec_rw.constprop.2+0x324/0x8e4 [zram])
> [<bf0bbbd8>] (zram_bvec_rw.constprop.2 [zram]) from [<bf0bc3cc>] (zram_make_request+0x234/0x46c [zram])
> [<bf0bc3cc>] (zram_make_request [zram]) from [<c09aff9c>] (generic_make_request+0x304/0x63c)
> [<c09aff9c>] (generic_make_request) from [<c09b0320>] (submit_bio+0x4c/0x1c8)
> [<c09b0320>] (submit_bio) from [<c0743570>] (submit_bh_wbc.constprop.15+0x238/0x26c)
> [<c0743570>] (submit_bh_wbc.constprop.15) from [<c0746cf8>] (__block_write_full_page+0x524/0x76c)
> [<c0746cf8>] (__block_write_full_page) from [<c07472c4>] (block_write_full_page+0x1bc/0x1d4)
> [<c07472c4>] (block_write_full_page) from [<c0748eb4>] (blkdev_writepage+0x24/0x28)
> [<c0748eb4>] (blkdev_writepage) from [<c064a780>] (__writepage+0x44/0x78)
> [<c064a780>] (__writepage) from [<c064b50c>] (write_cache_pages+0x3b8/0x800)
> [<c064b50c>] (write_cache_pages) from [<c064dd78>] (generic_writepages+0x74/0xa0)
> [<c064dd78>] (generic_writepages) from [<c0748e64>] (blkdev_writepages+0x18/0x1c)
> [<c0748e64>] (blkdev_writepages) from [<c064e890>] (do_writepages+0x68/0x134)
> [<c064e890>] (do_writepages) from [<c06368a4>] (__filemap_fdatawrite_range+0xb0/0xf4)
> [<c06368a4>] (__filemap_fdatawrite_range) from [<c0636b68>] (file_write_and_wait_range+0x64/0xd0)
> [<c0636b68>] (file_write_and_wait_range) from [<c0747af8>] (blkdev_fsync+0x54/0x84)
> [<c0747af8>] (blkdev_fsync) from [<c0739dac>] (vfs_fsync_range+0x70/0xd4)
> [<c0739dac>] (vfs_fsync_range) from [<c0739e98>] (do_fsync+0x4c/0x80)
> [<c0739e98>] (do_fsync) from [<c073a26c>] (sys_fsync+0x1c/0x20)
> [<c073a26c>] (sys_fsync) from [<c0401000>] (ret_fast_syscall+0x0/0x2c)
>
> when trying to decode (the pfn) and map the object.
>
> That happens because one architecture might not re-define
> MAX_PHYSMEM_BITS, like in this ARM 32-bit w/ LPAE enabled example. For
> 32-bit systems, if not re-defined, MAX_POSSIBLE_PHYSMEM_BITS will
> default to BITS_PER_LONG (32) in most cases, and, with PAE enabled,
> _PFN_BITS might be wrong: which may cause obj variable to overflow if
> frame number is in HIGHMEM and referencing a page above the 4GB
> watermark.
>
> commit 6e00ec00b1a7 ("staging: zsmalloc: calculate MAX_PHYSMEM_BITS if
> not defined") realized MAX_PHYSMEM_BITS depended on SPARSEMEM headers
> and "fixed" it by calculating it using BITS_PER_LONG if SPARSEMEM wasn't
> used, like in the example given above.
>
> Systems with potential for PAE exist for a long time and assuming
> BITS_PER_LONG seems inadequate. Defining MAX_PHYSMEM_BITS looks better,
> however it is NOT a constant anymore for x86.
>
> SO, instead, MAX_POSSIBLE_PHYSMEM_BITS should be defined by every
> architecture using zsmalloc, together with a sanity check for
> MAX_POSSIBLE_PHYSMEM_BITS being too big on 32-bit systems.
>
> Link: https://bugs.linaro.org/show_bug.cgi?id=3765#c17
> Signed-off-by: Rafael David Tinoco <rafael.tinoco@linaro.org>
> ---
> arch/arm/include/asm/pgtable-2level-types.h | 2 ++
> arch/arm/include/asm/pgtable-3level-types.h | 2 ++
> arch/arm64/include/asm/pgtable-types.h | 2 ++
> arch/ia64/include/asm/page.h | 2 ++
> arch/mips/include/asm/page.h | 2 ++
> arch/powerpc/include/asm/mmu.h | 2 ++
> arch/s390/include/asm/page.h | 2 ++
> arch/sh/include/asm/page.h | 2 ++
> arch/sparc/include/asm/page_32.h | 2 ++
> arch/sparc/include/asm/page_64.h | 2 ++
> arch/x86/include/asm/pgtable-2level_types.h | 2 ++
> arch/x86/include/asm/pgtable-3level_types.h | 3 +-
> arch/x86/include/asm/pgtable_64_types.h | 4 +--
> mm/zsmalloc.c | 35 +++++++++++----------
> 14 files changed, 45 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/include/asm/pgtable-2level-types.h b/arch/arm/include/asm/pgtable-2level-types.h
> index 66cb5b0e89c5..552dba411324 100644
> --- a/arch/arm/include/asm/pgtable-2level-types.h
> +++ b/arch/arm/include/asm/pgtable-2level-types.h
> @@ -64,4 +64,6 @@ typedef pteval_t pgprot_t;
>
> #endif /* STRICT_MM_TYPECHECKS */
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS 32
> +
> #endif /* _ASM_PGTABLE_2LEVEL_TYPES_H */
> diff --git a/arch/arm/include/asm/pgtable-3level-types.h b/arch/arm/include/asm/pgtable-3level-types.h
> index 921aa30259c4..664c39e6517c 100644
> --- a/arch/arm/include/asm/pgtable-3level-types.h
> +++ b/arch/arm/include/asm/pgtable-3level-types.h
> @@ -67,4 +67,6 @@ typedef pteval_t pgprot_t;
>
> #endif /* STRICT_MM_TYPECHECKS */
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS 36
Nit: with LPAE, physical addresses go up to 40 bits, not just 36.
Robin.
> +
> #endif /* _ASM_PGTABLE_3LEVEL_TYPES_H */
> diff --git a/arch/arm64/include/asm/pgtable-types.h b/arch/arm64/include/asm/pgtable-types.h
> index 345a072b5856..45c3834eb4c8 100644
> --- a/arch/arm64/include/asm/pgtable-types.h
> +++ b/arch/arm64/include/asm/pgtable-types.h
> @@ -64,4 +64,6 @@ typedef struct { pteval_t pgprot; } pgprot_t;
> #include <asm-generic/5level-fixup.h>
> #endif
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS CONFIG_ARM64_PA_BITS
> +
> #endif /* __ASM_PGTABLE_TYPES_H */
> diff --git a/arch/ia64/include/asm/page.h b/arch/ia64/include/asm/page.h
> index 5798bd2b462c..a3e055979e46 100644
> --- a/arch/ia64/include/asm/page.h
> +++ b/arch/ia64/include/asm/page.h
> @@ -235,4 +235,6 @@ get_order (unsigned long size)
>
> #define __HAVE_ARCH_GATE_AREA 1
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS 50
> +
> #endif /* _ASM_IA64_PAGE_H */
> diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
> index e8cc328fce2d..f6a5dea1a66c 100644
> --- a/arch/mips/include/asm/page.h
> +++ b/arch/mips/include/asm/page.h
> @@ -263,4 +263,6 @@ extern int __virt_addr_valid(const volatile void *kaddr);
> #include <asm-generic/memory_model.h>
> #include <asm-generic/getorder.h>
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS 48
> +
> #endif /* _ASM_PAGE_H */
> diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
> index eb20eb3b8fb0..2ebc1d2d9a5c 100644
> --- a/arch/powerpc/include/asm/mmu.h
> +++ b/arch/powerpc/include/asm/mmu.h
> @@ -324,6 +324,8 @@ static inline u16 get_mm_addr_key(struct mm_struct *mm, unsigned long address)
> #define MAX_PHYSMEM_BITS 46
> #endif
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS MAX_PHYSMEM_BITS
> +
> #ifdef CONFIG_PPC_BOOK3S_64
> #include <asm/book3s/64/mmu.h>
> #else /* CONFIG_PPC_BOOK3S_64 */
> diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h
> index a4d38092530a..8abec1461bf7 100644
> --- a/arch/s390/include/asm/page.h
> +++ b/arch/s390/include/asm/page.h
> @@ -180,4 +180,6 @@ static inline int devmem_is_allowed(unsigned long pfn)
> #include <asm-generic/memory_model.h>
> #include <asm-generic/getorder.h>
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS CONFIG_MAX_PHYSMEM_BITS
> +
> #endif /* _S390_PAGE_H */
> diff --git a/arch/sh/include/asm/page.h b/arch/sh/include/asm/page.h
> index 5eef8be3e59f..40c7e12cf09e 100644
> --- a/arch/sh/include/asm/page.h
> +++ b/arch/sh/include/asm/page.h
> @@ -205,4 +205,6 @@ typedef struct page *pgtable_t;
> #define ARCH_SLAB_MINALIGN 8
> #endif
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS 32
> +
> #endif /* __ASM_SH_PAGE_H */
> diff --git a/arch/sparc/include/asm/page_32.h b/arch/sparc/include/asm/page_32.h
> index b76d59edec8c..14e9ca4659d7 100644
> --- a/arch/sparc/include/asm/page_32.h
> +++ b/arch/sparc/include/asm/page_32.h
> @@ -139,4 +139,6 @@ extern unsigned long pfn_base;
> #include <asm-generic/memory_model.h>
> #include <asm-generic/getorder.h>
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS 32
> +
> #endif /* _SPARC_PAGE_H */
> diff --git a/arch/sparc/include/asm/page_64.h b/arch/sparc/include/asm/page_64.h
> index e80f2d5bf62f..6d6f3654ead1 100644
> --- a/arch/sparc/include/asm/page_64.h
> +++ b/arch/sparc/include/asm/page_64.h
> @@ -163,4 +163,6 @@ extern unsigned long PAGE_OFFSET;
>
> #include <asm-generic/getorder.h>
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS MAX_PHYS_ADDRESS_BITS
> +
> #endif /* _SPARC64_PAGE_H */
> diff --git a/arch/x86/include/asm/pgtable-2level_types.h b/arch/x86/include/asm/pgtable-2level_types.h
> index 6deb6cd236e3..c2eae59e6505 100644
> --- a/arch/x86/include/asm/pgtable-2level_types.h
> +++ b/arch/x86/include/asm/pgtable-2level_types.h
> @@ -38,4 +38,6 @@ typedef union {
> /* This covers all VMSPLIT_* and VMSPLIT_*_OPT variants */
> #define PGD_KERNEL_START (CONFIG_PAGE_OFFSET >> PGDIR_SHIFT)
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS 32
> +
> #endif /* _ASM_X86_PGTABLE_2LEVEL_DEFS_H */
> diff --git a/arch/x86/include/asm/pgtable-3level_types.h b/arch/x86/include/asm/pgtable-3level_types.h
> index 33845d36897c..5fce514a49a0 100644
> --- a/arch/x86/include/asm/pgtable-3level_types.h
> +++ b/arch/x86/include/asm/pgtable-3level_types.h
> @@ -45,7 +45,8 @@ typedef union {
> */
> #define PTRS_PER_PTE 512
>
> -#define MAX_POSSIBLE_PHYSMEM_BITS 36
> #define PGD_KERNEL_START (CONFIG_PAGE_OFFSET >> PGDIR_SHIFT)
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS 36
> +
> #endif /* _ASM_X86_PGTABLE_3LEVEL_DEFS_H */
> diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
> index 84bd9bdc1987..d808cfde3d19 100644
> --- a/arch/x86/include/asm/pgtable_64_types.h
> +++ b/arch/x86/include/asm/pgtable_64_types.h
> @@ -64,8 +64,6 @@ extern unsigned int ptrs_per_p4d;
> #define P4D_SIZE (_AC(1, UL) << P4D_SHIFT)
> #define P4D_MASK (~(P4D_SIZE - 1))
>
> -#define MAX_POSSIBLE_PHYSMEM_BITS 52
> -
> #else /* CONFIG_X86_5LEVEL */
>
> /*
> @@ -154,4 +152,6 @@ extern unsigned int ptrs_per_p4d;
>
> #define PGD_KERNEL_START ((PAGE_SIZE / 2) / sizeof(pgd_t))
>
> +#define MAX_POSSIBLE_PHYSMEM_BITS (pgtable_l5_enabled() ? 52 : 46)
> +
> #endif /* _ASM_X86_PGTABLE_64_DEFS_H */
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 0787d33b80d8..132c20b6fd4f 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -80,23 +80,7 @@
> * as single (unsigned long) handle value.
> *
> * Note that object index <obj_idx> starts from 0.
> - *
> - * This is made more complicated by various memory models and PAE.
> - */
> -
> -#ifndef MAX_POSSIBLE_PHYSMEM_BITS
> -#ifdef MAX_PHYSMEM_BITS
> -#define MAX_POSSIBLE_PHYSMEM_BITS MAX_PHYSMEM_BITS
> -#else
> -/*
> - * If this definition of MAX_PHYSMEM_BITS is used, OBJ_INDEX_BITS will just
> - * be PAGE_SHIFT
> */
> -#define MAX_POSSIBLE_PHYSMEM_BITS BITS_PER_LONG
> -#endif
> -#endif
> -
> -#define _PFN_BITS (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)
>
> /*
> * Memory for allocating for handle keeps object position by
> @@ -116,6 +100,25 @@
> */
> #define OBJ_ALLOCATED_TAG 1
> #define OBJ_TAG_BITS 1
> +
> +/*
> + * MAX_POSSIBLE_PHYSMEM_BITS should be defined by all archs using zsmalloc:
> + * Trying to guess it from MAX_PHYSMEM_BITS, or considering it BITS_PER_LONG,
> + * proved to be wrong by not considering PAE capabilities, or using SPARSEMEM
> + * only headers, leading to bad object encoding due to object index overflow.
> + */
> +#ifndef MAX_POSSIBLE_PHYSMEM_BITS
> + #define MAX_POSSIBLE_PHYSMEM_BITS BITS_PER_LONG
> + #error "MAX_POSSIBLE_PHYSMEM_BITS HAS to be defined by arch using zsmalloc";
> +#else
> + #ifndef CONFIG_64BIT
> + #if (MAX_POSSIBLE_PHYSMEM_BITS >= (BITS_PER_LONG + PAGE_SHIFT - OBJ_TAG_BITS))
> + #error "MAX_POSSIBLE_PHYSMEM_BITS is wrong for this arch";
> + #endif
> + #endif
> +#endif
> +
> +#define _PFN_BITS (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)
> #define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
> #define OBJ_INDEX_MASK ((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC][PATCH 3/3] arm64: elf: Advertise relaxed ABI
From: Vincenzo Frascino @ 2018-12-10 14:30 UTC (permalink / raw)
To: linux-arm-kernel, linux-doc, linux-mm, linux-arch,
linux-kselftest, linux-kernel
Cc: Mark Rutland, Kate Stewart, Catalin Marinas, Will Deacon,
Kostya Serebryany, Chintan Pandya, Shuah Khan, Ingo Molnar,
Jacob Bramley, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
Andrey Konovalov, Ramana Radhakrishnan, Alexander Viro,
Dmitry Vyukov, Greg Kroah-Hartman, Kirill A . Shutemov, Lee Smith,
Andrew Morton, Robin Murphy, Luc Van Oostenryck
In-Reply-To: <20181210143044.12714-1-vincenzo.frascino@arm.com>
On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x hence
the userspace (EL0) is allowed to set a non-zero value in the top
byte but the resulting pointers are not allowed at the user-kernel
syscall ABI boundary.
This patch sets ARM64_AT_FLAGS_SYSCALL_TBI (bit[0]) in the AT_FLAGS
to advertise the relaxation of the ABI to the userspace.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
CC: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
arch/arm64/include/asm/atflags.h | 7 +++++++
arch/arm64/include/asm/elf.h | 5 +++++
arch/arm64/include/uapi/asm/atflags.h | 8 ++++++++
3 files changed, 20 insertions(+)
create mode 100644 arch/arm64/include/asm/atflags.h
create mode 100644 arch/arm64/include/uapi/asm/atflags.h
diff --git a/arch/arm64/include/asm/atflags.h b/arch/arm64/include/asm/atflags.h
new file mode 100644
index 000000000000..b20093d61bf2
--- /dev/null
+++ b/arch/arm64/include/asm/atflags.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_ATFLAGS_H
+#define __ASM_ATFLAGS_H
+
+#include <uapi/asm/atflags.h>
+
+#endif
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 433b9554c6a1..da5a6d310ff4 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -16,6 +16,7 @@
#ifndef __ASM_ELF_H
#define __ASM_ELF_H
+#include <asm/atflags.h>
#include <asm/hwcap.h>
/*
@@ -163,6 +164,10 @@ do { \
NEW_AUX_ENT(AT_IGNORE, 0); \
} while (0)
+/* Platform specific AT_FLAGS */
+#define ELF_AT_FLAGS ARM64_AT_FLAGS_SYSCALL_TBI
+#define COMPAT_ELF_AT_FLAGS 0
+
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
struct linux_binprm;
extern int arch_setup_additional_pages(struct linux_binprm *bprm,
diff --git a/arch/arm64/include/uapi/asm/atflags.h b/arch/arm64/include/uapi/asm/atflags.h
new file mode 100644
index 000000000000..1cf25692ffd6
--- /dev/null
+++ b/arch/arm64/include/uapi/asm/atflags.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __UAPI_ASM_ATFLAGS_H
+#define __UAPI_ASM_ATFLAGS_H
+
+/* Platform specific AT_FLAGS */
+#define ARM64_AT_FLAGS_SYSCALL_TBI (1 << 0)
+
+#endif
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC][PATCH 0/3] arm64 relaxed ABI
From: Vincenzo Frascino @ 2018-12-10 14:30 UTC (permalink / raw)
To: linux-arm-kernel, linux-doc, linux-mm, linux-arch,
linux-kselftest, linux-kernel
Cc: Mark Rutland, Kate Stewart, Catalin Marinas, Will Deacon,
Kostya Serebryany, Chintan Pandya, Shuah Khan, Ingo Molnar,
Jacob Bramley, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
Andrey Konovalov, Ramana Radhakrishnan, Alexander Viro,
Dmitry Vyukov, Greg Kroah-Hartman, Kirill A . Shutemov, Lee Smith,
Andrew Morton, Robin Murphy, Luc Van Oostenryck
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x hence
the userspace (EL0) is allowed to set a non-zero value in the top
byte but the resulting pointers are not allowed at the user-kernel
syscall ABI boundary.
This patchset proposes a relaxation of the ABI and a mechanism to
advertise it to the userspace via an AT_FLAGS.
The rationale behind the choice of AT_FLAGS is that the Unix System V
ABI defines AT_FLAGS as "flags", leaving some degree of freedom in
interpretation.
There are two previous attempts of using AT_FLAGS in the Linux Kernel
for different reasons: the first was more generic and was used to expose
the support for the GNU STACK NX feature [1] and the second was done for
the MIPS architecture and was used to expose the support of "MIPS ABI
Extension for IEEE Std 754 Non-Compliant Interlinking" [2].
Both the changes are currently _not_ merged in mainline.
The only architecture that reserves some of the bits in AT_FLAGS is
currently MIPS, which introduced the concept of platform specific ABI
(psABI) reserving the top-byte [3].
When ARM64_AT_FLAGS_SYSCALL_TBI is set the kernel is advertising
to the userspace that a relaxed ABI is supported hence this type
of pointers are now allowed to be passed to the syscalls when they are
in memory ranges obtained by anonymous mmap() or brk().
The userspace _must_ verify that the flag is set before passing tagged
pointers to the syscalls allowed by this relaxation.
More in general, exposing the ARM64_AT_FLAGS_SYSCALL_TBI flag and mandating
to the software to check that the feature is present, before using the
associated functionality, it provides a degree of control on the decision
of disabling such a feature in future without consequently breaking the
userspace.
The change required a modification of the elf common code, because in Linux
the AT_FLAGS are currently set to zero by default by the kernel.
The newly added flag has been verified on arm64 using the code below.
#include <stdio.h>
#include <stdbool.h>
#include <sys/auxv.h>
#define ARM64_AT_FLAGS_SYSCALL_TBI (1 << 0)
bool arm64_syscall_tbi_is_present(void)
{
unsigned long at_flags = getauxval(AT_FLAGS);
if (at_flags & ARM64_AT_FLAGS_SYSCALL_TBI)
return true;
return false;
}
void main()
{
if (arm64_syscall_tbi_is_present())
printf("ARM64_AT_FLAGS_SYSCALL_TBI is present\n");
}
This patchset should be merged together with [4].
[1] https://patchwork.ozlabs.org/patch/579578/
[2] https://lore.kernel.org/patchwork/cover/618280/
[3] ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/psABI_mips3.0.pdf
[4] https://patchwork.kernel.org/cover/10674351/
ABI References:
---------------
Sco SysV ABI: http://www.sco.com/developers/gabi/2003-12-17/contents.html
PowerPC AUXV: http://openpowerfoundation.org/wp-content/uploads/resources/leabi/content/dbdoclet.50655242_98651.html
AMD64 ABI: https://www.cs.tufts.edu/comp/40-2012f/readings/amd64-abi.pdf
x86 ABI: https://www.uclibc.org/docs/psABI-i386.pdf
MIPS ABI: ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/psABI_mips3.0.pdf
ARM ABI: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf
SPARC ABI: http://math-atlas.sourceforge.net/devel/assembly/abi_sysV_sparc.pdf
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Chintan Pandya <cpandya@codeaurora.org>
Cc: Jacob Bramley <Jacob.Bramley@arm.com>
Cc: Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Lee Smith <Lee.Smith@arm.com>
Cc: Kostya Serebryany <kcc@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
Cc: Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Evgeniy Stepanov <eugenis@google.com>
CC: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Vincenzo Frascino (3):
elf: Make AT_FLAGS arch configurable
arm64: Define Documentation/arm64/elf_at_flags.txt
arm64: elf: Advertise relaxed ABI
Documentation/arm64/elf_at_flags.txt | 111 ++++++++++++++++++++++++++
arch/arm64/include/asm/atflags.h | 7 ++
arch/arm64/include/asm/elf.h | 5 ++
arch/arm64/include/uapi/asm/atflags.h | 8 ++
fs/binfmt_elf.c | 6 +-
fs/binfmt_elf_fdpic.c | 6 +-
fs/compat_binfmt_elf.c | 5 ++
7 files changed, 146 insertions(+), 2 deletions(-)
create mode 100644 Documentation/arm64/elf_at_flags.txt
create mode 100644 arch/arm64/include/asm/atflags.h
create mode 100644 arch/arm64/include/uapi/asm/atflags.h
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC][PATCH 2/3] arm64: Define Documentation/arm64/elf_at_flags.txt
From: Vincenzo Frascino @ 2018-12-10 14:30 UTC (permalink / raw)
To: linux-arm-kernel, linux-doc, linux-mm, linux-arch,
linux-kselftest, linux-kernel
Cc: Mark Rutland, Kate Stewart, Catalin Marinas, Will Deacon,
Kostya Serebryany, Chintan Pandya, Shuah Khan, Ingo Molnar,
Jacob Bramley, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
Andrey Konovalov, Ramana Radhakrishnan, Alexander Viro,
Dmitry Vyukov, Greg Kroah-Hartman, Kirill A . Shutemov, Lee Smith,
Andrew Morton, Robin Murphy, Luc Van Oostenryck
In-Reply-To: <20181210143044.12714-1-vincenzo.frascino@arm.com>
On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x hence
the userspace (EL0) is allowed to set a non-zero value in the
top byte but the resulting pointers are not allowed at the
user-kernel syscall ABI boundary.
With the relaxed ABI proposed through this document, it is now possible
to pass tagged pointers to the syscalls, when these pointers are in
memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap() or brk().
This change in the ABI requires a mechanism to inform the userspace
that such an option is available.
This patch specifies and documents the way on which AT_FLAGS can be
used to advertise this feature to the userspace.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
CC: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
Documentation/arm64/elf_at_flags.txt | 111 +++++++++++++++++++++++++++
1 file changed, 111 insertions(+)
create mode 100644 Documentation/arm64/elf_at_flags.txt
diff --git a/Documentation/arm64/elf_at_flags.txt b/Documentation/arm64/elf_at_flags.txt
new file mode 100644
index 000000000000..153e657c058a
--- /dev/null
+++ b/Documentation/arm64/elf_at_flags.txt
@@ -0,0 +1,111 @@
+ARM64 ELF AT_FLAGS
+==================
+
+This document describes the usage and semantics of AT_FLAGS on arm64.
+
+1. Introduction
+---------------
+
+AT_FLAGS is part of the Auxiliary Vector, contains the flags and it
+is currently set to zero by the kernel on arm64.
+
+The auxiliary vector can be accessed by the userspace using the
+getauxval() API provided by the C library.
+getauxval() returns an unsigned long and when a flag is present in
+the AT_FLAGS, the corresponding bit in the returned value is set to 1.
+
+The AT_FLAGS with a "defined semantic" on arm64 are exposed to the
+userspace via user API (uapi/asm/atflags.h).
+The AT_FLAGS bits with "undefined semantics" are set to zero by default.
+This means that the AT_FLAGS bits to which this document does not assign
+an explicit meaning are to be intended reserved for future use.
+The kernel will populate all such bits with zero until meanings are
+assigned to them. If and when meanings are assigned, it is guaranteed
+that they will not impact the functional operation of existing userspace
+software. Userspace software should ignore any AT_FLAGS bit whose meaning
+is not defined when the software is written.
+
+The userspace software can test for features by acquiring the AT_FLAGS
+entry of the auxiliary vector, and testing whether a relevant flag
+is set.
+
+Example of a userspace test function:
+
+bool feature_x_is_present(void)
+{
+ unsigned long at_flags = getauxval(AT_FLAGS);
+ if (at_flags & FEATURE_X)
+ return true;
+
+ return false;
+}
+
+Where the software relies on a feature advertised by AT_FLAGS, it
+should check that the feature is present before attempting to
+use it.
+
+2. Features exposed via AT_FLAGS
+--------------------------------
+
+bit[0]: ARM64_AT_FLAGS_SYSCALL_TBI
+
+ On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x hence
+ the userspace (EL0) is allowed to set a non-zero value in the top
+ byte but the resulting pointers are not allowed at the user-kernel
+ syscall ABI boundary.
+ When bit[0] is set to 1 the kernel is advertising to the userspace
+ that a relaxed ABI is supported hence this type of pointers are now
+ allowed to be passed to the syscalls, when these pointers are in
+ memory ranges obtained by anonymous (MAP_ANONYMOUS) mmap() or brk().
+ In these cases the tag is preserved as the pointer goes through the
+ kernel. Only when the kernel needs to check if a pointer is coming
+ from userspace (i.e. access_ok()) an untag operation is required.
+
+3. ARM64_AT_FLAGS_SYSCALL_TBI
+-----------------------------
+
+When ARM64_AT_FLAGS_SYSCALL_TBI is enabled every syscalls can accept tagged
+pointers, when these pointers are in memory ranges obtained by an anonymous
+(MAP_ANONYMOUS) mmap() or brk().
+
+A definition of the meaning of tagged pointers on arm64 can be found in:
+Documentation/arm64/tagged-pointers.txt.
+
+When a pointer does not are in a memory range obtained by an anonymous mmap()
+or brk(), this can not be passed to a syscall if it is tagged.
+
+To be more explicit: a syscall can accept pointers whose memory range is
+obtained by a non-anonymous mmap() or brk() if and only if the tag encoded in
+the top-byte is 0x00.
+
+When a new syscall is added, this can accept tagged pointers if and only if
+these pointers are in memory ranges obtained by an anonymous (MAP_ANONYMOUS)
+mmap() or brk(). In all the other cases, the tag encoded in the top-byte is
+expected to be 0x00.
+
+Example of correct usage (pseudo-code) for a userspace application:
+
+bool arm64_syscall_tbi_is_present(void)
+{
+ unsigned long at_flags = getauxval(AT_FLAGS);
+ if (at_flags & ARM64_AT_FLAGS_SYSCALL_TBI)
+ return true;
+
+ return false;
+}
+
+void main(void)
+{
+ char *addr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS, -1, 0);
+
+ /* Check if the relaxed ABI is supported */
+ if (arm64_syscall_tbi_is_present()) {
+ /* Add a tag to the pointer and to the memory */
+ addr = tag_pointer_and_memory(addr);
+ }
+
+ /* Write to memory */
+ strcpy("Hello World\n", addr);
+}
+
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC][PATCH 1/3] elf: Make AT_FLAGS arch configurable
From: Vincenzo Frascino @ 2018-12-10 14:30 UTC (permalink / raw)
To: linux-arm-kernel, linux-doc, linux-mm, linux-arch,
linux-kselftest, linux-kernel
Cc: Mark Rutland, Kate Stewart, Catalin Marinas, Will Deacon,
Kostya Serebryany, Chintan Pandya, Shuah Khan, Ingo Molnar,
Jacob Bramley, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
Andrey Konovalov, Ramana Radhakrishnan, Alexander Viro,
Dmitry Vyukov, Greg Kroah-Hartman, Kirill A . Shutemov, Lee Smith,
Andrew Morton, Robin Murphy, Luc Van Oostenryck
In-Reply-To: <20181210143044.12714-1-vincenzo.frascino@arm.com>
Currently, the AT_FLAGS in the elf auxiliary vector are set to 0
by default by the kernel.
Some architectures might need to expose to the userspace a non-zero
value to advertise some platform specific ABI functionalities.
This patch makes AT_FLAGS configurable by the architectures that
require it.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
CC: Andrey Konovalov <andreyknvl@google.com>
CC: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
fs/binfmt_elf.c | 6 +++++-
fs/binfmt_elf_fdpic.c | 6 +++++-
fs/compat_binfmt_elf.c | 5 +++++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 54207327f98f..9fa20cc4a437 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -86,6 +86,10 @@ static int elf_core_dump(struct coredump_params *cprm);
#define ELF_CORE_EFLAGS 0
#endif
+#ifndef ELF_AT_FLAGS
+#define ELF_AT_FLAGS 0
+#endif
+
#define ELF_PAGESTART(_v) ((_v) & ~(unsigned long)(ELF_MIN_ALIGN-1))
#define ELF_PAGEOFFSET(_v) ((_v) & (ELF_MIN_ALIGN-1))
#define ELF_PAGEALIGN(_v) (((_v) + ELF_MIN_ALIGN - 1) & ~(ELF_MIN_ALIGN - 1))
@@ -251,7 +255,7 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
NEW_AUX_ENT(AT_PHENT, sizeof(struct elf_phdr));
NEW_AUX_ENT(AT_PHNUM, exec->e_phnum);
NEW_AUX_ENT(AT_BASE, interp_load_addr);
- NEW_AUX_ENT(AT_FLAGS, 0);
+ NEW_AUX_ENT(AT_FLAGS, ELF_AT_FLAGS);
NEW_AUX_ENT(AT_ENTRY, exec->e_entry);
NEW_AUX_ENT(AT_UID, from_kuid_munged(cred->user_ns, cred->uid));
NEW_AUX_ENT(AT_EUID, from_kuid_munged(cred->user_ns, cred->euid));
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index b53bb3729ac1..cf1e680a6b88 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -82,6 +82,10 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *,
static int elf_fdpic_core_dump(struct coredump_params *cprm);
#endif
+#ifndef ELF_AT_FLAGS
+#define ELF_AT_FLAGS 0
+#endif
+
static struct linux_binfmt elf_fdpic_format = {
.module = THIS_MODULE,
.load_binary = load_elf_fdpic_binary,
@@ -651,7 +655,7 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
NEW_AUX_ENT(AT_PHENT, sizeof(struct elf_phdr));
NEW_AUX_ENT(AT_PHNUM, exec_params->hdr.e_phnum);
NEW_AUX_ENT(AT_BASE, interp_params->elfhdr_addr);
- NEW_AUX_ENT(AT_FLAGS, 0);
+ NEW_AUX_ENT(AT_FLAGS, ELF_AT_FLAGS);
NEW_AUX_ENT(AT_ENTRY, exec_params->entry_addr);
NEW_AUX_ENT(AT_UID, (elf_addr_t) from_kuid_munged(cred->user_ns, cred->uid));
NEW_AUX_ENT(AT_EUID, (elf_addr_t) from_kuid_munged(cred->user_ns, cred->euid));
diff --git a/fs/compat_binfmt_elf.c b/fs/compat_binfmt_elf.c
index 15f6e96b3bd9..a21cf99701ae 100644
--- a/fs/compat_binfmt_elf.c
+++ b/fs/compat_binfmt_elf.c
@@ -79,6 +79,11 @@
#define ELF_HWCAP2 COMPAT_ELF_HWCAP2
#endif
+#ifdef COMPAT_ELF_AT_FLAGS
+#undef ELF_AT_FLAGS
+#define ELF_AT_FLAGS COMPAT_ELF_AT_FLAGS
+#endif
+
#ifdef COMPAT_ARCH_DLINFO
#undef ARCH_DLINFO
#define ARCH_DLINFO COMPAT_ARCH_DLINFO
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 08/13] arm64: expose user PAC bit positions via ptrace
From: Will Deacon @ 2018-12-10 14:29 UTC (permalink / raw)
To: Richard Henderson
Cc: Mark Rutland, Andrew Jones, Steve Capper, linux-kernel,
Jacob Bramley, Ard Biesheuvel, Marc Zyngier, Catalin Marinas,
Adam Wallis, Suzuki K Poulose, Christoffer Dall,
Kristina Martsenko, Dave P Martin, Cyrill Gorcunov,
Ramana Radhakrishnan, Amit Kachhap, kvmarm, linux-arm-kernel,
Kees Cook
In-Reply-To: <ba48e082-3e47-43bc-77d1-97d741c59284@linaro.org>
On Mon, Dec 10, 2018 at 08:22:06AM -0600, Richard Henderson wrote:
> On 12/10/18 6:03 AM, Catalin Marinas wrote:
> >> However, it won't be too long before someone implements support for
> >> ARMv8.2-LVA, at which point, without changes to mandatory pointer tagging, we
> >> will only have 3 authentication bits: [54:52]. This seems useless and easily
> >> brute-force-able.
> >
> > Such support is already here (about to be queued):
> >
> > https://lore.kernel.org/linux-arm-kernel/20181206225042.11548-1-steve.capper@arm.com/
>
> Thanks for the pointer.
>
> >> Unfortunately, there is no obvious path to making this optional that does not
> >> break compatibility with Documentation/arm64/tagged-pointers.txt.
> >
> > There is also the ARMv8.5 MTE (memory tagging) which relies on tagged
> > pointers.
>
> So it does. I hadn't read through that extension completely before.
>
> > An alternative would be to allow the opt-in to 52-bit VA, leaving it at
> > 48-bit by default. However, it has the problem of changing the PAC size
> > and not being able to return.
>
> Perhaps the opt-in should be at exec time, with ELF flags (or equivalent) on
> the application. Because, as you say, changing the shape of the PAC in the
> middle of execution is in general not possible.
I think we'd still have a potential performance problem with that approach,
since we'd end up having to context-switch TCR.T0SZ, which is permitted to
be cached in a TLB and would therefore force us to introduce TLB
invalidation when context-switching between tasks using 52-bit VAs and tasks
using 48-bit VAs.
There's a chance we could get the architecture tightened here, but it's
not something we've pushed for so far and it depends on what's already been
built.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 08/13] arm64: expose user PAC bit positions via ptrace
From: Richard Henderson @ 2018-12-10 14:22 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Andrew Jones, Steve Capper, Jacob Bramley,
Ard Biesheuvel, Marc Zyngier, linux-kernel, Adam Wallis,
Suzuki K Poulose, Will Deacon, Christoffer Dall,
Kristina Martsenko, Dave P Martin, Cyrill Gorcunov,
Ramana Radhakrishnan, Amit Kachhap, kvmarm, linux-arm-kernel,
Kees Cook
In-Reply-To: <20181210120330.GB4048@arrakis.emea.arm.com>
On 12/10/18 6:03 AM, Catalin Marinas wrote:
>> However, it won't be too long before someone implements support for
>> ARMv8.2-LVA, at which point, without changes to mandatory pointer tagging, we
>> will only have 3 authentication bits: [54:52]. This seems useless and easily
>> brute-force-able.
>
> Such support is already here (about to be queued):
>
> https://lore.kernel.org/linux-arm-kernel/20181206225042.11548-1-steve.capper@arm.com/
Thanks for the pointer.
>> Unfortunately, there is no obvious path to making this optional that does not
>> break compatibility with Documentation/arm64/tagged-pointers.txt.
>
> There is also the ARMv8.5 MTE (memory tagging) which relies on tagged
> pointers.
So it does. I hadn't read through that extension completely before.
> An alternative would be to allow the opt-in to 52-bit VA, leaving it at
> 48-bit by default. However, it has the problem of changing the PAC size
> and not being able to return.
Perhaps the opt-in should be at exec time, with ELF flags (or equivalent) on
the application. Because, as you say, changing the shape of the PAC in the
middle of execution is in general not possible.
It isn't perfect, since old kernels won't fail to exec an application setting
flags that can't be supported. And it requires tooling changes.
r~
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support
From: Rafael David Tinoco @ 2018-12-10 14:21 UTC (permalink / raw)
To: Russell King
Cc: Rich Felker, linux-ia64, Sergey Senozhatsky, linux-sh,
Benjamin Herrenschmidt, Heiko Carstens, Ram Pai, linux-mips,
linux-mm, Khalid Aziz, Paul Mackerras, H . Peter Anvin,
sparclinux, linux-s390, Yoshinori Sato, Michael Ellerman, x86,
Ingo Molnar, Catalin Marinas, James Hogan, Anthony Yznaga,
Nitin Gupta, Fenghua Yu, Joerg Roedel, Rafael David Tinoco,
Juergen Gross, Vasily Gorbik, Will Deacon, Nicholas Piggin,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Christophe Leroy, Tony Luck, Jiri Kosina,
linux-kernel, Ralf Baechle, Minchan Kim, Paul Burton,
Aneesh Kumar K . V, Martin Schwidefsky, linuxppc-dev,
David S . Miller, Kirill A . Shutemov
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break, causing:
BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
Read of size 4 at addr 00000000 by task mkfs.ext4/623
CPU: 2 PID: 623 Comm: mkfs.ext4 Not tainted 4.19.0-rc8-00017-g8239bc6d3307-dirty #15
Hardware name: Generic DT based system
[<c0418f7c>] (unwind_backtrace) from [<c0410ca4>] (show_stack+0x20/0x24)
[<c0410ca4>] (show_stack) from [<c16bd540>] (dump_stack+0xbc/0xe8)
[<c16bd540>] (dump_stack) from [<c06cab74>] (kasan_report+0x248/0x390)
[<c06cab74>] (kasan_report) from [<c06c94e8>] (__asan_load4+0x78/0xb4)
[<c06c94e8>] (__asan_load4) from [<c06ddc24>] (zs_map_object+0xa4/0x2bc)
[<c06ddc24>] (zs_map_object) from [<bf0bbbd8>] (zram_bvec_rw.constprop.2+0x324/0x8e4 [zram])
[<bf0bbbd8>] (zram_bvec_rw.constprop.2 [zram]) from [<bf0bc3cc>] (zram_make_request+0x234/0x46c [zram])
[<bf0bc3cc>] (zram_make_request [zram]) from [<c09aff9c>] (generic_make_request+0x304/0x63c)
[<c09aff9c>] (generic_make_request) from [<c09b0320>] (submit_bio+0x4c/0x1c8)
[<c09b0320>] (submit_bio) from [<c0743570>] (submit_bh_wbc.constprop.15+0x238/0x26c)
[<c0743570>] (submit_bh_wbc.constprop.15) from [<c0746cf8>] (__block_write_full_page+0x524/0x76c)
[<c0746cf8>] (__block_write_full_page) from [<c07472c4>] (block_write_full_page+0x1bc/0x1d4)
[<c07472c4>] (block_write_full_page) from [<c0748eb4>] (blkdev_writepage+0x24/0x28)
[<c0748eb4>] (blkdev_writepage) from [<c064a780>] (__writepage+0x44/0x78)
[<c064a780>] (__writepage) from [<c064b50c>] (write_cache_pages+0x3b8/0x800)
[<c064b50c>] (write_cache_pages) from [<c064dd78>] (generic_writepages+0x74/0xa0)
[<c064dd78>] (generic_writepages) from [<c0748e64>] (blkdev_writepages+0x18/0x1c)
[<c0748e64>] (blkdev_writepages) from [<c064e890>] (do_writepages+0x68/0x134)
[<c064e890>] (do_writepages) from [<c06368a4>] (__filemap_fdatawrite_range+0xb0/0xf4)
[<c06368a4>] (__filemap_fdatawrite_range) from [<c0636b68>] (file_write_and_wait_range+0x64/0xd0)
[<c0636b68>] (file_write_and_wait_range) from [<c0747af8>] (blkdev_fsync+0x54/0x84)
[<c0747af8>] (blkdev_fsync) from [<c0739dac>] (vfs_fsync_range+0x70/0xd4)
[<c0739dac>] (vfs_fsync_range) from [<c0739e98>] (do_fsync+0x4c/0x80)
[<c0739e98>] (do_fsync) from [<c073a26c>] (sys_fsync+0x1c/0x20)
[<c073a26c>] (sys_fsync) from [<c0401000>] (ret_fast_syscall+0x0/0x2c)
when trying to decode (the pfn) and map the object.
That happens because one architecture might not re-define
MAX_PHYSMEM_BITS, like in this ARM 32-bit w/ LPAE enabled example. For
32-bit systems, if not re-defined, MAX_POSSIBLE_PHYSMEM_BITS will
default to BITS_PER_LONG (32) in most cases, and, with PAE enabled,
_PFN_BITS might be wrong: which may cause obj variable to overflow if
frame number is in HIGHMEM and referencing a page above the 4GB
watermark.
commit 6e00ec00b1a7 ("staging: zsmalloc: calculate MAX_PHYSMEM_BITS if
not defined") realized MAX_PHYSMEM_BITS depended on SPARSEMEM headers
and "fixed" it by calculating it using BITS_PER_LONG if SPARSEMEM wasn't
used, like in the example given above.
Systems with potential for PAE exist for a long time and assuming
BITS_PER_LONG seems inadequate. Defining MAX_PHYSMEM_BITS looks better,
however it is NOT a constant anymore for x86.
SO, instead, MAX_POSSIBLE_PHYSMEM_BITS should be defined by every
architecture using zsmalloc, together with a sanity check for
MAX_POSSIBLE_PHYSMEM_BITS being too big on 32-bit systems.
Link: https://bugs.linaro.org/show_bug.cgi?id=3765#c17
Signed-off-by: Rafael David Tinoco <rafael.tinoco@linaro.org>
---
arch/arm/include/asm/pgtable-2level-types.h | 2 ++
arch/arm/include/asm/pgtable-3level-types.h | 2 ++
arch/arm64/include/asm/pgtable-types.h | 2 ++
arch/ia64/include/asm/page.h | 2 ++
arch/mips/include/asm/page.h | 2 ++
arch/powerpc/include/asm/mmu.h | 2 ++
arch/s390/include/asm/page.h | 2 ++
arch/sh/include/asm/page.h | 2 ++
arch/sparc/include/asm/page_32.h | 2 ++
arch/sparc/include/asm/page_64.h | 2 ++
arch/x86/include/asm/pgtable-2level_types.h | 2 ++
arch/x86/include/asm/pgtable-3level_types.h | 3 +-
arch/x86/include/asm/pgtable_64_types.h | 4 +--
mm/zsmalloc.c | 35 +++++++++++----------
14 files changed, 45 insertions(+), 19 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-2level-types.h b/arch/arm/include/asm/pgtable-2level-types.h
index 66cb5b0e89c5..552dba411324 100644
--- a/arch/arm/include/asm/pgtable-2level-types.h
+++ b/arch/arm/include/asm/pgtable-2level-types.h
@@ -64,4 +64,6 @@ typedef pteval_t pgprot_t;
#endif /* STRICT_MM_TYPECHECKS */
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
+
#endif /* _ASM_PGTABLE_2LEVEL_TYPES_H */
diff --git a/arch/arm/include/asm/pgtable-3level-types.h b/arch/arm/include/asm/pgtable-3level-types.h
index 921aa30259c4..664c39e6517c 100644
--- a/arch/arm/include/asm/pgtable-3level-types.h
+++ b/arch/arm/include/asm/pgtable-3level-types.h
@@ -67,4 +67,6 @@ typedef pteval_t pgprot_t;
#endif /* STRICT_MM_TYPECHECKS */
+#define MAX_POSSIBLE_PHYSMEM_BITS 36
+
#endif /* _ASM_PGTABLE_3LEVEL_TYPES_H */
diff --git a/arch/arm64/include/asm/pgtable-types.h b/arch/arm64/include/asm/pgtable-types.h
index 345a072b5856..45c3834eb4c8 100644
--- a/arch/arm64/include/asm/pgtable-types.h
+++ b/arch/arm64/include/asm/pgtable-types.h
@@ -64,4 +64,6 @@ typedef struct { pteval_t pgprot; } pgprot_t;
#include <asm-generic/5level-fixup.h>
#endif
+#define MAX_POSSIBLE_PHYSMEM_BITS CONFIG_ARM64_PA_BITS
+
#endif /* __ASM_PGTABLE_TYPES_H */
diff --git a/arch/ia64/include/asm/page.h b/arch/ia64/include/asm/page.h
index 5798bd2b462c..a3e055979e46 100644
--- a/arch/ia64/include/asm/page.h
+++ b/arch/ia64/include/asm/page.h
@@ -235,4 +235,6 @@ get_order (unsigned long size)
#define __HAVE_ARCH_GATE_AREA 1
+#define MAX_POSSIBLE_PHYSMEM_BITS 50
+
#endif /* _ASM_IA64_PAGE_H */
diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index e8cc328fce2d..f6a5dea1a66c 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -263,4 +263,6 @@ extern int __virt_addr_valid(const volatile void *kaddr);
#include <asm-generic/memory_model.h>
#include <asm-generic/getorder.h>
+#define MAX_POSSIBLE_PHYSMEM_BITS 48
+
#endif /* _ASM_PAGE_H */
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index eb20eb3b8fb0..2ebc1d2d9a5c 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -324,6 +324,8 @@ static inline u16 get_mm_addr_key(struct mm_struct *mm, unsigned long address)
#define MAX_PHYSMEM_BITS 46
#endif
+#define MAX_POSSIBLE_PHYSMEM_BITS MAX_PHYSMEM_BITS
+
#ifdef CONFIG_PPC_BOOK3S_64
#include <asm/book3s/64/mmu.h>
#else /* CONFIG_PPC_BOOK3S_64 */
diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h
index a4d38092530a..8abec1461bf7 100644
--- a/arch/s390/include/asm/page.h
+++ b/arch/s390/include/asm/page.h
@@ -180,4 +180,6 @@ static inline int devmem_is_allowed(unsigned long pfn)
#include <asm-generic/memory_model.h>
#include <asm-generic/getorder.h>
+#define MAX_POSSIBLE_PHYSMEM_BITS CONFIG_MAX_PHYSMEM_BITS
+
#endif /* _S390_PAGE_H */
diff --git a/arch/sh/include/asm/page.h b/arch/sh/include/asm/page.h
index 5eef8be3e59f..40c7e12cf09e 100644
--- a/arch/sh/include/asm/page.h
+++ b/arch/sh/include/asm/page.h
@@ -205,4 +205,6 @@ typedef struct page *pgtable_t;
#define ARCH_SLAB_MINALIGN 8
#endif
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
+
#endif /* __ASM_SH_PAGE_H */
diff --git a/arch/sparc/include/asm/page_32.h b/arch/sparc/include/asm/page_32.h
index b76d59edec8c..14e9ca4659d7 100644
--- a/arch/sparc/include/asm/page_32.h
+++ b/arch/sparc/include/asm/page_32.h
@@ -139,4 +139,6 @@ extern unsigned long pfn_base;
#include <asm-generic/memory_model.h>
#include <asm-generic/getorder.h>
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
+
#endif /* _SPARC_PAGE_H */
diff --git a/arch/sparc/include/asm/page_64.h b/arch/sparc/include/asm/page_64.h
index e80f2d5bf62f..6d6f3654ead1 100644
--- a/arch/sparc/include/asm/page_64.h
+++ b/arch/sparc/include/asm/page_64.h
@@ -163,4 +163,6 @@ extern unsigned long PAGE_OFFSET;
#include <asm-generic/getorder.h>
+#define MAX_POSSIBLE_PHYSMEM_BITS MAX_PHYS_ADDRESS_BITS
+
#endif /* _SPARC64_PAGE_H */
diff --git a/arch/x86/include/asm/pgtable-2level_types.h b/arch/x86/include/asm/pgtable-2level_types.h
index 6deb6cd236e3..c2eae59e6505 100644
--- a/arch/x86/include/asm/pgtable-2level_types.h
+++ b/arch/x86/include/asm/pgtable-2level_types.h
@@ -38,4 +38,6 @@ typedef union {
/* This covers all VMSPLIT_* and VMSPLIT_*_OPT variants */
#define PGD_KERNEL_START (CONFIG_PAGE_OFFSET >> PGDIR_SHIFT)
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
+
#endif /* _ASM_X86_PGTABLE_2LEVEL_DEFS_H */
diff --git a/arch/x86/include/asm/pgtable-3level_types.h b/arch/x86/include/asm/pgtable-3level_types.h
index 33845d36897c..5fce514a49a0 100644
--- a/arch/x86/include/asm/pgtable-3level_types.h
+++ b/arch/x86/include/asm/pgtable-3level_types.h
@@ -45,7 +45,8 @@ typedef union {
*/
#define PTRS_PER_PTE 512
-#define MAX_POSSIBLE_PHYSMEM_BITS 36
#define PGD_KERNEL_START (CONFIG_PAGE_OFFSET >> PGDIR_SHIFT)
+#define MAX_POSSIBLE_PHYSMEM_BITS 36
+
#endif /* _ASM_X86_PGTABLE_3LEVEL_DEFS_H */
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index 84bd9bdc1987..d808cfde3d19 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -64,8 +64,6 @@ extern unsigned int ptrs_per_p4d;
#define P4D_SIZE (_AC(1, UL) << P4D_SHIFT)
#define P4D_MASK (~(P4D_SIZE - 1))
-#define MAX_POSSIBLE_PHYSMEM_BITS 52
-
#else /* CONFIG_X86_5LEVEL */
/*
@@ -154,4 +152,6 @@ extern unsigned int ptrs_per_p4d;
#define PGD_KERNEL_START ((PAGE_SIZE / 2) / sizeof(pgd_t))
+#define MAX_POSSIBLE_PHYSMEM_BITS (pgtable_l5_enabled() ? 52 : 46)
+
#endif /* _ASM_X86_PGTABLE_64_DEFS_H */
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 0787d33b80d8..132c20b6fd4f 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -80,23 +80,7 @@
* as single (unsigned long) handle value.
*
* Note that object index <obj_idx> starts from 0.
- *
- * This is made more complicated by various memory models and PAE.
- */
-
-#ifndef MAX_POSSIBLE_PHYSMEM_BITS
-#ifdef MAX_PHYSMEM_BITS
-#define MAX_POSSIBLE_PHYSMEM_BITS MAX_PHYSMEM_BITS
-#else
-/*
- * If this definition of MAX_PHYSMEM_BITS is used, OBJ_INDEX_BITS will just
- * be PAGE_SHIFT
*/
-#define MAX_POSSIBLE_PHYSMEM_BITS BITS_PER_LONG
-#endif
-#endif
-
-#define _PFN_BITS (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)
/*
* Memory for allocating for handle keeps object position by
@@ -116,6 +100,25 @@
*/
#define OBJ_ALLOCATED_TAG 1
#define OBJ_TAG_BITS 1
+
+/*
+ * MAX_POSSIBLE_PHYSMEM_BITS should be defined by all archs using zsmalloc:
+ * Trying to guess it from MAX_PHYSMEM_BITS, or considering it BITS_PER_LONG,
+ * proved to be wrong by not considering PAE capabilities, or using SPARSEMEM
+ * only headers, leading to bad object encoding due to object index overflow.
+ */
+#ifndef MAX_POSSIBLE_PHYSMEM_BITS
+ #define MAX_POSSIBLE_PHYSMEM_BITS BITS_PER_LONG
+ #error "MAX_POSSIBLE_PHYSMEM_BITS HAS to be defined by arch using zsmalloc";
+#else
+ #ifndef CONFIG_64BIT
+ #if (MAX_POSSIBLE_PHYSMEM_BITS >= (BITS_PER_LONG + PAGE_SHIFT - OBJ_TAG_BITS))
+ #error "MAX_POSSIBLE_PHYSMEM_BITS is wrong for this arch";
+ #endif
+ #endif
+#endif
+
+#define _PFN_BITS (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)
#define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
#define OBJ_INDEX_MASK ((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
--
2.20.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 05/12] KVM: arm64: Implement PV_FEATURES call
From: Steven Price @ 2018-12-10 14:20 UTC (permalink / raw)
To: Mark Rutland
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20181210103943.g5txylpjvfxdolpi@lakrids.cambridge.arm.com>
On 10/12/2018 10:39, Mark Rutland wrote:
> On Wed, Nov 28, 2018 at 02:45:20PM +0000, Steven Price wrote:
>> This provides a mechanism for querying which paravirtualized features
>> are available in this hypervisor.
>>
>> Also add the header file which defines the ABI for the paravirtualized
>> clock features we're about to add.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> arch/arm64/include/asm/pvclock-abi.h | 32 ++++++++++++++++++++++++++++
>> include/kvm/arm_pv.h | 28 ++++++++++++++++++++++++
>> include/linux/arm-smccc.h | 1 +
>> virt/kvm/arm/hypercalls.c | 9 ++++++++
>> 4 files changed, 70 insertions(+)
>> create mode 100644 arch/arm64/include/asm/pvclock-abi.h
>> create mode 100644 include/kvm/arm_pv.h
>>
>> diff --git a/arch/arm64/include/asm/pvclock-abi.h b/arch/arm64/include/asm/pvclock-abi.h
>> new file mode 100644
>> index 000000000000..64ce041c8922
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/pvclock-abi.h
>> @@ -0,0 +1,32 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (C) 2018 Arm Ltd. */
>> +
>> +#ifndef __ASM_PVCLOCK_ABI_H
>> +#define __ASM_PVCLOCK_ABI_H
>> +
>> +#include <kvm/arm_pv.h>
>> +
>> +struct pvclock_vm_time_info {
>> + __le32 revision;
>> + __le32 attributes;
>> + __le64 sequence_number;
>> + __le64 scale_mult;
>> + __le32 shift;
>> + __le32 reserved;
>> + __le64 native_freq;
>> + __le64 pv_freq;
>> + __le64 div_by_pv_freq_mult;
>> +} __packed;
>> +
>> +struct pvclock_vcpu_stolen_time_info {
>> + __le32 revision;
>> + __le32 attributes;
>> + __le64 stolen_time;
>> + /* Structure must be 64 byte aligned, pad to that size */
>> + u8 padding[48];
>> +} __packed;
>> +
>> +#define PV_VM_TIME_NOT_SUPPORTED -1
>> +#define PV_VM_TIME_INVALID_PARAMETERS -2
>
> Could you please add a comment describing that these are defined in ARM
> DEN0057A?
No problem.
>> +
>> +#endif
>> diff --git a/include/kvm/arm_pv.h b/include/kvm/arm_pv.h
>> new file mode 100644
>> index 000000000000..19d2dafff31a
>> --- /dev/null
>> +++ b/include/kvm/arm_pv.h
>> @@ -0,0 +1,28 @@
>> +/* SPDX-License-Identifier: GPL-2.0
>> + * Copyright (C) 2018 Arm Ltd.
>> + */
>> +
>> +#ifndef __KVM_ARM_PV_H
>> +#define __KVM_ARM_PV_H
>> +
>> +#include <linux/arm-smccc.h>
>> +
>> +#define ARM_SMCCC_HV_PV_FEATURES \
>> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
>> + ARM_SMCCC_SMC_64, \
>> + ARM_SMCCC_OWNER_HYP_STANDARD, \
>> + 0x20)
>> +
>> +#define ARM_SMCCC_HV_PV_TIME_LPT \
>> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
>> + ARM_SMCCC_SMC_64, \
>> + ARM_SMCCC_OWNER_HYP_STANDARD, \
>> + 0x21)
>> +
>> +#define ARM_SMCCC_HV_PV_TIME_ST \
>> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
>> + ARM_SMCCC_SMC_64, \
>> + ARM_SMCCC_OWNER_HYP_STANDARD, \
>> + 0x22)
>> +
>> +#endif /* __KVM_ARM_PV_H */
>
> Do these need to live in a separate header, away from the struct
> definitions?
>
> I'd be happy for these to live in <linux/arm-smccc.h>, given they're
> standard calls.
I'll move them to linux/arm-smccc.h - I didn't want to place them in
pvclock-abi.h as it seemed wrong to pull that into the generic SMCCC
code which doesn't care about these structures.
> As before, a comment referring to ARM DEN0057A would be nice.
Will add
>> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
>> index b047009e7a0a..4e0866cc48c0 100644
>> --- a/include/linux/arm-smccc.h
>> +++ b/include/linux/arm-smccc.h
>> @@ -54,6 +54,7 @@
>> #define ARM_SMCCC_OWNER_SIP 2
>> #define ARM_SMCCC_OWNER_OEM 3
>> #define ARM_SMCCC_OWNER_STANDARD 4
>> +#define ARM_SMCCC_OWNER_HYP_STANDARD 5
>
> Minor nit, but could we make that STANDARD_HYP?
Sure
>> #define ARM_SMCCC_OWNER_TRUSTED_APP 48
>> #define ARM_SMCCC_OWNER_TRUSTED_APP_END 49
>> #define ARM_SMCCC_OWNER_TRUSTED_OS 50
>> diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c
>> index 153aa7642100..ba13b798f0f8 100644
>> --- a/virt/kvm/arm/hypercalls.c
>> +++ b/virt/kvm/arm/hypercalls.c
>> @@ -5,6 +5,7 @@
>> #include <linux/kvm_host.h>
>>
>> #include <asm/kvm_emulate.h>
>> +#include <asm/pvclock-abi.h>
>>
>> #include <kvm/arm_hypercalls.h>
>> #include <kvm/arm_psci.h>
>> @@ -40,6 +41,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
>> break;
>> }
>> break;
>> + case ARM_SMCCC_HV_PV_FEATURES:
>> + val = SMCCC_RET_SUCCESS;
>> + break;
>> + }
>> + break;
>> + case ARM_SMCCC_HV_PV_FEATURES:
>> + feature = smccc_get_arg1(vcpu);
>> + switch (feature) {
>> }
>
> IIUC, at this point in time, this happens to always return
> SMCCC_RET_NOT_SUPPORTED.
Yes, this is because on an oddity in the specification that I'm tempted
to ignore. I originally had PV_FEATURES (only) in the switch in this
patch. However the specification states:
If PV_func_id identifies PV_FEATURES this function can return:
• NOT_SUPPORTED (-1) to indicate that all functions in this
specification are not supported.
• SUCCESS (0) to indicate that one or more
paravirtualization functions are supported.
Since by this patch we haven't reached "one or more" functions a strict
reading of the specification says that even PV_FEATURES should be
returning NOT_SUPPORTED.
> If you leave this part out of the patch, and add it as required, this
> patch is purely adding definitions, which would be a bit nicer for
> review.
Before getting lost in the above wording the specification I had tried
to make the LPT and stolen time patches not dependent on each other.
Given your other comments (in reply to the cover letter), I think I'll
merge this chunk with the first stolen time patch and put all the stolen
time patches first.
Thanks,
Steve
> Thanks,
> Mark.
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH v2] clocksource/arm_arch_timer: fix a lockdep warning
From: Valentin Schneider @ 2018-12-10 14:19 UTC (permalink / raw)
To: Peter Zijlstra, Qian Cai
Cc: mark.rutland, marc.zyngier, daniel.lezcano, linux-kernel, mingo,
longman, akpm, tglx, linux-arm-kernel
In-Reply-To: <20181210140703.GM5289@hirez.programming.kicks-ass.net>
Hi,
On 10/12/2018 14:07, Peter Zijlstra wrote:
[...]
> ---
> kernel/cpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 91d5c38eb7e5..e1ee8caf28b5 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -313,6 +313,8 @@ void cpus_write_unlock(void)
>
> void lockdep_assert_cpus_held(void)
> {
> + if (system_state < SYSTEM_RUNNING)
> + return;
> percpu_rwsem_assert_held(&cpu_hotplug_lock);
> }
>
Kinda hijacking the thread here - is that something we'd want to replace
40fa3780bac2 ("sched/core: Take the hotplug lock in sched_init_smp()")
with?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: Enable NXP pcf85363 rtc
From: Biju Das @ 2018-12-10 14:05 UTC (permalink / raw)
To: Simon Horman
Cc: Stefan Wahren, Fabrizio Castro, Chris Paterson, Alexandre Torgue,
Arnd Bergmann, Tony Lindgren, Russell King, Stefan Agner,
Biju Das, linux-renesas-soc, Simon Horman, Olof Johansson,
Geert Uytterhoeven, linux-arm-kernel, Marek Szyprowski
The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase
hardware support enable the driver in the multi_v7_defconfig
multiplatform configuration.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index f29f49a..7762815 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -826,6 +826,7 @@ CONFIG_RTC_DRV_MAX8997=m
CONFIG_RTC_DRV_MAX77686=y
CONFIG_RTC_DRV_RK808=m
CONFIG_RTC_DRV_RS5C372=m
+CONFIG_RTC_DRV_PCF85363=m
CONFIG_RTC_DRV_BQ32K=m
CONFIG_RTC_DRV_TWL4030=y
CONFIG_RTC_DRV_PALMAS=y
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox