On 02/21/2018 05:55 PM, Ram Pai wrote:
> From: Thiago Jung Bauermann
>
> The sig_chld() handler calls dprintf2() taking care of setting
> dprint_in_signal so that sigsafe_printf() won't call printf().
> Unfortunately, this precaution is is negated by dprintf_level(), which
> has a call to fflush(
On 02/21/2018 05:55 PM, Ram Pai wrote:
...
> @@ -888,6 +917,7 @@ void setup_hugetlbfs(void)
> void *(*pkey_malloc[])(long size, int prot, u16 pkey) = {
>
> malloc_pkey_with_mprotect,
> + malloc_pkey_with_mprotect_subpage,
> malloc_pkey_anon_huge,
> malloc_pkey_hugetlb
> /*
On 02/21/2018 05:55 PM, Ram Pai wrote:
> Generally the signal handler restores the state of the pkey register
> before returning. However there are times when the read/write operation
> can legitamely fail without invoking the signal handler. Eg: A
> sys_read() operaton to a write-protected page s
On 02/21/2018 05:55 PM, Ram Pai wrote:
> detect write-violation on a page to which access-disabled
> key is associated much after the page is mapped.
Acked-by: Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote:
> detect write-violation on a page to which write-disabled
> key is associated much after the page is mapped.
The more tests the merrier.
Acked-by: Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote:
> detect access-violation on a page to which access-disabled
> key is associated much after the page is mapped.
Looks fine to me. Did this actually find a bug for you?
Acked-by: Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote:
> +static inline int arch_reserved_keys(void)
> +{
> +#if defined(__i386__) || defined(__x86_64__) /* arch */
> + return NR_RESERVED_PKEYS;
> +#elif __powerpc64__ /* arch */
> + if (sysconf(_SC_PAGESIZE) == 4096)
> + return NR_RESERVED_PKEY
When building a uImage or zImage using ppc6xx_defconfig and some other
defconfigs, the following error occurs:
BOOTCC arch/powerpc/boot/fdt.o
In file included from arch/powerpc/boot/fdt.c:51:0:
../arch/powerpc/boot/libfdt_env.h:10:13: error: redefinition of typedef
'uint32_t'
../arch/pow
On 02/21/2018 05:55 PM, Ram Pai wrote:
> #define PAGE_SIZE (0x1UL << 16)
> -static inline int cpu_has_pku(void)
> +static inline bool is_pkey_supported(void)
> {
> - return 1;
> + /*
> + * No simple way to determine this.
> + * lets try allocating a key and see if it succeeds.
>
On 02/21/2018 05:55 PM, Ram Pai wrote:
> diff --git a/tools/testing/selftests/vm/protection_keys.c
> b/tools/testing/selftests/vm/protection_keys.c
> index c4c73e6..e82bd88 100644
> --- a/tools/testing/selftests/vm/protection_keys.c
> +++ b/tools/testing/selftests/vm/protection_keys.c
> @@ -586,7
On 02/21/2018 05:55 PM, Ram Pai wrote:
> static inline u32 pkey_to_shift(int pkey)
> {
> +#if defined(__i386__) || defined(__x86_64__) /* arch */
> return pkey * PKEY_BITS_PER_PKEY;
> +#elif __powerpc64__ /* arch */
> + return (NR_PKEYS - pkey - 1) * PKEY_BITS_PER_PKEY;
> +#endif /* arc
On 02/21/2018 05:55 PM, Ram Pai wrote:
> cleanup the code to satisfy coding styles.
>
> cc: Dave Hansen
> cc: Florian Weimer
> Signed-off-by: Ram Pai
> ---
> tools/testing/selftests/vm/protection_keys.c | 81
> ++
> 1 files changed, 43 insertions(+), 38 deletions(-)
On 02/21/2018 05:55 PM, Ram Pai wrote:
> expected_pkey_fault() is comparing the contents of pkey
> register with 0. This may not be true all the time. There
> could be bits set by default by the architecture
> which can never be changed. Hence compare the value against
> shadow pkey register, which
On 02/21/2018 05:55 PM, Ram Pai wrote:
> open_hugepage_file() <- opens the huge page file
> get_start_key() <-- provides the first non-reserved key.
>
Looks reasonable.
Reviewed-by: Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote:
> alloc_random_pkey() was allocating the same pkey every time.
> Not all pkeys were geting tested. fixed it.
...
> @@ -602,13 +603,15 @@ int alloc_random_pkey(void)
> int alloced_pkeys[NR_PKEYS];
> int nr_alloced = 0;
> int random_index;
> +
On 02/21/2018 05:55 PM, Ram Pai wrote:
> When a key is freed, the key is no more effective.
> Clear the bits corresponding to the pkey in the shadow
> register. Otherwise it will carry some spurious bits
> which can trigger false-positive asserts.
...
> diff --git a/tools/testing/selftests/v
On 02/21/2018 05:55 PM, Ram Pai wrote:
> --- a/tools/testing/selftests/vm/protection_keys.c
> +++ b/tools/testing/selftests/vm/protection_keys.c
> @@ -461,7 +461,7 @@ void pkey_disable_clear(int pkey, int flags)
> pkey, pkey, pkey_rights);
> pkey_assert(pkey_rights >= 0)
On 02/21/2018 05:55 PM, Ram Pai wrote:
> If the flag is 0, no bits will be set. Hence we cant expect
> the resulting bitmap to have a higher value than what it
> was earlier.
>
> cc: Dave Hansen
> cc: Florian Weimer
> Signed-off-by: Ram Pai
> ---
> tools/testing/selftests/vm/protection_keys.c
On 02/21/2018 05:55 PM, Ram Pai wrote:
> +static inline u32 pkey_to_shift(int pkey)
> +{
> + return pkey * PKEY_BITS_PER_PKEY;
> +}
pkey_bit_position(), perhaps?
> +static inline pkey_reg_t reset_bits(int pkey, pkey_reg_t bits)
> +{
> + u32 shift = pkey_to_shift(pkey);
> +
> + return
On 02/21/2018 05:55 PM, Ram Pai wrote:
> -static inline unsigned int _rdpkey_reg(int line)
> +static inline pkey_reg_t _rdpkey_reg(int line)
> {
> - unsigned int pkey_reg = __rdpkey_reg();
> + pkey_reg_t pkey_reg = __rdpkey_reg();
>
> - dprintf4("rdpkey_reg(line=%d) pkey_reg: %x shad
On 02/21/2018 05:55 PM, Ram Pai wrote:
> int pkey_set(int pkey, unsigned long rights, unsigned long flags)
> {
> u32 mask = (PKEY_DISABLE_ACCESS|PKEY_DISABLE_WRITE);
> - u32 old_pkru = __rdpkru();
> - u32 new_pkru;
> + u32 old_pkey_reg = __rdpkey_reg();
> + u32 new_pkey_reg;
Thiago Jung Bauermann writes:
> Now the modsig is only ignored if it references a signature that is not
> present in IMA's keyring (or if there's a parsing error, obviously). If the
The above should read "Now the modsig is only ignored if it references a
*key* that is not present in IMA's keyri
Hi Michael,
On Sat, 17 Mar 2018 01:13:36 +1100 Michael Ellerman wrote:
>
> Stephen Rothwell writes:
>
> > I get the following from a powerpc_ppc44x defconfig build in current
> > linux-next:
> >
> > arch/powerpc/boot/ebony.dtb: Warning (pci_bridge): /plb/pci@20ec0:
> > missing bus-range fo
IMA will need to know the key that signed a given PKCS#7 message, so add
pkcs7_get_message_sig().
It will also need to verify an already parsed PKCS#7 message. For this
purpose, add verify_pkcs7_message_sig() which takes a struct pkcs7_message
for verification instead of the raw bytes that verify_
Define new "d-sig" template field which holds the digest that is expected
to match the one contained in the modsig.
Also add modsig support to the "sig" template field, allowing the the
contents of the modsig to be included in the measurement list.
Suggested-by: Mimi Zohar
Signed-off-by: Thiago
This patch actually implements the appraise_type=imasig|modsig option,
allowing IMA to read and verify modsig signatures.
In case both are present in the same file, IMA will first check whether the
key used by the xattr signature is present in the kernel keyring. If not,
it will try the appended s
This is the code needed by IMA-appraise to work with modsig signatures.
It will be used by the next two patches.
Signed-off-by: Thiago Jung Bauermann
---
security/integrity/ima/Kconfig | 3 +
security/integrity/ima/ima.h| 41
security/integrity/ima/ima_modsig.c | 181 +++
This patch introduces the modsig keyword to the IMA policy syntax to
specify that a given hook should expect the file to have the IMA signature
appended to it. Here is how it can be used in a rule:
appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig
With this rule, IMA will accept either
ima_read_modsig() will need it so that it can show an error message.
Signed-off-by: Thiago Jung Bauermann
---
security/integrity/ima/ima.h| 2 ++
security/integrity/ima/ima_policy.c | 12 ++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/security/integrity/ima/
This avoids a dependency cycle in CONFIG_IMA_APPRAISE_MODSIG (introduced by
a later patch in this series): it will select CONFIG_MODULE_SIG_FORMAT
which in turn selects CONFIG_KEYS. Kconfig then complains that
CONFIG_INTEGRITY_SIGNATURE depends on CONFIG_KEYS.
Signed-off-by: Thiago Jung Bauermann
IMA will only look for a modsig if the xattr sig references a key which is
not in the expected kernel keyring. To that end, introduce
asymmetric_sig_has_known_key().
The logic of extracting the key used in the xattr sig is factored out from
asymmetric_verify() so that it can be used by the new fun
IMA will need to obtain the keyring used to verify file signatures so that
it can verify the module-style signature appended to files.
Signed-off-by: Thiago Jung Bauermann
---
security/integrity/digsig.c| 28 +---
security/integrity/integrity.h | 6 ++
2 files ch
With the introduction of another IMA signature type (modsig), some places
will need to check for both of them. It is cleaner to do that if there's a
helper function to tell whether an xattr_value represents an IMA
signature.
Suggested-by: Mimi Zohar
Signed-off-by: Thiago Jung Bauermann
---
secu
IMA will need to access the digest of the PKCS7 message (as calculated by
the kernel) before the signature is verified, so introduce
pkcs7_get_digest() for that purpose.
Also, modify pkcs7_digest() to detect when the digest was already
calculated so that it doesn't have to do redundant work. Verif
IMA will use the module_signature format for append signatures, so export
the relevant definitions and factor out the code which verifies that the
appended signature trailer is valid.
Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
and be able to use validate_module_sig()
Hello,
The main highlight in this version is that it's not necessary to appraise
the file before storing its measurement anymore. This is possible due to a
new approach that Mimi suggested: we decide whether the modsig should be
used or not at the time it is read from the file, while before we wou
We should zero an array using sizeof instead of number of elements.
Fixes the following compiler (GCC 7.3.0) warnings:
drivers/macintosh/rack-meter.c: In function 'rackmeter_do_pause':
drivers/macintosh/rack-meter.c:157:2: warning: 'memset' used with length equal
to number of elements without mu
On Fri, Mar 16, 2018 at 10:02:22PM +1100, Balbir Singh wrote:
> On Fri, Mar 16, 2018 at 9:33 PM, Ram Pai wrote:
> > Applications need the ability to associate an address-range with some
> > key and latter revert to its initial default key. Pkey-0 comes close to
> > providing this function but fall
On Fri, Mar 16, 2018 at 2:15 AM, Michal Suchánek wrote:
>
> As far as I understand barriers they separate code before the barrier
> and code after the barrier.
Almost certainly not. Even if you were to do an expensive
serialization before the branch, the branch will still predict after
the serial
Michael,
On 03/16/2018 11:18 AM, Michael Ellerman wrote:
I still think the correct, informative messages are a good way to go:)
Yeah I agree.
We probably want to do both, print what's available at boot, and print
what's actually patched when the patching happens.
Nice. Not sure you had a ch
Hi Murilo and Michal,
On 03/16/2018 05:52 AM, Michal Suchánek wrote:
Do we need to take into account if no_rfi_flush == true?
I think it makes sense you are able to override that using debugfs.
It's interface used for diagnostics and testing.
If this was in sysfs it would be a different sto
four/Speculative-page-faults/20180316-151833
>
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G
>
> caused below changes (please refer t
Le 13/03/2018 à 10:30, Christophe Lombard a écrit :
This patch adds new kernel traces in the current in-kernel 'library'
which can be called by other drivers to help interacting with an
IBM XSL on a POWER9 system.
If some kernel traces exist in the 'normal path' to handle a page or a
segment f
On Fri, Mar 16, 2018 at 09:26:53PM +1100, Michael Ellerman wrote:
> Dan Carpenter writes:
> > On Wed, Mar 14, 2018 at 06:22:07PM -0300, Thiago Jung Bauermann wrote:
> >> SF Markus Elfring writes:
> >> > From: Markus Elfring
> >> > Date: Sun, 11 Mar 2018 09:03:42 +0100
> >> >
> >> > Add a jump ta
On Sat, 17 Mar 2018 00:46:33 +1100
Michael Ellerman wrote:
> We've had dynamic ftrace support for over 9 years since Steve first
> wrote it, all the distros use dynamic, and static is basically
> untested these days, so drop support for static ftrace.
>
> Signed-off-by: Michael Ellerman
> ---
>
On Sat, 17 Mar 2018 00:46:32 +1100
Michael Ellerman wrote:
> There is a small but non-zero amount of code required by arches to
> suppory non-dynamic (static) ftrace, and more importantly there is the
> added work of testing both configurations.
>
> There are also almost no down sides to dynamic
Mauricio Faria de Oliveira writes:
> On 03/13/2018 03:36 PM, Michal Suchánek wrote:
>> On Tue, 13 Mar 2018 15:13:11 -0300
>> Mauricio Faria de Oliveira wrote:
>>
>>> On 03/13/2018 02:59 PM, Michal Suchánek wrote:
Maybe it would make more sense to move the messages to the function
that
Nicholas Piggin writes:
> On Tue, 13 Mar 2018 23:41:46 +1100
> Michael Ellerman wrote:
>> Nicholas Piggin writes:
>> > diff --git a/arch/powerpc/platforms/pseries/kexec.c
>> > b/arch/powerpc/platforms/pseries/kexec.c
>> > index eeb13429d685..3fe126796975 100644
>> > --- a/arch/powerpc/platforms
Stephen Rothwell writes:
> Hi all,
>
>
> I get the following from a powerpc_ppc44x defconfig build in current
> linux-next:
>
> arch/powerpc/boot/ebony.dtb: Warning (pci_bridge): /plb/pci@20ec0:
> missing bus-range for PCI bridge
> arch/powerpc/boot/ebony.dtb: Warning (pci_device_bus_num): F
Christophe LEROY writes:
> Le 25/02/2018 à 18:22, Mathieu Malaterre a écrit :
>> Since the value of `tmp` is never intended to be read, declare both `tmp`
>> variables as unused. Fix warning (treated as error in W=1):
>
> What about using fault_in_pages_readable() instead ?
Yeah that looks like
Dmitry Torokhov writes:
> On Wed, Mar 14, 2018 at 10:17:52PM +1100, Michael Ellerman wrote:
>> The analog joystick driver spits a warning at us:
>>
>> drivers/input/joystick/analog.c:176:2: warning: #warning Precise timer
>> not defined for this architecture.
>>
>> PPC has get_cycles() so us
We've had dynamic ftrace support for over 9 years since Steve first
wrote it, all the distros use dynamic, and static is basically
untested these days, so drop support for static ftrace.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/inclu
There is a small but non-zero amount of code required by arches to
suppory non-dynamic (static) ftrace, and more importantly there is the
added work of testing both configurations.
There are also almost no down sides to dynamic ftrace once it's well
tested, other than a small increase in code/data
Hi Michal,
Thanks for working on this series in the absence of any documentation.
Michal Suchánek writes:
> On Fri, 16 Mar 2018 15:18:23 +1000
> Nicholas Piggin wrote:
>
>> On Thu, 15 Mar 2018 20:15:52 +0100
>> Michal Suchanek wrote:
>>
>> > On powerpc syscall entry is done in assembly so pat
Linus Torvalds writes:
> On Thu, Mar 15, 2018 at 12:15 PM, Michal Suchanek wrote:
>> This is based on x86 patch doing the same.
>>
>> Signed-off-by: Michal Suchanek
>> ---
>> --- a/arch/powerpc/include/asm/uaccess.h
>> +++ b/arch/powerpc/include/asm/uaccess.h
>> @@ -258,8 +259,10 @@ do {
Bjorn Helgaas created a patch for making PCI_SCAN_ALL_PCIE_DEVS work for
Root Ports as well as Downstream. Previously PCI_SCAN_ALL_PCIE_DEVS (set
by quirks or the "pci=pcie_scan_all"
kernel parameter) only affected Switch Downstream Ports, not Root Ports.
The problem is, that we have to add alwa
On 02 December 2017 at 00:27PM, Bjorn Helgaas wrote:
> On Fri, Dec 01, 2017 at 11:08:46PM +0100, Christian Zigotzky wrote:
>> On 30.11.2017 23:42, Bjorn Helgaas wrote:
>>>
>>> 00:11.0 claims to be a PCIe Root Port leading to [bus 05-06]. That
>>> means there's a Link (presumably this A-Link II Exp
CC arch/powerpc/xmon/spu-dis.o
../arch/powerpc/xmon/spu-dis.c: In function ‘print_insn_spu’:
../arch/powerpc/xmon/spu-dis.c:137:18: error: format ‘%d’ expects argument of
type ‘int’, but argument 2 has type ‘long unsigned int’ [-Werror=format=]
printf("$%d",
^
../a
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘prregs’:
../arch/powerpc/xmon/xmon.c:1665:17: error: format ‘%ld’ expects argument of
type ‘long int’, but argument 2 has type ‘int’ [-Werror=format=]
printf("R%.2ld = "REG" R%.2ld = "REG"\n",
^
../
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘dump_one_paca’:
../arch/powerpc/xmon/xmon.c:2339:9: error: '#' flag used with ‘%p’ gnu_printf
format [-Werror=format=]
printf(" %-*s = %#-*"format"\t(0x%lx)\n", 20, #name, 18, paca->name, \
^
../arch/powerpc/xm
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘dump_spu_fields’:
../arch/powerpc/xmon/xmon.c:3827:10: error: format ‘%d’ expects argument of
type ‘int’, but argument 4 has type ‘u64 {aka long long unsigned int}’
[-Werror=format=]
printf(" %-*s = "format"\n", DUMP
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘dump_one_paca’:
../arch/powerpc/xmon/xmon.c:2339:9: error: format ‘%llx’ expects argument of
type ‘long long unsigned int’, but argument 5 has type ‘long unsigned int’
[-Werror=format=]
printf(" %-*s = %#-*"format"\t(0
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘dump_spu_ls’:
../arch/powerpc/xmon/xmon.c:3896:50: error: format ‘%d’ expects argument of
type ‘int’, but argument 2 has type ‘long unsigned int’ [-Werror=format=]
printf("*** Error: accessing spu info for spu %d\n", n
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘dump_one_paca’:
../arch/powerpc/xmon/xmon.c:2339:9: error: format ‘%lx’ expects argument of
type ‘long unsigned int’, but argument 5 has type ‘u64 {aka long long unsigned
int}’ [-Werror=format=]
printf(" %-*s = %#-*"fo
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘dump_spu_fields’:
../arch/powerpc/xmon/xmon.c:3827:10: error: format ‘%p’ expects argument of
type ‘void *’, but argument 4 has type ‘long long unsigned int’
[-Werror=format=]
printf(" %-*s = "format"\n", DUMP_WIDTH,
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘dump_one_paca’:
../arch/powerpc/xmon/xmon.c:2380:43: error: format ‘%lx’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘u32 {aka unsigned int}’
[-Werror=format=]
printf(" slb_cache[%d]:
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘cpu_cmd’:
../arch/powerpc/xmon/xmon.c:1168:18: error: format ‘%x’ expects argument of
type ‘unsigned int’, but argument 2 has type ‘long unsigned int’
[-Werror=format=]
printf("cpu 0x%x isn't in xmon\n", cpu);
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘excprint’:
../arch/powerpc/xmon/xmon.c:1625:26: error: format ‘%lx’ expects argument of
type ‘long unsigned int’, but argument 2 has type ‘struct paca_struct *’
[-Werror=format=]
printf(" paca= 0x%lx\t softe: %d\t
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘show_pte’:
../arch/powerpc/xmon/xmon.c:3016:24: error: format ‘%lx’ expects argument of
type ‘long unsigned int’, but argument 2 has type ‘pgd_t * {aka struct
*}’ [-Werror=format=]
printf("pgd @ 0x%016lx\n", pgdir);
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘excprint’:
../arch/powerpc/xmon/xmon.c:1629:25: error: format ‘%ld’ expects argument of
type ‘long int’, but argument 2 has type ‘pid_t {aka int}’ [-Werror=format=]
printf("pid = %ld, comm = %s\n",
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘dump_by_size’:
../arch/powerpc/xmon/xmon.c:2570:16: error: format ‘%lx’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘u64 {aka long long unsigned
int}’ [-Werror=format=]
printf("%0*lx", size
CC arch/powerpc/xmon/xmon.o
arch/powerpc/xmon/xmon.c: In function ‘xmon_core’:
arch/powerpc/xmon/xmon.c:630:36: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 2 has type ‘int’ [-Werror=format=]
printf("Stopped at breakpoint %lx (", BP_NUM(bp));
also remove extra fp->link since no formatter associated.
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘excprint’:
../arch/powerpc/xmon/xmon.c:1607:31: error: format ‘%lx’ expects argument of
type ‘long unsigned int’, but argument 4 has type ‘struct pt_regs *’
[-We
This series is part of my warning fixes branch. When preparing the patch, I
figured that sending it as single patch would make the reviewing task fairly
difficult. I decided to split it into fake commits and group them by warning
types to make reviewing much easier. Obviously this series is not mea
CC arch/powerpc/xmon/xmon.o
arch/powerpc/xmon/xmon.c: In function ‘memdiffs’:
arch/powerpc/xmon/xmon.c:2863:17: error: format ‘%x’ expects argument of type
‘unsigned int’, but argument 2 has type ‘unsigned char *’ [-Werror=format=]
printf("%.16x %.2x # %.16x %.2x\n", p1 - 1,
CC arch/powerpc/xmon/xmon.o
../arch/powerpc/xmon/xmon.c: In function ‘memdiffs’:
../arch/powerpc/xmon/xmon.c:2866:17: error: format ‘%x’ expects argument of
type ‘unsigned int’, but argument 2 has type ‘unsigned char *’ [-Werror=format=]
printf("%.16x %.2x # %.16x %.2x\n", p1 - 1,
Update also the other prototype declaration in asm/xmon.h.
Silence warnings (triggered at W=1) by adding relevant __printf attribute.
Move #define at bottom of the file to prevent conflict with gcc attribute.
CC arch/powerpc/xmon/nonstdio.o
arch/powerpc/xmon/nonstdio.c: In function ‘xmon_p
On Fri, Mar 16, 2018 at 9:33 PM, Ram Pai wrote:
> Applications need the ability to associate an address-range with some
> key and latter revert to its initial default key. Pkey-0 comes close to
> providing this function but falls short, because the current
> implementation disallows applications t
On Fri, 16 Mar 2018 10:15:49 +0100
Michal Suchánek wrote:
> Hello,
>
> On Fri, 16 Mar 2018 15:18:23 +1000
> Nicholas Piggin wrote:
>
> > On Thu, 15 Mar 2018 20:15:52 +0100
> > Michal Suchanek wrote:
> >
> > > On powerpc syscall entry is done in assembly so patch in an explicit
> > > barrie
Applications need the ability to associate an address-range with some
key and latter revert to its initial default key. Pkey-0 comes close to
providing this function but falls short, because the current
implementation disallows applications to explicitly associate pkey-0 to
the address range.
Clar
Joe Perches writes:
> On Thu, 2018-03-15 at 14:57 +0300, Dan Carpenter wrote:
>> On Wed, Mar 14, 2018 at 06:22:07PM -0300, Thiago Jung Bauermann wrote:
>> > SF Markus Elfring writes:
>> > > From: Markus Elfring
>> > > Date: Sun, 11 Mar 2018 09:03:42 +0100
>> > >
>> > > Add a jump target so that
Dan Carpenter writes:
> On Wed, Mar 14, 2018 at 06:22:07PM -0300, Thiago Jung Bauermann wrote:
>> SF Markus Elfring writes:
>> > From: Markus Elfring
>> > Date: Sun, 11 Mar 2018 09:03:42 +0100
>> >
>> > Add a jump target so that a bit of exception handling can be better reused
>> > at the end of
Stephen Rothwell writes:
> Hi all,
>
> These warnings have beeen around for a while now;
>
> drivers/macintosh/rack-meter.c:157:2: warning: 'memset' used with length
> equal to number of elements without multiplication by element size
> [-Wmemset-elt-size]
> memset(rdma->buf1, 0, ARRAY_SIZE(rd
xmon can be entered via sreset NMI (from a management sreset, or an
NMI IPI), which can interrupt OPAL. xmon will then issue OPAL calls
to read and write the console, which re-enter OPAL and will destroy
the OPAL stack. So xmon must not attempt to recover in this case.
Signed-off-by: Nicholas Pigg
opal_nvram_write currently just assumes success if it encounters an
error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
on other errors instead.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/platforms/powernv/opal-nvram.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arc
system_reset_exception does most of its own crash handling now,
invoking the debugger or crash dumps if they are registered. If not,
then it goes through to die() to print stack traces, and then is
supposed to panic (according to comments).
However after die() prints oopses, it does its own handli
System Reset, being an NMI, must return more carefully than other
interrupts. It has traditionally returned via the nromal return
from exception path, but that has a number of problems.
- r13 does not get restored if returning to kernel. This is for
interrupts which may cause a context switch, w
This code seems to never end. This series attempts to make sreset
debugging more robust, particularly I'm looking at taking exceptions
from CPUs within OPAL. This is starting to work to a degree now (with
some skiboot patches I'll post in a minute). At least we can examine
registers of the CPU from
Hi Aaro,
On Fri, 16 Mar 2018 11:37:47 +0200 Aaro Koskinen wrote:
>
> I can send a fix for this and test on Xserve.
Excellent. (I should send emails about more old warnings :-))
--
Cheers,
Stephen Rothwell
pgpZq9olF2Lag.pgp
Description: OpenPGP digital signature
Hi,
On Fri, Mar 16, 2018 at 04:46:14PM +1100, Stephen Rothwell wrote:
> These warnings have beeen around for a while now;
>
> drivers/macintosh/rack-meter.c:157:2: warning: 'memset' used with length
> equal to number of elements without multiplication by element size
> [-Wmemset-elt-size]
> m
On Fri, 16 Mar 2018 09:08:10 +0100
Greg Kroah-Hartman wrote:
> On Thu, Mar 15, 2018 at 08:15:49PM +0100, Michal Suchanek wrote:
> > Yes, it is good idea to add some commit messages.
>
> Always a good idea :)
>
> Also, any reason you are not tagging these for the stable release(s)?
Oh, right.
Hello,
On Fri, 16 Mar 2018 15:18:23 +1000
Nicholas Piggin wrote:
> On Thu, 15 Mar 2018 20:15:52 +0100
> Michal Suchanek wrote:
>
> > On powerpc syscall entry is done in assembly so patch in an explicit
> > barrier_nospec.
>
> Same comment as Linus for this -- the barriers are before the bra
On Thu, 15 Mar 2018 17:36:00 -0300
Murilo Opsfelder Araujo wrote:
> On 03/14/2018 07:40 PM, Mauricio Faria de Oliveira wrote:
> > From: Michael Ellerman
> >
> > rfi_flush_enable() includes a check to see if we're already
> > enabled (or disabled), and in that case does nothing.
> >
> > But tha
Hi Desnes,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Thu, Mar 15, 2018 at 08:15:49PM +0100, Michal Suchanek wrote:
> Yes, it is good idea to add some commit messages.
Always a good idea :)
Also, any reason you are not tagging these for the stable release(s)?
thanks,
greg k-h
95 matches
Mail list logo
