Re: [RFC/PATCH 00/14] split exception table content out of module.h into extable.h

On Sun, Jul 24, 2016 at 8:42 PM, Paul Gortmaker wrote: > > While doing an audit looking for unnecessary instances of module.h > inclusion across arch/x86/ I found a significant number of includes > of module.h were for things like search_exception_table and friends.

Re: [PULL] alpha.git

On Sun, Apr 8, 2018 at 11:44 AM, Matt Turner wrote: > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git > for you to fetch changes up to cd0e00c106722eca40b38ebf11cf134c01901086: They aren't actually where you

Re: [PATCH] fix osf_wait4() breakage

Applied. Just a note: On Sun, Jul 22, 2018 at 7:07 AM Al Viro wrote: > > Fixes: "osf_wait4: switch to kernel_wait4()" Please put the actual commit ID there too, because that's what people with automation check. > Cc: sta...@vger.kernel.org # v4.12+ .. and when you do that, you'll see that it

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 22, 2018 at 6:03 AM Christoph Hellwig wrote: > > The 0 return doesn't work for direct mappings that have ram at address > zero and a lot of IOMMUs that start allocating bus space from address > zero, so we can't consolidate on that, but I think we can move everyone > to all-Fs, which

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux wrote: > > I'm afraid that won't work very well - 32 bit platforms with 64-bit > addresses (LPAE) would have dma_addr_t as a 64-bit value, which > wouldn't fit into an unsigned long. Good point. So we'd have to have a special IS_DMA_ERR()

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 22, 2018 at 9:52 AM Robin Murphy wrote: > > Unfortunately, with things like the top-down IOVA allocator, and 32-bit > systems in general, "the top 4095" values may well still be valid > addresses - Ugh. > The only immediate benefit I can see is that we could distinguish cases > like

Re: remove the ->mapping_error method from dma_map_ops V2

On Tue, Nov 27, 2018 at 11:41 PM Christoph Hellwig wrote: > > On Fri, Nov 23, 2018 at 07:55:11AM +0100, Christoph Hellwig wrote: > > Well, I can tweak the last patch to return -EINVAL from dma_mapping_error > > instead of the old 1 is as bool true. The callers should all be fine, > > although

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 29, 2018 at 8:23 AM Christoph Hellwig wrote: > > We can. At least in theory. The problem is that depending on the > crazy mapping from physical and kernel virtual address to dma addresses > these might be pages at pretty random places. Look at fun like >

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 29, 2018 at 10:31 AM Christoph Hellwig wrote: > > > Or, better yet, plan on removing the single-page dma mappign entirely > > at a later date, and make the issue moot. > > What would be the replacement? Build a S/G list for every single page > mapping? Not sure that would create a

Re: remove the ->mapping_error method from dma_map_ops V3

On Fri, Nov 30, 2018 at 5:23 AM Christoph Hellwig wrote: > > Error reporting for the dma_map_single and dma_map_page operations is > currently a mess. [..] I don't see anything objectionable there, but it's not like I checked any of the context of the patches. For all I know there are odd corner

Re: [PATCH] alpha: add udelay to io port paths

On Wed, Apr 3, 2019 at 9:28 AM Mikulas Patocka wrote: > > So, I submit this patch that adds 1us delay between any I/O accesses > directed at the ISA bus. This patch makes my machine boot. 1us seems to be > minimal acceptable value, with 800ns I still get hangs. I don't think this is right. The

Re: [PATCH] add delay between port write and port read

On Wed, Feb 27, 2019 at 9:26 AM Will Deacon wrote: > > I suppose you might need the mb() before *and* after the I/O access in the > read case. The idea with readX()/ioreadX() is that you should be able to > do something like: Yeah, that sounds reasonable. You might relax the barrier after the

Re: [PATCH] add delay between port write and port read

On Wed, Feb 27, 2019 at 9:05 AM Mikulas Patocka wrote: > > Should "writeb_relaxed" on Alpha also use the barrier? I think they should. Only the double-underscore (__raw_xyz()) ones are entirely unordered, the relaxed ones are just unordered wrt regular memory and DMA. That said, I doubt

Re: [PATCH] add delay between port write and port read

On Wed, Feb 27, 2019 at 10:54 AM Maciej W. Rozycki wrote: > > For that reason though we don't have the trailing barrier in the > `readX_relaxed' accessors in the MIPS port. Makes sense. And alpha should probably follow suit. Linus

Re: [PATCH] add delay between port write and port read

On Fri, Mar 1, 2019 at 1:52 PM Arnd Bergmann wrote: > > Without that, using __raw_xyz() to copy between RAM and > buffers in PCI memory space is broken, as you said, but the > assumption would be broken on certain older machines that > do a hardware endian swap by swizzling the address lines

