ode, in particular in gup the
existing reference is simply the one from the pte. So in this case our
freeze *would* succeeed.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
On Tue, May 05, 2020 at 05:34:45AM -0700, Dave Hansen wrote:
> On 5/4/20 6:41 AM, Ulrich Weigand wrote:
> > You're right that there is no mechanism to prevent new references,
> > but that's really never been the goal either. We're simply trying
> > to ensure that no I/O i
-backed page is in the page table but not page cache).
I'm not sure what exactly the requirements for your use case are; if those
are significantly differently, maybe we can work together to find an
approach that works for both?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Anshuman Khandual wrote on 19.05.2015
17:07:56:
>This patch series adds twelve new ELF core note sections which can
> be used with existing ptrace request PTRACE_GETREGSET-SETREGSET for
accessing
> various transactional memory and other miscellaneous debug register sets
on
> powerpc
Anshuman Khandual khand...@linux.vnet.ibm.com wrote on 19.05.2015
17:07:56:
This patch series adds twelve new ELF core note sections which can
be used with existing ptrace request PTRACE_GETREGSET-SETREGSET for
accessing
various transactional memory and other miscellaneous debug register
Anshuman Khandual wrote on 21.04.2015
06:55:24:
> Changed ELF core note sections
> --
> These core note sections need to be changed to accommodate the in
> transaction ptrace requests when the running/current value of these
> registers will reside some where else
Anshuman Khandual khand...@linux.vnet.ibm.com wrote on 21.04.2015
06:55:24:
Changed ELF core note sections
--
These core note sections need to be changed to accommodate the in
transaction ptrace requests when the running/current value of these
registers will
Anshuman Khandual wrote on 13.04.2015
10:48:57:
> On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
> > - You provide checkpointed FPR and VMX registers, but there doesn't
seem
> > to be any way to get at the checkpointed *VSX* registers (i.e. the
part
> > that is neither
Anshuman Khandual khand...@linux.vnet.ibm.com wrote on 13.04.2015
10:48:57:
On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
- You provide checkpointed FPR and VMX registers, but there doesn't
seem
to be any way to get at the checkpointed *VSX* registers (i.e. the
part
that is neither
Anshuman Khandual wrote on 23.03.2015
11:34:30:
> > With that in mind, do we have a way to set the top 32bits of the MSR
> > (which contain the TM bits) when ptracing 32 bit processes? I can't
> > find anything like that in this patch set.
>
> No, we dont have that yet. When ptracing in 32-bit
Anshuman Khandual khand...@linux.vnet.ibm.com wrote on 23.03.2015
11:34:30:
With that in mind, do we have a way to set the top 32bits of the MSR
(which contain the TM bits) when ptracing 32 bit processes? I can't
find anything like that in this patch set.
No, we dont have that yet. When
Michael Neuling wrote on 23.02.2015 05:51:50:
> Sorry for the slow response.
Same here :-(
> Should this inferior function be run in the current mode of the
> processor? ie if the process is currently transactional and the
> transaction aborts, should we be able to see any global state change
Michael Neuling mi...@neuling.org wrote on 23.02.2015 05:51:50:
Sorry for the slow response.
Same here :-(
Should this inferior function be run in the current mode of the
processor? ie if the process is currently transactional and the
transaction aborts, should we be able to see any global
Michael Neuling wrote on 28.01.2015 05:28:09:
> Sorry, I'm rethinking this as we didn't consider user suspended
> transactions.
>
> It makes sense for normal transactions but for user suspended
> transactions the running values are the ones you want to modify since
> that is where you'll end up
Michael Neuling mi...@neuling.org wrote on 28.01.2015 05:28:09:
Sorry, I'm rethinking this as we didn't consider user suspended
transactions.
It makes sense for normal transactions but for user suspended
transactions the running values are the ones you want to modify since
that is where
Michael Neuling wrote on 22.01.2015 00:39:57:
> On Thu, 2015-01-01 at 13:38 +0530, Anshuman Khandual wrote:
> > On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
> > > The patchset seems to change the "original" ptrace requests (i.e.
> > > PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return
Michael Neuling mi...@neuling.org wrote on 22.01.2015 00:39:57:
On Thu, 2015-01-01 at 13:38 +0530, Anshuman Khandual wrote:
On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
The patchset seems to change the original ptrace requests (i.e.
PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to
Arnd Bergmann wrote on 13.11.2014 11:21:28:
> I have to admit that I don't really understand gdb internals, but from
> a first look I get the impression that it will just do the right thing
> if you reuse NT_S390_SYSTEM_CALL on ARM64 with the same semantics.
There's an interface between BFD and
Arnd Bergmann a...@arndb.de wrote on 13.11.2014 11:21:28:
I have to admit that I don't really understand gdb internals, but from
a first look I get the impression that it will just do the right thing
if you reuse NT_S390_SYSTEM_CALL on ARM64 with the same semantics.
There's an interface
Whether this is particularly pretty is debateable, but it
appears to be correct.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Ph
to be correct.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
-
To unsubscribe from
start_secondary [0x1d98c8]
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
-
To unsubsc
check++;/* carry overflow */
+iph->check = htons(check);
return --iph->ttl;
}
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boebling
overflow */
+iph-check = htons(check);
return --iph-ttl;
}
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727
+86 [0x1d991e]
1 start_secondary [0x1d98c8]
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: [EMAIL
o many buffers for this socket already.
Test case is simple: keep spawning lots of long-running 'ping' processes
until physical memory is exhausted.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland E
many buffers for this socket already.
Test case is simple: keep spawning lots of long-running 'ping' processes
until physical memory is exhausted.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design Development
IBM Deutschland Entwicklung
(), KERNEL_DS)) {
wait_on_page(page);
memcpy(dest, buf, len);
flush_dcache_page(page_address(page));
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutsch
(), KERNEL_DS)) {
wait_on_page(page);
memcpy(dest, buf, len);
flush_dcache_page(page_address(page));
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design Development
IBM Deutschland
David Miller wrote:
>From: Ulrich Weigand <[EMAIL PROTECTED]>
>Date: Mon, 1 Jan 2001 23:15:26 +0100 (MET)
>
> * Is there some reason why ptep_test_and_clear_young should
> *not*, after all, flush the TLB?
>
> Yes, because the accuracy of tha
David Miller wrote:
From: Ulrich Weigand [EMAIL PROTECTED]
Date: Mon, 1 Jan 2001 23:15:26 +0100 (MET)
* Is there some reason why ptep_test_and_clear_young should
*not*, after all, flush the TLB?
Yes, because the accuracy of that state bit is not required to
be %100
...
Thanks,
Ulrich Weigand
(IBM Linux for S/390 development)
diff -ur linux-2.4.0-prerelease/include/asm-generic/pgtable.h
linux-2.4.0-prerelease-tlb/include/asm-generic/pgtable.h
--- linux-2.4.0-prerelease/include/asm-generic/pgtable.hMon Dec 11 22:45:42
2000
+++ linux-2.4.0-prerelease-tlb
...
Thanks,
Ulrich Weigand
(IBM Linux for S/390 development)
diff -ur linux-2.4.0-prerelease/include/asm-generic/pgtable.h
linux-2.4.0-prerelease-tlb/include/asm-generic/pgtable.h
--- linux-2.4.0-prerelease/include/asm-generic/pgtable.hMon Dec 11 22:45:42
2000
+++ linux-2.4.0-prerelease-tlb
our bitops macros to use ints?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: [EMAIL PROTE
our bitops macros to use ints?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED
situations.
What's the correct way to fix this? In mlock and mprotect,
potentially many segments could be freed; do we need to
call lock_vma_mappings on all of them before calling
merge_segments?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design
situations.
What's the correct way to fix this? In mlock and mprotect,
potentially many segments could be freed; do we need to
call lock_vma_mappings on all of them before calling
merge_segments?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design
ve's patch (without any #ifdef __s390__) now.
However, we'd like to look further for a more general solution
that would allow us to make use of IPTE again in the future.
This would possibly involve something like making establish_pte
architecture-specific.
Mit freundlichen Gruessen / Best Regards
U
.
However, we'd like to look further for a more general solution
that would allow us to make use of IPTE again in the future.
This would possibly involve something like making establish_pte
architecture-specific.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
39 matches
Mail list logo
