On 03/22/2019 01:01 PM, Linus Torvalds wrote:
> On Fri, Mar 22, 2019 at 7:30 AM Waiman Long wrote:
>> 19 files changed, 133 insertions(+), 930 deletions(-)
> Lovely. And it all looks sane to me.
>
> So ack.
>
> The only comment I have is about __down_read_trylock(), which probably
> isn't
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
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.
As the generic rwsem-xadd code is using the appropriate acquire and
release versions of the atomic operations, the arch specific rwsem.h
files will not be that much faster than the generic code as long as the
atomic functions are properly implemented. So we can remove those arch
specific rwsem.h
Modify __down_read_trylock() to optimize for an unlocked rwsem and make
it generate slightly better code.
Before this patch, down_read_trylock:
0x <+0>: callq 0x5
0x0005 <+5>: jmp0x18
0x0007 <+7>: lea0x1(%rdx),%rcx
Currently, we have two different implementation of rwsem:
1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)
As we are going to use a single generic implementation for rwsem-xadd.c
and no architecture-specific code will be needed, there is no
v5:
- Rebase to the latest v5.1 tree and fix conflicts in
arch/{xtensa,s390}/include/asm/Kbuild.
v4:
- Remove rwsem-spinlock.c and make all archs use rwsem-xadd.c.
v3:
- Optimize __down_read_trylock() for the uncontended case as suggested
by Linus.
v2:
- Add patch 2 to optimize
I have a business Proposal that will be of benefit to the both of us.Kindly
contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.
On Sun, Mar 17, 2019 at 7:30 PM Dmitry V. Levin wrote:
>
> This argument is required to extend the generic ptrace API with
> PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going
> to be called from ptrace_request() along with syscall_get_nr(),
> syscall_get_arguments(),
* Arnd Bergmann:
> Ok, so not '__fds_bits'.
>
> Is '__kernel_fds_bits' ok? I would prefer to keep at least the
> name __kernel_ namespace that we have for typedefs and the
> occasional struct tag.
glibc should be okay with that. We use __kernel_ in the math
libraries for something completely
On Mon, Mar 18, 2019 at 2:12 PM Florian Weimer wrote:
> > On Mon, Mar 18, 2019 at 10:25 AM Florian Weimer wrote:
> >>
> >> * Arnd Bergmann:
> >>
> >> > Should we just remove __kernel_fd_set from the exported headers and
> >> > define the internal fd_set directly in include/linux/types.h? (Adding
* Arnd Bergmann:
> On Mon, Mar 18, 2019 at 10:25 AM Florian Weimer wrote:
>>
>> * Arnd Bergmann:
>>
>> > Should we just remove __kernel_fd_set from the exported headers and
>> > define the internal fd_set directly in include/linux/types.h? (Adding the
>> > folks from the old thread to Cc).
>>
>>
* Arnd Bergmann:
> Should we just remove __kernel_fd_set from the exported headers and
> define the internal fd_set directly in include/linux/types.h? (Adding the
> folks from the old thread to Cc).
The type is used in the sanitizers, but incorrectly. They assume that
FD_SETSIZE is always 1024.
On Sun, Mar 17, 2019 at 7:20 PM Deepa Dinamani wrote:
> On Fri, Mar 15, 2019 at 2:20 PM Florian Weimer wrote:
> > > On Thu, Mar 14, 2019 at 7:41 PM Florian Weimer wrote:
> > >> > diff --git a/arch/alpha/include/uapi/asm/socket.h
> > >> > b/arch/alpha/include/uapi/asm/socket.h
> > >> > index
This argument is required to extend the generic ptrace API with
PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going
to be called from ptrace_request() along with syscall_get_nr(),
syscall_get_arguments(), syscall_get_error(), and
syscall_get_return_value() functions with a tracee as their
On Fri, Mar 15, 2019 at 2:20 PM Florian Weimer wrote:
>
> * Arnd Bergmann:
>
> > On Thu, Mar 14, 2019 at 7:41 PM Florian Weimer wrote:
> >>
> >> * Arnd Bergmann:
> >>
> >> > diff --git a/arch/alpha/include/uapi/asm/socket.h
> >> > b/arch/alpha/include/uapi/asm/socket.h
> >> > index
* Arnd Bergmann:
> On Thu, Mar 14, 2019 at 7:41 PM Florian Weimer wrote:
>>
>> * Arnd Bergmann:
>>
>> > diff --git a/arch/alpha/include/uapi/asm/socket.h
>> > b/arch/alpha/include/uapi/asm/socket.h
>> > index 0d0fddb7e738..976e89b116e5 100644
>> > --- a/arch/alpha/include/uapi/asm/socket.h
>> >
On Thu, Mar 14, 2019 at 7:41 PM Florian Weimer wrote:
>
> * Arnd Bergmann:
>
> > diff --git a/arch/alpha/include/uapi/asm/socket.h
> > b/arch/alpha/include/uapi/asm/socket.h
> > index 0d0fddb7e738..976e89b116e5 100644
> > --- a/arch/alpha/include/uapi/asm/socket.h
> > +++
--
I am Captain JAMES WILLIAMS from united states, but I am currently in
Syria for peace keeping mission. I am the commanding officer of the
third Battalion soldier regime.
Please forgive my manners I am not good when it comes to the Internet
because that is not really my field.
I came
On Tue, Mar 12, 2019 at 9:46 AM Geert Uytterhoeven wrote:
>
> Yeah, the alphas on the server side, powering AltaVista, are also long
> gone...
As usual with these things, people can still use older Linux releases
for a very long time. If they really need it (e.g. commercially), they
have the
On Mon, Mar 11, 2019 at 10:46 PM Linus Torvalds
wrote:
> 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
On Mon, Mar 11, 2019 at 03:11:55PM -0700, Matt Turner wrote:
> On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann wrote:
> > On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård wrote:
> > > Linus Torvalds writes:
> > > > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote:
> > > > We don't have any
Linus Torvalds writes:
> 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
On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann wrote:
>
> On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård wrote:
> > Linus Torvalds writes:
> > > 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
Arnd Bergmann writes:
> On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård wrote:
>> Linus Torvalds writes:
>> > 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.
>> >
>>
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
On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård wrote:
> Linus Torvalds writes:
> > 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
On Mon, Mar 11, 2019 at 12:47 PM Måns Rullgård wrote:
>
> Linus Torvalds writes:
>
> > 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
Linus Torvalds writes:
> 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
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
On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård wrote:
>
> Linus Torvalds writes:
>
> > On Sun, Mar 10, 2019 at 2:37 PM Matt Turner wrote:
> >>
> >> I'm not aware of a reason to keep a.out support on alpha.
> >
> > Hmm. I was looking at removing a.out support entirely, but it's
> > actually
Linus Torvalds writes:
> 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
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
Linus Torvalds writes:
> On Sun, Mar 10, 2019 at 2:37 PM Matt Turner wrote:
>>
>> I'm not aware of a reason to keep a.out support on alpha.
>
> Hmm. I was looking at removing a.out support entirely, but it's
> actually fairly incestuous on alpha.
>
> For example,
Referencing the __kernel_long_t type caused some user space applications
to stop compiling when they had not already included linux/posix_types.h,
e.g.
s/multicast.c -o ext/sockets/multicast.lo
In file included from /builddir/build/BUILD/php-7.3.3/main/php.h:468,
from
Formatting of Kconfig files doesn't look so pretty, so let the
Great White Handkerchief come around and clean it up.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/alpha/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/Kconfig
On Sun, Mar 10, 2019 at 11:46 PM Linus Torvalds
wrote:
>
> On Sun, Mar 10, 2019 at 2:37 PM Matt Turner wrote:
> >
> > I'm not aware of a reason to keep a.out support on alpha.
>
> Hmm. I was looking at removing a.out support entirely, but it's
> actually fairly incestuous on alpha.
>
> For
Hi Linus!
On 3/11/19 7:40 AM, Linus Torvalds wrote:
> So this attached patch does not compile on alpha, but it's been many
> many years since I had an alpha to test with, so I'm stuck.
Michael Cree (CC'ed) has several Alpha servers running which are also used
for building Debian packages and
On Sun, Mar 10, 2019 at 03:40:20PM -0700, Linus Torvalds wrote:
> SYSCALL_DEFINE3(osf_readv, unsigned long, fd,
> const struct iovec __user *, vector, unsigned long, count)
> {
> -#ifdef CONFIG_OSF4_COMPAT
> - if (unlikely(personality(current->personality) == PER_OSF4))
> -
On Sun, Mar 10, 2019 at 2:37 PM Matt Turner wrote:
>
> I'm not aware of a reason to keep a.out support on alpha.
Hmm. I was looking at removing a.out support entirely, but it's
actually fairly incestuous on alpha.
For example, arch/alpha/boot/tools/objstrip.c very much has some a.out
support in
On Tue, Mar 5, 2019 at 11:04 AM Borislav Petkov wrote:
>
> On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote:
> > I guess you could Cc arch maintainers with the a.out-core.h removal
> > patch to see if anyone screams.
>
> And they're like two for which we need confirmation:
>
> $
Hi Borislav,
On Tue, Mar 5, 2019 at 8:04 PM Borislav Petkov wrote:
> On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote:
> > I guess you could Cc arch maintainers with the a.out-core.h removal
> > patch to see if anyone screams.
>
> And they're like two for which we need
On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote:
> I guess you could Cc arch maintainers with the a.out-core.h removal
> patch to see if anyone screams.
And they're like two for which we need confirmation:
$ git ls-files | grep a.out-core.h
arch/alpha/include/asm/a.out-core.h
On Fri, 1 Mar 2019, Linus Torvalds 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 rather
>
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
On Fri, 1 Mar 2019, Arnd Bergmann wrote:
> > 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 gives you straight-through behavior.
> >
> > And yes, any driver using them needs to be aware of
On Fri, Mar 1, 2019 at 8:19 PM Linus Torvalds
wrote:
>
> 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.
On Fri, 1 Mar 2019, Linus Torvalds wrote:
> Because quite often you don't want any extra byte ordering because
> you've moving things around anyway (ie you're copying from the device
> to memory or similar, and switching to little-endian in between would
> just mean that you have to switch back
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
On Fri, 1 Mar 2019, Linus Torvalds wrote:
> So that would seem what an architecture implementation should _aim_
> for: having various "ioremap_xyz()" for setting the
> PCIe/system/whatever controller level ordering, and then using the
> "__raw_xyz()" accessors for unordered CPU accesses.
What
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
Hi Will,
> > FAOD, I think this assumption/requirement only applies to the plain
> > accessors (`inX', `readX', `ioreadX', etc.).
>
> It's also a requirement for the *_relaxed accessors, and there are drivers
> that rely on this being the case.
Well, from the reading of memory-barriers.txt,
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
Hi Maciej,
On Wed, Feb 27, 2019 at 06:49:57PM +, Maciej W. Rozycki wrote:
> On Tue, 26 Feb 2019, Will Deacon wrote:
>
> > > If they are the same device (just different data ports), I'd
> > > *definitely* expect them to be ordered.
> > >
> > > We have tons of code that depends on that.
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
On Wed, 27 Feb 2019, Linus Torvalds 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.
For that reason though we
On Tue, 26 Feb 2019, Will Deacon wrote:
> > If they are the same device (just different data ports), I'd
> > *definitely* expect them to be ordered.
> >
> > We have tons of code that depends on that. Almost every driver out
> > there, in fact.
> >
> > So we need the mb() on alpha to guarantee
On Wed, 27 Feb 2019, Linus Torvalds 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
On Wed, 27 Feb 2019, Sinan Kaya wrote:
> What we missed is the fact that alpha reorders accesses across two
> register accesses. This is guaranteed in other architectures.
Not for MIPS either.
Maciej
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
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
On Wed, Feb 27, 2019 at 12:12:51PM -0500, Mikulas Patocka wrote:
>
>
> On Tue, 26 Feb 2019, Linus Torvalds wrote:
>
> > Does anybody see any worries with the "just move the mb() earlier in
> > the ioread functions" model?
> >
> > Linus
>
> It used to be like that and it worked.
>
>
On 2/27/2019 12:12 PM, Mikulas Patocka wrote:
It used to be like that and it worked.
Then, commits cd0e00c106722eca40b38ebf11cf134c01901086 and
92d7223a74235054f2aa7227d207d9c57f84dca0 came.
These commits claim that they changed the code to be consistent with the
specification (now we have
On Tue, 26 Feb 2019, Linus Torvalds wrote:
> Does anybody see any worries with the "just move the mb() earlier in
> the ioread functions" model?
>
> Linus
It used to be like that and it worked.
Then, commits cd0e00c106722eca40b38ebf11cf134c01901086 and
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information will be provided by the
p?d_large() functions/macros.
For alpha, we don't support huge pages, so add stubs
On Tue, 26 Feb 2019, Linus Torvalds wrote:
> 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
On Tue, Feb 26, 2019 at 10:43:24AM -0800, Linus Torvalds wrote:
> 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
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.
>
>
On Tue, Feb 26, 2019 at 10:12:03AM -0800, Linus Torvalds wrote:
> 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
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);
>
>
Linus,
I have added you to this discussion in hope you can clear any uncertainty
there might be about MMIO ordering properties of the Alpha; a question for
you is towards the end of this e-mail.
On Thu, 21 Feb 2019, Mikulas Patocka wrote:
> Do you think that we should fix this by identifying
On Wed, Feb 20, 2019 at 05:52:18PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 20, 2019 at 4:38 PM Maciej W. Rozycki
> wrote:
> > On Wed, 20 Feb 2019, Mikulas Patocka wrote:
> > > > Well, actually `iowriteX' is generic and for MMIO you have `writeX'.
> > > > See lib/iomap.c, the comment at the
ATTENTION:
WE RECEIVE YOUR CONTENT OF YOUR EMAIL FORM THIS DHL MASTER CARD
OFFICES FUND OF $USD.8 MILLION AFTER THE BOARD OF DIRECTORS
MEETING,WE DECIDED TO ISSUE YOU AN ATM VISA CARD VALUED AT 8
MILLION DOLLAR.
THIS IS TO BRING TO YOUR NOTICE THAT YOUR VALUED SUM OF 8 MILLION
DOLLAR HAS
On 02/21/2019 09:14 AM, Will Deacon wrote:
> On Wed, Feb 13, 2019 at 05:00:17PM -0500, Waiman Long wrote:
>> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
>> it generate slightly better code.
>>
>> Before this patch, down_read_trylock:
>>
>>0x <+0>:
Do you think that we should fix this by identifying hardware that needs
the delays and adding the delays there?
In my opinion, adding mb() to the port accessing functions is safer - it
is 6 line patch.
Reading all the hardware manuals is time consuming and hardly anyone will
do it for 25
On Wed, Feb 13, 2019 at 05:00:17PM -0500, Waiman Long wrote:
> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
> it generate slightly better code.
>
> Before this patch, down_read_trylock:
>
>0x <+0>: callq 0x5
>0x0005 <+5>:
On Thu 21-02-19 01:23:50, Meelis Roos wrote:
> > > First, I found out that both the problematic alphas had memory compaction
> > > and
> > > page migration and bounce buffers turned on, and working alphas had them
> > > off.
> > >
> > > Next, turing off these options makes the problematic
First, I found out that both the problematic alphas had memory compaction and
page migration and bounce buffers turned on, and working alphas had them off.
Next, turing off these options makes the problematic alphas work.
OK, thanks for testing! Can you narrow down whether the problem is due
On Wed, 20 Feb 2019, Mikulas Patocka wrote:
> > Will Deacon is in the process of sanitizing our documentation for this,
> > and this part is still under discussion.
> >
> > I personally don't see a problem with having different barrier
> > semantics between outb() and iowrite8(), the reasoning
On Wed, 20 Feb 2019, Arnd Bergmann wrote:
> On Wed, Feb 20, 2019 at 4:38 PM Maciej W. Rozycki
> wrote:
> > On Wed, 20 Feb 2019, Mikulas Patocka wrote:
> > > > Well, actually `iowriteX' is generic and for MMIO you have `writeX'.
> > > > See lib/iomap.c, the comment at the top and e.g.
On Wed, 20 Feb 2019, Arnd Bergmann wrote:
> I personally don't see a problem with having different barrier
> semantics between outb() and iowrite8(), the reasoning being that
> any caller of iowriteX() would already have to be careful about
> posted writes when iowriteX is backed by ioremapped
On Tue, 19 Feb 2019, Maciej W. Rozycki wrote:
> On Tue, 19 Feb 2019, Mikulas Patocka wrote:
>
> > > As I say, shouldn't the barrier be in `iowriteX' instead? I don't
> > > suppose these are allowed to be weakly ordered.
> > >
> > > Maciej
> >
> > iowriteX is for memory-mapped I/O,
On Wed, Feb 13, 2019 at 05:00:15PM -0500, Waiman Long wrote:
> As the generic rwsem-xadd code is using the appropriate acquire and
> release versions of the atomic operations, the arch specific rwsem.h
> files will not be that much faster than the generic code as long as the
> atomic functions are
On Wed, Feb 13, 2019 at 05:00:16PM -0500, Waiman Long wrote:
> Currently, we have two different implementation of rwsem:
> 1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
> 2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)
>
> As we are going to use a single generic implementation for
On Wed 20-02-19 08:31:05, Meelis Roos wrote:
> > Could
> > https://lore.kernel.org/linux-mm/20190219123212.29838-1-lar...@axis.com/T/#u
> > be relevant?
>
> Tried it, still broken.
OK, I didn't put too much hope into this patch as you see filesystem
metadata corruption so icache/dcache coherency
Could
https://lore.kernel.org/linux-mm/20190219123212.29838-1-lar...@axis.com/T/#u
be relevant?
Tried it, still broken.
I wrote:
But my kernel config had memory compaction (that turned on page migration) and
bounce buffers. I do not remember why I found them necessary but I will try
without
On Tue, 19 Feb 2019, Mikulas Patocka wrote:
> > As I say, shouldn't the barrier be in `iowriteX' instead? I don't
> > suppose these are allowed to be weakly ordered.
> >
> > Maciej
>
> iowriteX is for memory-mapped I/O, out[bwl] is for I/O ports.
Well, actually `iowriteX' is generic and
On Tue, 19 Feb 2019, Arnd Bergmann wrote:
> On Tue, Feb 19, 2019 at 2:44 PM Mikulas Patocka wrote:
> > On Tue, 19 Feb 2019, Mikulas Patocka wrote:
> >
> > > The patches cd0e00c106722eca40b38ebf11cf134c01901086 and
> > > 92d7223a74235054f2aa7227d207d9c57f84dca0 fix a theoretical issue where
On Tue, 19 Feb 2019, Maciej W. Rozycki wrote:
> On Tue, 19 Feb 2019, Arnd Bergmann wrote:
>
> > We clearly need this patch, but I assumed the alpha maintainers would pick
> > it up, not me. I merged the original changes since they were
> > cross-architecture,
> > but I don't normally take
On Tue, 19 Feb 2019, Arnd Bergmann wrote:
> We clearly need this patch, but I assumed the alpha maintainers would pick
> it up, not me. I merged the original changes since they were
> cross-architecture,
> but I don't normally take patches for a particular architecture through the
> asm-generic
On Tue, Feb 19, 2019 at 02:20:26PM +0100, Jan Kara wrote:
> Thanks for information. Yeah, that makes somewhat more sense. Can you ever
> see the failure if you disable CONFIG_TRANSPARENT_HUGEPAGE? Because your
> findings still seem to indicate that there' some problem with page
> migration and
On Tue, Feb 19, 2019 at 2:44 PM Mikulas Patocka wrote:
> On Tue, 19 Feb 2019, Mikulas Patocka wrote:
>
> > The patches cd0e00c106722eca40b38ebf11cf134c01901086 and
> > 92d7223a74235054f2aa7227d207d9c57f84dca0 fix a theoretical issue where the
> > code didn't follow the specification.
The patches cd0e00c106722eca40b38ebf11cf134c01901086 and
92d7223a74235054f2aa7227d207d9c57f84dca0 fix a theoretical issue where the
code didn't follow the specification. Unfortunatelly, they also reduce
timing when port write is followed by a port read.
These reduced timing cause hang on boot on
On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> On Mon, Aug 20, 2018 at 11:42 PM Mikulas Patocka wrote:
> > On Mon, 20 Aug 2018, Arnd Bergmann wrote:
> >
> > > On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka
> > > wrote:
> > > > On Sun, 19 Aug 2018, ok...@codeaurora.org wrote:
> > > >
> > > > >
On Tue 19-02-19 14:17:09, Meelis Roos wrote:
> > > > > The result of the bisection is
> > > > > [88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration
> > > > > stalls for blkdev pages
> > > > >
> > > > > Is that result relevant for the problem or should I continue
> > > > >
The result of the bisection is
[88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for
blkdev pages
Is that result relevant for the problem or should I continue bisecting between
4.20.0 and the so far first bad commit?
Can you try reverting the commit and see if it
On Fri, Feb 15, 2019 at 01:58:34PM -0500, Waiman Long wrote:
> On 02/15/2019 01:40 PM, Will Deacon wrote:
> > On Thu, Feb 14, 2019 at 11:37:15AM +0100, Peter Zijlstra wrote:
> >> On Wed, Feb 13, 2019 at 05:00:14PM -0500, Waiman Long wrote:
> >>> v4:
> >>> - Remove rwsem-spinlock.c and make all
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Trofimovich
commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
Fix page fault handling code to fixup r16-r18 registers.
Before the patch code had off-by-two registers bug.
This
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Trofimovich
commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
Fix page fault handling code to fixup r16-r18 registers.
Before the patch code had off-by-two registers bug.
This
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Trofimovich
commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
Fix page fault handling code to fixup r16-r18 registers.
Before the patch code had off-by-two registers bug.
This
701 - 800 of 2609 matches
Mail list logo
