Re: [PATCH v2 2/2] Documentation: best practices for using Link trailers
Konstantin Ryabitsev writes: > Based on multiple conversations, most recently on the ksummit mailing > list [1], add some best practices for using the Link trailer, such as: > > - how to use markdown-like bracketed numbers in the commit message to > indicate the corresponding link > - when to use lore.kernel.org vs patch.msgid.link domains > > Cc: ksum...@lists.linux.dev > Link: > https://lore.kernel.org/20240617-arboreal-industrious-hedgehog-5b84ae@meerkat > # [1] > Signed-off-by: Konstantin Ryabitsev > --- > Documentation/process/maintainer-tip.rst | 30 ++ > 1 file changed, 22 insertions(+), 8 deletions(-) > > diff --git a/Documentation/process/maintainer-tip.rst > b/Documentation/process/maintainer-tip.rst > index 64739968afa6..ba312345d030 100644 > --- a/Documentation/process/maintainer-tip.rst > +++ b/Documentation/process/maintainer-tip.rst > @@ -372,17 +372,31 @@ following tag ordering scheme: > > - Link: ``https://link/to/information`` > > - For referring to an email on LKML or other kernel mailing lists, > - please use the lore.kernel.org redirector URL:: > + For referring to an email posted to the kernel mailing lists, please > + use the lore.kernel.org redirector URL:: > > - https://lore.kernel.org/r/email-message@id > + Link: https://lore.kernel.org/email-message-id@here > > - The kernel.org redirector is considered a stable URL, unlike other email > - archives. > + This URL should be used when referring to relevant mailing list > + topics, related patch sets, or other notable discussion threads. > + A convenient way to associate ``Link:`` trailers with the commit > + message is to use markdown-like bracketed notation, for example:: > > - Maintainers will add a Link tag referencing the email of the patch > - submission when they apply a patch to the tip tree. This tag is useful > - for later reference and is also used for commit notifications. > + A similar approach was attempted before as part of a different > + effort [1], but the initial implementation caused too many > + regressions [2], so it was backed out and reimplemented. > + > + Link: https://lore.kernel.org/some-msgid@here # [1] > + Link: https://bugzilla.example.org/bug/12345 # [2] Does it actually make sense to use the Link: prefix here? These sort of links are part of the prose, they're not something a script can download and make any sense of. I see some existing usage of the above style, but equally there's lots of examples of footnote-style links without the Link: tag, eg: commit 40b561e501768ef24673d0e1d731a7b9b1bc6709 Merge: d9f843fbd45e 31611cc8faa0 Author: Arnd Bergmann Date: Mon Apr 29 22:29:44 2024 +0200 Merge tag 'tee-ts-for-v6.10' of https://git.linaro.org/people/jens.wiklander/linux-tee into soc/drivers TEE driver for Trusted Services This introduces a TEE driver for Trusted Services [1]. Trusted Services is a TrustedFirmware.org project that provides a framework for developing and deploying device Root of Trust services in FF-A [2] Secure Partitions. The project hosts the reference implementation of Arm Platform Security Architecture [3] for Arm A-profile devices. ... [1] https://www.trustedfirmware.org/projects/trusted-services/ [2] https://developer.arm.com/documentation/den0077/ [3] https://www.arm.com/architecture/security-features/platform-security The above style is standard markdown style for reference links (or as standard as markdown gets). cheers
[PATCH] Documentation: embargoed-hardware-issues.rst: Add myself for Power
Unfortunately Anton has left IBM. Add myself as the contact for Power, until someone else volunteers. Signed-off-by: Michael Ellerman --- Documentation/process/embargoed-hardware-issues.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index bb2100228cc7..6e9a4597bf2c 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -252,7 +252,7 @@ an involved disclosed party. The current ambassadors list: AMD Tom Lendacky Ampere Darren Hart ARM Catalin Marinas - IBM PowerAnton Blanchard + IBM PowerMichael Ellerman IBM ZChristian Borntraeger IntelTony Luck Qualcomm Trilok Soni -- 2.44.0
Re: [PATCH v3] powerpc/fadump: sysfs for fadump memory reservation
Hari Bathini writes: > On 26/08/19 4:14 PM, Sourabh Jain wrote: >> On 8/26/19 3:46 PM, Sourabh Jain wrote: >>> On 8/26/19 3:29 PM, Hari Bathini wrote: On 10/08/19 11:29 PM, Sourabh Jain wrote: > Add a sys interface to allow querying the memory reserved by > fadump for saving the crash dump. > > Add an ABI doc entry for new sysfs interface. >- /sys/kernel/fadump_mem_reserved > > Signed-off-by: Sourabh Jain > --- > Changelog: > v1 -> v2: > - Added ABI doc for new sysfs interface. > > v2 -> v3: > - Updated the ABI documentation. > --- > > Documentation/ABI/testing/sysfs-kernel-fadump| 6 ++ Shouldn't this be Documentation/ABI/testing/sysfs-kernel-fadump_mem_reserved? >> >> How about documenting fadump_mem_reserved and other sysfs attributes >> suggested >> by you in a single file Documentation/ABI/testing/sysfs-kernel-fadump? > > I wouldn't mind that but please do check if it is breaking a convention.. AIUI a file named like that would hold the documentation for the files inside a directory called /sys/kernel/fadump. And in fact that's probably where these files should live, rather than just dropped directly into /sys/kernel. cheers
Re: [PATCH v4 19/28] docs: powerpc: convert docs to ReST and rename to *.rst
Jonathan Corbet writes: > On Wed, 12 Jun 2019 14:52:55 -0300 > Mauro Carvalho Chehab wrote: > >> Convert docs to ReST and add them to the arch-specific >> book. >> >> The conversion here was trivial, as almost every file there >> was already using an elegant format close to ReST standard. >> >> The changes were mostly to mark literal blocks and add a few >> missing section title identifiers. >> >> One note with regards to "--": on Sphinx, this can't be used >> to identify a list, as it will format it badly. This can be >> used, however, to identify a long hyphen - and "---" is an >> even longer one. >> >> At its new index.rst, let's add a :orphan: while this is not linked to >> the main index.rst file, in order to avoid build warnings. >> >> Signed-off-by: Mauro Carvalho Chehab >> Acked-by: Andrew Donnellan # cxl > > This one fails to apply because ... > > [...] > >> diff --git a/Documentation/PCI/pci-error-recovery.rst >> b/Documentation/PCI/pci-error-recovery.rst >> index 83db42092935..acc21ecca322 100644 >> --- a/Documentation/PCI/pci-error-recovery.rst >> +++ b/Documentation/PCI/pci-error-recovery.rst >> @@ -422,3 +422,24 @@ That is, the recovery API only requires that: >> - drivers/net/cxgb3 >> - drivers/net/s2io.c >> - drivers/net/qlge >> + >> +>>> As of this writing, there is a growing list of device drivers with >> +>>> patches implementing error recovery. Not all of these patches are in >> +>>> mainline yet. These may be used as "examples": >> +>>> >> +>>> drivers/scsi/ipr >> +>>> drivers/scsi/sym53c8xx_2 >> +>>> drivers/scsi/qla2xxx >> +>>> drivers/scsi/lpfc >> +>>> drivers/next/bnx2.c >> +>>> drivers/next/e100.c >> +>>> drivers/net/e1000 >> +>>> drivers/net/e1000e >> +>>> drivers/net/ixgb >> +>>> drivers/net/ixgbe >> +>>> drivers/net/cxgb3 >> +>>> drivers/net/s2io.c >> +>>> drivers/net/qlge > > ...of this, which has the look of a set of conflict markers that managed > to get committed...? I don't think so. There's some other uses of >>> in that file, eg about line 162: >>> The current powerpc implementation assumes that a device driver will >>> *not* schedule or semaphore in this routine; the current powerpc >>> implementation uses one kernel thread to notify all devices; >>> thus, if one device sleeps/schedules, all devices are affected. >>> Doing better requires complex multi-threaded logic in the error >>> recovery implementation (e.g. waiting for all notification threads >>> to "join" before proceeding with recovery.) This seems excessively >>> complex and not worth implementing. So it's just an odd choice of emphasis device I think. cheers
Re: [PATCH] Documentation/stackprotector: powerpc supports stack protector
Jonathan Corbet writes: > On Thu, 30 May 2019 18:37:46 +0530 > Bhupesh Sharma wrote: > >> > This should probably go via the documentation tree? >> > >> > Acked-by: Michael Ellerman >> >> Thanks for the review Michael. >> I am ok with this going through the documentation tree as well. > > Works for me too, but I don't seem to find the actual patch anywhere I > look. Can you send me a copy? You can get it from lore: https://lore.kernel.org/linuxppc-dev/1559212177-7072-1-git-send-email-bhsha...@redhat.com/raw Or patchwork (automatically adds my ack): https://patchwork.ozlabs.org/patch/1107706/mbox/ Or Bhupesh can send it to you :) cheers
Re: [PATCH] Documentation/stackprotector: powerpc supports stack protector
Bhupesh Sharma writes:
> powerpc architecture (both 64-bit and 32-bit) supports stack protector
> mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
> add stack protector support")].
>
> Update stackprotector arch support documentation to reflect the same.
>
> Signed-off-by: Bhupesh Sharma
> ---
> Documentation/features/debug/stackprotector/arch-support.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/features/debug/stackprotector/arch-support.txt
> b/Documentation/features/debug/stackprotector/arch-support.txt
> index ea521f3e..32bbdfc64c32 100644
> --- a/Documentation/features/debug/stackprotector/arch-support.txt
> +++ b/Documentation/features/debug/stackprotector/arch-support.txt
> @@ -22,7 +22,7 @@
> | nios2: | TODO |
> |openrisc: | TODO |
> | parisc: | TODO |
> -| powerpc: | TODO |
> +| powerpc: | ok |
> | riscv: | TODO |
> |s390: | TODO |
> | sh: | ok |
> --
> 2.7.4
Thanks.
This should probably go via the documentation tree?
Acked-by: Michael Ellerman
cheers
Re: [PATCH 0/1] Start conversion of PowerPC docs
Jonathan Corbet writes: > On Thu, 7 Feb 2019 17:03:15 +1100 > "Tobin C. Harding" wrote: > >> As discussed at LCA here is the start to the docs conversion for PowerPC >> to RST. >> >> This applies cleanly on top of the mainline (5.20-rc5) and Jon's tree >> (docs-next branch). >> >> I'm guessing it should go in through the PowerPC tree because I doubt >> you want to review this Jon, it's one big single patch (all blame for >> that falls on mpe ;) > > Well, I went and took a look anyway, being a glutton for punishment. So > naturally I do have some comments... > > - I don't think this should be a top-level directory full of docs; the top > level is already rather overpopulated. At worst, we should create an > arch/ directory for architecture-specific docs. We currently have arch specific directories for arm, arm64, ia64, m68k, nios2, openrisc, parisc, powerpc, s390, sh, sparc, x86, xtensa. Do you mean they should all be moved to Documentation/arch ? > I kind of think that > this should be thought through a bit more, though, with an eye toward > who the audience is. Some of it is clearly developer documentation, and > some of it is aimed at admins; ptrace.rst is user-space API stuff. > Nobody ever welcomes me saying this, but we should really split things > into the appropriate manuals according to audience. I don't think any of it's aimed at admins, but I haven't read every word. I see it as aimed at kernel devs or people writing directly to the kernel API, eg. gdb developers reading ptrace.rst. If Documentation/ wants to be more user focused and nicely curated perhaps we need arch/foo/docs/ for these developer centric docs? > - It would be good to know how much of this stuff is still relevant. > bootwrapper.txt hasn't been modified since it was added in 2008. It hasn't been modified but AFAIK it's still pretty much accurate and definitely something we want to have documented. > cpu_features.txt predates the git era But so does the code it's documenting. > as does mpc52xx.txt; hvcs.txt is nearly as old. And so on. Can we > perhaps stop dragging some of those docs around? We support some hardware that is ~25 years old, so we have some old documentation too, and I'd rather we didn't drop things just because they're old. > - The use of flat-table in isa-versions.rst totally wrecks the readability > of those tables in the plain-text version. Said tables are pretty close > to being RST in their original form; it would be far better to just fix > anything needing fixing but to keep that form. Yes agree, I'd like the docs to be as readable as possible as plain text. > - I'm glad you're adding SPDX lines, but do you know that the license is > correct in each case? It's best to be careful with such things. None of the files have licenses so I think we just fall back to COPYING don't we? In which case GPL-2.0 is correct for all files. cheers
Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES
Jeremy Kerr writes: > Hi Jon, > >>> Signed-off-by: Colin Ian King >>> --- >>> Documentation/filesystems/spufs.txt | 2 +- >>> Documentation/gpu/drm-uapi.rst | 4 ++-- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >> >> Applied, thanks. >> >> This is the first patch to spufs.txt since 2006...I wonder if that stuff >> is being used by anybody... > > Anyone who is using the vector processors on the Cell BE processors will > be using it. However, that hardware is becoming pretty rare now. > > We'll want to remove the spufs bits if/when we drop support for the cell > platforms (IBM QSxx, PS3, celleb). mpe: any ides on that? Do you have a > policy for dropping platform support? I don't have a policy. We discussed it a bit at maintainer summit, that basically boiled down to stuff should get removed when it is not used much and/or is causing undue maintenance burden - both of which are fairly arbitrary criteria. My feeling is spufs is not causing anyone much work, it does get hit by some VFS updates but it's just one of many many filesystems, so the incremental overhead is pretty small I think - though VFS people may disagree :) I still have a working IBM QS22, and Geoff is still maintaining PS3, celleb is gone. Basically we're keeping it around in case people are still using it on their PS3s. I don't know how we gauge how many people that is without removing support and seeing who is annoyed. But even if we did that a lot of folks will probably not notice for months to years, and when they do notice they'll just bin their PS3s rather than telling us. But maybe Geoff has a better feel for how many people (other than him) are still running upstream on PS3s. cheers
Re: [v3] powerpc: wire up memtest
On Fri, 2018-09-28 at 15:39:20 UTC, Christophe Leroy wrote: > Add call to early_memtest() so that kernel compiled with > CONFIG_MEMTEST really perform memtest at startup when requested > via 'memtest' boot parameter. > > Tested-by: Daniel Axtens > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/d90fe2acd9b2900790da01354dbca4 cheers
Re: [PATCH v4 6/7] ocxl: Add an IOCTL so userspace knows what OCXL features are available
"Alastair D'Silva" writes:
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 8d2748e69c84..bb80f294b429 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd {
> #define OCXL_IOCTL_IRQ_SET_FD_IOW(OCXL_MAGIC, 0x13, struct
> ocxl_ioctl_irq_fd)
> #define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct
> ocxl_ioctl_metadata)
> #define OCXL_IOCTL_ENABLE_P9_WAIT_IOR(OCXL_MAGIC, 0x15, struct
> ocxl_ioctl_p9_wait)
> +#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct
> ocxl_ioctl_platform)
I don't have ocxl_ioctl_platform ?
../include/uapi/misc/ocxl.h:78:56: error: invalid application of ‘sizeof’ to
incomplete type ‘struct ocxl_ioctl_platform’
#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct
ocxl_ioctl_platform)
^
../include/uapi/asm-generic/ioctl.h:73:5: note: in definition of macro ‘_IOC’
((size) << _IOC_SIZESHIFT))
^~~~
../include/uapi/asm-generic/ioctl.h:86:56: note: in expansion of macro
‘_IOC_TYPECHECK’
#define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
^~
../include/uapi/misc/ocxl.h:78:33: note: in expansion of macro ‘_IOR’
#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct
ocxl_ioctl_platform)
^~~~
../drivers/misc/ocxl/file.c:262:7: note: in expansion of macro
‘OCXL_IOCTL_GET_FEATURES’
case OCXL_IOCTL_GET_FEATURES:
^~~
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] ocxl: Expose the thread_id needed for wait on POWER9
"Alastair D'Silva" writes:
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 0af83d80fb3e..8d2748e69c84 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata {
> __u64 reserved[13]; // Total of 16*u64
> };
>
> +struct ocxl_ioctl_p9_wait {
> + __u16 thread_id; // The thread ID required to wake this thread
> + __u16 reserved1;
> + __u32 reserved2;
> + __u64 reserved3[3];
> +};
> +
> +};
> +
O_o
???
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
Masahiro Yamada writes: > > > (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) We may do something like this on powerpc, where we have 32/64-bit and big/little endian (on 64-bit) and then some ABI options that we set/unset depending on endian. The above looks like it could work though. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v10,03/27] powerpc: initial pkey plumbing
On Fri, 2018-01-19 at 01:50:24 UTC, Ram Pai wrote: > Basic plumbing to initialize the pkey system. > Nothing is enabled yet. A later patch will enable it > once all the infrastructure is in place. > > Signed-off-by: Ram Pai Patches 3-27 applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/92e3da3cf193fd27996909956c12a2 cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface
Dave Hansen writes: > On 11/06/2017 12:57 AM, Ram Pai wrote: >> Expose useful information for programs using memory protection keys. >> Provide implementation for powerpc and x86. >> >> On a powerpc system with pkeys support, here is what is shown: >> >> $ head /sys/kernel/mm/protection_keys/* >> ==> /sys/kernel/mm/protection_keys/disable_access_supported <== >> true > > This is cute, but I don't think it should be part of the ABI. Put it in > debugfs if you want it for cute tests. The stuff that this tells you > can and should come from pkey_alloc() for the ABI. Yeah I agree this is not sysfs material. In particular the total/usable numbers are completely useless vs other threads allocating pkeys out from under you. > http://man7.org/linux/man-pages/man7/pkeys.7.html > >>Any application wanting to use protection keys needs to be able to >>function without them. They might be unavailable because the >>hardware that the application runs on does not support them, the >>kernel code does not contain support, the kernel support has been >>disabled, or because the keys have all been allocated, perhaps by a >>library the application is using. It is recommended that >>applications wanting to use protection keys should simply call >>pkey_alloc(2) and test whether the call succeeds, instead of >>attempting to detect support for the feature in any other way. > > Do you really not have standard way on ppc to say whether hardware > features are supported by the kernel? For instance, how do you know if > a given set of registers are known to and are being context-switched by > the kernel? Yes we do, we emit feature bits in the AT_HWCAP entry of the aux vector, same as some other architectures. But I don't see the need to use a feature bit for pkeys. If they're not supported then pkey_alloc() will just always fail. Apps have to handle that anyway because keys are a finite resource. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull
Linus Torvalds writes: > On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding wrote: >> >> Linus do you care what protocol? I'm patching Documentation and since >> the point is creating pull requests for you 'some people' don't matter. > > I actually tend to prefer the regular git:// protocol and signed tags. > > It's true that https should have the proper certificate and perhaps > help with DNS spoofing, but I'm not convinced that git won't just > accept self-signed random certs, and I basically don't think we should > trust that. git does not accept self-signed certs by default, at least in recent versions. Though you can do a trust-on-first-use type thing, by downloading the cert and telling git where to find it. So https does provide additional security vs git:// IMHO. There is some verification of the server and your data is encrypted on the wire. It's not like it would be trivial to MITM a git fetch to insert a malicious Makefile change, but it's also not *hard*. > In contrast, using ssh I would actually trust, but it's not convenient > and involves people sending things that aren't necessarily publicly > available. > > So instead, I prefer just using git:// and not trying to fool people > into thinking the protocol is secure - the security should come from > the signed tag. That's true, but only when you're pulling a signed tag, which for most people is not the common case. ... > That said, I actually would prefer even kernel.org repositories to > just send pull requests with signed tags, despite the protocol itself > being secure for that (and only that). Which you mention here. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/4] boot/param: add pointer to next argument to unknown parameter callback
Michal Suchanek writes:
> The fadump parameter processing re-does the logic of next_arg quote
> stripping to determine where the argument ends. Pass pointer to the
> next argument instead to make this more robust.
>
> Signed-off-by: Michal Suchanek
> ---
> arch/powerpc/kernel/fadump.c | 13 +
> arch/powerpc/mm/hugetlbpage.c | 4 ++--
> include/linux/moduleparam.h | 2 +-
> init/main.c | 12 ++--
> kernel/module.c | 4 ++--
> kernel/params.c | 19 +++
> lib/dynamic_debug.c | 2 +-
> 7 files changed, 28 insertions(+), 28 deletions(-)
Can you split out a patch that adds the next argument and updates the
callers. And then a patch for the fadump to use the new arg.
cheers
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index d7da4ce9f7ae..6ef96711ee9a 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -474,13 +474,14 @@ struct param_info {
> };
>
> static void __init fadump_update_params(struct param_info *param_info,
> - char *param, char *val)
> + char *param, char *val, char *next)
> {
> ptrdiff_t param_offset = param - param_info->tmp_cmdline;
> size_t vallen = val ? strlen(val) : 0;
> char *tgt = param_info->cmdline + param_offset +
> FADUMP_EXTRA_ARGS_LEN - param_info->shortening;
> - int shortening = 0;
> + int shortening = ((next - 1) - (param))
> + - (FADUMP_EXTRA_ARGS_LEN + 1 + vallen);
>
> if (!val)
> return;
> @@ -488,10 +489,6 @@ static void __init fadump_update_params(struct
> param_info *param_info,
> /* remove '=' */
> *tgt++ = ' ';
>
> - /* next_arg removes one leading and one trailing '"' */
> - if ((*tgt == '"') && (*(tgt + vallen + shortening) == '"'))
> - shortening += 2;
> -
> /* remove one leading and one trailing quote if both are present */
> if ((val[0] == '"') && (val[vallen - 1] == '"')) {
> shortening += 2;
> @@ -517,7 +514,7 @@ static void __init fadump_update_params(struct param_info
> *param_info,
> * to enforce the parameters passed through it
> */
> static int __init fadump_rework_cmdline_params(char *param, char *val,
> -const char *unused, void *arg)
> + char *next, const char *unused, void *arg)
> {
> struct param_info *param_info = (struct param_info *)arg;
>
> @@ -525,7 +522,7 @@ static int __init fadump_rework_cmdline_params(char
> *param, char *val,
>strlen(FADUMP_EXTRA_ARGS_PARAM) - 1))
> return 0;
>
> - fadump_update_params(param_info, param, val);
> + fadump_update_params(param_info, param, val, next);
>
> return 0;
> }
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index e1bf5ca397fe..3a4cce552906 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -268,8 +268,8 @@ int alloc_bootmem_huge_page(struct hstate *hstate)
>
> unsigned long gpage_npages[MMU_PAGE_COUNT];
>
> -static int __init do_gpage_early_setup(char *param, char *val,
> -const char *unused, void *arg)
> +static int __init do_gpage_early_setup(char *param, char *val, char *unused1,
> +const char *unused2, void *arg)
> {
> static phys_addr_t size;
> unsigned long npages;
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index 1ee7b30dafec..fec05a186c08 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -326,7 +326,7 @@ extern char *parse_args(const char *name,
> s16 level_min,
> s16 level_max,
> void *arg,
> - int (*unknown)(char *param, char *val,
> + int (*unknown)(char *param, char *val, char *next,
>const char *doing, void *arg));
>
> /* Called by module remove. */
> diff --git a/init/main.c b/init/main.c
> index 052481fbe363..920c3564b2f0 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -239,7 +239,7 @@ static int __init loglevel(char *str)
> early_param("loglevel", loglevel);
>
> /* Change NUL term back to "=", to make "param" the whole string. */
> -static int __init repair_env_string(char *param, char *val,
> +static int __init repair_env_string(char *param, char *val, char *unused2,
> const char *unused, void *arg)
> {
> if (val) {
> @@ -257,7 +257,7 @@ static int __init repair_env_string(char *param, char
> *val,
> }
>
> /* Anything after -- gets handed straight to init. */
> -static int __init set_init_arg(char *param, char *val,
> +static int __init set_init_arg(char *param, char *val, c
Re: [PATCH v7 3/4] lib/cmdline.c Remove quotes symmetrically.
Michal Suchanek writes:
> Remove quotes from argument value only if there is qoute on both sides.
>
> Signed-off-by: Michal Suchanek
> ---
> arch/powerpc/kernel/fadump.c | 6 ++
> lib/cmdline.c| 7 ++-
Can you split that into two patches?
cheers
> 2 files changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index a1614d9b8a21..d7da4ce9f7ae 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -489,10 +489,8 @@ static void __init fadump_update_params(struct
> param_info *param_info,
> *tgt++ = ' ';
>
> /* next_arg removes one leading and one trailing '"' */
> - if (*tgt == '"')
> - shortening += 1;
> - if (*(tgt + vallen + shortening) == '"')
> - shortening += 1;
> + if ((*tgt == '"') && (*(tgt + vallen + shortening) == '"'))
> + shortening += 2;
>
> /* remove one leading and one trailing quote if both are present */
> if ((val[0] == '"') && (val[vallen - 1] == '"')) {
> diff --git a/lib/cmdline.c b/lib/cmdline.c
> index 4c0888c4a68d..01e701b2afe8 100644
> --- a/lib/cmdline.c
> +++ b/lib/cmdline.c
> @@ -227,14 +227,11 @@ char *next_arg(char *args, char **param, char **val)
> *val = args + equals + 1;
>
> /* Don't include quotes in value. */
> - if (**val == '"') {
> + if ((**val == '"') && (args[i-1] == '"')) {
> (*val)++;
> - if (args[i-1] == '"')
> - args[i-1] = '\0';
> + args[i-1] = '\0';
> }
> }
> - if (quoted && args[i-1] == '"')
> - args[i-1] = '\0';
>
> if (args[i]) {
> args[i] = '\0';
> --
> 2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v6 21/62] powerpc: introduce execute-only pkey
Thiago Jung Bauermann writes: > Michael Ellerman writes: > >> Thiago Jung Bauermann writes: >>> Ram Pai writes: >> ... >>>> + >>>> + /* We got one, store it and use it from here on out */ >>>> + if (need_to_set_mm_pkey) >>>> + mm->context.execute_only_pkey = execute_only_pkey; >>>> + return execute_only_pkey; >>>> +} >>> >>> If you follow the code flow in __execute_only_pkey, the AMR and UAMOR >>> are read 3 times in total, and AMR is written twice. IAMR is read and >>> written twice. Since they are SPRs and access to them is slow (or isn't >>> it?), >> >> SPRs read/writes are slow, but they're not *that* slow in comparison to >> a system call (which I think is where this code is being called?). > > Yes, this code runs on mprotect and mmap syscalls if the memory is > requested to have execute but not read nor write permissions. Yep. That's not in the fast path for key usage, ie. the fast path is userspace changing the AMR itself, and the overhead of a syscall is already hundreds of cycles. >> So we should try to avoid too many SPR read/writes, but at the same time >> we can accept more than the minimum if it makes the code much easier to >> follow. > > Ok. Ram had asked me to suggest a way to optimize the SPR reads and > writes and I came up with the patch below. Do you think it's worth it? At a glance no I don't think it is. Sorry you spent that much time on it. I think we can probably reduce the number of SPR accesses without needing to go to that level of complexity. But don't throw the patch away, I may eat my words once I have the full series applied and am looking at it hard - at the moment I'm just reviewing the patches piecemeal as I get time. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v6 21/62] powerpc: introduce execute-only pkey
Thiago Jung Bauermann writes: > Ram Pai writes: ... >> + >> +/* We got one, store it and use it from here on out */ >> +if (need_to_set_mm_pkey) >> +mm->context.execute_only_pkey = execute_only_pkey; >> +return execute_only_pkey; >> +} > > If you follow the code flow in __execute_only_pkey, the AMR and UAMOR > are read 3 times in total, and AMR is written twice. IAMR is read and > written twice. Since they are SPRs and access to them is slow (or isn't > it?), SPRs read/writes are slow, but they're not *that* slow in comparison to a system call (which I think is where this code is being called?). So we should try to avoid too many SPR read/writes, but at the same time we can accept more than the minimum if it makes the code much easier to follow. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v6 20/62] powerpc: store and restore the pkey state across context switches
Ram Pai writes: > On Thu, Jul 27, 2017 at 02:32:59PM -0300, Thiago Jung Bauermann wrote: >> Ram Pai writes: >> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c >> > index 2ad725e..9429361 100644 >> > --- a/arch/powerpc/kernel/process.c >> > +++ b/arch/powerpc/kernel/process.c >> > @@ -1096,6 +1096,11 @@ static inline void save_sprs(struct thread_struct >> > *t) >> >t->tar = mfspr(SPRN_TAR); >> >} >> > #endif >> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS >> > + t->amr = mfspr(SPRN_AMR); >> > + t->iamr = mfspr(SPRN_IAMR); >> > + t->uamor = mfspr(SPRN_UAMOR); >> > +#endif >> > } >> > >> > static inline void restore_sprs(struct thread_struct *old_thread, >> > @@ -1131,6 +1136,14 @@ static inline void restore_sprs(struct >> > thread_struct *old_thread, >> >mtspr(SPRN_TAR, new_thread->tar); >> >} >> > #endif >> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS >> > + if (old_thread->amr != new_thread->amr) >> > + mtspr(SPRN_AMR, new_thread->amr); >> > + if (old_thread->iamr != new_thread->iamr) >> > + mtspr(SPRN_IAMR, new_thread->iamr); >> > + if (old_thread->uamor != new_thread->uamor) >> > + mtspr(SPRN_UAMOR, new_thread->uamor); >> > +#endif >> > } >> >> Shouldn't the saving and restoring of the SPRs be guarded by a check for >> whether memory protection keys are enabled? What happens when trying to >> access these registers on a CPU which doesn't have them? > > Good point. need to guard it. However; i think, these registers have been > available since power6. The kernel runs on CPUs much older than that. IAMR was added on Power8. And performance is also an issue, so we should only switch them when we need to. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v6 19/62] powerpc: ability to create execute-disabled pkeys
Ram Pai writes: > On Thu, Jul 27, 2017 at 11:54:31AM -0300, Thiago Jung Bauermann wrote: >> >> Ram Pai writes: >> >> > --- a/arch/powerpc/include/asm/pkeys.h >> > +++ b/arch/powerpc/include/asm/pkeys.h >> > @@ -2,6 +2,18 @@ >> > #define _ASM_PPC64_PKEYS_H >> > >> > extern bool pkey_inited; >> > +/* override any generic PKEY Permission defines */ >> > +#undef PKEY_DISABLE_ACCESS >> > +#define PKEY_DISABLE_ACCESS0x1 >> > +#undef PKEY_DISABLE_WRITE >> > +#define PKEY_DISABLE_WRITE 0x2 >> > +#undef PKEY_DISABLE_EXECUTE >> > +#define PKEY_DISABLE_EXECUTE 0x4 >> > +#undef PKEY_ACCESS_MASK >> > +#define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\ >> > + PKEY_DISABLE_WRITE |\ >> > + PKEY_DISABLE_EXECUTE) >> > + >> >> Is it ok to #undef macros from another header? Especially since said >> header is in uapi (include/uapi/asm-generic/mman-common.h). >> >> Also, it's unnecessary to undef the _ACCESS and _WRITE macros since they >> are identical to the original definition. And since these macros are >> originally defined in an uapi header, the powerpc-specific ones should >> be in an uapi header as well, if I understand it correctly. > > The architectural neutral code allows the implementation to define the > macros to its taste. powerpc headers due to legacy reason includes the > include/uapi/asm-generic/mman-common.h header. That header includes the > generic definitions of only PKEY_DISABLE_ACCESS and PKEY_DISABLE_WRITE. > Unfortunately we end up importing them. I dont want to depend on them. > Any changes there could effect us. Example if the generic uapi header > changed PKEY_DISABLE_ACCESS to 0x4, we will have a conflict with > PKEY_DISABLE_EXECUTE. Hence I undef them and define the it my way. Don't do that. The generic header can't change the values, it's an ABI. Doing it this way risks the uapi value diverging from the value used in the powerpc code (due to a change in the powerpc version), which would mean userspace and the kernel wouldn't agree on what the values meant ... which would be exciting. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v4 17/17] procfs: display the protection-key number associated with a vma
Ram Pai writes: > Display the pkey number associated with the vma in smaps of a task. > The key will be seen as below: > > VmFlags: rd wr mr mw me dw ac key=0 Why wouldn't we just emit a "ProtectionKey:" line like x86 does? See their arch_show_smap(). You should probably also do what x86 does, which is to not display the key on CPUs that don't support keys. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kernel-hardening] Re: [PATCH] gcc-plugins: update architecture list in documentation
Kees Cook writes:
> On Mon, Mar 20, 2017 at 1:39 AM, Michael Ellerman wrote:
>> Andrew Donnellan writes:
>>
>>> Commit 65c059bcaa73 ("powerpc: Enable support for GCC plugins") enabled GCC
>>> plugins on powerpc, but neglected to update the architecture list in the
>>> docs. Rectify this.
>>>
>>> Fixes: 65c059bcaa73 ("powerpc: Enable support for GCC plugins")
>>> Signed-off-by: Andrew Donnellan
>>> ---
>>> Documentation/gcc-plugins.txt | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> It would be nice to merge this for v4.11, so the docs are up to do date
>> with the code for the release.
>>
>> I'm not sure who owns it though, should it go via Jon as docs
>> maintainer (added to CC), or via Kees tree or mine?
>
> If you have other changes queued for v4.11, please take it via your
> tree. Otherwise, perhaps the docs tree or mine? (I don't currently
> have any fixes queued; I'm just trying to minimize pull requests going
> to Linus...)
I have some fixes queued already, so unless Jon yells I'll take it in
the next day or so.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gcc-plugins: update architecture list in documentation
Andrew Donnellan writes:
> Commit 65c059bcaa73 ("powerpc: Enable support for GCC plugins") enabled GCC
> plugins on powerpc, but neglected to update the architecture list in the
> docs. Rectify this.
>
> Fixes: 65c059bcaa73 ("powerpc: Enable support for GCC plugins")
> Signed-off-by: Andrew Donnellan
> ---
> Documentation/gcc-plugins.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
It would be nice to merge this for v4.11, so the docs are up to do date
with the code for the release.
I'm not sure who owns it though, should it go via Jon as docs
maintainer (added to CC), or via Kees tree or mine?
cheers
>
> diff --git a/Documentation/gcc-plugins.txt b/Documentation/gcc-plugins.txt
> index 891c69464434..433eaefb4aa1 100644
> --- a/Documentation/gcc-plugins.txt
> +++ b/Documentation/gcc-plugins.txt
> @@ -18,8 +18,8 @@ because gcc versions 4.5 and 4.6 are compiled by a C
> compiler,
> gcc-4.7 can be compiled by a C or a C++ compiler,
> and versions 4.8+ can only be compiled by a C++ compiler.
>
> -Currently the GCC plugin infrastructure supports only the x86, arm and arm64
> -architectures.
> +Currently the GCC plugin infrastructure supports only the x86, arm, arm64 and
> +powerpc architectures.
>
> This infrastructure was ported from grsecurity [6] and PaX [7].
>
> --
> Andrew Donnellan OzLabs, ADL Canberra
> andrew.donnel...@au1.ibm.com IBM Australia Limited
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] selftests: update filesystems Makefile to work under selftests
Shuah Khan writes: > Update to work under selftests. dnotify_test will not be run as part of > selftests suite and will not included in install targets. It can be built > separately for now. > > Signed-off-by: Shuah Khan > --- > tools/testing/selftests/filesystems/Makefile | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/tools/testing/selftests/filesystems/Makefile > b/tools/testing/selftests/filesystems/Makefile > index 883010c..f1dce5c 100644 > --- a/tools/testing/selftests/filesystems/Makefile > +++ b/tools/testing/selftests/filesystems/Makefile > @@ -1,5 +1,7 @@ > -# List of programs to build > -hostprogs-y := dnotify_test > +TEST_PROGS := dnotify_test > +all: $(TEST_PROGS) > > -# Tell kbuild to always build the programs > -always := $(hostprogs-y) > +include ../lib.mk > + > +clean: > + rm -fr dnotify_test That's a complete rewrite of the Makefile, so I don't think there's any value in bringing its content across from Documentation. Better IMHO would be to squash this with the previous patch, so we get a working test under selftests in a single commit. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] powerpc/mm: movable hotplug memory nodes
Reza Arbab writes: > These changes enable onlining memory into ZONE_MOVABLE on power, and the > creation of discrete nodes of movable memory. > > Node hotplug is not supported on power [1]. But maybe it should be? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
