* Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()
From: Rafael J. Wysocki @ 2018-02-21 13:25 UTC (permalink / raw)
To: Michael Ellerman
Cc: Rafael J. Wysocki, Viresh Kumar, Shilpasri G Bhat,
Rafael J. Wysocki, Linux PM, Linux Kernel Mailing List,
linuxppc-dev
In-Reply-To: <87vaeqqye8.fsf@concordia.ellerman.id.au>
On Wed, Feb 21, 2018 at 2:13 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> "Rafael J. Wysocki" <rafael@kernel.org> writes:
>
>> On Wed, Feb 21, 2018 at 6:54 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>> On 21-02-18, 16:39, Michael Ellerman wrote:
>>>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>>
>>>> > AFAICT, you will get -1 here only if the freq table had no valid
>>>> > frequencies (or the freq table is empty). Why would that happen ?
>>>>
>>>> Bugs?
>>>
>>> The cupfreq driver shouldn't have registered itself in that case (i.e.
>>> if the cpufreq table is empty).
>>
>> To be precise, ->init() should fail as that's where the table is
>> created. The registration fails as a result then.
>>
>> But what if the bug is that ->init() doesn't fail when it should?
>>
>> I guess the core could double check the frequency table after ->init()
>> if ->target_index is not NULL.
>>
>> The overall point here is that if you get a negative index in
>> ->fast_switch(), that's way too late anyway and we should be able to
>> catch that error much earlier.
>
> OK.
>
> Still it's one thing for the driver to print a warning and bail out,
> it's another to access off the front of an array and keep running using
> some junk values, or oops (though not in this case because the array
> happens to be static).
Well, let me rephrase. If ->fast_switch() runs, then it must not be
possible to get a negative index in it. That has to be guaranteed by
the core.
^ permalink raw reply
* Re: [PATCH v3] watchdog: add SPDX identifiers for watchdog subsystem
From: Johannes Thumshirn @ 2018-02-21 13:31 UTC (permalink / raw)
To: Marcus Folkesson
Cc: Wim Van Sebroeck, Guenter Roeck, Joel Stanley, Nicolas Ferre,
Alexandre Belloni, Eric Anholt, Stefan Wahren, Florian Fainelli,
Ray Jui, Scott Branden, bcm-kernel-feedback-list, Linus Walleij,
Support Opensource, Baruch Siach, William Breathitt Gray,
Jimmy Vance, Keguang Zhang, Joachim Eastwood, Tomas Winkler,
Andreas Werner, Carlo Caione, Kevin Hilman, Matthias Brugger,
Wan ZongShun, Michal Simek, Vladimir Zapolskiy, Sylvain Lemieux,
Kukjin Kim, Krzysztof Kozlowski, Zwane Mwaikambo, Jim Cromie,
Barry Song, Patrice Chotard, Maxime Ripard, Chen-Yu Tsai,
Marc Gonzalez, Mans Rullgard, Thierry Reding, Jonathan Hunter,
Masahiro Yamada, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Jun Nie, Baoyou Xie, Shawn Guo, linux-watchdog,
linux-kernel, linux-arm-kernel, linux-rpi-kernel,
adi-buildroot-devel, linux-mips, linux-amlogic, linux-mediatek,
linux-samsung-soc, linux-tegra, linuxppc-dev, patches
In-Reply-To: <20180221122744.28300-1-marcus.folkesson@gmail.com>
On Wed, Feb 21, 2018 at 01:27:34PM +0100, Marcus Folkesson wrote:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
> license
[...]
> drivers/watchdog/mena21_wdt.c | 4 +--
Acked-by: Johannes Thumshirn <jth@kernel.org>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [RFC PATCH v0 1/2] powerpc, drmem: Fix unexpected flag value in ibm, dynamic-memory-v2
From: Bharata B Rao @ 2018-02-21 13:36 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, nfont, mwb
In-Reply-To: <87zi42r2bh.fsf@concordia.ellerman.id.au>
On Wed, Feb 21, 2018 at 10:48:18PM +1100, Michael Ellerman wrote:
> Bharata B Rao <bharata@linux.vnet.ibm.com> writes:
>
> > Memory addtion and removal by count and indexed-count methods
> > temporarily mark the LMBs that are being added/removed by a special
> > flag value DRMEM_LMB_RESERVED. Accessing flags value directly at
> > a few places without proper accessor method is causing two unexpected
> > side-effects:
> >
> > - DRMEM_LMB_RESERVED bit is becoming part of the flags word of
> > drconf_cell_v2 entries in ibm,dynamic-memory-v2 DT property.
> > - This results in extra drconf_cell entries in ibm,dynamic-memory-v2.
> > For example if 1G memory is added, it leads to one entry for 3 LMBs
> > and 1 separate entry for the last LMB. All the 4 LMBs should be
> > defined by one entry here.
> >
> > Fix this by always accessing the flags by its accessor method
> > drmem_lmb_flags().
> >
> > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
>
> Presumably:
>
> Fixes: 2b31e3aec1db ("powerpc/drmem: Add support for ibm, dynamic-memory-v2 property")
Yes.
Regards,
Bharata.
^ permalink raw reply
* RE: [PATCH v3] watchdog: add SPDX identifiers for watchdog subsystem
From: Winkler, Tomas @ 2018-02-21 13:39 UTC (permalink / raw)
To: Marcus Folkesson, Wim Van Sebroeck, Guenter Roeck, Joel Stanley,
Nicolas Ferre, Alexandre Belloni, Eric Anholt, Stefan Wahren,
Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list@broadcom.com, Linus Walleij,
Support Opensource, Baruch Siach, William Breathitt Gray,
Jimmy Vance, Keguang Zhang, Joachim Eastwood, Johannes Thumshirn,
Andreas Werner, Carlo Caione, Kevin Hilman, Matthias Brugger,
Wan ZongShun, Michal Simek, Vladimir Zapolskiy, Sylvain Lemieux,
Kukjin Kim, Krzysztof Kozlowski, Zwane Mwaikambo, Jim Cromie,
Barry Song, Patrice Chotard, Maxime Ripard, Chen-Yu Tsai,
Marc Gonzalez, Mans Rullgard, Thierry Reding, Jonathan Hunter,
Masahiro Yamada, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Jun Nie, Baoyou Xie, Shawn Guo
Cc: linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org,
adi-buildroot-devel@lists.sourceforge.net,
linux-mips@linux-mips.org, linux-amlogic@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, patches@opensource.cirrus.com
In-Reply-To: <20180221122744.28300-1-marcus.folkesson@gmail.com>
PiANCj4gLSBBZGQgU1BEWCBpZGVudGlmaWVyDQo+IC0gUmVtb3ZlIGJvaWxlciBwbGF0ZSBsaWNl
bnNlIHRleHQNCj4gLSBJZiBNT0RVTEVfTElDRU5TRSBhbmQgYm9pbGVyIHBsYXRlIGRvZXMgbm90
IG1hdGNoLCBnbyBmb3IgYm9pbGVyIHBsYXRlDQo+ICAgbGljZW5zZQ0KPiANCj4gU2lnbmVkLW9m
Zi1ieTogTWFyY3VzIEZvbGtlc3NvbiA8bWFyY3VzLmZvbGtlc3NvbkBnbWFpbC5jb20+DQo+IEFj
a2VkLWJ5OiBBZGFtIFRob21zb24gPEFkYW0uVGhvbXNvbi5PcGVuc291cmNlQGRpYXNlbWkuY29t
Pg0KPiBBY2tlZC1ieTogQ2hhcmxlcyBLZWVwYXggPGNrZWVwYXhAb3BlbnNvdXJjZS5jaXJydXMu
Y29tPg0KPiBBY2tlZC1ieTogTWFucyBSdWxsZ2FyZCA8bWFuc0BtYW5zci5jb20+DQo+IEFja2Vk
LWJ5OiBNYXR0aGlhcyBCcnVnZ2VyIDxtYXR0aGlhcy5iZ2dAZ21haWwuY29tPg0KPiBBY2tlZC1i
eTogTWljaGFsIFNpbWVrIDxtaWNoYWwuc2ltZWtAeGlsaW54LmNvbT4NCj4gQWNrZWQtYnk6IE5l
aWwgQXJtc3Ryb25nIDxuYXJtc3Ryb25nQGJheWxpYnJlLmNvbT4NCj4gQWNrZWQtYnk6IE5pY29s
YXMgRmVycmUgPG5pY29sYXMuZmVycmVAbWljcm9jaGlwLmNvbT4NCj4gQWNrZWQtYnk6IFRoaWVy
cnkgUmVkaW5nIDx0cmVkaW5nQG52aWRpYS5jb20+DQo+IFJldmlld2VkLWJ5OiBFcmljIEFuaG9s
dCA8ZXJpY0BhbmhvbHQubmV0Pg0KPiAtLS0NCj4gDQo+IE5vdGVzOg0KPiAgICAgdjM6DQo+ICAg
ICAJLSBLZWVwIGxpY2Vuc2UgdGV4dCBmb3IgZWJjLWMzODRfd2R0DQo+ICAgICB2MjoNCj4gICAg
IAktIFB1dCBiYWNrIHJlbW92ZWQgY29weXJpZ2h0IHRleHRzIGZvciBtZXNvbl9neGJiX3dkdCBh
bmQNCj4gY29oOTAxMzI3X3dkdA0KPiAgICAgCS0gQ2hhbmdlIHRvIEJTRC0zLUNsYXVzZSBmb3Ig
bWVzb25fZ3hiYl93ZHQNCj4gICAgIHYxOiBQbGVhc2UgaGF2ZSBhbiBleHRyYSBsb29rIGF0IG1l
c29uX2d4YmJfd2R0LmMNCj4gDQo+ICAgKg0KPiAtICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29m
dHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkgaXQNCj4gLSAqIHVu
ZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAy
IGFzIHB1Ymxpc2hlZA0KPiAtICogYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCj4g
ICAqDQo+IA0KDQo+ICAjaW5jbHVkZSA8bGludXgvZXJyLmg+DQo+IGRpZmYgLS1naXQgYS9kcml2
ZXJzL3dhdGNoZG9nL21laV93ZHQuYyBiL2RyaXZlcnMvd2F0Y2hkb2cvbWVpX3dkdC5jDQo+IGlu
ZGV4IGI4MTk0YjAyYWJlMC4uODAyM2NmMjg2NTdhIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3dh
dGNoZG9nL21laV93ZHQuYw0KPiArKysgYi9kcml2ZXJzL3dhdGNoZG9nL21laV93ZHQuYw0KPiBA
QCAtMSwxNSArMSw3IEBADQo+ICsvLyBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMA0K
PiAgLyoNCj4gICAqIEludGVsIE1hbmFnZW1lbnQgRW5naW5lIEludGVyZmFjZSAoSW50ZWwgTUVJ
KSBMaW51eCBkcml2ZXINCj4gICAqIENvcHlyaWdodCAoYykgMjAxNSwgSW50ZWwgQ29ycG9yYXRp
b24uDQo+IC0gKg0KPiAtICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4g
cmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkgaXQNCj4gLSAqIHVuZGVyIHRoZSB0ZXJtcyBh
bmQgY29uZGl0aW9ucyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsDQo+IC0gKiB2
ZXJzaW9uIDIsIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLg0K
PiAtICoNCj4gLSAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSBpdCB3
aWxsIGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQNCj4gLSAqIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQo+IE1FUkNIQU5UQUJJTElUWSBvcg0KPiAtICog
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UNCj4gZm9yDQo+IC0gKiBtb3JlIGRldGFpbHMuDQo+ICAgKi8NCj4gDQo+ICAj
aW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQo+IEBAIC02ODcsNSArNjc5LDUgQEAgc3RhdGljIHN0
cnVjdCBtZWlfY2xfZHJpdmVyIG1laV93ZHRfZHJpdmVyID0gew0KPiAgbW9kdWxlX21laV9jbF9k
cml2ZXIobWVpX3dkdF9kcml2ZXIpOw0KPiANCj4gIE1PRFVMRV9BVVRIT1IoIkludGVsIENvcnBv
cmF0aW9uIik7DQo+IC1NT0RVTEVfTElDRU5TRSgiR1BMIik7DQo+ICtNT0RVTEVfTElDRU5TRSgi
R1BMIHYyIik7DQo+ICBNT0RVTEVfREVTQ1JJUFRJT04oIkRldmljZSBkcml2ZXIgZm9yIEludGVs
IE1FSSBpQU1UIHdhdGNoZG9nIik7DQoNCkFja2VkLWJ5OiBUb21hcyBXaW5rbGVyIDx0b21hcy53
aW5rbGVyQGludGVsLmNvbT4NCg0KDQoNCg==
^ permalink raw reply
* Re: [RFC PATCH v0 0/2] ibm,dynamic-memory-v2 fix
From: Bharata B Rao @ 2018-02-21 13:41 UTC (permalink / raw)
To: Balbir Singh
Cc: open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Nathan Fontenot,
Michael Bringmann
In-Reply-To: <CAKTCnzm8TJBWG2VG9Bts2zQF01Tsya72bJJSTRimE32XuFC-YA@mail.gmail.com>
On Wed, Feb 21, 2018 at 11:27:20PM +1100, Balbir Singh wrote:
> On Wed, Feb 21, 2018 at 9:36 PM, Bharata B Rao
> <bharata@linux.vnet.ibm.com> wrote:
> > Patch 1 fixes a bug that results in unexpected flag bit in
> > ibm,dynamic-memory-v2 DT property and wrong number of entries
> > getting created in the same property during hotplug.
> >
>
> Could you please elaborate on what this means?
Described in 1/2 patch.
> Is there a test case -
> how do we reproduce this?
Hotplug some memory and check the entries in ibm,dynamic-memory-v2 and also
check the flags there, you will see DRMEM_LMB_RESERVED set, which
shouldn't be set.
You would need QEMU which supports ibm,dynamic-memory-v2. I have posted
the initial patches for that at:
http://lists.gnu.org/archive/html/qemu-ppc/2018-02/msg00236.html
Regards,
Bharata.
^ permalink raw reply
* Re: [PATCH] bpf, powerpc: fix jit for seccomp_data access
From: Mark Lord @ 2018-02-21 13:41 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Alexei Starovoitov, Daniel Borkmann, Kees Cook, Andy Lutomirski,
mpe, Will Drewry, linuxppc-dev
In-Reply-To: <32a60518-1de6-9f9c-b3e6-5e5292d6b289@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]
On 18-02-21 07:52 AM, Mark Lord wrote:
> On 18-02-21 03:35 AM, Naveen N. Rao wrote:
..
>> Looks good to me, but I am not able to apply this patch. There seems to be whitespace damage.
>
> Here (attached) is a clean copy.
Again, this time with the commit message included!
I am using SECCOMP to filter syscalls on a ppc32 platform,
and noticed that the JIT compiler was failing on the BPF
even though the interpreter was working fine.
The issue was that the compiler was missing one of the instructions
used by SECCOMP, so here is a patch to enable JIT for that instruction.
Signed-Off-By: Mark Lord <mlord@pobox.com>
--- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.000000000 -0500
+++ linux/arch/powerpc/net/bpf_jit_comp.c 2018-02-20 14:41:20.805227494 -0500
@@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
break;
+ case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + K)); */
+ PPC_LWZ_OFFS(r_A, r_skb, K);
+ break;
case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, len));
break;
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
[-- Attachment #2: ppc-jit.patch --]
[-- Type: text/x-patch, Size: 940 bytes --]
I am using SECCOMP to filter syscalls on a ppc32 platform,
and noticed that the JIT compiler was failing on the BPF
even though the interpreter was working fine.
The issue was that the compiler was missing one of the instructions
used by SECCOMP, so here is a patch to enable JIT for that instruction.
Signed-Off-By: Mark Lord <mlord@pobox.com>
--- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.000000000 -0500
+++ linux/arch/powerpc/net/bpf_jit_comp.c 2018-02-20 14:41:20.805227494 -0500
@@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
break;
+ case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + K)); */
+ PPC_LWZ_OFFS(r_A, r_skb, K);
+ break;
case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, len));
break;
^ permalink raw reply
* Re: ocxl: Fix potential bad errno on irq allocation
From: Michael Ellerman @ 2018-02-21 13:43 UTC (permalink / raw)
To: Frederic Barrat, andrew.donnellan, linuxppc-dev; +Cc: dan.carpenter
In-Reply-To: <20180216130118.26008-1-fbarrat@linux.vnet.ibm.com>
On Fri, 2018-02-16 at 13:01:18 UTC, Frederic Barrat wrote:
> Fix some issues found by a static checker:
>
> When allocating an AFU interrupt, if the driver cannot copy the output
> parameters to userland, the errno value was not set to EFAULT
>
> Remove a (now) useless cast.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/423688abd9ab654044bddd82eb5983
cheers
^ permalink raw reply
* Re: powerpc/eeh: Add conditional check on notify_resume
From: Michael Ellerman @ 2018-02-21 13:43 UTC (permalink / raw)
To: Bryant G. Ly, benh, paulus; +Cc: aik, linuxppc-dev, jjalvare, seroyer
In-Reply-To: <1518720591-84657-1-git-send-email-bryantly@linux.vnet.ibm.com>
On Thu, 2018-02-15 at 18:49:51 UTC, "Bryant G. Ly" wrote:
> From: "Juan J. Alvarez" <jjalvare@linux.vnet.ibm.com>
>
> EEH structure is not populated with function
> notify resume when running on systems that do not support
> it, i.e: BMC. Hence adding a conditional check for NULL for
> systems that don't add function notify_resume.
>
> Signed-off-by: Juan J. Alvarez <jjalvare@linux.vnet.ibm.com>
> Reviewed-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
> Tested-by: Carol L. Soto <clsoto@us.ibm.com>
> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Tested-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
> Acked-by: Michael Neuling <mikey@neuling.org>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/521ca5a9859a870e354d1a6b84a6ff
cheers
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/mm/32: Use pfn_valid to check if pointer is in RAM
From: Jonathan Neuschäfer @ 2018-02-21 13:51 UTC (permalink / raw)
To: christophe leroy
Cc: Jonathan Neuschäfer, linuxppc-dev, linux-kernel,
Michael Ellerman, linux-mm, Joel Stanley, Benjamin Herrenschmidt,
Paul Mackerras, Balbir Singh, Guenter Roeck
In-Reply-To: <0d14cb2c-dd00-d258-cb15-302b2a9d684f@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
Hello Christophe,
On Tue, Feb 20, 2018 at 06:45:09PM +0100, christophe leroy wrote:
[...]
> > - if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
> > + if (slab_is_available() && pfn_valid(__phys_to_pfn(p)) &&
>
> I'm not sure this is equivalent:
>
> high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
> #define ARCH_PFN_OFFSET ((unsigned long)(MEMORY_START >> PAGE_SHIFT))
> #define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && (pfn) < max_mapnr)
> set_max_mapnr(max_pfn);
>
> So in the current implementation it checks against max_low_pfn while your
> patch checks against max_pfn
>
> max_low_pfn = max_pfn = memblock_end_of_DRAM() >> PAGE_SHIFT;
> #ifdef CONFIG_HIGHMEM
> max_low_pfn = lowmem_end_addr >> PAGE_SHIFT;
> #endif
Good point, I haven't considered CONFIG_HIGHMEM before.
As far as I understand it, in the non-CONFIG_HIGHMEM case:
- max_low_pfn is set to the same value as max_pfn, so the ioremap
check should detect the same PFNs as RAM.
and with CONFIG_HIGHMEM:
- max_low_pfn is set to lowmem_end_addr >> PAGE_SHIFT
- but max_pfn isn't
So, I think you're right.
While looking through arch/powerpc/mm, I noticed that there's a
page_is_ram function, which simply uses the memblocks directly, on
PPC32. It seems like a good candidate for the RAM check in
__ioremap_caller, except that there's this code, which apparently
trashes memblock 0 completely on non-CONFIG_NEED_MULTIPLE_NODES:
https://elixir.bootlin.com/linux/v4.16-rc2/source/arch/powerpc/mm/mem.c#L223
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] bpf, powerpc: fix jit for seccomp_data access
From: Naveen N. Rao @ 2018-02-21 14:08 UTC (permalink / raw)
To: Mark Lord
Cc: Alexei Starovoitov, Daniel Borkmann, Kees Cook, linuxppc-dev,
Andy Lutomirski, mpe, Will Drewry
In-Reply-To: <2e79ef59-1731-f3a5-9868-c15beb939142@pobox.com>
Mark Lord wrote:
> On 18-02-21 07:52 AM, Mark Lord wrote:
>> On 18-02-21 03:35 AM, Naveen N. Rao wrote:
> ..
>>> Looks good to me, but I am not able to apply this patch. There seems to=
be whitespace damage.
>>=20
>> Here (attached) is a clean copy.
>=20
> Again, this time with the commit message included!
Thanks. However...
I am able to apply this using 'patch', but not with 'git am' since the=20
headers are missing. FWIW, the usual workflow is to make the changes and=20
commit it into your repository using 'git commit' and then use 'git=20
format-patch' to generate a patch file that you can then post.
I'll defer to Michael on whether he is ok to process this as it is.
>=20
> I am using SECCOMP to filter syscalls on a ppc32 platform,
> and noticed that the JIT compiler was failing on the BPF
> even though the interpreter was working fine.
>=20
> The issue was that the compiler was missing one of the instructions
> used by SECCOMP, so here is a patch to enable JIT for that instruction.
>=20
> Signed-Off-By: Mark Lord <mlord@pobox.com>
Minot nit: The correct (TM) tag to use is:
Signed-off-by:
(note the case)
>=20
> --- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.000000000 -05=
00
> +++ linux/arch/powerpc/net/bpf_jit_comp.c 2018-02-20 14:41:20.80522=
7494 -0500
> @@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
> BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) !=
=3D 4);
> PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,=
len));
> break;
> + case BPF_LDX | BPF_W | BPF_ABS: /* A =3D *((u32 *)(seccom=
p_data + K)); */
> + PPC_LWZ_OFFS(r_A, r_skb, K);
> + break;
> case BPF_LDX | BPF_W | BPF_LEN: /* X =3D skb->len; */
> PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff,=
len));
> break;
Apart from those aspects, for this patch:
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
- Naveen
=
^ permalink raw reply
* Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
From: Jonathan Neuschäfer @ 2018-02-21 14:42 UTC (permalink / raw)
To: Christophe LEROY
Cc: Jonathan Neuschäfer, linuxppc-dev, Joel Stanley,
linux-kernel, linux-mm
In-Reply-To: <193a407d-e6b8-9e29-af47-3d401b6414a0@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Hi,
On Wed, Feb 21, 2018 at 08:06:10AM +0100, Christophe LEROY wrote:
>
>
> Le 20/02/2018 à 17:14, Jonathan Neuschäfer a écrit :
> > This patchset adds support for DISCONTIGMEM on 32-bit PowerPC. This is
> > required to properly support the Nintendo Wii's memory layout, in which
> > there are two blocks of RAM and MMIO in the middle.
> >
> > Previously, this memory layout was handled by code that joins the two
> > RAM blocks into one, reserves the MMIO hole, and permits allocations of
> > reserved memory in ioremap. This hack didn't work with resource-based
> > allocation (as used for example in the GPIO driver for Wii[1]), however.
> >
> > After this patchset, users of the Wii can either select CONFIG_FLATMEM
> > to get the old behaviour, or CONFIG_DISCONTIGMEM to get the new
> > behaviour.
>
> My question might me stupid, as I don't know PCC64 in deep, but when looking
> at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling the PPC64
> implements ram by blocks. Isn't it what you are trying to achieve ? Wouldn't
> it be feasible to map to what's done in PPC64 for PPC32 ?
Using page_is_ram in __ioremap_caller and the same memblock-based
approach that's used on PPC64 on PPC32 *should* work, but I think due to
the following line in initmem_init, it won't:
memblock_set_node(0, (phys_addr_t)ULLONG_MAX, &memblock.memory, 0);
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/mm/32: Use pfn_valid to check if pointer is in RAM
From: Jonathan Neuschäfer @ 2018-02-21 14:44 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: christophe leroy, linuxppc-dev, linux-kernel, Michael Ellerman,
linux-mm, Joel Stanley, Benjamin Herrenschmidt, Paul Mackerras,
Balbir Singh, Guenter Roeck
In-Reply-To: <20180221135119.d3qgvdck5yruomi7@latitude>
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
On Wed, Feb 21, 2018 at 02:51:19PM +0100, Jonathan Neuschäfer wrote:
[...]
> While looking through arch/powerpc/mm, I noticed that there's a
> page_is_ram function, which simply uses the memblocks directly, on
> PPC32.
Oops, I misread the code here. memblock is used on PPC64.
> It seems like a good candidate for the RAM check in
> __ioremap_caller, except that there's this code, which apparently
> trashes memblock 0 completely on non-CONFIG_NEED_MULTIPLE_NODES:
>
> https://elixir.bootlin.com/linux/v4.16-rc2/source/arch/powerpc/mm/mem.c#L223
>
>
> Thanks,
> Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH V2] powerpc/powernv : Add support to enable sensor groups
From: Shilpasri G Bhat @ 2018-02-21 14:55 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, linux-kernel, benh, Shilpasri G Bhat
Adds support to enable/disable a sensor group. This can be used to
select the sensor groups that needs to be copied to main memory by
OCC. Sensor groups like power, temperature, current, voltage,
frequency, utilization can be enabled/disabled at runtime.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
---
Changes from V1:
- Rebase on master
- Add documentation
.../ABI/testing/sysfs-firmware-opal-sensor-groups | 34 ++++++
arch/powerpc/include/asm/opal-api.h | 4 +-
arch/powerpc/include/asm/opal.h | 1 +
.../powerpc/platforms/powernv/opal-sensor-groups.c | 123 ++++++++++++++++-----
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
5 files changed, 132 insertions(+), 31 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
new file mode 100644
index 0000000..81081de
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
@@ -0,0 +1,34 @@
+What: /sys/firmware/opal/sensor_groups
+Date: January 2018
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Sensor groups directory for POWER9 powernv servers
+
+ Each folder in this directory contains a sensor group
+ which are classified based on type of the sensor
+ like power, temperature, frequency, current, etc. They
+ can also indicate the group of sensors belonging to
+ different owners like CSM, Profiler, Job-Scheduler
+
+What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/clear
+Date: Januaury 2018
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Sysfs file to clear the min-max of all the sensors
+ belonging to the group.
+
+ Writing 1 to this file will clear the minimum and
+ maximum values of all the sensors in the group. The
+ min-max of a sensor is the historical minimum and
+ maximum value of the sensor cached by OCC.
+
+What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/enable
+Date: Januaury 2018
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Sysfs file to enable/disable the sensor-group
+
+ Writing 0 value to this file will disable the copying
+ of the sensor-group to main memory by OCC. And writing
+ 1 to this file will enable the sensor-group copying.
+ By default all the sensor-groups are enabled and will
+ be copied to main memory. This file can be used to
+ increase the update frequency of selective
+ sensor-groups.
diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
index 94bd1bf..b6bbbd8 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -204,7 +204,9 @@
#define OPAL_NPU_SPA_SETUP 159
#define OPAL_NPU_SPA_CLEAR_CACHE 160
#define OPAL_NPU_TL_SET 161
-#define OPAL_LAST 161
+#define OPAL_SENSOR_READ_U64 162
+#define OPAL_SENSOR_GROUP_ENABLE 163
+#define OPAL_LAST 163
/* Device tree flags */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 12e70fb..e708c41 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -286,6 +286,7 @@ int64_t opal_imc_counters_init(uint32_t type, uint64_t address,
int opal_get_power_shift_ratio(u32 handle, int token, u32 *psr);
int opal_set_power_shift_ratio(u32 handle, int token, u32 psr);
int opal_sensor_group_clear(u32 group_hndl, int token);
+int opal_sensor_group_enable(u32 group_hndl, int token, bool enable);
s64 opal_signal_system_reset(s32 cpu);
diff --git a/arch/powerpc/platforms/powernv/opal-sensor-groups.c b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
index 7e5a235..1a3359d 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor-groups.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
@@ -24,6 +24,8 @@
struct sg_attr {
u32 handle;
struct kobj_attribute attr;
+ u32 opal_no;
+ int enable;
};
static struct sensor_group {
@@ -32,34 +34,44 @@ struct sg_attr {
struct sg_attr *sgattrs;
} *sgs;
-static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static int sensor_group_clear(u32 handle)
{
- struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
struct opal_msg msg;
- u32 data;
- int ret, token;
-
- ret = kstrtoint(buf, 0, &data);
- if (ret)
- return ret;
-
- if (data != 1)
- return -EINVAL;
+ int token, ret;
token = opal_async_get_token_interruptible();
- if (token < 0) {
- pr_devel("Failed to get token\n");
+ if (token < 0)
return token;
+
+ ret = opal_sensor_group_clear(handle, token);
+ if (ret == OPAL_ASYNC_COMPLETION) {
+ ret = opal_async_wait_response(token, &msg);
+ if (ret) {
+ pr_devel("Failed to wait for the async response\n");
+ ret = -EIO;
+ goto out;
+ }
+ ret = opal_error_code(opal_get_async_rc(msg));
+ } else {
+ ret = opal_error_code(ret);
}
- ret = mutex_lock_interruptible(&sg_mutex);
- if (ret)
- goto out_token;
+out:
+ opal_async_release_token(token);
+ return ret;
+}
+
+static int sensor_group_enable(u32 handle, int enable)
+{
+ struct opal_msg msg;
+ int token, ret;
+
+ token = opal_async_get_token_interruptible();
+ if (token < 0)
+ return token;
- ret = opal_sensor_group_clear(sattr->handle, token);
- switch (ret) {
- case OPAL_ASYNC_COMPLETION:
+ ret = opal_sensor_group_enable(handle, token, enable);
+ if (ret == OPAL_ASYNC_COMPLETION) {
ret = opal_async_wait_response(token, &msg);
if (ret) {
pr_devel("Failed to wait for the async response\n");
@@ -67,39 +79,90 @@ static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
goto out;
}
ret = opal_error_code(opal_get_async_rc(msg));
- if (!ret)
- ret = count;
+ } else {
+ ret = opal_error_code(ret);
+ }
+
+out:
+ opal_async_release_token(token);
+ return ret;
+}
+
+static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
+ u32 data;
+ int ret;
+
+ ret = kstrtoint(buf, 0, &data);
+ if (ret)
+ return ret;
+
+ ret = mutex_lock_interruptible(&sg_mutex);
+ if (ret)
+ return ret;
+
+ ret = -EINVAL;
+ switch (sattr->opal_no) {
+ case OPAL_SENSOR_GROUP_CLEAR:
+ if (data == 1)
+ ret = sensor_group_clear(sattr->handle);
break;
- case OPAL_SUCCESS:
- ret = count;
+ case OPAL_SENSOR_GROUP_ENABLE:
+ if (data == 0 || data == 1) {
+ if (data != sattr->enable) {
+ ret = sensor_group_enable(sattr->handle, data);
+ if (!ret)
+ sattr->enable = data;
+ } else {
+ ret = 0;
+ }
+ }
break;
default:
- ret = opal_error_code(ret);
+ break;
}
-out:
+ if (!ret)
+ ret = count;
+
mutex_unlock(&sg_mutex);
-out_token:
- opal_async_release_token(token);
return ret;
}
+static ssize_t sg_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+ struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
+
+ return sprintf(buf, "%d\n", sattr->enable);
+}
+
static struct sg_ops_info {
int opal_no;
const char *attr_name;
ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count);
+ ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf);
+ umode_t mode;
} ops_info[] = {
- { OPAL_SENSOR_GROUP_CLEAR, "clear", sg_store },
+ { OPAL_SENSOR_GROUP_CLEAR, "clear", sg_store, NULL, 0220 },
+ { OPAL_SENSOR_GROUP_ENABLE, "enable", sg_store, sg_show, 0660 },
};
static void add_attr(int handle, struct sg_attr *attr, int index)
{
attr->handle = handle;
+ attr->opal_no = ops_info[index].opal_no;
sysfs_attr_init(&attr->attr.attr);
attr->attr.attr.name = ops_info[index].attr_name;
- attr->attr.attr.mode = 0220;
+ attr->attr.attr.mode = ops_info[index].mode;
attr->attr.store = ops_info[index].store;
+ attr->attr.show = ops_info[index].show;
+ if (attr->opal_no == OPAL_SENSOR_GROUP_ENABLE)
+ attr->enable = 1;
}
static int add_attr_group(const __be32 *ops, int len, struct sensor_group *sg,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 1b2936b..90c2b40 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -323,3 +323,4 @@ OPAL_CALL(opal_sensor_group_clear, OPAL_SENSOR_GROUP_CLEAR);
OPAL_CALL(opal_npu_spa_setup, OPAL_NPU_SPA_SETUP);
OPAL_CALL(opal_npu_spa_clear_cache, OPAL_NPU_SPA_CLEAR_CACHE);
OPAL_CALL(opal_npu_tl_set, OPAL_NPU_TL_SET);
+OPAL_CALL(opal_sensor_group_enable, OPAL_SENSOR_GROUP_ENABLE);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
From: Christophe LEROY @ 2018-02-21 15:02 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linuxppc-dev, Joel Stanley, linux-kernel, linux-mm
In-Reply-To: <20180221144240.pfu2run3pixt3pzo@latitude>
Le 21/02/2018 à 15:42, Jonathan Neuschäfer a écrit :
> Hi,
>
> On Wed, Feb 21, 2018 at 08:06:10AM +0100, Christophe LEROY wrote:
>>
>>
>> Le 20/02/2018 à 17:14, Jonathan Neuschäfer a écrit :
>>> This patchset adds support for DISCONTIGMEM on 32-bit PowerPC. This is
>>> required to properly support the Nintendo Wii's memory layout, in which
>>> there are two blocks of RAM and MMIO in the middle.
>>>
>>> Previously, this memory layout was handled by code that joins the two
>>> RAM blocks into one, reserves the MMIO hole, and permits allocations of
>>> reserved memory in ioremap. This hack didn't work with resource-based
>>> allocation (as used for example in the GPIO driver for Wii[1]), however.
>>>
>>> After this patchset, users of the Wii can either select CONFIG_FLATMEM
>>> to get the old behaviour, or CONFIG_DISCONTIGMEM to get the new
>>> behaviour.
>>
>> My question might me stupid, as I don't know PCC64 in deep, but when looking
>> at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling the PPC64
>> implements ram by blocks. Isn't it what you are trying to achieve ? Wouldn't
>> it be feasible to map to what's done in PPC64 for PPC32 ?
>
> Using page_is_ram in __ioremap_caller and the same memblock-based
> approach that's used on PPC64 on PPC32 *should* work, but I think due to
> the following line in initmem_init, it won't:
>
> memblock_set_node(0, (phys_addr_t)ULLONG_MAX, &memblock.memory, 0);
Can't we just fix that ?
Christophe
>
>
> Thanks,
> Jonathan Neuschäfer
>
^ permalink raw reply
* Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
From: Arnd Bergmann @ 2018-02-21 16:03 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Rich Felker, Kernel Hardening, X86 ML, Paul Mackerras,
H. Peter Anvin, sparclinux, Sam Ravnborg, Yoshinori Sato,
Jonathan Corbet, Richard Weinberger, Linux-sh list, Ingo Molnar,
Emese Revfy, Kees Cook, uml-devel, Linux Kbuild mailing list,
Peter Oberparleiter, Jeff Dike, linuxppc-dev,
user-mode-linux-user, Thomas Gleixner, Michal Marek,
Ulf Magnusson, Greg Kroah-Hartman, Randy Dunlap,
open list:DOCUMENTATION, Linux Kernel Mailing List,
Linus Torvalds, David S. Miller
In-Reply-To: <CAK7LNAR3OMh9Q9ZfaBq=FpSJ-+DT5-RH_20ohV-iu34pX9hFKw@mail.gmail.com>
On Wed, Feb 21, 2018 at 1:57 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>>> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
>>>> <yamada.masahiro@socionext.com> wrote:
>>>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
>
> Hmm, I think I can implement those somehow.
> But, I hope we do not have many instances like this...
>
>
> If you know more naive cases, please share your knowledge.
>
One case that comes to mind would be architecture level selection on 32-bit
ARM, which is roughly this (I probably have some details wrong, but you
get the idea):
- older compilers don't support the latest architecture setting (-march=armv8
or -march=armv7ve)
- newer compilers no longer support really old architectures (-march=armv4)
- setting -mthumb requires setting one of -march=armv7-a, armv7ve, armv7-m or
armv8 if the compiler doesn't default to those
- on a compiler that defaults to -marm, setting -march=armv7-m requires
setting -mthumb (IIRC)
- really old compilers only support OABI, but not EABI
- newer compilers no longer support OABI
- mthumb requires EABI
- armv6 and higher are subtly broken with OABI, but only when using
certain inline assembly with 64-bit arguments in register pairs.
I think we just shouldn't try to capture all of the above correctly in Kconfig
conditionals.
Arnd
^ permalink raw reply
* Re: [PATCH 5/6] powerpc: Implement DISCONTIGMEM and allow selection on PPC32
From: Jonathan Neuschäfer @ 2018-02-21 16:08 UTC (permalink / raw)
To: kbuild test robot
Cc: Jonathan Neuschäfer, kbuild-all, linuxppc-dev, linux-kernel,
Michael Ellerman, linux-mm, Joel Stanley, Benjamin Herrenschmidt,
Paul Mackerras, Greg Kroah-Hartman, Thomas Gleixner,
Philippe Ombredanne, Kate Stewart, Nathan Fontenot,
Michael Bringmann, Thiago Jung Bauermann, Kees Cook
In-Reply-To: <201802210756.OZokd64C%fengguang.wu@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
On Wed, Feb 21, 2018 at 07:46:28AM +0800, kbuild test robot wrote:
[...]
> >> include/linux/mmzone.h:1239:19: error: conflicting types for 'pfn_valid'
> static inline int pfn_valid(unsigned long pfn)
> ^~~~~~~~~
> In file included from include/linux/mmzone.h:912:0,
> from include/linux/gfp.h:6,
> from include/linux/mm.h:10,
> from include/linux/mman.h:5,
> from arch/powerpc/kernel/asm-offsets.c:22:
> arch/powerpc/include/asm/mmzone.h:40:19: note: previous definition of 'pfn_valid' was here
> static inline int pfn_valid(int pfn)
> ^~~~~~~~~
> make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
> make[2]: Target '__build' not remade because of errors.
> make[1]: *** [prepare0] Error 2
> make[1]: Target 'prepare' not remade because of errors.
> make: *** [sub-make] Error 2
Oops, I'll fix this in the next version (and compile-test on ppc64...).
Weirdly enough, x86-32 and parisc define pfn_valid with an int
parameter, too (both of them since the Beginning Of Time, aka.
v2.6.12-rc2).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
From: Jonathan Neuschäfer @ 2018-02-21 16:52 UTC (permalink / raw)
To: Christophe LEROY
Cc: Jonathan Neuschäfer, linuxppc-dev, Joel Stanley,
linux-kernel, linux-mm
In-Reply-To: <a36983ec-5e97-e968-8143-1b2615ea55f8@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
On Wed, Feb 21, 2018 at 04:02:25PM +0100, Christophe LEROY wrote:
[...]
> > > My question might me stupid, as I don't know PCC64 in deep, but when looking
> > > at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling the PPC64
> > > implements ram by blocks. Isn't it what you are trying to achieve ? Wouldn't
> > > it be feasible to map to what's done in PPC64 for PPC32 ?
> >
> > Using page_is_ram in __ioremap_caller and the same memblock-based
> > approach that's used on PPC64 on PPC32 *should* work, but I think due to
> > the following line in initmem_init, it won't:
> >
> > memblock_set_node(0, (phys_addr_t)ULLONG_MAX, &memblock.memory, 0);
>
> Can't we just fix that ?
I'll give it a try.
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] powerpc: Implement DISCONTIGMEM and allow selection on PPC32
From: christophe leroy @ 2018-02-21 17:53 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: Kate Stewart, Kees Cook, Greg Kroah-Hartman, Philippe Ombredanne,
linux-kernel, linux-mm, Michael Bringmann, Paul Mackerras,
kbuild-all, Thiago Jung Bauermann, Nathan Fontenot,
Thomas Gleixner, linuxppc-dev, Joel Stanley
In-Reply-To: <20180221160815.dxhpsejt74zeqqjd@latitude>
Le 21/02/2018 à 17:08, Jonathan Neuschäfer a écrit :
> On Wed, Feb 21, 2018 at 07:46:28AM +0800, kbuild test robot wrote:
> [...]
>>>> include/linux/mmzone.h:1239:19: error: conflicting types for 'pfn_valid'
>> static inline int pfn_valid(unsigned long pfn)
>> ^~~~~~~~~
>> In file included from include/linux/mmzone.h:912:0,
>> from include/linux/gfp.h:6,
>> from include/linux/mm.h:10,
>> from include/linux/mman.h:5,
>> from arch/powerpc/kernel/asm-offsets.c:22:
>> arch/powerpc/include/asm/mmzone.h:40:19: note: previous definition of 'pfn_valid' was here
>> static inline int pfn_valid(int pfn)
>> ^~~~~~~~~
>> make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
>> make[2]: Target '__build' not remade because of errors.
>> make[1]: *** [prepare0] Error 2
>> make[1]: Target 'prepare' not remade because of errors.
>> make: *** [sub-make] Error 2
>
> Oops, I'll fix this in the next version (and compile-test on ppc64...).
>
> Weirdly enough, x86-32 and parisc define pfn_valid with an int
> parameter, too (both of them since the Beginning Of Time, aka.
> v2.6.12-rc2).
>
Behind the fact that the pfn type is different, my understanding is that
you have to define CONFIG_HAVE_ARCH_PFN_VALID in the Kconfig in order to
avoid it being included in include/linux/mmzone.h
Christophe
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* [PATCH v12 07/11] mm: Add address parameter to arch_validate_prot()
From: Khalid Aziz @ 2018-02-21 17:15 UTC (permalink / raw)
To: akpm, benh, paulus, mpe, davem, dave.hansen
Cc: Khalid Aziz, bsingharora, nborisov, aarcange, anthony.yznaga,
mgorman, linuxram, kirill.shutemov, dan.j.williams, jack,
ross.zwisler, gregkh, tglx, mhocko, n-horiguchi, jglisse,
henry.willard, aneesh.kumar, khandual, linuxppc-dev, linux-kernel,
linux-mm, sparclinux, Khalid Aziz
In-Reply-To: <cover.1519227112.git.khalid.aziz@oracle.com>
A protection flag may not be valid across entire address space and
hence arch_validate_prot() might need the address a protection bit is
being set on to ensure it is a valid protection flag. For example, sparc
processors support memory corruption detection (as part of ADI feature)
flag on memory addresses mapped on to physical RAM but not on PFN mapped
pages or addresses mapped on to devices. This patch adds address to the
parameters being passed to arch_validate_prot() so protection bits can
be validated in the relevant context.
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
Cc: Khalid Aziz <khalid@gonehiking.org>
Reviewed-by: Anthony Yznaga <anthony.yznaga@oracle.com>
---
v8:
- Added addr parameter to powerpc arch_validate_prot() (suggested
by Michael Ellerman)
v9:
- new patch
arch/powerpc/include/asm/mman.h | 4 ++--
arch/powerpc/kernel/syscalls.c | 2 +-
include/linux/mman.h | 2 +-
mm/mprotect.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
index 07e3f54de9e3..e3f1b5ba5d5c 100644
--- a/arch/powerpc/include/asm/mman.h
+++ b/arch/powerpc/include/asm/mman.h
@@ -43,7 +43,7 @@ static inline pgprot_t arch_vm_get_page_prot(unsigned long vm_flags)
}
#define arch_vm_get_page_prot(vm_flags) arch_vm_get_page_prot(vm_flags)
-static inline bool arch_validate_prot(unsigned long prot)
+static inline bool arch_validate_prot(unsigned long prot, unsigned long addr)
{
if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_SAO))
return false;
@@ -51,7 +51,7 @@ static inline bool arch_validate_prot(unsigned long prot)
return false;
return true;
}
-#define arch_validate_prot(prot) arch_validate_prot(prot)
+#define arch_validate_prot arch_validate_prot
#endif /* CONFIG_PPC64 */
#endif /* _ASM_POWERPC_MMAN_H */
diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index a877bf8269fe..6d90ddbd2d11 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -48,7 +48,7 @@ static inline long do_mmap2(unsigned long addr, size_t len,
{
long ret = -EINVAL;
- if (!arch_validate_prot(prot))
+ if (!arch_validate_prot(prot, addr))
goto out;
if (shift) {
diff --git a/include/linux/mman.h b/include/linux/mman.h
index 6a4d1caaff5c..4b08e9c9c538 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -92,7 +92,7 @@ static inline void vm_unacct_memory(long pages)
*
* Returns true if the prot flags are valid
*/
-static inline bool arch_validate_prot(unsigned long prot)
+static inline bool arch_validate_prot(unsigned long prot, unsigned long addr)
{
return (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) == 0;
}
diff --git a/mm/mprotect.c b/mm/mprotect.c
index e3309fcf586b..088ea9c08678 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -417,7 +417,7 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
end = start + len;
if (end <= start)
return -ENOMEM;
- if (!arch_validate_prot(prot))
+ if (!arch_validate_prot(prot, start))
return -EINVAL;
reqprot = prot;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] powerpc/pseries: Fix duplicate firmware feature for DRC_INFO
From: Tyrel Datwyler @ 2018-02-21 21:37 UTC (permalink / raw)
To: Michael Ellerman, mwb, nfont; +Cc: linuxppc-dev
In-Reply-To: <20180221130523.27836-1-mpe@ellerman.id.au>
On 02/21/2018 05:05 AM, Michael Ellerman wrote:
> We had a mid-air collision between two new firmware features, DRMEM_V2
> and DRC_INFO, and they ended up with the same value.
>
> No one's actually reported any problems, presumably because the new
> firmware that supports both properties is not widely available, and
> the two properties tend to be enabled together.
>
> Still if we ever had one enabled but not the other, the bugs that
> could result are many and varied. So fix it.
>
> Fixes: 3f38000eda48 ("powerpc/firmware: Add definitions for new drc-info firmware feature")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
Good catch.
Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> arch/powerpc/include/asm/firmware.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/firmware.h b/arch/powerpc/include/asm/firmware.h
> index 511acfd7ab0d..535add3f7791 100644
> --- a/arch/powerpc/include/asm/firmware.h
> +++ b/arch/powerpc/include/asm/firmware.h
> @@ -52,7 +52,7 @@
> #define FW_FEATURE_TYPE1_AFFINITY ASM_CONST(0x0000000100000000)
> #define FW_FEATURE_PRRN ASM_CONST(0x0000000200000000)
> #define FW_FEATURE_DRMEM_V2 ASM_CONST(0x0000000400000000)
> -#define FW_FEATURE_DRC_INFO ASM_CONST(0x0000000400000000)
> +#define FW_FEATURE_DRC_INFO ASM_CONST(0x0000000800000000)
>
> #ifndef __ASSEMBLY__
>
^ permalink raw reply
* Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
From: Ulf Magnusson @ 2018-02-21 21:39 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Arnd Bergmann, Rich Felker, Kernel Hardening, X86 ML,
Paul Mackerras, H. Peter Anvin, sparclinux, Sam Ravnborg,
Yoshinori Sato, Jonathan Corbet, Richard Weinberger,
Linux-sh list, Ingo Molnar, Emese Revfy, Kees Cook, uml-devel,
Linux Kbuild mailing list, Peter Oberparleiter, Jeff Dike,
linuxppc-dev, user-mode-linux-user, Thomas Gleixner, Michal Marek,
Greg Kroah-Hartman, Randy Dunlap, open list:DOCUMENTATION,
Linux Kernel Mailing List, Linus Torvalds, David S. Miller
In-Reply-To: <CAK7LNAR3OMh9Q9ZfaBq=FpSJ-+DT5-RH_20ohV-iu34pX9hFKw@mail.gmail.com>
On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote:
> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
> > <yamada.masahiro@socionext.com> wrote:
> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
> >>> <yamada.masahiro@socionext.com> wrote:
> >>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> >>
> >> Let me clarify my concern.
> >>
> >> When we test the compiler flag, is there a case
> >> where a particular flag depends on -m{32,64} ?
> >>
> >> For example, is there a compiler that supports -fstack-protector
> >> for 64bit mode, but unsupports it for 32bit mode?
> >>
> >> $(cc-option -m32) -> y
> >> $(cc-option -m64) -> y
> >> $(cc-option -fstack-protector) -> y
> >> $(cc-option -m32 -fstack-protector) -> n
> >> $(cc-option -m64 -fstack-protector) -> y
> >>
> >> I guess this is unlikely to happen,
> >> but I am not whether it is zero possibility.
> >>
> >> If this could happen,
> >> $(cc-option ) must be evaluated together with
> >> correct bi-arch option (either -m32 or -m64).
> >>
> >>
> >> Currently, -m32/-m64 is specified in Makefile,
> >> but we are moving compiler tests to Kconfig
> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig.
> >
> > I don't think it can happen for this particular combination (stack protector
> > and word size), but I'm sure we'll eventually run into options that
> > need to be tested in combination. For the current CFLAGS_KERNEL
> > setting, we definitely have the case of needing the variables to be
> > evaluated in a specific order.
> >
>
>
>
>
> I was thinking of how we can handle complex cases
> in the current approach.
>
>
>
> (Case 1)
>
> Compiler flag -foo and -bar interacts, so
> we also need to check the combination of the two.
>
>
> config CC_HAS_FOO
> def_bool $(cc-option -foo)
>
> config CC_HAS_BAR
> def_bool $(cc-option -bar)
>
> config CC_HAS_FOO_WITH_BAR
> def_bool $(cc-option -foo -bar)
>
>
>
> (Case 2)
> Compiler flag -foo is sensitive to word-size.
> So, we need to test this option together with -m32/-m64.
> User can toggle CONFIG_64BIT, like i386/x86_64.
>
>
> config CC_NEEDS_M64
> def_bool $(cc-option -m64) && 64BIT
>
> config CC_NEEDS_M32
> def_bool $(cc-option -m32) && !64BIT
>
> config CC_HAS_FOO
> bool
> default $(cc-option -m64 -foo) if CC_NEEDS_M64
> default $(cc-option -m32 -foo) if CC_NEEDS_M32
> default $(cc-option -foo)
>
>
>
> (Case 3)
> Compiler flag -foo is sensitive to endian-ness.
>
>
> config CC_NEEDS_BIG_ENDIAN
> def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN
>
> config CC_NEEDS_LITTLE_ENDIAN
> def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN
>
> config CC_HAS_FOO
> bool
> default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN
> default $(cc-option -mlittle-endian -foo) if CC_NEEDS_LITTLE_ENDIAN
> default $(cc-option -foo)
>
>
>
>
> Hmm, I think I can implement those somehow.
> But, I hope we do not have many instances like this...
>
>
> If you know more naive cases, please share your knowledge.
>
> Thanks!
>
>
> --
> Best Regards
> Masahiro Yamada
Would get pretty bad if a test needs to consider multiple symbols.
Exponential explosion there...
I thought some more about the implementation of dynamic (post-parsing)
functions to see how bad it would get with the current implementation.
Some background on how things work now:
1. All expression operands in Kconfig are symbols.
2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets
you symbols with those strings as names and S_UNKNOWN type (because
they act like references to undefined symbols).
3. For "foo-$(fn foo)", you also get a symbol with that string as its
name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols)
4. Symbols with S_UNKNOWN type get their name as their string value,
and the tristate value n.
So, if you do string expansion on the names of symbols with S_UNKNOWN
type in sym_calc_value(), you're almost there with the current
implementation, except for the tristate case.
Maybe you could set the tristate value of S_UNKNOWN symbols depending on
the string value you end up with. Things are getting pretty confusing at
that point.
Could have something like S_DYNAMIC as well. More Kconfig complexity...
Then there's other complications:
1. SYMBOL_CONST is no longer constant.
2. Dependency loop detection needs to consider symbol references
within strings.
3. Dependency loop detection relies on static knowledge of what
symbols a symbol depends on. That might get messy for certain
expansions, though it might be things you wouldn't do in practice.
4. Symbols still need to be properly invalidated. It looks like at
least menuconfig just does a dumb invalidate-everything whenever
the value of a symbol is changed though, so it might not require
extra work. (Bit messier in Kconfiglib, which does minimal
invalidation to keep scripts fast, but just need to extract a few
extra deps there.)
It looks like dynamic functions could get quite messy, but might be
doable if absolutely required. There's probably more devils in the
details though.
I don't think the static function model precludes switching models later
btw, when people have more experience.
Cheers,
Ulf
^ permalink raw reply
* [PATCH] powerpc/time: stop validating rtc_time in .read_time
From: Alexandre Belloni @ 2018-02-21 21:46 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev, linux-rtc,
linux-kernel, Alexandre Belloni
The RTC core is always calling rtc_valid_tm after the read_time callback.
It is not necessary to call it just before returning from the callback.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
arch/powerpc/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index a32823dcd9a4..f7d96a68ecaa 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1234,7 +1234,7 @@ void calibrate_delay(void)
static int rtc_generic_get_time(struct device *dev, struct rtc_time *tm)
{
ppc_md.get_rtc_time(tm);
- return rtc_valid_tm(tm);
+ return 0;
}
static int rtc_generic_set_time(struct device *dev, struct rtc_time *tm)
--
2.16.1
^ permalink raw reply related
* [PATCH v12 00/11] Application Data Integrity feature introduced by SPARC M7
From: Khalid Aziz @ 2018-02-21 17:15 UTC (permalink / raw)
To: davem, dave.hansen
Cc: Khalid Aziz, aarcange, akpm, allen.pais, aneesh.kumar,
anthony.yznaga, arnd, benh, bob.picco, bsingharora, corbet,
dan.j.williams, dave.jiang, david.j.aldridge, dwindsor, ebiederm,
elena.reshetova, gregkh, hannes, henry.willard, hpa, hughd,
imbrenda, jack, jag.raman, jane.chu, jglisse, jroedel, khalid,
khandual, kirill.shutemov, kstewart, ktkhai, liam.merwick,
linux-arch, linux-doc, linux-kernel, linux-mm, linuxppc-dev,
linuxram, linux, me, mgorman, mgorman, mhocko, mike.kravetz,
minchan, mingo, mingo, mpe, nadav.amit, nagarathnam.muthusamy,
nborisov, n-horiguchi, nick.alcock, nitin.m.gupta, pasha.tatashin,
paulus, pombredanne, punit.agrawal, rob.gardner, ross.zwisler,
shannon.nelson, shli, sparclinux, steven.sistare, tglx,
thomas.tai, tklauser, tom.hromatka, vegard.nossum, vijay.ac.kumar,
viro, willy, x86, zi.yan
V12 changes:
This series is same as v10 and v11 and was simply rebased on 4.16-rc2
kernel and patch 11 was added to update signal delivery code to use the
new helper functions added by Eric Biederman. Can mm maintainers please
review patches 2, 7, 8 and 9 which are arch independent, and
include/linux/mm.h and mm/ksm.c changes in patch 10 and ack these if
everything looks good?
SPARC M7 processor adds additional metadata for memory address space
that can be used to secure access to regions of memory. This additional
metadata is implemented as a 4-bit tag attached to each cacheline size
block of memory. A task can set a tag on any number of such blocks.
Access to such block is granted only if the virtual address used to
access that block of memory has the tag encoded in the uppermost 4 bits
of VA. Since sparc processor does not implement all 64 bits of VA, top 4
bits are available for ADI tags. Any mismatch between tag encoded in VA
and tag set on the memory block results in a trap. Tags are verified in
the VA presented to the MMU and tags are associated with the physical
page VA maps on to. If a memory page is swapped out and page frame gets
reused for another task, the tags are lost and hence must be saved when
swapping or migrating the page.
A userspace task enables ADI through mprotect(). This patch series adds
a page protection bit PROT_ADI and a corresponding VMA flag
VM_SPARC_ADI. VM_SPARC_ADI is used to trigger setting TTE.mcd bit in the
sparc pte that enables ADI checking on the corresponding page. MMU
validates the tag embedded in VA for every page that has TTE.mcd bit set
in its pte. After enabling ADI on a memory range, the userspace task can
set ADI version tags using stxa instruction with ASI_MCD_PRIMARY or
ASI_MCD_ST_BLKINIT_PRIMARY ASI.
Once userspace task calls mprotect() with PROT_ADI, kernel takes
following overall steps:
1. Find the VMAs covering the address range passed in to mprotect and
set VM_SPARC_ADI flag. If address range covers a subset of a VMA, the
VMA will be split.
2. When a page is allocated for a VA and the VMA covering this VA has
VM_SPARC_ADI flag set, set the TTE.mcd bit so MMU will check the
vwersion tag.
3. Userspace can now set version tags on the memory it has enabled ADI
on. Userspace accesses ADI enabled memory using a virtual address that
has the version tag embedded in the high bits. MMU validates this
version tag against the actual tag set on the memory. If tag matches,
MMU performs the VA->PA translation and access is granted. If there is a
mismatch, hypervisor sends a data access exception or precise memory
corruption detected exception depending upon whether precise exceptions
are enabled or not (controlled by MCDPERR register). Kernel sends
SIGSEGV to the task with appropriate si_code.
4. If a page is being swapped out or migrated, kernel must save any ADI
tags set on the page. Kernel maintains a page worth of tag storage
descriptors. Each descriptors pointsto a tag storage space and the
address range it covers. If the page being swapped out or migrated has
ADI enabled on it, kernel finds a tag storage descriptor that covers the
address range for the page or allocates a new descriptor if none of the
existing descriptors cover the address range. Kernel saves tags from the
page into the tag storage space descriptor points to.
5. When the page is swapped back in or reinstantiated after migration,
kernel restores the version tags on the new physical page by retrieving
the original tag from tag storage pointed to by a tag storage descriptor
for the virtual address range for new page.
User task can disable ADI by calling mprotect() again on the memory
range with PROT_ADI bit unset. Kernel clears the VM_SPARC_ADI flag in
VMAs, merges adjacent VMAs if necessary, and clears TTE.mcd bit in the
corresponding ptes.
IOMMU does not support ADI checking. Any version tags embedded in the
top bits of VA meant for IOMMU, are cleared and replaced with sign
extension of the first non-version tag bit (bit 59 for SPARC M7) for
IOMMU addresses.
This patch series adds support for this feature in 11 patches:
Patch 1/11
Tag mismatch on access by a task results in a trap from hypervisor as
data access exception or a precide memory corruption detected
exception. As part of handling these exceptions, kernel sends a
SIGSEGV to user process with special si_code to indicate which fault
occurred. This patch adds three new si_codes to differentiate between
various mismatch errors.
Patch 2/11
When a page is swapped or migrated, metadata associated with the page
must be saved so it can be restored later. This patch adds a new
function that saves/restores this metadata when updating pte upon a
swap/migration.
Patch 3/11
SPARC M7 processor adds new fields to control registers to support ADI
feature. It also adds a new exception for precise traps on tag
mismatch. This patch adds definitions for the new control register
fields, new ASIs for ADI and an exception handler for the precise trap
on tag mismatch.
Patch 4/11
New hypervisor fault types were added by sparc M7 processor to support
ADI feature. This patch adds code to handle these fault types for data
access exception handler.
Patch 5/11
When ADI is in use for a page and a tag mismatch occurs, processor
raises "Memory corruption Detected" trap. This patch adds a handler
for this trap.
Patch 6/11
ADI usage is governed by ADI properties on a platform. These
properties are provided to kernel by firmware. Thsi patch adds new
auxiliary vectors that provide these values to userpsace.
Patch 7/11
arch_validate_prot() is used to validate the new protection bits asked
for by the userspace app. Validating protection bits may need the
context of address space the bits are being applied to. One such
example is PROT_ADI bit on sparc processor that enables ADI protection
on an address range. ADI protection applies only to addresses covered
by physical RAM and not other PFN mapped addresses or device
addresses. This patch adds "address" to the parameters being passed to
arch_validate_prot() to provide that context.
Patch 8/11
When protection bits are changed on a page, kernel carries forward all
protection bits except for read/write/exec. Additional code was added
to allow kernel to clear PKEY bits on x86 but this requirement to
clear other bits is not unique to x86. This patch extends the existing
code to allow other architectures to clear any other protection bits
as well on protection bit change.
Patch 9/11
When a processor supports additional metadata on memory pages, that
additional metadata needs to be copied to new memory pages when those
pages are moved. This patch allows architecture specific code to
replace the default copy_highpage() routine with arch specific
version that copies the metadata as well besides the data on the page.
Patch 10/11
This patch adds support for a user space task to enable ADI and enable
tag checking for subsets of its address space. As part of enabling
this feature, this patch adds to support manipulation of precise
exception for memory corruption detection, adds code to save and
restore tags on page swap and migration, and adds code to handle ADI
tagged addresses for DMA.
Patch 11/11
Update signal delivery code in arch/sparc/kernel/traps_64.c to use
the new helper function force_sig_fault() added by commit
f8ec66014ffd ("signal: Add send_sig_fault and force_sig_fault").
Changelog v12:
- Rebased to 4.16-rc2
- Added patch 11 to update signal delivery functions
Changelog v11:
- Rebased to 4.15
Changelog v10:
- Patch 1/10: Updated si_codes definitions for SEGV to match 4.14
- Patch 2/10: No changes
- Patch 3/10: Updated copyright
- Patch 4/10: No changes
- Patch 5/10: No changes
- Patch 6/10: Updated copyright
- Patch 7/10: No changes
- Patch 8/10: No changes
- Patch 9/10: No changes
- Patch 10/10: Added code to return from kernel path to set
PSTATE.mcde if kernel continues execution in another thread
(Suggested by Anthony)
Changelog v9:
- Patch 1/10: No changes
- Patch 2/10: No changes
- Patch 3/10: No changes
- Patch 4/10: No changes
- Patch 5/10: No changes
- Patch 6/10: No changes
- Patch 7/10: No changes
- Patch 8/10: No changes
- Patch 9/10: New patch
- Patch 10/10: Patch 9 from v8. Added code to copy ADI tags when
pages are migrated. Updated code to detect overflow and underflow
of addresses when allocating tag storage.
Changelog v8:
- Patch 1/9: No changes
- Patch 2/9: Fixed and erroneous "}"
- Patch 3/9: Minor print formatting change
- Patch 4/9: No changes
- Patch 5/9: No changes
- Patch 6/9: Added AT_ADI_UEONADI back
- Patch 7/9: Added addr parameter to powerpc arch_validate_prot()
- Patch 8/9: No changes
- Patch 9/9:
- Documentation updates
- Added an IPI on mprotect(...PROT_ADI...) call and
restore of TSTATE.MCDE on context switch
- Removed restriction on enabling ADI on read-only
memory
- Changed kzalloc() for tag storage to use GFP_NOWAIT
- Added code to handle overflow and underflow when
allocating tag storage
- Replaced sun_m7_patch_1insn_range() with
sun4v_patch_1insn_range()
- Added membar after restoring ADI tags in
copy_user_highpage()
Changelog v7:
- Patch 1/9: No changes
- Patch 2/9: Updated parameters to arch specific swap in/out
handlers
- Patch 3/9: No changes
- Patch 4/9: new patch split off from patch 4/4 in v6
- Patch 5/9: new patch split off from patch 4/4 in v6
- Patch 6/9: new patch split off from patch 4/4 in v6
- Patch 7/9: new patch
- Patch 8/9: new patch
- Patch 9/9:
- Enhanced arch_validate_prot() to enable ADI only on
writable addresses backed by physical RAM
- Added support for saving/restoring ADI tags for each
ADI block size address range on a page on swap in/out
- copy ADI tags on COW
- Updated values for auxiliary vectors to not conflict
with values on other architectures to avoid conflict
in glibc
- Disable same page merging on ADI enabled pages
- Enable ADI only on writable addresses backed by
physical RAM
- Split parts of patch off into separate patches
Changelog v6:
- Patch 1/4: No changes
- Patch 2/4: No changes
- Patch 3/4: Added missing nop in the delay slot in
sun4v_mcd_detect_precise
- Patch 4/4: Eliminated instructions to read and write PSTATE
as well as MCDPER and PMCDPER on every access to userspace
addresses by setting PSTATE and PMCDPER correctly upon entry
into kernel
Changelog v5:
- Patch 1/4: No changes
- Patch 2/4: Replaced set_swp_pte_at() with new architecture
functions arch_do_swap_page() and arch_unmap_one() that
suppoprt architecture specific actions to be taken on page
swap and migration
- Patch 3/4: Fixed indentation issues in assembly code
- Patch 4/4:
- Fixed indentation issues and instrcuctions in assembly
code
- Removed CONFIG_SPARC64 from mdesc.c
- Changed to maintain state of MCDPER register in thread
info flags as opposed to in mm context. MCDPER is a
per-thread state and belongs in thread info flag as
opposed to mm context which is shared across threads.
Added comments to clarify this is a lazily maintained
state and must be updated on context switch and
copy_process()
- Updated code to use the new arch_do_swap_page() and
arch_unmap_one() functions
Testing:
- All functionality was tested with 8K normal pages as well as hugepages
using malloc, mmap and shm.
- Multiple long duration stress tests were run using hugepages over 2+
months. Normal pages were tested with shorter duration stress tests.
- Tested swapping with malloc and shm by reducing max memory and
allocating three times the available system memory by active processes
using ADI on allocated memory. Ran through multiple hours long runs of
this test.
- Tested page migration with malloc and shm by migrating data pages of
active ADI test process using migratepages, back and forth between two
nodes every few seconds over an hour long run. Verified page migration
through /proc/<pid>/numa_maps.
- Tested COW support using test that forks children that read from
ADI enabled pages shared with parent and other children and write to
them as well forcing COW.
---------
Khalid Aziz (11):
signals, sparc: Add signal codes for ADI violations
mm, swap: Add infrastructure for saving page metadata on swap
sparc64: Add support for ADI register fields, ASIs and traps
sparc64: Add HV fault type handlers for ADI related faults
sparc64: Add handler for "Memory Corruption Detected" trap
sparc64: Add auxiliary vectors to report platform ADI properties
mm: Add address parameter to arch_validate_prot()
mm: Clear arch specific VM flags on protection change
mm: Allow arch code to override copy_highpage()
sparc64: Add support for ADI (Application Data Integrity)
sparc64: Update signal delivery to use new helper functions
Documentation/sparc/adi.txt | 278 ++++++++++++++++++++++
arch/powerpc/include/asm/mman.h | 4 +-
arch/powerpc/kernel/syscalls.c | 2 +-
arch/sparc/include/asm/adi.h | 6 +
arch/sparc/include/asm/adi_64.h | 47 ++++
arch/sparc/include/asm/elf_64.h | 5 +
arch/sparc/include/asm/hypervisor.h | 2 +
arch/sparc/include/asm/mman.h | 84 ++++++-
arch/sparc/include/asm/mmu_64.h | 17 ++
arch/sparc/include/asm/mmu_context_64.h | 50 ++++
arch/sparc/include/asm/page_64.h | 6 +
arch/sparc/include/asm/pgtable_64.h | 48 ++++
arch/sparc/include/asm/thread_info_64.h | 2 +-
arch/sparc/include/asm/trap_block.h | 2 +
arch/sparc/include/asm/ttable.h | 10 +
arch/sparc/include/uapi/asm/asi.h | 5 +
arch/sparc/include/uapi/asm/auxvec.h | 11 +
arch/sparc/include/uapi/asm/mman.h | 2 +
arch/sparc/include/uapi/asm/pstate.h | 10 +
arch/sparc/kernel/Makefile | 1 +
arch/sparc/kernel/adi_64.c | 397 ++++++++++++++++++++++++++++++++
arch/sparc/kernel/entry.h | 3 +
arch/sparc/kernel/etrap_64.S | 27 ++-
arch/sparc/kernel/head_64.S | 1 +
arch/sparc/kernel/mdesc.c | 2 +
arch/sparc/kernel/process_64.c | 25 ++
arch/sparc/kernel/rtrap_64.S | 33 ++-
arch/sparc/kernel/setup_64.c | 2 +
arch/sparc/kernel/sun4v_mcd.S | 18 ++
arch/sparc/kernel/traps_64.c | 130 ++++++++++-
arch/sparc/kernel/ttable_64.S | 6 +-
arch/sparc/kernel/urtt_fill.S | 7 +-
arch/sparc/kernel/vmlinux.lds.S | 5 +
arch/sparc/mm/gup.c | 37 +++
arch/sparc/mm/hugetlbpage.c | 14 +-
arch/sparc/mm/init_64.c | 69 ++++++
arch/sparc/mm/tsb.c | 21 ++
arch/x86/kernel/signal_compat.c | 2 +-
include/asm-generic/pgtable.h | 36 +++
include/linux/highmem.h | 4 +
include/linux/mm.h | 9 +
include/linux/mman.h | 2 +-
include/uapi/asm-generic/siginfo.h | 5 +-
mm/ksm.c | 4 +
mm/memory.c | 1 +
mm/mprotect.c | 4 +-
mm/rmap.c | 14 ++
47 files changed, 1445 insertions(+), 25 deletions(-)
create mode 100644 Documentation/sparc/adi.txt
create mode 100644 arch/sparc/include/asm/adi.h
create mode 100644 arch/sparc/include/asm/adi_64.h
create mode 100644 arch/sparc/kernel/adi_64.c
create mode 100644 arch/sparc/kernel/sun4v_mcd.S
--
2.11.0
^ permalink raw reply
* Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
From: Jonathan Neuschäfer @ 2018-02-21 23:31 UTC (permalink / raw)
To: Christophe LEROY
Cc: Jonathan Neuschäfer, linuxppc-dev, Joel Stanley,
linux-kernel, linux-mm
In-Reply-To: <a36983ec-5e97-e968-8143-1b2615ea55f8@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On Wed, Feb 21, 2018 at 04:02:25PM +0100, Christophe LEROY wrote:
[...]
> > > My question might me stupid, as I don't know PCC64 in deep, but when looking
> > > at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling the PPC64
> > > implements ram by blocks. Isn't it what you are trying to achieve ? Wouldn't
> > > it be feasible to map to what's done in PPC64 for PPC32 ?
> >
> > Using page_is_ram in __ioremap_caller and the same memblock-based
> > approach that's used on PPC64 on PPC32 *should* work, but I think due to
> > the following line in initmem_init, it won't:
> >
> > memblock_set_node(0, (phys_addr_t)ULLONG_MAX, &memblock.memory, 0);
>
> Can't we just fix that ?
Turns out I was completely wrong about this. memblock_set_node as called
above only assigns all memory to node 0 and merges *adjacent* memblocks.
It doesn't merge the memblocks on the Wii, which are far apart.
So now I actually have a working patchset (coming soon), that's a good
deal shorter than this patchset, and hopefully won't break
CONFIG_HIGHMEM in the same way.
Thanks for your input! :)
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Alastair D'Silva @ 2018-02-21 23:32 UTC (permalink / raw)
To: Balbir Singh
Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Arnd Bergmann,
frederic.barrat, Greg KH, Andrew Donnellan
In-Reply-To: <CAKTCnz=cy5CkeRjJYpZ1NQpyQN-BVTvKXUxTxOMtTNosZFqJ7A@mail.gmail.com>
On Wed, 2018-02-21 at 17:43 +1100, Balbir Singh wrote:
> On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva <alastair@au1.ibm.c
> om> wrote:
> > From: Alastair D'Silva <alastair@d-silva.org>
> >
> > Some required information is not exposed to userspace currently
> > (eg. the
> > PASID), pass this information back, along with other information
> > which
> > is currently communicated via sysfs, which saves some parsing
> > effort in
> > userspace.
> >
> > Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> > ---
> > drivers/misc/ocxl/file.c | 27 +++++++++++++++++++++++++++
> > include/uapi/misc/ocxl.h | 22 ++++++++++++++++++++++
> > 2 files changed, 49 insertions(+)
> >
> > diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
> > index d9aa407db06a..11514a8444e5 100644
> > --- a/drivers/misc/ocxl/file.c
> > +++ b/drivers/misc/ocxl/file.c
> > @@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct
> > ocxl_context *ctx,
> > return rc;
> > }
> >
> > +static long afu_ioctl_get_metadata(struct ocxl_context *ctx,
> > + struct ocxl_ioctl_get_metadata __user *uarg)
>
> Why do we call this metadata? Isn't this an afu_descriptor?
>
It's metadata for the descriptor.
> > +{
> > + struct ocxl_ioctl_get_metadata arg;
> > +
> > + memset(&arg, 0, sizeof(arg));
> > +
> > + arg.version = 0;
>
> Does it make sense to have version 0? Even if does, you can afford
> to skip initialization due to the memset above. I prefer that
> versions
> start with 1
>
Setting it to 0 is for the reader, not the compiler. I'm not clear on
the benefit of starting the version at 1, could you clarify?
> > +
> > + arg.afu_version_major = ctx->afu->config.version_major;
> > + arg.afu_version_minor = ctx->afu->config.version_minor;
> > + arg.pasid = ctx->pasid;
> > + arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride;
> > + arg.global_mmio_size = ctx->afu->config.global_mmio_size;
> > +
> > + if (copy_to_user(uarg, &arg, sizeof(arg)))
> > + return -EFAULT;
> > +
> > + return 0;
> > +}
> > +
> > #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH"
> > : \
> > x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC"
> > : \
> > x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE"
> > : \
> > x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD"
> > : \
> > + x == OCXL_IOCTL_GET_METADATA ?
> > "GET_METADATA" : \
> > "UNKNOWN")
> >
> > static long afu_ioctl(struct file *file, unsigned int cmd,
> > @@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file,
> > unsigned int cmd,
> > irq_fd.eventfd);
> > break;
> >
> > + case OCXL_IOCTL_GET_METADATA:
> > + rc = afu_ioctl_get_metadata(ctx,
> > + (struct ocxl_ioctl_get_metadata
> > __user *) args);
> > + break;
> > +
> > default:
> > rc = -EINVAL;
> > }
> > diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> > index 4b0b0b756f3e..16e1f48ce280 100644
> > --- a/include/uapi/misc/ocxl.h
> > +++ b/include/uapi/misc/ocxl.h
> > @@ -32,6 +32,27 @@ struct ocxl_ioctl_attach {
> > __u64 reserved3;
> > };
> >
> > +/*
> > + * Version contains the version of the struct.
> > + * Versions will always be backwards compatible, that is, new
> > versions will not
> > + * alter existing fields
> > + */
> > +struct ocxl_ioctl_get_metadata {
>
> This sounds more like a function name, do we need it to be
> _get_metdata?
>
It pretty much is a function, it returns to userspace metadata about
the descriptor being operated on.
> > + __u16 version;
> > +
> > + // Version 0 fields
> > + __u8 afu_version_major;
> > + __u8 afu_version_minor;
> > + __u32 pasid;
> > +
> > + __u64 pp_mmio_size;
> > + __u64 global_mmio_size;
> > +
>
> Should we document the fields? pp_ stands for per process, but is not
> very clear at first look. Why do we care to return only the size,
> what
> about lpc size?
>
Yes, I would rather call it per_pasid_mmio_size, but consistency with
the rest of the driver (& exposed sysfs entries) is also important.
> > + // End version 0 fields
> > +
> > + __u64 reserved[13]; // Total of 16*u64
> > +};
>
>
> Balbir Singh.
>
--
Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australiamob: 0423 762 819
^ permalink raw reply
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