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
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
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
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: 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't the int
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: 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 BAR be
> 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
...
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
...
> 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,
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
...
> 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
>
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
From: Maninder Singh
> Sent: 29 May 2023 12:14
>
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for hexagon it was defined as "128" directly.
> and commit '61968dbc2d5d' changed define
From: Michael Ellerman
> Sent: 05 May 2023 04:51
>
> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> __kfence_alloc() and __kfence_free()"), kfence reports failures in
> random places at boot on big endian machines.
>
> The problem is that the new KFENCE_CANARY_PATTERN_U64
From: Danny Tsen
> Sent: 24 April 2023 19:47
>
> Improve overall performance of chacha20 encrypt and decrypt operations
> for Power10 or later CPU.
>
> Signed-off-by: Danny Tsen
> ---
> arch/powerpc/crypto/chacha-p10le-8x.S | 842 ++
> 1 file changed, 842 insertions(+)
From: Dave Hansen
> Sent: 11 April 2023 14:44
>
> On 4/11/23 04:35, Mark Rutland wrote:
> > I agree it'd be nice to have performance figures, but I think those would
> > only
> > need to demonstrate a lack of a regression rather than a performance
> > improvement, and I think it's fairly clear
From: Geert Uytterhoeven
> Sent: 11 April 2023 09:50
>
> Hi David,
>
> On Wed, Apr 5, 2023 at 11:37 PM David Laight wrote:
> > From: Linuxppc-dev Arnd Bergmann
> > > Sent: 05 April 2023 21:32
> > >
> > > On Wed, Apr 5, 2023, at 22:00, H. Peter
From: Uros Bizjak
> Sent: 06 April 2023 09:39
>
> On Thu, Apr 6, 2023 at 10:26 AM David Laight wrote:
> >
> > From: Dave Hansen
> > > Sent: 05 April 2023 17:37
> > >
> > > On 4/5/23 07:17, Uros Bizjak wrote:
> > > > Add ge
From: Dave Hansen
> Sent: 05 April 2023 17:37
>
> On 4/5/23 07:17, Uros Bizjak wrote:
> > Add generic and target specific support for local{,64}_try_cmpxchg
> > and wire up support for all targets that use local_t infrastructure.
>
> I feel like I'm missing some context.
>
> What are the actual
From: Linuxppc-dev Arnd Bergmann
> Sent: 05 April 2023 21:32
>
> On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote:
> > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle
> > wrote:
> >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote:
> >>> We introduce a new HAS_IOPORT Kconfig option
From: Arnd Bergmann
> Sent: 31 March 2023 11:39
...
> Most architectures that have write-through caches (m68k,
> microblaze) or write-back caches but no speculation (all other
> armv4/armv5, hexagon, openrisc, sh, most mips, later xtensa)
> only invalidate before DMA but not after.
>
> OTOH, most
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
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 alignment
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: 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
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: 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
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()
>
...
> > 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
> >
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
From: James Bottomley
> Sent: 21 November 2022 14:03
...
> > Then how does the networking code handle the namespace stuff in
> > sysfs?
> > That seems to work today, or am I missing something?
>
> have you actually tried?
>
> jejb@lingrow:~> sudo unshare --net bash
> lingrow:/home/jejb # ls
From: Theodore Ts'o
> Sent: 17 November 2022 15:43
...
> The problem with "between", "ranged", "spanning" is that they don't
> tell the reader whether we're dealing with an "open interval" or a
> "closed interval". They are just different ways of saying that it's a
> range between, say, 0 and 20.
From: Tony Luck
> Sent: 21 October 2022 05:08
> When we do return to user mode the task is going to be busy servicing
> a SIGBUS ... so shouldn't try to touch the poison page before the
> memory_failure() called by the worker thread cleans things up.
What about an RT process on a busy
From: Joe Perches
> Sent: 12 October 2022 20:17
>
> On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> > The prandom_u32() function has been a deprecated inline wrapper around
> > get_random_u32() for several releases now, and compiles down to the
> > exact same code. Replace the
From: Jason A. Donenfeld
> Sent: 07 October 2022 19:01
>
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function. The
From: Jason A. Donenfeld
> Sent: 07 October 2022 19:01
>
> Rather than incurring a division or requesting too many random bytes for
> the given range, use the prandom_u32_max() function, which only takes
> the minimum required bytes from the RNG and avoids divisions.
>
...
> ---
From: Jason A. Donenfeld
> Sent: 07 October 2022 18:56
...
> > Given these kinds of less mechanical changes, it may make sense to split
> > these from the "trivial" conversions in a treewide patch. The chance of
> > needing a revert from the simple 1:1 conversions is much lower than the
> > need
From: Christophe Leroy
> Sent: 06 October 2022 18:43
...
> But taking into account that sp must remain 16 bytes aligned, would it
> be better to do something like ?
>
> sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
That makes me think...
If prandom_u32_max() is passed a (constant) power of 2
From: Nicholas Piggin
> Sent: 23 September 2022 16:42
>
> WARN_ONCE and similar are often used in frequently executed code, and
> should not crash the system. The program check interrupt caused by
> WARN_ON_ONCE can be a significant overhead even when nothing is being
> printed. This can cause
From: Stephen Hemminger
> Sent: 31 July 2022 20:06
> To: net...@vger.kernel.org
>
> Decnet is an obsolete network protocol that receives more attention
> from kernel janitors than users. It belongs in computer protocol
> history museum not in Linux kernel.
>
> It has been Orphaned in kernel
...
> More directly, the reason we don't want to error is because the use case
> has fallbacks meant to handle errors. The cascade looks like this
> (quoting from the other email):
>
> unsigned long array[whatever];
> for (i = 0; i < ARRAY_SIZE(array);) {
> longs =
From: Michael Ellerman
> Sent: 18 July 2022 05:41
...
> So we're memsetting all of args to 254, not zero.
>
> That's happening because allmodconfig with gcc 12 enables
> CONFIG_INIT_STACK_ALL_PATTERN, whereas gcc 11 doesn't.
I can't help feeling it would be better if that generated
a call to a
From: Christophe Leroy
> Sent: 30 June 2022 10:40
>
> Le 30/06/2022 à 10:04, David Laight a écrit :
> > From: Michael Schmitz
> >> Sent: 29 June 2022 00:09
> >>
> >> Hi Arnd,
> >>
> >> On 29/06/22 09:50, Arnd Bergmann wrote:
> >
From: Michael Schmitz
> Sent: 29 June 2022 00:09
>
> Hi Arnd,
>
> On 29/06/22 09:50, Arnd Bergmann wrote:
> > On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz
> > wrote:
> >> On 28/06/22 19:03, Geert Uytterhoeven wrote:
> The driver allocates bounce buffers using kmalloc if it hits an
>
From: Sebastian Andrzej Siewior
> Sent: 14 June 2022 14:26
...
> > These changes seem to drop the priority from above that of the
> > highest priority RT process down to that of a default priority
> > user process.
> > There is no real guarantee that the latter will run 'any time soon'.
>
> Not
From: Sebastian Andrzej Siewior
> Sent: 09 June 2022 16:03
>
> On 2022-05-30 16:15:11 [-0700], Davidlohr Bueso wrote:
> > Tasklets have long been deprecated as being too heavy on the system
> > by running in irq context - and this is not a performance critical
> > path. If a higher priority
From: Michael Ellerman
> Sent: 07 June 2022 03:05
>
> Bagas Sanjaya writes:
> > Hi,
> >
> > I'm trying to verify Drop ppc_inst_as_str() patch on [1] by performing
> > ppc64_defconfig build with powerpc64-unknown-linux-gnu-gcc (GCC 12.1.0).
> > The patch is applied on top of powerpc tree, next
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
> >
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: 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
> > 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
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
> >> ---
> >>
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: 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
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: 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: 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
>
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 anywhere el
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
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
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: 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'
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
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: 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...@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: Kees Cook
> Sent: 24 February 2022 06:04
>
> Under CONFIG_HARDENED_USERCOPY=y, when exact stack frame boundary checking
> is not available (i.e. everything except x86 with FRAME_POINTER), check
> a stack object as being at least "current depth valid", in the sense
> that any object within
From: Christoph Hellwig
> Sent: 18 February 2022 06:29
...
>
> > diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
> > index 15b058eefc4e..ee117fcf46ed 100644
> > --- a/arch/x86/kernel/stacktrace.c
> > +++ b/arch/x86/kernel/stacktrace.c
> > @@ -90,7 +90,7 @@
From: Andy Lutomirski
> Sent: 17 February 2022 19:15
...
> This isn't actually optimal. On x86, TASK_SIZE_MAX is a bizarre
> constant that has a very specific value to work around a bug^Wdesign
> error^Wfeature of Intel CPUs. TASK_SIZE_MAX is the maximum address at
> which userspace is permitted
From: Masahiro Yamada
> Sent: 17 February 2022 17:27
>
> On Fri, Feb 18, 2022 at 1:49 AM David Laight wrote:
> >
> > From: Masahiro Yamada
> > > Sent: 17 February 2022 16:17
> > ...
> > > No. Not that one.
> > >
> > > The co
From: Masahiro Yamada
> Sent: 17 February 2022 16:17
...
> No. Not that one.
>
> The commit you presumably want to revert is:
>
> a771f2b82aa2 ("[PATCH] Add a section about inlining to
> Documentation/CodingStyle")
>
> This is now referred to as "__always_inline disease", though.
That
From: Christophe Leroy
> Sent: 17 February 2022 14:55
>
> Le 17/02/2022 à 15:50, Christophe Leroy a écrit :
> > Adding Ingo, Andrew and Nick as they were involved in the subjet,
> >
> > Le 17/02/2022 à 14:36, David Laight a écrit :
> >> From: Christophe Lero
From: Christophe Leroy
> Sent: 17 February 2022 12:19
>
> All functions defined as static inline in net/checksum.h are
> meant to be inlined for performance reason.
>
> But since commit ac7c3e4ff401 ("compiler: enable
> CONFIG_OPTIMIZE_INLINING forcibly") the compiler is allowed to
> uninline
From: Arnd Bergmann
> Sent: 16 February 2022 13:13
>
> These two architectures implement 8-byte get_user() through
> a memcpy() into a four-byte variable, which won't fit.
>
> Use a temporary 64-bit variable instead here, and use a double
> cast the way that risc-v and openrisc do to avoid
From: Arnd Bergmann
> Sent: 15 February 2022 10:02
>
> On Tue, Feb 15, 2022 at 8:13 AM Al Viro wrote:
> > On Tue, Feb 15, 2022 at 07:29:42AM +0100, Christoph Hellwig wrote:
> > > On Tue, Feb 15, 2022 at 12:37:41AM +, Al Viro wrote:
> > > > Perhaps simply wrap that sucker into #ifdef
> > > >
From: Ard Biesheuvel
> Sent: 15 February 2022 08:18
>
> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > arm64 has an inline asm implementation of access_ok() that is derived from
> > the 32-bit arm version and optimized for the case that both the limit and
From: Linus Torvalds
> Sent: 14 February 2022 20:24
> >
> > x86-64 has always(*) used TASK_SIZE_MAX for access_ok(), and the
> > get_user() assembler implementation does the same.
>
> Side note: we could just check the sign bit instead, and avoid big
> constants that way.
The cheap test for most
From: Christoph Hellwig
> Sent: 14 February 2022 17:01
>
> On Mon, Feb 14, 2022 at 05:34:41PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The get_user()/put_user() functions are meant to check for
> > access_ok(), while the __get_user()/__put_user() functions
> > don't.
> >
> >
From: Segher Boessenkool
> Sent: 13 February 2022 09:16
>
> > What happens on x86-64?
> >
> > Trying to do the same in the x86 ipcsum code tended to make the code worse.
> > (Although that test is for an odd length fragment and can just be removed.)
>
> In an ideal world the compiler could
From: Christophe Leroy
> Sent: 11 February 2022 10:25
>
> When building kernel with CONFIG_CC_OPTIMISE_FOR_SIZE, several
> copies of csum_sub() are generated, with the following code:
>
> 0170 :
>170: 7c 84 20 f8 not r4,r4
>174: 7c 63 20 14
From: Christophe Leroy
> Sent: 11 February 2022 08:48
>
> Today's implementation of csum_shift() leads to branching based on
> parity of 'offset'
>
> 02f8 :
>2f8: 70 a5 00 01 andi. r5,r5,1
>2fc: 41 a2 00 08 beq 304
>300:
From: David T-G
> Sent: 09 February 2022 13:42
>
> ...and then Wols Lists said...
> %
> % On 08/02/2022 15:21, Paul Menzel wrote:
> ...
> %
> % As commented elsewhere, for the sake of us ENGLISH speakers,
> % *PLEASE* make that $(hash). A pound sign is £.
>
> Or, even better, $(octothorpe) since
From: Paul Menzel
> Sent: 26 January 2022 11:42
>
..
> +pound := \#
Please use 'hash' not 'pound'.
Only american greengrocers use that horrid name.
A 'pound' is '£'.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386
...
> One example of software that runs into virtual memory size limitations is
> the gnu linker when building large applications, but it's unlikely that you'll
> actually need to run applications that run into this, while also needing to
> build them natively.
There are also database programs
From: Arnd Bergmann
> Sent: 20 January 2022 11:52
..
> As with compat_flock, the packed attribute has no impact on the layout
> here, but please drop it anyway for consistency.
Never mind the structure layout, because 'packed' allows the
structure to be aligned on any boundary it forces the
> > Limit 32-bit compatible process in 0-2GB virtual address range
> > (which is enough for real scenarios), because it could avoid
> > address sign extend problem when 32-bit enter 64-bit and ease
> > software design.
Eh?
I thought nearly all the other 32bit unix ports (of any flavour)
put the
From: Christoph Hellwig
> Sent: 11 January 2022 08:35
>
> 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.
>
...
> /*
> - * IA32 uses 4
From: Jason Wang
> Sent: 20 December 2021 03:24
>
> The strlcpy should not be used because it doesn't limit the source
> length. So that it will lead some potential bugs.
>
> But the strscpy doesn't require reading memory from the src string
> beyond the specified "count" bytes, and since the
From: Segher Boessenkool
> Sent: 16 December 2021 18:56
...
> > The only remaining problem here is reinterpreting a char* pointer to a
> > u32*, e.g., for accessing the IP address in an Ethernet frame when
> > NET_IP_ALIGN == 2, which could suffer from the same UB problem again,
> > as I
From: Ard Biesheuvel
> Sent: 16 December 2021 17:30
>
> Hi Arnd,
>
> (replying to an old thread as this came up in the discussion regarding
> misaligned loads and stored in siphash() when compiled for ARM
> [f7e5b9bfa6c8820407b64eabc1f29c9a87e8993d])
>
> On Fri, 14 May 2021 at 12:02, Arnd
From: Yury Norov
> Sent: 14 December 2021 19:43
...
>
> I think that for long bitmaps the most time consuming operation is moving
> data to L1, and for short bitmaps the difference between approaches is
> barely measurable.
>
> But hweght_long on each iteration can't be more effective than the
From: Matthew Wilcox
> Sent: 12 December 2021 11:48
>
> On Sat, Dec 11, 2021 at 05:53:46PM +0000, David Laight wrote:
> > From: Tiezhu Yang
> > > Sent: 11 December 2021 03:33
> > >
> > > v2:
> > > -- add copy_to_user_or_kernel() in li
From: Tiezhu Yang
> Sent: 11 December 2021 03:33
>
> v2:
> -- add copy_to_user_or_kernel() in lib/usercopy.c
> -- define userbuf as bool type
Instead of having a flag to indicate whether the buffer is user or kernel,
would it be better to have two separate buffer pointers.
One for a user
From: Christophe Leroy
> Sent: 14 October 2021 09:34
>
> Le 14/10/2021 à 10:15, David Laight a écrit :
> > From: Hari Bathini
> >> Sent: 12 October 2021 13:31
> >>
> >> Patch #1 & #2 are simple cleanup patches. Patch #3 refactors JIT
>
From: Hari Bathini
> Sent: 12 October 2021 13:31
>
> Patch #1 & #2 are simple cleanup patches. Patch #3 refactors JIT
> compiler code with the aim to simplify adding BPF_PROBE_MEM support.
> Patch #4 introduces PPC_RAW_BRANCH() macro instead of open coding
> branch instruction. Patch #5 & #7 add
From: Jarkko Sakkinen
> Sent: 12 October 2021 18:41
>
> On Tue, 2021-10-12 at 12:43 -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 12, 2021 at 06:29:58PM +0300, Jarkko Sakkinen wrote:
> > > On Mon, 2021-10-11 at 00:01 +0800, Cai Huoqing wrote:
> > > > Replacing
From: Segher Boessenkool
> Sent: 06 October 2021 22:27
>
> On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote:
> > You have defined of_get_cpu_hwid to return u64, will this create compiler
> > warnings when since we are storing a u64 into a u32?
> >
> > It seems only if we make with
From: Christophe Leroy
> Sent: 17 September 2021 14:58
>
> Long time ago we had a config item called STRICT_MM_TYPECHECKS
> to build the kernel with pte_t defined as a structure in order
> to perform additional build checks or build it with pte_t
> defined as a simple type in order to get simpler
From: Christophe Leroy
> Sent: 16 September 2021 08:24
>
> Le 16/09/2021 à 09:16, Benjamin Herrenschmidt a écrit :
> > On Thu, 2021-09-16 at 17:15 +1000, Benjamin Herrenschmidt wrote:
> >> On Wed, 2021-09-15 at 16:31 +0200, Christophe Leroy wrote:
> >>> dcbz instruction shouldn't be used on
1 - 100 of 585 matches
Mail list logo
