For the record, the benefits of dynamic XCR0 for rr recording
portability still apply. I guess it'd be useful for CRIU too. We would
also benefit from anything that incentivizes increased support for
CPUID faulting.
Rob
--
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy
ot m
On Mon, Feb 1, 2021 at 12:40 PM Andy Lutomirski wrote:
> I admit that PTRACE_SINGLESTEP seems like an odd way to spell "advance
> to the end of the syscall", but you're right, it should work.
We don't know of any better way to advance to the end of the syscall
without executing any userspace inst
On Fri, Jun 26, 2020 at 11:49 AM Gabriel Krisman Bertazi
wrote:
> We couldn't patch Windows code because of the aforementioned DRM and
> anti-cheat mechanisms, but I suppose this limitation doesn't apply to
> Wine/native code, and if this assumption is correct, this approach could
> work.
>
> One
rr (https://rr-project.org, https://arxiv.org/abs/1705.05937) grapples
with a similar problem. We need to intercept commonly-executed system
calls and wrap them with our own processing, with minimal overhead. I
think our basic approach might work for Wine without kernel changes.
We use SECCOMP_SET
On Fri, May 3, 2019 at 3:20 AM Ingo Molnar wrote:
> So what might work better is if we defined a Rust dialect that used C
> syntax. I.e. the end result would be something like the 'c2rust' or
> 'citrus' projects, where code like this would be directly translatable to
> Rust:
>
> void gz_compress(F
On Sat, Apr 27, 2019 at 10:46 PM Ingo Molnar wrote:
> - A C language runtime that is a subset of current C syntax and
>semantics used in the kernel, and which doesn't allow access outside
>of existing objects and thus creates a strictly enforced separation
>between memory used for dat
On Tue, Jan 15, 2019 at 8:25 PM Eric W. Biederman wrote:
> Can you confirm this fixes it for you?
Sorry --- I made a mistake. It looks like this is already fixed on
master, by commit e21120383f2dce32312f63ffca145ff8a87d41f5 (though I
don't think Al Viro knew he was fixing this bug). So, nothing t
This commit refactored the implementation of TIOCGPTPEER, moving "case
TIOCGPTPEER" from pty_unix98_ioctl() to tty_ioctl().
pty_unix98_ioctl() is called by pty_unix98_compat_ioctl(), so before
the commit, TIOCGPTPEER worked for 32-bit userspace. Unfortunately
tty_compat_ioctl() does not call tty_io
On Fri, Jun 15, 2018 at 10:16 AM, Kyle Huey wrote:
>
> If you want a sysctl for your own reasons that's fine. But we don't
> want a sysctl. We want to work without any further configuration.
Also toggling a sysctl would require root privileges, but rr does not
currently need to run as root. Thus
The commit says
Once upon a time net/socket.c:dev_ifsioc() used to handle SIOCSHWTSTAMP and
SIOCSIFMAP. These have different native and compat layout, so the format
conversion had been needed. In 2009 these two cases had been taken out,
turning the rest into a convoluted way to c
Sorry about replying to this old thread, but...
On Mon, Apr 3, 2017 at 9:07 AM, Eric W. Biederman wrote:
> I don't know who actually useses PTRACE_O_TRACEEXIT so I don't actually
> know what the implications of changing it are. Let's see...
>
> gdb - no
> upstart - no
> lldb - yes
> strace - no
On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote:
> Should any of those be moved into the "should be dropped" pile?
Why not be conservative and clear every sample you're not sure about?
We'd appreciate a fix sooner rather than later here, since rr is
currently broken on every stable Linux kern
On Wed, Jun 28, 2017 at 10:19 AM, Mark Rutland wrote:
> It seems odd that an event without any samples to take has a sample
> period. I'm surprised that there's not *some* sample_type set.
Yes, it is a bit odd :-). Rather than trying to gather some limited
set of information about the target proc
On Tue, May 30, 2017 at 11:08 AM, Keno Fischer wrote:
> Now, while we're probably fine with using the fallbacks, I know there's
> others that rely on this behavior as well (cc'ing Robert O'Callahan of the
> rr project for which this change will result in signific
Great, thanks!
Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr
.a war hsrer holsa rodvted,t nenh hneir
Ping? Is there something else I need to do to get someone to look at this?
Thanks,
Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa kbn e hnystoivateweh uresyf tul
nt, sizeof(count));
printf("\nConditional branches: %lld\n%s\n", count,
count < 500 ? "FAILED" : "PASSED");
return 0;
}
Robert O'Callahan (1):
KVM: x86: never specify a sample period for virtualized in_tx_cp
counters
arch/x86/kvm/pmu
lently (from the guest's point of view) stops
counting events.
We fix event counting by forcing attr.sample_period to always be zero for
in_tx_cp counters. Sampling doesn't work, but it already didn't work and
can't be fixed without major changes to the approach in hsw_hw_config().
stop
counting events.
We fix event counting by forcing attr.sample_period to always be zero for
in_tx_cp counters. Sampling doesn't work, but it already didn't work and
can't be fixed without major changes to the approach in hsw_hw_config().
Signed-off-by: Robert O&#x
Thanks!
On Fri, Aug 12, 2016 at 3:12 AM, Oleg Nesterov wrote:
> > The bug happens because when __seccomp_filter() detects
> > fatal_signal_pending(), it calls do_exit() without dequeuing the fatal
> > signal. When do_exit() sends the PTRACE_EVENT_EXIT
>
> I _never_ understood what PTRACE_EVENT_EX
now there is no way for us
to avoid that possibility.
My guess is that __seccomp_filter() should dequeue the fatal signal it
detects before calling do_exit(), to behave more like get_signal(). Is
that correct, and if so, what would be the right way to do that?
Thanks,
Robert O'Callahan
--
21 matches
Mail list logo