Re: [PATCH] add delay between port write and port read

On Fri, Mar 1, 2019 at 10:03 AM Maciej W. Rozycki wrote: > > Well, `__raw_*' accessors are never byte-swapped, not at least with the > MIPS port, making them a tad cumbersome for a driver that has no interest > in paying attention to any endianness mismatch between the CPU bus and the > device's

Re: [PATCH] add delay between port write and port read

On Fri, Mar 1, 2019 at 11:13 AM Maciej W. Rozycki wrote: > > What do we do WRT straight-through vs byte-swapping properties of these > accessors? I think the whole point of __raw_xyz() is that it's the lowest level model. It gives you relaxed ordering (together with the ioremap model), and it

Re: [PATCH] add delay between port write and port read

On Fri, Mar 1, 2019 at 9:33 AM Will Deacon wrote: > > I'd expect accesses to device RAM to use something like ioremap_wc() if > possible. In that case, the ordering of accesses is weakened by the > underlying memory type in the page tables, but we're not yet at the point > where we've figured out

Re: [PATCH] add delay between port write and port read

On Tue, Feb 26, 2019 at 10:38 AM Will Deacon wrote: > > That makes sense to me for this Alpha-specific case, but in general I > don't think we require that I/O accesses to different endpoints are > ordered with respect to each other, which was implied by one of Maciej's > examples. e.g. > >

Re: [PATCH] add delay between port write and port read

On Tue, Feb 26, 2019 at 9:52 AM Maciej W. Rozycki wrote: > > The thing is taking for example `ioreadX' and `iowriteX' we have `mb' > before a write and `mb' after a read. So if we do say (addresses are > arbitrary for illustration only): > > iowrite8(0, 1); > ioread8(2); > >

Re: [PATCH] x86: Deprecate a.out support

- * Copyright (C) 1991, 1992, 1996 Linus Torvalds - * Hacked together by Andi Kleen - */ - -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#inclu

Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features

On Thu, Feb 7, 2019 at 11:08 AM Waiman Long wrote: > > This patchset revamps the current rwsem-xadd implementation to make > it saner and easier to work with. This patchset removes all the > architecture specific assembly code and uses generic C code for all > architectures. This eases

Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features

On Fri, Feb 8, 2019 at 12:31 PM Waiman Long wrote: > > > (b) what's the new fastpath case > > The only change in the fastpath is the use of cmpxchg for writer lock. .. since a big deal here was about using the generic atomic accessor functions, I really was looking forward to seeing the

Re: [PATCH v2 2/2] locking/rwsem: Optimize down_read_trylock()

On Mon, Feb 11, 2019 at 11:31 AM Waiman Long wrote: > > Modify __down_read_trylock() to make it generate slightly better code > (smaller and maybe a tiny bit faster). This looks good, but I would ask you to try one slightly different approach. Instead of this: >long tmp =

Re: [PATCH v3 2/2] locking/rwsem: Optimize down_read_trylock()

On Thu, Feb 14, 2019 at 9:51 AM Linus Torvalds wrote: > > The arm64 numbers scaled horribly even before, and that's because > there is too much ping-pong, and it's probably because there is no > "stickiness" to the cacheline to the core, and thus adding the extra > lo

Re: [PATCH v3 2/2] locking/rwsem: Optimize down_read_trylock()

On Thu, Feb 14, 2019 at 6:53 AM Waiman Long wrote: > > The ARM64 result is what I would have expected given that the change was > to optimize for the uncontended case. The x86-64 result is kind of an > anomaly to me, but I haven't bothered to dig into that. I would say that the ARM result is

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 9:41 AM Christian Brauner wrote: > > Yeah, you mentioned this before. I do like being able to specify an > upper bound to have the ability to place fds strategically after said > upper bound. I suspect that's the case. And if somebody really wants to just close

Re: [GIT PULL 3/4] ARM: SoC-related driver updates

