expected by our freeze code, 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 ensur
27;t think Linux mm code would be able to handle the
case where a file-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 platform.
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 inste
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 nei
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 m
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 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 r
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 the
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
happen.
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
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
is means we have too 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 &
(), 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
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 s
ble.h ...
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-prereleas
do? Fix nfs_page to use a 'long'
variable, or change 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 Boeblin
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 D
hould apply Steve'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 G
21 matches
Mail list logo
