Hi.
We have a regression because of this patch:
http://lkml.indiana.edu/hypermail/linux/kernel/1210.1/01456.html
While it is arguably reasonable to have this for tcdrain or close,
it also slows down poll/select a lot because n_tty_poll() does this:
tty_chars_in_buffer(tty) < WAKEUP_CHARS
And it
03.05.2013 20:30, Greg KH пишет:
We need some way to check the chars in the buffer, is the device you are
using just very slow to respond to this request? How slow? Do you have
a test case that we can see how it is affected?
Greg, unfortunately, I do have nothing.
The customer is in CC list, s
03.05.2013 20:52, Greg KH пишет:
On Fri, May 03, 2013 at 09:38:50PM +0400, Stas Sergeev wrote:
03.05.2013 20:30, Greg KH пишет:
We need some way to check the chars in the buffer, is the device you are
using just very slow to respond to this request? How slow? Do you have
a test case that we
03.05.2013 20:52, Greg KH пишет:
What exactly is the "problem" being seen?
OK, the problem is that while select() "stalls", the entire
output queue is transmitted, and when the app writes
more, there is already a big pause.
In fact, the app calls select() before writing every char,
so then the d
03.05.2013 21:16, Greg KH пишет:
Sounds like an application is doing a foolish thing and should stop it.
Its not.
The app is quering only for _input_ (specifying only read fds
to select). But the select() in linux is implemented the way that
even when it polls for input, it will still call tty_
04.05.2013 00:34, Greg KH пишет:
On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote:
03.05.2013 21:16, Greg KH пишет:
Sounds like an application is doing a foolish thing and should stop it.
Its not.
The app is quering only for _input_ (specifying only read fds
to select). But the
04.05.2013 00:34, Greg KH пишет:
Don't call select for every character :)
OK, let me draw an approximate workflow of the
setup in question.
Lets say we have 3 tty devices, A, B and C.
A and B are blazingly fast, while C is a casual usb-serial
chip.
The app must establish a bidirectional relay be
04.05.2013 15:15, Johan Hovold пишет:
The query takes longer than the transmit at decent baudrates (>=38k)
and under the assumption that flow control isn't causing any delays.
But you do have a point, and I have been meaning to look into whether
the added overhead of checking the hardware buffer
05.05.2013 22:32, Johan Hovold пишет:
Add generic wait_until_sent implementation which polls for empty
hardware buffers using the new port-operation tx_empty.
The generic implementation will be used for all sub-drivers that
implement tx_empty but does not define wait_until_sent.
Hi Johan.
The
x any problem I can practically observe,
the chances are high that I am missing something obvious.
Can someone please take a look if there is really a bug here?
>From cea19eda592e61db780e3ce1a7bf9a5f0899a0fc Mon Sep 17 00:00:00 2001
From: Stas Sergeev
Date: Sat, 18 May 2013 15:06:39 +0400
Hello.
I am writing an app that needs to control the
serial xmit in real-time. What I need is a notification
that the TTY output queue fillup (returned by TIOCOUTQ
ioctl) have dropped below the specified value.
I haven't found anything that can help implementing
this. If I can't get an async noti
Hi Alan, thanks, clear enough now. :)
10.08.2012 23:33, Alan Cox wrote:
if (bytes_left < constant)
write_wakeup
and I suspect if you made that adjustable and turned off the fifo and any
other funnies you'd at least make it work for a sufficiently rigged demo.
You sugge
Hi Ingo et all.
Ingo Molnar wrote:
the crashes below happen when PAGEALLOC is enabled. It's this
instruction:
movb OLDSS(%esp), %ah
I am really sorry about that screwup :(
I can't do too much right now as I am
reading the mail in a batch mode, and
the next time I'll be reading it will
be 24 hours
Hi Linus,
Linus Torvalds wrote:
This one can pass through vm86 mode stuff without the high-16-bit fixup,
as far as I can tell.
Yes, but according to Petr, vm86 is not
affected by the bug at all. I did some
rough tests in the past that seem to
confirm that. Also, in any case, the
dependance of vm86
Hi,
Linus Torvalds wrote:
Yes. But how do you have _such_ an empty stack when the interrupt comes
in? See what I mean?
Yes, I hope so.
IOW, that requires that the kernel stack would have
only two words on it when the interrupt happens. How?
Well, you can simply do something like this:
--- entry.S.o
Hello.
Ingo Molnar wrote:
now if an interrupt hits at this point, it will set up a 'same privilege
level' stackframe, which has eip/xcs/eflags, i.e. no esp/xss.
Yes, that's something I tried to say
when talking about the interrupt gates
(sorry if I wasn't clear).
If upon
irq-return we then examin
Hello.
Linus Torvalds wrote:
So I really think that the _correct_ fix is literally to move the "cli"
in the sysenter path down two lines. It doesn't just "hide" the bug, it
literally fixes is.
OK, Linus, I find it amazing that you
like all my patches, even though I myself
think they are wrong:)
I
Hi Linus.
Linus Torvalds wrote:
The NMI code had better be really careful, and yeah, I suspect it needs
fixing.
And since the NMI return will need a
ESP fixup too, it will require the
"branched" version of the restore_all
checks I suppose.
2. How can one be sure there are no more
of the like place
Hello.
Linus Torvalds wrote:
2. How can one be sure there are no more
of the like places where the stack is left
empty?
That's a good argument, and may be the strongest reason for _not_ doing
the speculation. However, I don't think it really can happen anywhere
else.
OK, so how do you feel about
Hello.
I am trying to format the CD-RW disc
on my NEC ND-3520A DVD writer, and the
results are completely unexpected: I do
cdrwtool -d /dev/cdrom -q
It proceeds with the formatting, but
while it does so, the system is pretty
much dead. It can do some trivial tasks
like the console switching, but as
Hello.
Alistair John Strachan wrote:
You probably don't have DMA enabled on the drive. Please check this.
It looks enabled. And even if it didn't,
such a behaviour would still be strange.
# hdparm -v /dev/cdrom
/dev/cdrom:
HDIO_GET_MULTCOUNT failed: Invalid argument
IO_support = 1 (32-bit)
unmas
ased -mm3:)
Well, at least you can still apply the
comments if you feel like that. Here
they are.
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2/arch/i386/kernel/entry.S 2005-04-06 09:34:35.0 +0400
+++ linux/arch/i386/kernel/entry.S 2005-04-11 10:49:28.00
Hello.
Andrew Morton wrote:
Program received signal SIGTRAP, Trace/breakpoint trap.
SIGTRAP - it looks like the "int $3"
triggered, not "mov0x30(%esp),%eax",
which is just the next insn and so the
%eip points to it, but it might be
innocent. And besides, 0x30(%esp) is
EFLAGS, not OLDSS. So I th
Hello.
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
Fails to compile with
!CONFIG_ACPI && CONFIG_SMP.
CONFIG_SMP sets CONFIG_X86_HT,
which sets CONFIG_ACPI_BOOT,
but that fails without CONFIG_ACPI:
CC arch/i386/kernel/setup.o
ar
Hello.
do_debug() returns void, do_int3() too when
!CONFIG_KPROBES.
This patch fixes the CONFIG_KPROBES variant
of do_int3() to return void too and adjusts
the entry.S accordingly.
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
--- linux/arch/i386/kernel/entry.S.old 2005-04-12 09:47:38.000
Hello.
Andrew Morton wrote:
OK, the `int $3' is part of the CONFIG_TRAP_BAD_SYSCALL_EXITS thing which I
never use.
I'm not sure what problem is actually being reported here, now you mention it.
The problem being reported here is that
CONFIG_TRAP_BAD_SYSCALL_EXITS does nothing
but locking up your ma
Obviously it never worked.
The attached patch moves the check to the
right place (to the syscall_exit path) and
replaces the "int $3" by the call to the
helper function that only prints some debug
info and doesn't crash the system.
This fully solves the reported problem.
Signed-off
Hello.
This patch moves the CONFIG_TRAP_BAD_SYSCALL_EXIT
from "Executable file formats" section to the
KGDB section. I had real problems finding that
option where it was.
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
--- linux/arch/i386/Kconfig.old 2005-04-12 09:47:38.0
Hello.
Andrew Morton wrote:
do_debug() returns void, do_int3() too when
This patch is applicable to the mainline kernel, is it not?
I think so - with some offsets it applies
and looks valid.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi Ingo.
I have some programs that crash
in 2.6.12-rc2-mm3. After seeing this:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.1/1091.html
I tried to revert the
sched-unlocked-context-switches.patch
and indeed the problem goes away.
Attached is the (crappy) test-case.
If you can make it to say "
Hello.
Ingo Molnar wrote:
does the patch below fix the problem for you?
Works perfectly, thankyou!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read t
I am using linux-2.2.19 and I have a problem with irq handling:
if some program requests an irq and doesn't free it before exit, I have to
reboot my machine in order to make this program to work again.
I mean dosemu: if it crashes, it doesn't handle irqs any more until reboot.
I can demonstrate t
As nobody responded to my previous posting
( http://www.uwsg.indiana.edu/hypermail/linux/kernel/0106.1/0219.html )
I had no other options than to try to solve a problem myself.
The problem was that linux fails to do a cleanup if a program does
vm86()/VM86_REQUEST_IRQ without VM86_FREE_IRQ (see tes
some
other driver, or to disable the annoying
beeps.
Acked-by: Vojtech Pavlik <[EMAIL PROTECTED]>
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
diff -urN linux-2.6.12-rc6/drivers/input/misc/pcspkr.c linux-2.6.12-rc6-spinlk/drivers/input/misc/pcspkr.c
--- linux-2.6.12-rc6/driver
Hello.
Right now it seems like the only interface
for registering the timer hooks is that one
of kernel/profile.c, and it is very limited.
The arch-specific timer hooks are provided
in an arch-specific headers as a static
functions.
Since my driver needs the timer hook, I
thought it might be a go
Hello.
john stultz wrote:
Interesting. Could you explain why the soft-timer interface doesn't<>
suffice?
I'll try to explain why *I think*
it doesn't suffice, please correct
me if my assumptions are wrong.
There are two (bad) things about the
PC-Speaker driver:
1. It needs the higher interrupt
Hello.
Nish Aravamudan wrote:
[PATCH] i386: Selectable Frequency of the Timer Interrupt
but it doesn't look like it ended up
with some patch applied, or where is it?
This thread resulted in CONFIG_HZ. You get to choose between 100, 250
or 1000. It was not meant to allow runtime HZ modifications
Hello.
Lee Revell wrote:
Wow, your driver implements bass and treble controls by varying the
frequency of the timer interrupt. That's a neat hack, but I'd expect it
to raise a few eyebrows if it's submitted for mainline...
I realized that some time ago, and now,
even though the code it still t
Hello.
Lee Revell wrote:
Lots of things aren't doable with the current timer API, hence all the
recent work on dynamic tick.
I've found only this about the dynamic
tick:
http://lwn.net/Articles/138969/
and it seems that it is intended only
to slow down the interrupts when there
is no work to d
Hello.
Lee Revell wrote:
should set CONFIG_HZ to the value I
need at compile-time, and just remove
all the timer reprogramming from the
driver in a hope the dynamic-tick patch
will slow it down itself when necessary?
The current implementations don't allow HZ to go higher than CONFIG_HZ
but tha
th
the proper value.
- On an exceptions the check is performed
to see if we are on a 16bit stack, and
if we are - switch to the 32bit one.
Alan, would it be possible to apply that
patch to an -ac tree?
Acked-by: Linus Torvalds <[EMAIL PROTECTED]>
Acked-by: Petr Vandrovec <[EMAIL PROTECTED]
Hello.
Grzegorz Kulewski wrote:
Does the bug also egsist on AMD CPU's?
Yes. As well as the ones of a Transmeta etc.
I just haven't tested the old Cyrixes, that
AFAIK were trying to ignore some Intel bugs.
The test-case for the bug is here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0690.h
Hello.
Ondrej Zary wrote:
I've just ran that on my Cyrix MII PR300 and the bug is present:<>
UMC U5SX/33 in my router - also present:
Thanks, now I know for sure that it exist
everywhere.
Now you can apply the patch and make sure
the bug goes away:)
-
To unsubscribe from this list: send the line "u
Hi.
Pavel Machek wrote:
+ andl $(VM_MASK | (4 << 8) | 3), %eax
+ cmpl $((4 << 8) | 3), %eax
+ je ldt_ss # returning to user-space with LDT SS
All common linux apps use same %ss, no? Perhaps it would be more
efficient to just check if %ss == 0x7b, and proceed
IL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
diff -ur linux-2.6.11-ac2/arch/i386/kernel/cpu/common.c linux-2.6.11-ac2-stk/arch/i386/kernel/cpu/common.c
--- linux-2.6.11-ac2/arch/i386/kernel/cpu/common.c 2005-03-13 17:59:45.0
Hi,
Linus Torvalds wrote:
Btw, Stas, one thing I'd really like to see is even a partial list of
anything that actually cares about this. Ie, if there is some known
Windows app where Wine works better or something like that, just adding
I am not using Wine too much, but I've
found this:
http://cvs
Hello.
Andi Kleen wrote:
The particular game I want to get working,
is "Master of Orion 2" for DOS.
How about you just run it in dosbox instead of dosemu ?
Way too slow, and there are other reasons
too, like the better networking support on
dosemu side (not for Orion, but for other
games is importa
Hi,
Jakob Eriksson wrote:
A long term goal of wine is to support DOS apps to. Of course
it's not a priority, but it's there.
Yes, that's exactly what I was hoping
for, thanks!
Even if no Windows apps do such a thing
(which wasn't confirmed yet), Wine may
still need that fix for the DOS support
in t
Hi!
Alan Cox wrote:
Alan, can you please apply that to an -ac
tree?
Ask Andrew Morton as it belongs in the -mm tree
Actually I tried that already. Andrew
had nothing against that patch personally,
as well as Linus, but after all that didn't
work:
http://lkml.org/lkml/2005/1/3/260
So it can't be app
Hello.
Brian Gerst wrote:
Can you tell me how the invisible high-word (invisible in VM-86, and
in real mode) could possibly harm something running in VM-86 or
read-mode ??? I don't even think it's a BUG. If the transition
into and out of VM-86 doesn't handle the fact that the high-word
of the stac
Hello.
Andrew Morton wrote:
I added this patch to -mm.
Many thanks!
Alan, sorry for bothering you with that.
- If the patch patches something which is in Linus's kernel, prepare a
diff against Linus's latest kernel.
- If the patch patches something which is only in -mm, prepare a patch
against
Hi,
Oleg Nesterov wrote:
x86: fix ESP corruption CPU bug (take 2)
I think that Stas tries to steal 1024 bytes from kernel's memory ...
I think so too, sorry.
I simply copied that from the cpu_gdt_table
definition, and here's the mistake :(
Probably this:
---
$ nm -g vmlinux |grep cpu_gdt_table
c0
Hello.
When I am trying to use the serial
port, I am getting the machine lockup.
This started to happen sometime in a
2.6.9 era I think, and is not fixed
in the latest 2.6.11 pre's.
The bug looks trivial, unless I am
missing something. "port.lock" is
acquired in serial8250_interrupt()
and later in
<><>
<><><>Hello.
Russell King wrote:
Known bug, just nobody has bothered to fix it. Please send the fix to
Linus so it gets into 2.6.11
The fix was submitted to and accepted by Linus on Feb 8th. Therefore,
there's nothing to "bother" with.
I've seen that fix in the latest -mm
patch released short
Pavel Machek wrote:
> > The problem is that there are comparisons of pointers to task_struct when
> > deciding if the task is alive. If one task dies and other one starts, it is
> > possible (is it?) that the task structure of the newly created task resides
> > at the very address where was the de
. But it may work as expected.
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
diff -ur linux-2.6.11/include/asm-alpha/signal.h linux-2.6.11-hdr/include/asm-alpha/signal.h
--- linux-2.6.11/include/asm-alpha/signal.h 2005-01-17 09:36:46.0 +0300
+++ linux-2.6.11-hdr/include/asm-alpha/signa
that
flag to all the other arch-specific headers
too. So I think such a clean-up makes sense.
Can this please be applied?
Unfortunately I have tested it on x86 only.
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
diff -ur linux-2.6.11/include/asm-alpha/signal.h linux-2.6.11-hdr/include/asm
Hello.
The attached patch fixes a trivial
mistake in a MODULE_PARAM_DESC of pata_it821x
driver. The parameter name in MODULE_PARAM_DESC
should match the one in module_param_named.
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
--- a/drivers/ata/pata_it821x.c 2007-04-27 12:46:35.000
Hi.
William Tambe wrote:
I understand your concern. But since I am working on a dynamic memory
management code that I wish to use with other projects that I have, I
didn't find appropriate to use shm_open.
Could you please provide a detailed list of the
problems you have with shm_open? If they
me, sorry...
---
Set CLOCK_SOURCE_IS_CONTINUOUS flag for the PIT clocksource
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
CC: Thomas Gleixner <[EMAIL PROTECTED]>
--- linux-2.6.21/arch/i386/kernel/i8253.c 2007-05-12 11:29:23.0 +0400
+++ linux-2.6.21-xx/arch/i386/kernel/i8
Hello.
Thomas Gleixner wrote:
The PIT can only be used as a clock source, when it is in periodic mode,
but it is never continuous. If we miss one PIT interrupt the time
keeping is hosed.
OK, thank you and Daniel for the explanations
about the flag, but now to the problem.
Before hrtimer_switch_
Hello.
Thomas Gleixner wrote:
You need either pm_timer or hpet in order to switch to highres /
dynticks. Are those enabled in the kernel config ?
Yes, both were enabled.
However, since this board is very old
(bios is dated 2000), I had "acpi=off".
Now removing that, makes the hrtimers to
work.
Hello.
Thomas Gleixner wrote:
Does this mean that on even an older
boards (without acpi at all) the hrtimers
won't work?
Not if PIT is the only clocksource available.
So you mean it can work without both the
pm_timer and hpet? Sorry for bothering you
too much, but I am trying to use the hrtime
Hello.
Thomas Gleixner wrote:
Does this mean that on even an older
boards (without acpi at all) the hrtimers
won't work?
Not if PIT is the only clocksource available.
I was confused as to where the above "not" applies.
It does _NOT_ work without pm_timer or hpet
Thanks, now its clear enough
Hi.
Hugh Dickins wrote:
You've answered your own question: we did not make the change Stas
suggested, IIRC because I remained a little uneasy with that change
in behaviour, and nobody else spoke up for it.
IIRC your argument, that made sense to me,
was that with such an approach, you can only
e
Hello.
William Tambe wrote:
And it just doesn't make sens to have mmap() map ANONYMOUS shared memory
and mremap() not to expand it and make the expanded area available.
I agree with this, but the argument against
that approach was that then you can only
enlarge the backing-store, but never shri
dy forgotten the
details, and pretty much lost the need for that patch.
So let's assume the authorship is yours. :)
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
mm/shmem.c | 41 -
Hello.
It seems hrtimer_forward was forgotten to
export - other symbols of the hrtimers API
are already exported.
Unless I am missing something, using the
hrtimers without that function is problematic.
Andrew, could you please apply?
Signed-off-by: <[EMAIL PROTECTED]>
--- a/kernel/hrtimer.c 20
Hello.
Peter Zijlstra wrote:
It seems hrtimer_forward was forgotten to
export - other symbols of the hrtimers API
Are there actual in-tree users of this symbol? Without we usually leave
the symbol unexported, this saves some space.
Do you mean it was really left intentional?
Unbeleivable! But
23.09.2016 19:56, Waiman Long пишет:
When running certain database workload on a high-end system with many
CPUs, it was found that spinlock contention in the sigprocmask syscalls
became a significant portion of the overall CPU cycles as shown below.
Hi, I was recently facing the same problem, an
, unfortunately, misses the Tesed-by tag.
The reported didn't test it, and I don't have the hardware in question.
Signed-off-by: Stas Sergeev
Reported-by: Caylan Van Larson
CC: Caylan Van Larson
CC: Alan Cox
CC: Johan Hovold
CC: Greg Kroah-Hartman
CC: linux-...@vger.kernel.org
CC: li
Tesed-by tag.
The reported didn't test it, and I don't have the hardware in question.
Signed-off-by: Stas Sergeev
Reported-by: Caylan Van Larson
CC: Caylan Van Larson
CC: Alan Cox
CC: Johan Hovold
CC: Greg Kroah-Hartman
CC: linux-...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
--
24.09.2016 16:57, Sergei Shtylyov пишет:
Hello.
On 9/24/2016 4:47 PM, Stas Sergeev wrote:
The TIOCOUTQ ioctl calls chars_in_buffer(), and some apps depend on
a correct behaviour of that.
mos7840 implements it wrongly: if you write just one char, TIOCOUTQ
will return 32.
This patch should fix
Tested-by tag.
The reporter didn't test it, and I don't have the hardware in question.
Signed-off-by: Stas Sergeev
Reported-by: Caylan Van Larson
CC: Caylan Van Larson
CC: Alan Cox
CC: Johan Hovold
CC: Greg Kroah-Hartman
CC: linux-...@vger.kernel.org
CC: linux-kernel@vger.ker
07.11.2017 01:26, Michael Kerrisk (man-pages) пишет:
Hello Stas,
Ping on the below?
Hi, the change with the "not recommended" warning
looks good to me.
Acked-by: Stas Sergeev
30.10.2017 13:50, Michael Kerrisk (man-pages) пишет:
I see what you mean. The point is back then that SS_ONSTACK was
the only flag that could (on Linux) be specified in ss.ss_flags,
so that "SS_ONSTACK | SOMETHING_FLAG" was a nonexistent case.
These days, it's possible to specify the new SS_AUTOD
13.10.2015 04:04, Andy Lutomirski пишет:
> + * UC_SIGCONTEXT_SS will be set when delivering 64-bit or x32 signals on
> + * kernels that save SS in the sigcontext. All kernels that set
> + * UC_SIGCONTEXT_SS will correctly restore at least the low 32 bits of esp
> + * regardless of SS (i.e. they im
14.10.2015 18:01, Ingo Molnar пишет:
>
> * Stas Sergeev wrote:
>
>> On an off-topic: there was recently a patch from you that
>> disables vm86() by mmap_min_addr. I've found that dosemu, when
>> started as root, could override mmap_min_addr. I guess this will
>
ucontext flag UC_SIGCONTEXT_SS.
>>
>> To avoid compilation issues, __pad0 is left as an alias for ss in
>> ucontext.
>>
>> The nitty-gritty details are documented in the header file.
>>
>> Cc: Stas Sergeev
>> Cc: Linus Torvalds
>> Cc: Cyrill Gorcun
14.10.2015 19:40, Andy Lutomirski пишет:
>>> + *
>>> + * Kernels that set UC_SIGCONTEXT_SS will also set UC_STRICT_RESTORE_SS
>>> + * when delivering a signal that came from 64-bit code.
>>> + *
>>> + * Sigreturn modifies its behavior depending on the UC_STRICT_RESTORE_SS
>>> + * flag. If UC_STRIC
14.10.2015 21:06, Andy Lutomirski пишет:
>> Also it doesn't seem to be saying what happens if CS is 32-bit
>> and SS is invalid (the flag is not set).
>
> A new signal will be delivered. sigreturn doesn't modify its behavior
> in this case -- it does the default thing, which is to honor the SS in
14.10.2015 21:52, Andy Lutomirski пишет:
On Wed, Oct 14, 2015 at 11:34 AM, Stas Sergeev wrote:
14.10.2015 21:06, Andy Lutomirski пишет:
Also it doesn't seem to be saying what happens if CS is 32-bit
and SS is invalid (the flag is not set).
A new signal will be delivered. sigreturn do
02.09.2015 08:12, Andy Lutomirski пишет:
On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev wrote:
19.08.2015 18:46, Andy Lutomirski пишет:
On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev wrote:
Incidentally, I tried implementing the sigaction flag approach. I
think it's no good. When we r
https://lkml.org/lkml/2015/7/21/208
Guys, you gonna be kidding.
Is this a new trend of breaking dosemu, or what?
VM86 is entirely broken if ptrace, syscall auditing, or
NOHZ_FULL is in use. The code is a big undocumented mess, it's
a real PITA to test, and it looks like a big chunk of vm86_32.
02.09.2015 17:08, Andy Lutomirski пишет:
> On Sep 2, 2015 2:51 AM, "Stas Sergeev" wrote:
>>
>> https://lkml.org/lkml/2015/7/21/208
>>
>> Guys, you gonna be kidding.
>> Is this a new trend of breaking dosemu, or what?
>>
>>> VM86 is entire
02.09.2015 17:21, Andy Lutomirski пишет:
>>> This should work for old DOSEMU. It's a bit gross, but it has the
>>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>>> ability to catch signals thrown from bogus SS contexts, which probably
>>> improves debugability. It's also n
02.09.2015 20:46, Josh Boyer пишет:
> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski wrote:
>> I'd be amenable to switching the default back to y and perhaps adding
>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian,
>> what do you think?
>
> Can you please leave the default a
02.09.2015 21:17, Andy Lutomirski пишет:
> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
>> 02.09.2015 17:21, Andy Lutomirski пишет:
>>>>> This should work for old DOSEMU. It's a bit gross, but it has the
>>>>> nice benefit that everyo
02.09.2015 23:22, Josh Boyer пишет:
On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev wrote:
02.09.2015 20:46, Josh Boyer пишет:
On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski wrote:
I'd be amenable to switching the default back to y and perhaps adding
a sysctl to make the distros
02.09.2015 22:06, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
02.09.2015 21:17, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
02.09.2015 17:21, Andy Lutomirski пишет:
This should work for old DOSEMU. It's a bit gross, b
02.09.2015 23:55, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev wrote:
02.09.2015 23:22, Josh Boyer пишет:
On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev wrote:
02.09.2015 20:46, Josh Boyer пишет:
On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
wrote:
I'd be ame
03.09.2015 00:40, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev wrote:
02.09.2015 23:55, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev wrote:
02.09.2015 23:22, Josh Boyer пишет:
On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev wrote:
02.09.2015 20
03.09.2015 00:39, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev wrote:
02.09.2015 22:06, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
02.09.2015 21:17, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote
03.09.2015 01:25, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev wrote:
How dosemu2 is supposed to do this:
1. sigreturn() (to DOS)
2. siglongjmp() (to 64bit C-coded)
This should work fine on any kernel, right?
1 - not.
2 - maybe.
If, as you say, siglongjmp() restores
03.09.2015 15:01, Austin S Hemmelgarn пишет:
> On 2015-09-02 17:12, Stas Sergeev wrote:
>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev wrote:
>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>> On Wed
03.09.2015 15:11, Austin S Hemmelgarn пишет:
> On 2015-09-02 17:53, Stas Sergeev wrote:
>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev wrote:
>>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>>
>>>>
03.09.2015 18:44, Austin S Hemmelgarn пишет:
> On 2015-09-03 08:15, Stas Sergeev wrote:
>> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>>> On 2015-09-02 17:53, Stas Sergeev wrote:
>>>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>>>> On Wed
03.09.2015 18:44, Austin S Hemmelgarn пишет:
> On 2015-09-03 08:15, Stas Sergeev wrote:
>> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>>> On 2015-09-02 17:53, Stas Sergeev wrote:
>>>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>>>> On Wed
03.09.2015 19:57, Linus Torvalds пишет:
> On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn
> wrote:
>>
>> This lets you turn this on or off at runtime.
>
> Tangential aside: we already effectively have a flag that could turn
> off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr.
>
> Sadly (
03.09.2015 20:21, Andy Lutomirski пишет:
> On Thu, Sep 3, 2015 at 10:19 AM, Stas Sergeev wrote:
>> 03.09.2015 19:57, Linus Torvalds пишет:
>>> On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn
>>> wrote:
>>>>
>>>> This lets you turn this
1 - 100 of 467 matches
Mail list logo