On Wed, May 15, 2019 at 11:43 PM Olof Johansson wrote: > > Various driver updates for platforms and a couple of the small driver > subsystems we merge through our tree: Hmm. This moved the aspeed drivers from drivers/misc to drivers/soc/aspeed (in commit 524feb799408 "soc: add aspeed folder and

Re: [PATCH v12 10/12] namei: aggressively check for nd->root escape on ".." resolution

On Wed, Sep 4, 2019 at 2:09 PM Linus Torvalds wrote: > > So you'd have three stages: > > 1) ".." always returns -EXDEV > > 2) ".." returns -EXDEV if there was a concurrent rename/mount > > 3) ".." returns -EXDEV if there was a concu

Re: [PATCH v12 10/12] namei: aggressively check for nd->root escape on ".." resolution

On Wed, Sep 4, 2019 at 2:35 PM Linus Torvalds wrote: > > On Wed, Sep 4, 2019 at 2:09 PM Linus Torvalds > wrote: > > > > So you'd have three stages: > > > > 1) ".." always returns -EXDEV > > > > 2) ".." returns -EXDEV if th

Re: [PATCH v12 10/12] namei: aggressively check for nd->root escape on ".." resolution

On Wed, Sep 4, 2019 at 2:49 PM Aleksa Sarai wrote: > > Hinting to userspace to do a retry (with -EAGAIN as you mention in your > other mail) wouldn't be a bad thing at all, though you'd almost > certainly get quite a few spurious -EAGAINs -- &{mount,rename}_lock are > global for the entire

Re: [PATCH v12 10/12] namei: aggressively check for nd->root escape on ".." resolution

On Wed, Sep 4, 2019 at 4:29 PM Al Viro wrote: > > On Wed, Sep 04, 2019 at 03:38:20PM -0700, Linus Torvalds wrote: > > On Wed, Sep 4, 2019 at 3:31 PM David Howells wrote: > > > > > > It ought to be reasonably easy to make them per-sb at least, I think. We > &

Re: [PATCH v12 10/12] namei: aggressively check for nd->root escape on ".." resolution

On Wed, Sep 4, 2019 at 1:23 PM Aleksa Sarai wrote: > > This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit > ".." resolution (in the case of LOOKUP_BENEATH the resolution will still > fail if ".." resolution would resolve a path outside of the root -- > while LOOKUP_IN_ROOT

Re: [PATCH v12 11/12] open: openat2(2) syscall

On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski wrote: > > Linus, you rejected resolveat() because you wanted a *nice* API No. I rejected resoveat() because it was a completely broken garbage API that couldn't do even basic stuff right (like O_CREAT). We have a ton of flag space in the new

Re: [PATCH v12 11/12] open: openat2(2) syscall

On Sat, Sep 7, 2019 at 5:40 AM Jeff Layton wrote: > > After thinking about this a bit, I wonder if we might be better served > with a new set of OA2_* flags instead of repurposing the O_* flags? I'd hate to have yet _another_ set of translation functions, and another chance of people just

Re: [PATCH 00/12] mm: remove __ARCH_HAS_4LEVEL_HACK

On Wed, Oct 23, 2019 at 5:29 AM Mike Rapoport wrote: > > These patches convert several architectures to use page table folding and > remove __ARCH_HAS_4LEVEL_HACK along with include/asm-generic/4level-fixup.h. Thanks for doing this. The patches look sane from a quick scan, and it's definitely

Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård wrote: > > Anyone running an Alpha machine likely also has some old OSF/1 binaries > they may wish to use. It would be a shame to remove this feature, IMO. If that's the case then we'd have to keep a.out alive for alpha, since that's the OSF/1

Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote: > > The latest version I have is 5.1, and that uses ECOFF. ECOFF _is_ a.out as far as Linux is concerned. So Linux basically treats ECOFF as "regular a.out with just some header extensions". We don't have any specific support for ECOFF. I

Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann wrote: > > The main historic use case I've heard of was running Netscape > Navigator on Alpha Linux, before there was an open source version. > Doing this today to connect to the open internet is probably > a bit pointless, but there may be other use

Re: [PATCH v5 3/3] locking/rwsem: Optimize down_read_trylock()

On Fri, Mar 22, 2019 at 7:30 AM Waiman Long wrote: > > Modify __down_read_trylock() to optimize for an unlocked rwsem and make > it generate slightly better code. Oh, that should teach me to read all patches in the series before starting to comment on them. So ignore my comment on #1.

Re: [PATCH v5 2/3] locking/rwsem: Remove rwsem-spinlock.c & use rwsem-xadd.c for all archs

On Fri, Mar 22, 2019 at 7:30 AM Waiman Long wrote: > > For simplication, we are going to remove rwsem-spinlock.c and make all > architectures use a single implementation of rwsem - rwsem-xadd.c. Ack. Linus

Re: [PATCH v14 2/6] namei: LOOKUP_IN_ROOT: chroot-like path resolution

On Wed, Oct 9, 2019 at 10:42 PM Aleksa Sarai wrote: > > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -2277,6 +2277,11 @@ static const char *path_init(struct nameidata *nd, > unsigned flags) > > nd->m_seq = read_seqbegin(_lock); > > + /* LOOKUP_IN_ROOT treats absolute paths as being