> * The proto-VSIDs are then scrambled into real VSIDs with the
> * multiplicative hash:
> ...
> * VSID_MULTIPLIER is prime, so in particular it is
> * co-prime to VSID_MODULUS, making this a 1:1 scrambling function.
> * Because the modulus is 2^n-1 we can compute it efficiently without
>
> I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
> IMHO, the warning/documentation should suffice for anybody wanting to
> try out this locking scheme for other use-cases.
I presume that by 'fairness' you mean 'write preference'?
I'd not sure how difficult it would be, but
> On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote:
> > All accessed to PGD entries are done via 0(r11).
> > By using lower part of swapper_pg_dir as load index to r11, we can remove
> > the
> > ori instruction.
> >
> > Signed-off-by: Christophe Leroy
>
> Nice :)
> Acked-by: Joakim Tjer
From: leroy christophe
> Le 06/01/2015 13:08, David Laight a écrit :
> >> On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote:
> >>> All accessed to PGD entries are done via 0(r11).
> >>> By using lower part of swapper_pg_dir as load index to r11
From: Anton Blanchard
> I noticed ksm spending quite a lot of time in memcmp on a large
> KVM box. The current memcmp loop is very unoptimised - byte at a
> time compares with no loop unrolling. We can do much much better.
>
> Optimise the loop in a few ways:
>
> - Unroll the byte at a time loop
From: Joakim Tjernlund
> On Mon, 2015-01-12 at 11:55 +1100, Anton Blanchard wrote:
> > Hi David,
> >
> > > The unrolled loop (deleted) looks excessive.
> > > On a modern cpu with multiple execution units you can usually
> > > manage to get the loop overhead to execute in parallel to the
> > > actu
From Christophe Leroy
> Having a macro will help keep clear code.
It might remove an #if but it doesn't really help.
All it means is that anyone reading the code has to hunt for
the definition before proceeding.
Some comment about what (and why) the extra code is needed
might help.
...
> +
> +#i
From: leroy
> Le 20/01/2015 12:09, David Laight a écrit :
> > From Christophe Leroy
> >> Having a macro will help keep clear code.
> > It might remove an #if but it doesn't really help.
> > All it means is that anyone reading the code has to hunt for
&
From: David Gibson
> arch/powerpc/include/asm/swab.h includes some powerpc specific
> byteswapping functions, which are implemented in terms of powerpc's
> built in byte reversed load/store instructions. There are two problems with
> this:
>
> 1) They're not necessary - gcc is perfectly capable
From: Markus Stockhausen
> 4K AES tables for big endian
I can't help feeling that you could give more information about how the
values are generated.
...
> + * These big endian AES encryption/decryption tables are designed to be
> simply
> + * accessed by a combination of rlwimi/lwz instruction
From: Ingo Molnar
...
> So why not trylock and time out here after a few seconds,
> instead of indefinitely supressing some potentially vital
> output due to some other CPU crashing/locking with the lock
> held?
I've used that for status requests that usually lock a table
to get a consistent view.
From: Markus Stockhausen
> [PATCH v1 1/3] SHA1 for PPC/SPE - assembler
>
> This is the assembler code for SHA1 implementation with
> the SIMD SPE instruction set. With the enhanced instruction
> set we can operate on 2 32 bit words in parallel. That helps
> reducing the time to calculate W16-W79.
From: Stephen Rothwell
> This runs a bit faster and removes another use of perl from
> the kernel build.
...
> diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh
> new file mode 100755
> index ..182eae9cc40d
> --- /dev/null
> +++ b/arch/powerpc/relocs_check.sh
> @@
From: Thomas Gleixner
> Sent: 20 October 2019 20:53
> On Sun, 20 Oct 2019, Andreas Schwab wrote:
> > On Okt 20 2019, Thomas Gleixner wrote:
> >
> > > POSIX does not mention anything about the validity of the pointer handed
> > > to
> > > clock_getres().
> >
> > Sure it does: "If the argument res i
From: Segher Boessenkool
> Sent: 24 October 2019 18:29
> On Thu, Oct 24, 2019 at 11:47:30AM +1100, Michael Ellerman wrote:
> > Some of our scripts are passed $objdump and then call it as
> > "$objdump". This doesn't work if it contains spaces because we're
> > using ccache, for example you get erro
From: Nathan Chancellor
> Sent: 28 August 2019 19:45
...
> However, I think that -fno-builtin-* would be appropriate here because
> we are providing our own setjmp implementation, meaning clang should not
> be trying to do anything with the builtin implementation like building a
> declaration for i
From: Nathan Chancellor [mailto:natechancel...@gmail.com]
> Sent: 04 September 2019 01:24
> On Tue, Sep 03, 2019 at 02:31:28PM -0500, Segher Boessenkool wrote:
> > On Mon, Sep 02, 2019 at 10:55:53PM -0700, Nathan Chancellor wrote:
> > > On Thu, Aug 29, 2019 at 09:59:48AM +000
From: Bjorn Helgaas
> Sent: 27 September 2019 23:02
> On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote:
> > When hot-adding a device, the bridge may have windows not big enough (or
> > fragmented too much) for newly requested BARs to fit in. And expanding
> > these bridge windo
From: Segher Boessenkool
> Sent: 21 December 2020 16:32
>
> On Mon, Dec 21, 2020 at 04:17:21PM +0100, Christophe Leroy wrote:
> > Le 21/12/2020 à 04:27, Xiaoming Ni a écrit :
> > >Since the commit 2b0e86cc5de6 ("powerpc/fsl_booke/32: implement KASLR
> > >infrastructure"), the powerpc system is rea
From: Andy Lutomirski
> Sent: 29 December 2020 00:36
...
> I mean that the mapping from the name "sync_core" to its semantics is
> x86 only. The string "sync_core" appears in the kernel only in
> arch/x86, membarrier code, membarrier docs, and a single SGI driver
> that is x86-only. Sure, the ide
From: Christoph Hellwig
> Sent: 21 September 2020 15:34
>
> Stop duplicating the iovec verify code, and instead add add a
> __import_iovec helper that does the whole verify and import, but takes
> a bool compat to decided on the native or compat layout. This also
> ends up massively simplifying
From: sonicadvan...@gmail.com
> Sent: 15 January 2021 07:03
> Problem presented:
> A backwards compatibility layer that allows running x86-64 and x86
> processes inside of an AArch64 process.
> - CPU is emulated
> - Syscall interface is mostly passthrough
> - Some syscalls require patching or
...
> He's already doing the system call emulation for all the system
> calls other than ioctl in user space though. In my experience,
> there are actually fairly few ioctl commands that are different
> between architectures -- most of them have no misaligned
> or architecture-defined struct member
From: Christophe Leroy
> Sent: 20 January 2021 07:49
>
> STDBINUTILS is just a toggle to allow 256k page size
> to appear in the possible page sizes list for the 44x.
>
> Make 256k page size appear all the time with an
> explicit warning on binutils, and remove this unneccessary
> STDBINUTILS con
From: Christophe Leroy
> Sent: 21 January 2021 10:00
>
> Le 21/01/2021 à 08:49, Christoph Hellwig a écrit :
> > Add a helper that takes modules_mutex and uses find_module to check if a
> > given module is loaded. This provides a better abstraction for the two
> > callers, and allows to unexport m
>
> On Thu, Jan 21, 2021 at 11:00:20AM +0100, Christophe Leroy wrote:
> > > +bool module_loaded(const char *name);
> >
> > Maybe module_is_loaded() would be a better name.
>
> Fine with me.
It does look like both callers aren't 'unsafe'.
But it is a bit strange returning a stale value.
It did m
From: Christophe Leroy
> Sent: 25 January 2021 09:15
>
> Le 24/01/2021 à 09:22, Nicholas Piggin a écrit :
> > Support huge page vmalloc mappings. Config option HAVE_ARCH_HUGE_VMALLOC
> > enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
> > supports PMD sized vmap mappings.
> >
From: Nicholas Piggin
> Sent: 26 January 2021 10:21
>
> Excerpts from Christophe Leroy's message of January 26, 2021 12:48 am:
> > syscall_64.c will be reused almost as is for PPC32.
> >
> > Rename it syscall.c
>
> Could you rename it to interrupt.c instead? A system call is an
> interrupt, and t
From: Christopher M. Riedl
> Sent: 28 January 2021 04:04
>
> Reuse the "safe" implementation from signal.c except for calling
> unsafe_copy_from_user() to copy into a local buffer.
>
> Signed-off-by: Christopher M. Riedl
> ---
> arch/powerpc/kernel/signal.h | 33
From: Christopher M. Riedl
> Sent: 01 February 2021 15:56
>
> On Thu Jan 28, 2021 at 4:38 AM CST, David Laight wrote:
> > From: Christopher M. Riedl
> > > Sent: 28 January 2021 04:04
> > >
> > > Reuse the "safe" implementation from signal.c exce
From: Christopher M. Riedl
> Sent: 01 February 2021 16:55
...
> > > > > + int i;
> > > > > \
> > > > > +
> > > > > \
> > > > > + unsafe_copy_from_user(buf, __f, ELF
From: Segher Boessenkool
> Sent: 03 February 2021 21:18
...
> Power9 does:
>
> Load with Update Instructions (RA = 0)
> EA is placed into R0.
Does that change the value of 0?
Rather reminds me of some 1960s era systems that had the small integers
at fixed (global) addresses.
FORTRAN always
From: Segher Boessenkool
> Sent: 09 February 2021 13:51
>
> On Tue, Feb 09, 2021 at 12:36:20PM +1000, Nicholas Piggin wrote:
> > What if you did this?
>
> > +static inline struct task_struct *get_current(void)
> > +{
> > + register struct task_struct *task asm ("r2");
> > +
> > + return task;
From: Christophe Leroy
> Sent: 09 February 2021 17:04
>
> Le 09/02/2021 à 15:31, David Laight a écrit :
> > From: Segher Boessenkool
> >> Sent: 09 February 2021 13:51
> >>
> >> On Tue, Feb 09, 2021 at 12:36:20PM +1000, Nicholas Piggin wrote:
> >&g
From: Linuxppc-dev Guenter Roeck
> Sent: 11 March 2021 21:35
>
> On 3/11/21 1:17 PM, Chris Packham wrote:
> >
> > On 11/03/21 9:18 pm, Wolfram Sang wrote:
> >>> Bummer. What is really weird is that you see clock stretching under
> >>> CPU load. Normally clock stretching is triggered by the device,
From: Chris Packham
> Sent: 14 March 2021 21:26
>
> On 12/03/21 10:25 pm, David Laight wrote:
> > From: Linuxppc-dev Guenter Roeck
> >> Sent: 11 March 2021 21:35
> >>
> >> On 3/11/21 1:17 PM, Chris Packham wrote:
> >>> On 11/03/21 9:18 pm, Wo
From: Rasmus Villemoes
> Sent: 15 March 2021 16:24
>
> On 12/03/2021 03.29, Segher Boessenkool wrote:
> > Hi!
> >
> > On Tue, Mar 09, 2021 at 06:19:30AM +, Christophe Leroy wrote:
> >> With some defconfig including CONFIG_CC_OPTIMIZE_FOR_SIZE,
> >> (for instance mvme5100_defconfig and ps3_defc
From: Segher Boessenkool
> Sent: 16 March 2021 00:00
...
> > Although you may need to disable loop unrolling (often dubious at best)
> > and either force or disable some function inlining.
>
> The cases where GCC does loop unrolling at -O2 always help quite a lot.
> Or, do you have a counter-examp
From: Jordan Niethe
> Sent: 07 August 2023 02:46
>
> The LPID register is 32 bits long. The host keeps the lpids for each
> guest in an unsigned word struct kvm_arch. Currently, LPIDs are already
> limited by mmu_lpid_bits and KVM_MAX_NESTED_GUESTS_SHIFT.
>
> The nestedv2 API returns a 64 bit "Gu
...
> All of "\\n", "\n", '\n' are the same.
and \\n (without any quote characters at all).
Personally I'd use 'format' for printf.
To make it obvious that nothing is to be expanded.
But it isn't really worth changing existing 'stuff'.
David
-
Registered Address Lakeside, Bramley Road,
...
I've got a target to generate AER errors by generating read cycles
that are inside the address range that the bridge forwards but
outside of any BAR because there are 2 different sized BARs.
(Pretty easy to setup.)
On the system I was using they didn't get propagated all the way
to the root bri
> It would be nice if they worked the same, but I suspect that vendors
> may rely on the fact that CPER_SEV_FATAL forces a restart/panic as
> part of their system integrity story.
The file system errors created by a panic (especially an NMI panic)
could easily be more problematic than a failed PCI
From: Shuai Xue
> Sent: 25 September 2023 02:44
>
> On 2023/9/21 21:20, David Laight wrote:
> > ...
> > I've got a target to generate AER errors by generating read cycles
> > that are inside the address range that the bridge forwards but
> > outside of any B
From: Athira Rajeev
> Sent: 29 September 2023 05:12
>
> Running shellcheck on tests/shell/test_arm_coresight.sh
> throws below warnings:
>
> In tests/shell/test_arm_coresight.sh line 15:
> cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name cpu*
> -print -quit)
>
From: David Laight
> Sent: 05 October 2023 11:16
...
> > - cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name cpu*
> > -print -quit)
> > + cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name 'cpu*'
> > -print -quit)
>
> Isn
From: Segher Boessenkool
> Sent: 13 February 2024 19:13
>
> On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote:
> > clang warns about explicitly casting between incompatible function
> > pointers:
> >
> > drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void
> > *)'
From: Christophe Leroy
> Sent: 23 February 2024 10:07
...
> > +/* Ethernet headers are 14 bytes and NET_IP_ALIGN is used to align them */
> > +#define IP_ALIGNMENT (14 + NET_IP_ALIGN)
>
> Only if no VLAN.
>
> When using VLANs it is 4 bytes more. But why do you mind that at all ?
Wasn't one archi
From: Adrian Hunter
> Sent: 11 April 2024 10:04
>
> On 11/04/24 10:56, Arnd Bergmann wrote:
> > On Thu, Apr 11, 2024, at 09:16, Adrian Hunter wrote:
> >> On 11/04/24 10:04, Arnd Bergmann wrote:
> >>> On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote:
> BUG() does not return, and arch implem
From: Segher Boessenkool
> Sent: 16 April 2024 11:38
>
> On Tue, Apr 16, 2024 at 03:02:52PM +0530, Naresh Kamboju wrote:
> > In file included from arch/powerpc/include/asm/io.h:672:
> > arch/powerpc/include/asm/io-defs.h:43:1: error: performing pointer
> > arithmetic on a null pointer has undefine
From: Aleksa Sarai
> Sent: 25 July 2023 17:36
...
> We almost certainly want to support AT_EMPTY_PATH at the same time.
> Otherwise userspace will still need to go through /proc when trying to
> chmod a file handle they have.
That can't be allowed.
Just because a process has a file open and write
...
> FWIW, I agree with Christian that these behaviours are not ideal (and
> I'm working on a series that might allow for these things to be properly
> blocked in the future) but there's also the consistency argument -- I
> don't think fchownat() is much safer to allow in this way than
> fchmodat(
From: guo...@kernel.org
> Sent: 27 February 2022 16:28
>
> From: Christoph Hellwig
>
> Provide a single common definition for the compat_flock and
> compat_flock64 structures using the same tricks as for the native
> variants. Another extra define is added for the packing required on
> x86.
...
From: Guo Ren
> Sent: 28 February 2022 11:52
>
> On Mon, Feb 28, 2022 at 2:40 PM David Laight wrote:
> >
> > From: guo...@kernel.org
> > > Sent: 27 February 2022 16:28
> > >
> > > From: Christoph Hellwig
> > >
> >
From: Guo Ren
> Sent: 28 February 2022 12:13
>
> On Mon, Feb 28, 2022 at 8:02 PM David Laight wrote:
> >
> > From: Guo Ren
> > > Sent: 28 February 2022 11:52
> > >
> > > On Mon, Feb 28, 2022 at 2:40 PM David Laight
> > > wrote:
&
From: Linus Torvalds
> Sent: 28 February 2022 19:56
> On Mon, Feb 28, 2022 at 4:19 AM Christian König
> wrote:
> >
> > I don't think that using the extra variable makes the code in any way
> > more reliable or easier to read.
>
> So I think the next step is to do the attached patch (which require
From: Matthew Wilcox
> Sent: 28 February 2022 20:16
>
> On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> > We can do
> >
> > typeof(pos) pos
> >
> > in the 'for ()' loop, and never use __iter at all.
> >
> > That means that inside the for-loop, we use a _different_ 'pos' t
From: Christophe Leroy
> Sent: 01 March 2022 10:20
>
> Le 13/02/2022 à 18:47, David Laight a écrit :
> > From: Segher Boessenkool
> >> Sent: 13 February 2022 09:16
> >
> >>
> >>> What happens on x86-64?
> >>>
> >&g
From: Christophe Leroy
> Sent: 01 March 2022 11:15
...
> Looks like ARM also does better code with the generic implementation as
> it seems to have some looking like conditional instructions 'rorne' and
> 'strne'.
In arm32 (and I think arm64) every instruction is conditional.
> static __always_in
From: Linus Torvalds
> Sent: 01 March 2022 19:07
> On Mon, Feb 28, 2022 at 2:29 PM James Bottomley
> wrote:
> >
> > However, if the desire is really to poison the loop variable then we
> > can do
> >
> > #define list_for_each_entry(pos, head, member) \
> > for (pos
From: Linus Torvalds
> Sent: 01 March 2022 23:03
>
> On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote:
> >
> > Can it be resolved by making:
> > #define list_entry_is_head(pos, head, member) ((pos) == NULL)
> > and double-checking that it isn't used anywhe
From: Xiaomeng Tong
> Sent: 02 March 2022 09:31
>
> On Mon, 28 Feb 2022 16:41:04 -0800, Linus Torvalds
> wrote:
> >
> > But basically to _me_, the important part is that the end result is
> > maintainable longer-term.
>
> I couldn't agree more. And because of that, I stick with the following
> a
From: Xiaomeng Tong
> Sent: 03 March 2022 02:27
>
> On Wed, 2 Mar 2022 14:04:06 +0000, David Laight
> wrote:
> > I think that it would be better to make any alternate loop macro
> > just set the variable to NULL on the loop exit.
> > That is easier to code for and t
From: Xiaomeng Tong
> Sent: 03 March 2022 07:27
>
> On Thu, 3 Mar 2022 04:58:23 +0000, David Laight wrote:
> > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > > The problem is the mis-use of iterator outside the loop on exit, and
> > > the iterator will b
From: Dan Carpenter
> Sent: 07 March 2022 15:01
>
> Updating this API is risky because some places rely on the old behavior
> and not all of them have been updated. Here are some additional places
> you might want to change.
I really can't help thinking that trying to merge this patch is
actuall
From: Christophe Leroy
> Sent: 09 March 2022 07:56
...
> diff --git a/arch/powerpc/include/asm/checksum.h
> b/arch/powerpc/include/asm/checksum.h
> index 8321f6053a67..4b573a3b7e17 100644
> --- a/arch/powerpc/include/asm/checksum.h
> +++ b/arch/powerpc/include/asm/checksum.h
> @@ -38,14 +38,15 @@
From: Kalle Valo
> Sent: 28 March 2022 10:29
>
> Larry Finger writes:
>
> > On 3/26/22 11:59, Benjamin Stürz wrote:
> >> This replaces comments with C99's designated
> >> initializers because the kernel supports them now.
> >>
> >> Signed-off-by: Benjamin Stürz
> >> ---
> >> drivers/net/wirel
> > Thanks for doing this implementation! One reason usercopy hardening
> > didn't persue doing a "full" stacktrace was because it seemed relatively
> > expensive. Did you do any usercopy-heavily workload testing to see if
> > there was a noticeable performance impact?
Look at anything that uses s
From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390 architecture th
From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
>
> > > The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean a
From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> > e
From: Ingo Molnar
> Sent: 11 January 2023 09:54
>
> * Michal Hocko wrote:
>
> > On Tue 10-01-23 16:44:42, Suren Baghdasaryan wrote:
> > > On Tue, Jan 10, 2023 at 4:39 PM Davidlohr Bueso wrote:
> > > >
> > > > On Mon, 09 Jan 2023, Suren Baghdasaryan wrote:
> > > >
> > > > >This configuration var
...
> > One thing that might be gnarly here is that I think you might not be
> > allowed to use up_read() to fully release ownership of an object -
> > from what I remember, I think that up_read() (unlike something like
> > spin_unlock()) can access the lock object after it's already been
> > acqui
From: Athira Rajeev
> Sent: 19 January 2023 11:31
...
> diff --git a/tools/perf/tests/shell/buildid.sh
> b/tools/perf/tests/shell/buildid.sh
> index aaf851108ca3..43e43e131be7 100755
> --- a/tools/perf/tests/shell/buildid.sh
> +++ b/tools/perf/tests/shell/buildid.sh
> @@ -66,7 +66,7 @@ check()
>
From: Athira Rajeev
> Sent: 19 January 2023 14:27
...
> The test script "tests/shell/buildid.sh" uses some of the
> string substitution ways which are supported in bash, but not in
> "sh" or other shells. Above error on line number 69 that reports
> "Bad substitution" is:
Looks better - assuming i
From: Arnaldo Carvalho de Melo
> Sent: 19 January 2023 17:00
>
> Em Thu, Jan 19, 2023 at 03:49:15PM +0000, David Laight escreveu:
> > From: Athira Rajeev
> > > Sent: 19 January 2023 14:27
> > ...
> > > The test script "tests/shell/buildid.sh" uses
From: Segher Boessenkool
> Sent: 20 January 2023 10:54
...
> > > I suggest to file a bug against gcc complaining about a "spurious
> > > warning", and using "-Werror -Wno-error-sizeof-pointer-div" until gcc is
> > > adapted to not emit the warning about the pointer division if the result
> > > is n
From: Segher Boessenkool
> Sent: 26 January 2023 17:19
>
> On Thu, Jan 26, 2023 at 12:09:53AM +1100, Michael Ellerman wrote:
> > Andrew Donnellan writes:
> > > A number of structures and buffers passed to PKS hcalls have alignment
> > > requirements, which could on occasion cause problems:
> > >
From: Andrew Donnellan
> Sent: 27 January 2023 03:21
>
> On Thu, 2023-01-26 at 17:31 +0000, David Laight wrote:
> > Changing the size to kzalloc() doesn't help.
> > The alignment depends on the allocator and is only required to have
> > a relatively small alignmen
From: Bjorn Helgaas
> Sent: 13 February 2023 21:38
>
> On Fri, Feb 10, 2023 at 02:33:23PM -0800, Ira Weiny wrote:
> > The CXL driver expects internal error reporting to be enabled via
> > pci_enable_pcie_error_reporting(). It is likely other drivers expect the
> > same.
> > Dave submitted a patc
From: Nicholas Piggin
> Sent: 15 July 2024 09:25
>
> On Sun Jul 14, 2024 at 6:27 PM AEST, Naveen N Rao wrote:
> > Function profile sequence on powerpc includes two instructions at the
> > beginning of each function:
> > mflrr0
> > bl ftrace_caller
> >
> > The call to ftrace_caller
From: Stewart Hildebrand
> Sent: 16 July 2024 20:33
>
> This series sets the default minimum resource alignment to 4k for memory
> BARs. In preparation, it makes an optimization and addresses some corner
> cases observed when reallocating BARs. I consider the prepapatory
> patches to be prerequisi
From: David Laight
> Sent: 17 July 2024 14:15
>
> From: Stewart Hildebrand
> > Sent: 16 July 2024 20:33
> >
> > This series sets the default minimum resource alignment to 4k for memory
> > BARs. In preparation, it makes an optimization and addresses so
From: Stewart Hildebrand
> Sent: 17 July 2024 19:31
...
> > For more normal hardware just ensuring that two separate targets don't share
> > a page while allowing (eg) two 1k BAR to reside in the same 64k page would
> > give some security.
>
> Allow me to understand this better, with an example:
>
From: Russell King - ARM Linux
> Sent: 04 December 2015 17:13
...
> I have a slightly different view...
>
> > > I don't see bust_spinlocks() dealing with any of these locks, so IMHO
> > > trying to make this work in NMI context strikes me as making the
> > > existing solution more unreliable on AR
> The MSI-X table is paravirtualized on vfio in general and interrupt
> remapping theoretically protects against errant interrupts, so why is
> this PPC64 specific? We have the same safeguards on x86 if we want to
> decide they're sufficient. Offhand, the only way I can think that a
> device can to
From: Alex Williamson
> Sent: 17 December 2015 21:07
...
> > Is this all related to the statements in the PCI(e) spec that the
> > MSI-X table and Pending bit array should in their own BARs?
> > (ISTR it even suggests a BAR each.)
> >
> > Since the MSI-X table exists in device memory/registers ther
From: Michael Ellerman
> Sent: 08 January 2016 02:17
> > I doubt you plan to fix all those. So making -Werror configurable seems like
> > the only way forward, then. (Glad you agreed!)
>
> Yep, I'm happy to make Werror configurable.
>
> cxl can probably just use the existing PPC_WERROR.
Personal
From: Michael Ellerman
> Sent: 11 January 2016 09:14
> On Tue, 2015-24-11 at 10:56:18 UTC, Vaibhav Jain wrote:
> > Presently when a user-space process issues CXL_IOCTL_START_WORK ioctl we
> > store the pid of the current task_struct and use it to get pointer to
> > the mm_struct of the process, whi
From: Vaibhav Jain
> Sent: 14 January 2016 07:51
> David Laight writes:
>
> > I don't even claim to understand the linux model for handling process
> > address maps, nor what the cxl driver is doing, but the above looks
> > more than dodgy.
> >
> >
From: Yongji Xie
> Sent: 15 January 2016 07:06
>
> MSI-X tables are not allowed to be mmapped in vfio-pci
> driver in case that user get to touch this directly.
> This will cause some performance issues when when PCI
> adapters have critical registers in the same page as
> the MSI-X table.
...
If t
From: Kees Cook
> Sent: 04 February 2016 21:01
> Some callers of strtobool were passing a pointer to unterminated strings.
> In preparation of adding multi-character processing to kstrtobool, update
> the callers to not pass single-character pointers, and switch to using the
> new kstrtobool_from_u
From: Konstantin Khlebnikov
> Sent: 23 May 2019 17:22
> > In addition, the syscall will also work for tasks that do not have procfs
> > mounted and on kernels that do not have procfs support compiled in. In such
> > situations the only way to make sure that all file descriptors are closed
From: Bjorn Helgaas
> Sent: 26 March 2019 20:29
>
> On Mon, Mar 11, 2019 at 04:31:10PM +0300, Sergey Miroshnichenko wrote:
> > If a PCIe device driver doesn't yet have support for movable BARs,
> > mark device's BARs with IORESOURCE_PCI_FIXED.
>
> I'm hesitant about using IORESOURCE_PCI_FIXED for
From: Adhemerval Zanella
> Sent: 21 April 2020 16:01
>
> On 21/04/2020 11:39, Rich Felker wrote:
> > On Tue, Apr 21, 2020 at 12:28:25PM +0000, David Laight wrote:
> >> From: Nicholas Piggin
> >>> Sent: 20 April 2020 02:10
> >> ...
> >>>&g
From: Nicholas Piggin
> Sent: 20 April 2020 02:10
...
> >> Yes, but does it really matter to optimize this specific usage case
> >> for size? glibc, for instance, tries to leverage the syscall mechanism
> >> by adding some complex pre-processor asm directives. It optimizes
> >> the syscall code si
From: Borislav Petkov
> Sent: 25 April 2020 18:53
...
> IOW, something like this (ontop) which takes care of the xen case too.
> If it needs to be used by all arches, then I'll split the patch:
.
> - asm ("");
> + prevent_tail_call_optimization();
> }
One obvious implementation would be a
From: Paul E. McKenney
> Sent: 01 November 2018 17:02
...
> And there is a push to define C++ signed arithmetic as 2s complement,
> but there are still 1s complement systems with C compilers. Just not
> C++ compilers. Legacy...
Hmmm... I've used C compilers for DSPs where signed integer arithmet
From: Linuxppc-dev
[mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On
Behalf Of
> Michael Ellerman
> Subject: Re: powerpc/xmon: Relax frame size for clang
>
> On Wed, 2018-10-31 at 01:09:34 UTC, Joel Stanley wrote:
> > When building with clang (8 trunk, 7.0 release) the fr
From: Alexandru Gagniuc
> Sent: 15 November 2018 23:16
...
> I've asked around a few people at Dell and they unanimously agree that
> _OSC is the correct way to determine ownership of AER.
This is all very well, but we have systems (they might be Dell ones)
where failure of a PCIe link (even when
From: Zhiqiang Hou
> Sent: 07 April 2016 04:17
...
> > Is there a reason specific to 85xx to have a different default than every
> > other
> > platform except lpc18xx? The description of MTD_SPI_NOR_USE_4K_SECTORS
> > acknowledges that erase speed is a tradeoff. Why is that concern more
> > comp
201 - 300 of 593 matches
Mail list logo
