From: Thomas Zimmermann
> Sent: 12 May 2023 11:25
>
> Cast I/O offsets to pointers to use them with I/O functions. The I/O
> functions expect pointers of type 'volatile void __iomem *', but the
> offsets are plain integers. Build warnings are
>
> ../drivers/video/fbdev/hitfb.c: In function 'hit
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: 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 @@ copy_stack_frame
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: 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 compil
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.
> >
> > Th
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 cu
From: Niklas Schnelle
> Sent: 21 April 2021 12:18
>
> When PCI_IOBASE is not defined, it is set to 0 such that it is ignored
> in calls to the readX/writeX primitives. This triggers clang's
> -Wnull-pointer-arithmetic warning and will result in illegal accesses on
> platforms that do not support I
From: Arnd Bergmann
> Sent: 20 April 2021 22:20
>
> On Tue, Apr 20, 2021 at 11:14 PM Vineet Gupta
> wrote:
> > On 4/20/21 12:07 AM, Arnd Bergmann wrote:
>
> > >
> > > which means that half the 32-bit architectures do this. This may
> > > cause more problems when arc and/or microblaze want to sup
From: Geert Uytterhoeven
> Sent: 20 April 2021 08:40
>
> Hi Willy,
>
> On Sat, Apr 17, 2021 at 4:49 AM Matthew Wilcox wrote:
> > Replacement patch to fix compiler warning.
> >
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, arm,
From: Matthew Wilcox
> Sent: 17 April 2021 03:45
>
> Replacement patch to fix compiler warning.
...
> static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
> {
> - return page->dma_addr;
> + dma_addr_t ret = page->dma_addr[0];
> + if (sizeof(dma_addr_t) > sizeof(unsigne
From: Matthew Wilcox (Oracle)
> Sent: 17 April 2021 00:07
>
> The net page_pool wants to use a magic value to identify page pool pages.
> The best place to put it is in the first word where it can be clearly a
> non-pointer value. That means shifting dma_addr up to alias with ->index,
> which me
From: Geert Uytterhoeven
> Sent: 24 February 2020 12:54
> To: Krzysztof Kozlowski
...
> > > > diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
> > > > b/drivers/net/wireless/ath/ath5k/ahb.c
> > > > index 2c9cec8b53d9..8bd01df369fb 100644
> > > > --- a/drivers/net/wireless/ath/ath5k/ahb.c
> > > >
From: Christophe Leroy
> Sent: 08 January 2020 08:49
...
> And as pointed by Arnd, the volatile is really only necessary for the
> dereference itself, should the arch use dereferencing.
I've had trouble with some versions of gcc and reading of 'volatile unsigned
char *'.
It tended to follow the m
From: Paul E. McKenney
> Sent: 06 June 2019 10:44
...
> But m68k is !SMP-only, correct? If so, the only issues would be
> interactions with interrupt handlers and the like, and doesn't current
> m68k hardware use exact interrupts? Or is it still possible to interrupt
> an m68k in the middle of an
From: Masahiro Yamada
> Sent: 04 June 2019 04:31
...
> > > > You could use:
> > > > $(shell sh -c "command -v $(c)gcc")
> > > > or maybe:
> > > > $(shell command$${x:+} -v $(c)gcc)
> > >
> > >
> > > How about this?
> > >
> > > $(shell : ~; command -v $(c)gcc)
> >
> > Overc
From: Masahiro Yamada
> Sent: 03 June 2019 12:38
> Hi David,
>
> On Mon, Jun 3, 2019 at 8:14 PM David Laight wrote:
> >
> > From: Masahiro Yamada
> > > Sent: 03 June 2019 11:49
> > >
> > > To print the pathname that will be used by shell
From: Masahiro Yamada
> Sent: 03 June 2019 12:45
> On Mon, Jun 3, 2019 at 8:16 PM David Laight wrote:
> >
> > From: Masahiro Yamada
> > > Sent: 03 June 2019 11:49
> > >
> > > To print the pathname that will be used by shell in the current
> > &g
From: Masahiro Yamada
> Sent: 03 June 2019 11:49
>
> To print the pathname that will be used by shell in the current
> environment, 'command -v' is a standardized way. [1]
>
> 'which' is also often used in scripting, but it is not portable.
All uses of 'which' should be expunged.
It is a bourne
From: Masahiro Yamada
> Sent: 03 June 2019 11:49
>
> To print the pathname that will be used by shell in the current
> environment, 'command -v' is a standardized way. [1]
>
> 'which' is also often used in scripting, but it is not portable.
>
> When I worked on commit bd55f96fa9fc ("kbuild: refa
From: Vineet Gupta
> Sent: 30 May 2019 19:23
...
> While it seems reasonable form hardware pov to not implement such atomicity by
> default it seems there's an additional burden on application writers. They
> could
> be happily using a lockless algorithm with just a shared flag between 2
> thread
From: gre...@linuxfoundation.org
> Sent: 31 March 2019 11:54
...
> Yes, "int" is a very nice variable for "size", you need to explain why
> it is better to use size_t here please.
Actually, on x86_64 you probably want 'unsigned int' to avoid the
compiler having to generate a sign-extending registe
From: Peter Zijlstra
> Sent: 14 February 2019 11:08
> On Thu, Feb 14, 2019 at 10:44:49AM +, Alexey Brodkin wrote:
> > > On Wed, Feb 13, 2019 at 03:23:36PM -0800, Vineet Gupta wrote:
> > > > On 2/13/19 4:56 AM, Peter Zijlstra wrote:
> > > > >
> > > > > Personally I think u64 and company should a
From: Peter Zijlstra
> Sent: 13 February 2019 12:57
...
...
> In the past I've proposed a GCC plugin / checker that would verify the
> alignment requirements against the various allocators.
>
> For instance:
>
> struct foo {
> spinlock_t a;
> int b;
> } __cacheline_aligned;
>
> stru
From: Vineet Gupta
> Sent: 12 February 2019 17:17
>
> On 2/8/19 2:55 AM, Alexey Brodkin wrote:
> > By default ARCH_SLAB_MINALIGN is defined in "include/linux/slab.h" as
> > "__alignof__(unsigned long long)" which looks fine but not for ARC.
>
> Just for the record, the issue happens because a LL
From: Vineet Gupta
...
> > It also seems to have used a different type of loop to the
> > other example, probably less efficient.
> > (Not that I'm an expert on ARC opcodes.)
>
> The difference is due to ISA and ensuing ARC gcc backends. ARCompact based
> cores
> don't support unaligned access an
From: Arnd Bergmann
> Sent: 30 November 2018 13:44
>
> On Fri, Nov 30, 2018 at 9:57 AM Jose Abreu wrote:
> > On 29-11-2018 21:20, Arnd Bergmann wrote:
> > > On Thu, Nov 29, 2018 at 5:14 PM Jose Abreu
> > > wrote:
> > >> See how the if condition added in this version is checked in
> > >> and th
From: Jose Abreu
> Sent: 29 November 2018 14:29
>
> Some ARC CPU's do not support unaligned loads/stores. Currently, generic
> implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
> This can lead to misfunction of some drivers as generic functions do a
> plain dereference of a
From: Jose Abreu [mailto:jose.ab...@synopsys.com]
> On 29-11-2018 12:47, David Laight wrote:
> > From: Jose Abreu
> >> Sent: 29 November 2018 12:42
> >>
> >> Some ARC CPU's do not support unaligned loads/stores. Currently, generic
> >> implementati
From: Jose Abreu
> Sent: 29 November 2018 12:42
>
> Some ARC CPU's do not support unaligned loads/stores. Currently, generic
> implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
> This can lead to misfunction of some drivers as generic functions do a
> plain dereference of a
From: Mark Rutland
> Sent: 09 July 2018 16:49
>
> On Mon, Jul 09, 2018 at 05:45:21PM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 09, 2018 at 05:34:27PM +0200, Peter Zijlstra wrote:
> > > On Mon, Jul 09, 2018 at 04:29:58PM +0100, Mark Rutland wrote:
> > > > Shouldn't that be 8? AFAICT, __alignof__
From: Peter Zijlstra
> Sent: 09 July 2018 15:49
> On Mon, Jul 09, 2018 at 02:33:26PM +, Alexey Brodkin wrote:
> > > In fact, since alloc_dr() uses kmalloc() to allocate the entire thing,
> > > it is impossible to guarantee a larger alignment than kmalloc does.
> >
> > Well but 4-bytes [which is
From: Alexey Brodkin
> Sent: 09 July 2018 13:48
> Atomic instructions require data they operate on to be aligned
> according to data size. I.e. 32-bit atomic values must be 32-bit
> aligned while 64-bit values must be 64-bit aligned.
>
> Otherwise even if CPU may handle not-aligend normal data acc
From: Alexey Brodkin
> Sent: 09 July 2018 11:00
...
> That's a good idea indeed but it doesn't solve the problem with
> struct devres_node. Consider the following snippet:
> >8---
> struct mystruct {
> atomic64_t myvar;
From: Geert Uytterhoeven
> Sent: 09 July 2018 10:23
> On Mon, Jul 9, 2018 at 11:15 AM David Laight wrote:
> > From: Alexey Brodkin
> > > Sent: 09 July 2018 05:45
> > > Depending on ABI "long long" type of a particular 32-bit CPU
> > > might be al
From: Alexey Brodkin
> Sent: 09 July 2018 05:45
> Depending on ABI "long long" type of a particular 32-bit CPU
> might be aligned by either word (32-bits) or double word (64-bits).
> Make sure "data" is really 64-bit aligned for any 32-bit CPU.
>
> At least for 32-bit ARC cores ABI requires "long
From: Sergey Senozhatsky
> Sent: 11 December 2017 12:50
> print_symbol() uses extra stack space to sprintf() symbol
> information and then to feed that buffer to printk()
>
> char buffer[KSYM_SYMBOL_LEN];
>
> sprint_symbol(buffer, address);
> printk(fmt, buffer);
>
> Replace print_symbol()
From: Linuxppc-dev Till Smejkal
> Sent: 13 March 2017 22:14
> The only way until now to create a new memory map was via the exported
> function 'mm_alloc'. Unfortunately, this function not only allocates a new
> memory map, but also completely initializes it. However, with the
> introduction of fir
41 matches
Mail list logo
