03.09.2015 21:51, Austin S Hemmelgarn пишет:
On 2015-09-03 12:34, Stas Sergeev wrote:
https://lkml.org/lkml/2015/9/2/317
Brian Gerst recently audited it:
---
That's
hopefully in much better shape now, though.
---
By audit, I don't mean just one person trying to make it more
mainta
03.09.2015 21:51, Austin S Hemmelgarn пишет:
As of right now, the only open-source project that I know of that is
actually actively used by people on new kernels that uses vm86 is
dosemu (and the forked dosemu2). the only other open source user of
vm86() that I know of is v86d,
According to t
04.09.2015 13:09, Chuck Ebbert пишет:
> On Fri, 4 Sep 2015 00:28:04 +0300
> Stas Sergeev wrote:
>
>> 03.09.2015 21:51, Austin S Hemmelgarn пишет:
>>> There are servers out there that have this enabled and _never_ use it
>>> at all,
>> Unless I am mistaken,
04.09.2015 15:34, Austin S Hemmelgarn пишет:
> On 2015-09-04 06:46, Stas Sergeev wrote:
>> 04.09.2015 13:09, Chuck Ebbert пишет:
>>> On Fri, 4 Sep 2015 00:28:04 +0300
>>> Stas Sergeev wrote:
>>>
>>>> 03.09.2015 21:51, Austin S Hemmelgarn пишет:
04.09.2015 22:51, Austin S Hemmelgarn пишет:
On 2015-09-04 09:06, Stas Sergeev wrote:
04.09.2015 15:34, Austin S Hemmelgarn пишет:
On 2015-09-04 06:46, Stas Sergeev wrote:
04.09.2015 13:09, Chuck Ebbert пишет:
On Fri, 4 Sep 2015 00:28:04 +0300
Stas Sergeev wrote:
03.09.2015 21:51, Austin
05.09.2015 00:16, Stas Sergeev пишет:
I agree. vm86() is a mess.
My point is that its risky parts and useless funtionality
is _already_ known (even I can point to the particular code
parts than can simply be removed). As such, it simply had
to be re-visited and cleaned up to match at least 1 and
05.09.2015 01:46, Raymond Jennings пишет:
On 09/04/15 14:30, Stas Sergeev wrote:
05.09.2015 00:16, Stas Sergeev пишет:
I agree. vm86() is a mess.
My point is that its risky parts and useless funtionality
is _already_ known (even I can point to the particular code
parts than can simply be
15.10.2015 00:41, Andy Lutomirski пишет:
If this my
understanding is correct and the flag is just an indication rather
than a requested action, perhaps the name should be different,
e.g. UC_SIG_FROM_32BIT or the like?
Anyway, this is minor. :)
I'll try to test the patch within a few days, thanks
18.10.2015 19:12, Andy Lutomirski пишет:
On Sun, Oct 18, 2015 at 6:36 AM, Stas Sergeev wrote:
15.10.2015 00:41, Andy Lutomirski пишет:
If this my
understanding is correct and the flag is just an indication rather
than a requested action, perhaps the name should be different,
e.g
18.10.2015 19:36, Andy Lutomirski пишет:
On Sun, Oct 18, 2015 at 9:29 AM, Stas Sergeev wrote:
18.10.2015 19:12, Andy Lutomirski пишет:
On Sun, Oct 18, 2015 at 6:36 AM, Stas Sergeev wrote:
15.10.2015 00:41, Andy Lutomirski пишет:
If this my
understanding is correct and the flag is just an
26.10.2015 04:25, Andy Lutomirski пишет:
> This is take 2 at fixing x86 64-bit signals wrt SS. After a lot of
> thought, this is not controlled by any flags -- I would much prefer
> to avoid opt-in behavior. Instead, it just tries hard to avoid
> triggering the cases that break DOSEMU.
>
> Stas,
03.04.2015 03:51, David Miller пишет:
> From: Stas Sergeev
> Date: Tue, 31 Mar 2015 16:24:59 +0300
>
>> @@ -2590,6 +2651,7 @@ static int mvneta_mdio_probe(struct mvneta_port *pp)
>>
>> static void mvneta_mdio_remove(struct mvneta_port *pp)
>> {
>> +
03.04.2015 22:25, Florian Fainelli пишет:
On 01/04/15 10:30, Stas Sergeev wrote:
- The callback needs to be registered before of_phy_connect() to
avoid running with outdated state, but of_phy_connect() returns the
phy_device pointer, which is needed to register the callback. Registering
it
Hello.
The following patches improve the precision of led
timer trigger and add the resolution control.
That allows to make PWM brightness control with timer
trigger.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mo
-off-by: Stas Sergeev
---
drivers/leds/led-class.c | 19 ---
drivers/leds/led-core.c |9 +
include/linux/leds.h |4 ++--
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 795ec99
ightness control, because the default mS resolution is not enough
for that tasks.
CC: Bryan Wu
CC: Richard Purdie
CC: linux-l...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Stas Sergeev
---
drivers/leds/led-class.c | 18 +++--
dri
on that I think it deserves a separate API
rather than the per-driver handling. There is an alternative implementation
that adds such API:
https://lkml.org/lkml/2015/3/27/346
CC: Thomas Petazzoni
CC: Florian Fainelli
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Stas
30.03.2015 19:06, Florian Fainelli пишет:
> So yes, it is a bug in the sense that it is not transparently handled,
> but at the same time, the PHY library has no way to know whether a
> fixed_link_update callback is being invoked since it is not poking
> into the fixed PHY driver.
Maybe then it wou
-kernel@vger.kernel.org
Signed-off-by: Stas Sergeev
---
drivers/net/ethernet/marvell/mvneta.c | 90 +
1 file changed, 79 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 96208f1..13a2aa2
30.03.2015 19:06, Florian Fainelli пишет:
> 2015-03-30 7:39 GMT-07:00 Stas Sergeev :
>> 27.03.2015 20:15, Florian Fainelli пишет:
>>> I think your concerns are valid, but I don't think there is going to be
>>> any problem with the approach I suggested because there
created with
invalid parameters. phylib calls adjust_link() only when the parameters
are validated, but calling it by hands may happen too early.
CC: Thomas Petazzoni
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: Florian Fainelli
Signed-off-by: Stas Sergeev
---
drivers/net
t people decide which approach is better.
No strong opinion on my side.
Signed-off-by: Stas Sergeev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
s the subsequent patch that implements
SGMII link status for mvneta, much cleaner.
CC: Florian Fainelli
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Stas Sergeev
---
drivers/net/phy/fixed_phy.c | 29 +
include/linux/phy_fixed.h |
status.
CC: Thomas Petazzoni
CC: Florian Fainelli
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Stas Sergeev
---
drivers/net/ethernet/marvell/mvneta.c | 106 +
1 file changed, 95 insertions(+), 11 deletions(-)
diff --git a/drivers/net
Hello.
The following patches improve the precision of led
timer trigger and add the delay unit control.
That allows to make PWM brightness control with timer
trigger.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mo
-off-by: Stas Sergeev
---
drivers/leds/led-class.c | 19 ---
drivers/leds/led-core.c |9 +
include/linux/leds.h |4 ++--
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 795ec99
-off-by: Stas Sergeev
---
drivers/leds/led-class.c | 19 ---
drivers/leds/led-core.c |9 +
include/linux/leds.h |4 ++--
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 795ec99
s not enough
for that tasks.
CC: Bryan Wu
CC: Richard Purdie
CC: Jacek Anaszewski
CC: linux-l...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Stas Sergeev
---
drivers/leds/led-class.c | 18 +++-
drivers/leds/trigger/ledtrig-timer.c | 77 ++
This adds the description of /sys/class/leds//delay_unit.
It allows you to specify the delay unit for the led trigger timer.
CC: Jonathan Corbet
CC: linux-...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Stas Sergeev
---
Documentation/leds/leds-class.txt |4
1
Hi.
27.04.2015 23:54, Pavel Machek пишет:
Hi!
The following patches improve the precision of led
timer trigger and add the delay unit control.
That allows to make PWM brightness control with timer
trigger.
Are you sure that is good idea? Doing LED pwm with main cpu is quite harsh...
Do you r
27.04.2015 23:54, Pavel Machek пишет:
Hi!
The following patches improve the precision of led
timer trigger and add the delay unit control.
That allows to make PWM brightness control with timer
trigger.
Are you sure that is good idea? Doing LED pwm with main cpu is quite harsh...
We already ha
28.04.2015 11:57, Jacek Anaszewski пишет:
> Hi Stas,
>
> Have you tested it?
Of course I did.
Works with gpio driver and provides up to 10usec precision on
armada-xp board.
This is 1000 times better than without my patch - the precision
was 10ms (jiffy).
> I tried it with Samsung M0 board and
> m
28.04.2015 15:58, Jacek Anaszewski пишет:
> On 04/28/2015 12:12 PM, Stas Sergeev wrote:
>> 28.04.2015 11:57, Jacek Anaszewski пишет:
>>> Hi Stas,
>>>
>>> Have you tested it?
>> Of course I did.
>> Works with gpio driver and provides up to 10usec
28.04.2015 15:58, Jacek Anaszewski пишет:
> On 04/28/2015 12:12 PM, Stas Sergeev wrote:
>> 28.04.2015 11:57, Jacek Anaszewski пишет:
>>> Hi Stas,
>>>
>>> Have you tested it?
>> Of course I did.
>> Works with gpio driver and provides up to 10usec
28.04.2015 15:58, Jacek Anaszewski пишет:
>>> I tried it with Samsung M0 board and
>>> my leds-aat1290 driver. It didn't work well. And for small delay
>>> intervals it will not have a chance to work reliably with all drivers,
>>> especially the ones which use mutex in their brightness_set op,
>>>
30.04.2015 20:30, Pavel Machek пишет:
For the timer trigger I would pretty much like my approach to stay.
The reason is that the PWM I need to do, is not strictly a PWM -
it needs the ON period in range of tens or hundreds of milliseconds,
while the OFF period is in a couple of usecs (or vice-ver
02.05.2015 17:59, Pavel Machek пишет:
> On Thu 2015-05-14 18:24:02, Stas Sergeev wrote:
>>
>> The following sequence:
>> echo timer >/sys/class/leds//trigger
>> echo 1 >/sys/class/leds//brightness
>> should change the ON brightness for blinking.
>> The
21.05.2015 18:26, Stas Sergeev пишет:
> 21.05.2015 16:37, Jacek Anaszewski пишет:
>> On 05/21/2015 03:27 PM, Stas Sergeev wrote:
>>> 21.05.2015 16:22, Jacek Anaszewski пишет:
>>>> Hi Stas,
>>>>
>>>> My intention was to add a developer of each d
01.06.2015 11:31, Jacek Anaszewski пишет:
> With this approach, the LED will remain in its current blink state, in
> case LED_BRIGHTNESS_FAST flag is not set and delay to be set is below
> LED_SLOW_MIN_PERIOD. This is because timer is deleted at the beginning
> of led_blink_set. Effectively this c
01.06.2015 17:19, Jacek Anaszewski пишет:
>> In fact, the things are more complicated: some drivers do small
>> udelay()'s but do not use a work-queue. I was not marking them as
>> FAST, although perhaps they could still be marked as SYNC?
> This could be handled by adding a property to struct led_
e the patch was tested to fix a regression, it should be applied to
stable tree.
Tested-by: Arnaud Ebalard
CC: Thomas Petazzoni
CC: Florian Fainelli
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: sta...@vger.kernel.org
Signed-off-by: Stas Sergeev
---
drivers/net/ethernet/marve
03.12.2013 04:18, Peter Hurley пишет:
> Unfortunately, this patch breaks EOF push handling.
>
> Normally, when an EOF is found not at the line start, the output
> is made available to a canonical reader (without the EOF) -- this is
> commonly referred to as EOF push. An EOF at the beginning of a li
03.12.2013 21:00, Peter Hurley пишет:
Any unit test is specifically designed to break the code under test.
This unit test does in fact break a possible input: note specifically
that the writer is not changing the termios so has no control over
the timing of when the input is received.
Also note
28.01.2014 16:03, Pavel Machek пишет:
> Hi!
>
How is this different from the unpatched kernel?
In the unpatched kernel, if you happen on reader side
to enable icanon while n_tty received all but VEOF (is this
possible at all?),
then the buffer will be flushed, and the remai
09.12.2013 21:10, Peter Hurley пишет:
On 12/09/2013 11:26 AM, Stas Sergeev wrote:
09.12.2013 18:50, Peter Hurley пишет:
if (found && read_buf(ldata, eol) == __DISABLED_CHAR) {
n--;
eof_push = !n && ldata->read_tail != ldata->line_start;
+
04.12.2013 03:53, Peter Hurley пишет:
On 12/03/2013 02:18 PM, Stas Sergeev wrote:
03.12.2013 21:00, Peter Hurley пишет:
Any unit test is specifically designed to break the code under test.
This unit test does in fact break a possible input: note specifically
that the writer is not changing the
ds an
explicit cache flushes.
Signed-off-by: Stas Sergeev
---
arch/sh/mm/gup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/sh/mm/gup.c b/arch/sh/mm/gup.c
index bf8daf9..37458f3 100644
--- a/arch/sh/mm/gup.c
+++ b/arch/sh/mm/gup.c
@@ -105,6 +105,8 @@ static noinline int gup_pte_range(
08.07.2015 19:30, Sebastien Rannou пишет:
Hi Stas,
On Fri, 27 Mar 2015, Stas Sergeev wrote:
When MDIO bus is unavailable (common setup for SGMII), the in-band
signaling must be used to correctly track link state.
This patch enables the in-band status delivery and interrupts for
links state
08.07.2015 10:35, Greg Kroah-Hartman пишет:
4.1-stable review patch. If anyone has any objections, please let me know.
--
From: Stas Sergeev
[ Upstream commit 538761b794c1542f1c6e31eadd9d7aae118889f7 ]
The commit 898b2970e2c9 ("mvneta: implement SGMII-based in-band
08.07.2015 20:36, Greg Kroah-Hartman пишет:
On Wed, Jul 08, 2015 at 08:10:46PM +0300, Stas Sergeev wrote:
08.07.2015 10:35, Greg Kroah-Hartman пишет:
4.1-stable review patch. If anyone has any objections, please let me know.
--
From: Stas Sergeev
[ Upstream commit
08.07.2015 22:36, Arnaud Ebalard пишет:
Hi,
Stas Sergeev writes:
Another problem was reported:
https://lkml.org/lkml/2015/7/8/865
So, while the above patch is correct and fixes what
it should, the original patch has more problems to deal
with. Maybe for stable it would be better to just
09.07.2015 12:19, Thomas Petazzoni пишет:
> Sebastien, Stas,
>
> On Thu, 9 Jul 2015 11:03:26 +0200 (CEST), Sebastien Rannou wrote:
>> On Wed, 8 Jul 2015, Stas Sergeev wrote:
>>
>>> What is there? A phy chip, or something else?
>>
>> It's "some
Hello.
Currently the link status auto-negotiation is enabled
for any SGMII link with fixed-link DT binding.
The regression was reported:
https://lkml.org/lkml/2015/7/8/865
Apparently not all HW that implements SGMII protocol, generates the
inband status for the auto-negotiation to work.
The follo
quot;auto" is needed to enable the link paramaters auto-negotiation,
that is built into some MII protocols, namely SGMII.
The appropriate documentation is added and explicitly states that
"auto" is very specific (protocol, HW and driver-specific), and
is therefore should be used with care.
S
ng regression:
https://lkml.org/lkml/2015/7/8/865
and is therefore CCed to stable.
Signed-off-by: Stas Sergeev
CC: Thomas Petazzoni
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: sta...@vger.kernel.org
---
drivers/net/ethernet/marvell/mvneta.c | 6 +++---
1 file changed,
09.07.2015 21:18, Florian Fainelli пишет:
On 09/07/15 10:41, Stas Sergeev wrote:
The commit 898b2970e2c9 ("mvneta: implement SGMII-based in-band link state
signaling") implemented the link parameters auto-negotiation unconditionally.
Unfortunately it appears that some HW that implem
09.07.2015 21:24, Florian Fainelli пишет:
(there is no such thing as linux-...@vger.kernel.org, please remove it
from your future submissions).
On 09/07/15 10:38, Stas Sergeev wrote:
Currently for fixed-link the link state is always set to UP.
Not quite true, this is always a driver decision
10.07.2015 00:14, Florian Fainelli пишет:
On 09/07/15 13:26, Stas Sergeev wrote:
09.07.2015 21:18, Florian Fainelli пишет:
On 09/07/15 10:41, Stas Sergeev wrote:
The commit 898b2970e2c9 ("mvneta: implement SGMII-based in-band link
state
signaling") implemented the link param
10.07.2015 00:15, Florian Fainelli пишет:
On 09/07/15 13:43, Stas Sergeev wrote:
09.07.2015 21:24, Florian Fainelli пишет:
(there is no such thing as linux-...@vger.kernel.org, please remove it
from your future submissions).
On 09/07/15 10:38, Stas Sergeev wrote:
Currently for fixed-link the
nk regardless,
outside of the "if (status->link)" block.
Other than that,
Acked-by: Stas Sergeev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
26.08.2015 17:58, Madalin Bucur пишет:
> The fixed link values parsed from the device tree are stored in
> the struct fixed_phy member status. The struct phy_device members
> speed, duplex were not updated.
ACK, but IMHO it will make more sense if you include that
into your upcoming patch set rath
14.08.2015 04:37, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote:
14.08.2015 04:21, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote:
14.08.2015 03:27, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
For
13.08.2015 20:00, Brian Gerst пишет:
On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski wrote:
On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
wrote:
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote:
I realize this patch may be good to have in general, but
breaking userspace without a
13.08.2015 23:07, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 12:59 PM, Stas Sergeev wrote:
It doesn't: fedora provides a "sanitized up" version of sigcontext.h
in /usr/include/bits, which comes from glibc-headers-2.21-7.fc22.x86_64.
So it seems the "sanitized up"
19.08.2015 01:47, Andy Lutomirski пишет:
> On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev wrote:
>> 14.08.2015 04:37, Andy Lutomirski пишет:
>>
>>> On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote:
>>>>
>>>> 14.08.2015 04:21, Andy Lutomirski п
19.08.2015 01:42, Andy Lutomirski пишет:
> On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev wrote:
>> 13.08.2015 20:00, Brian Gerst пишет:
>>
>>> On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski
>>> wrote:
>>>>
>>>> On Thu, Aug 13, 2015 a
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 return from a signal, there's no concept
>>> of siga
12.08.2015 22:20, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 11:55 AM, Stas Sergeev wrote:
12.08.2015 21:25, Andy Lutomirski пишет:
https://github.com/stsp/dosemu2/commit/7898ac60d5e569964127d6cc48f592caecd20b81
So the problem is that dosemu was actually hacking around the old
buggy
12.08.2015 23:01, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 12:55 PM, Stas Sergeev wrote:
12.08.2015 22:20, Andy Lutomirski пишет:
current kernels, it stays switched. If we change this, it won't stay
switched. Even ignoring old ABI, it's not really clear to me what the
righ
12.08.2015 23:28, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 1:14 PM, Stas Sergeev wrote:
12.08.2015 23:01, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 12:55 PM, Stas Sergeev wrote:
12.08.2015 22:20, Andy Lutomirski пишет:
current kernels, it stays switched. If we change this, it
12.08.2015 23:47, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 1:45 PM, Stas Sergeev wrote:
12.08.2015 23:28, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 1:14 PM, Stas Sergeev wrote:
12.08.2015 23:01, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 12:55 PM, Stas Sergeev wrote
13.08.2015 00:37, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 1:55 PM, Stas Sergeev wrote:
12.08.2015 23:47, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 1:45 PM, Stas Sergeev wrote:
12.08.2015 23:28, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 1:14 PM, Stas Sergeev wrote
13.08.2015 11:39, Ingo Molnar пишет:
* Andy Lutomirski wrote:
OK.
I'll try to test the patch tomorrow, but I think the sigreturn()'s
capability detection is still needed to easily replace the iret trampoline
in userspace (without generating a signal and testing by hands).
Can of course be done
13.08.2015 01:00, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 2:50 PM, Stas Sergeev wrote:
13.08.2015 00:37, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 1:55 PM, Stas Sergeev wrote:
12.08.2015 23:47, Andy Lutomirski пишет:
On Wed, Aug 12, 2015 at 1:45 PM, Stas Sergeev wrote
13.08.2015 11:39, Ingo Molnar пишет:
* Andy Lutomirski wrote:
OK.
I'll try to test the patch tomorrow, but I think the sigreturn()'s
capability detection is still needed to easily replace the iret trampoline
in userspace (without generating a signal and testing by hands).
Can of course be done
13.08.2015 17:58, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev wrote:
13.08.2015 11:39, Ingo Molnar пишет:
* Andy Lutomirski wrote:
OK.
I'll try to test the patch tomorrow, but I think the sigreturn()'s
capability detection is still needed to easily r
13.08.2015 18:38, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 8:22 AM, Stas Sergeev wrote:
13.08.2015 17:58, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev wrote:
13.08.2015 11:39, Ingo Molnar пишет:
* Andy Lutomirski wrote:
OK.
I'll try to test the
13.08.2015 19:09, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev wrote:
13.08.2015 18:38, Andy Lutomirski пишет:
So... what do we do about it? We could revert the whole mess. We
could tell everyone to fix their DOSEMU, which violates policy and is
especially annoying
13.08.2015 19:24, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev wrote:
13.08.2015 19:09, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev wrote:
13.08.2015 18:38, Andy Lutomirski пишет:
So... what do we do about it? We could revert the whole
13.08.2015 19:42, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev wrote:
13.08.2015 19:24, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev wrote:
13.08.2015 19:09, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev wrote
13.08.2015 19:59, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:48 AM, Stas Sergeev wrote:
13.08.2015 19:42, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev wrote:
13.08.2015 19:24, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev wrote
13.08.2015 18:37, Linus Torvalds пишет:
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote:
I realize this patch may be good to have in general, but
breaking userspace without a single warning is a bit
discouraging. Seems like the old "we don't break userspace"
rule have g
13.08.2015 20:17, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev wrote:
Ah, I see your point now.
But that's not what I mean, as it doesn't cover fs/gs, which
is what Linus is looking to revert now too (I am building the
testing kernels now).
So you obviously
13.08.2015 21:05, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 11:00 AM, Stas Sergeev wrote:
13.08.2015 20:17, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev wrote:
Ah, I see your point now.
But that's not what I mean, as it doesn't cover fs/gs, which
is
13.08.2015 21:25, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 11:19 AM, Stas Sergeev wrote:
It is more about selecting the right field for such a flag.
You can select the right field now, and introduce some flag
to it, like SIG_SAVE_SS or whatever. This will fix a regression.
Then, when
13.08.2015 21:35, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev wrote:
Hello Linus, I verified that patch-minimal.diff is enough
to fix the problem, BUT! dosemu is in fact using the .fs and
.gs fields of sigcontext as a placeholders. Why the minimal
patch alone helps is
13.08.2015 21:41, Andy Lutomirski пишет:
Stas: I think uc_flags is okay. We don't currently read it during
sigreturn, but I see no reason that we can't start reading it.
Andy, we definitely have some communication discontinuity here. :)
The point is not sigreturn. If we are talking about the fl
13.08.2015 22:01, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 11:57 AM, Stas Sergeev wrote:
13.08.2015 21:35, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev wrote:
Hello Linus, I verified that patch-minimal.diff is enough
to fix the problem, BUT! dosemu is in fact
13.08.2015 22:37, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 12:13 PM, Stas Sergeev wrote:
As for the compilation failure - I am surprised you even care.
I thought the "we don't break userspace" covers only run-time,
not compile-time. Oh well.
I definitely care.
Compil
13.08.2015 22:49, Andy Lutomirski пишет:
On Aug 13, 2015 12:05 PM, "Stas Sergeev" wrote:
13.08.2015 21:41, Andy Lutomirski пишет:
Stas: I think uc_flags is okay. We don't currently read it during
sigreturn, but I see no reason that we can't start reading it.
Andy, we
14.08.2015 00:46, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings wrote:
I am curious about what's supposed to happen normally on signal delivery.
Is SS a register that's supposed to be preserved like EIP/RIP and CS when a
signal is delivered?
What exactly does "suppos
14.08.2015 01:01, Raymond Jennings пишет:
On 08/13/15 14:46, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings
wrote:
I am curious about what's supposed to happen normally on signal
delivery.
Is SS a register that's supposed to be preserved like EIP/RIP and CS
when a
14.08.2015 01:11, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev wrote:
14.08.2015 00:46, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings
wrote:
I am curious about what's supposed to happen normally on signal delivery.
Is SS a register t
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
14.08.2015 01:11, Andy Lutomirski пишет:
Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
and then gets #GP. You
14.08.2015 02:00, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
14.08.2015 01:11, Andy Lutomirski пишет:
Now suppose you set some magic flag and jump (via sigreturn
14.08.2015 02:18, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
wrote:
The _only_ thing that matters is that something broke.
To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a work
14.08.2015 02:00, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
14.08.2015 01:11, Andy Lutomirski пишет:
Now suppose you set some magic flag and jump (via sigreturn
14.08.2015 03:05, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote:
14.08.2015 02:00, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote
14.08.2015 03:27, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sighandler to its current value",
I really think a prctl() is the wrong thing to do.
If
14.08.2015 04:21, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote:
14.08.2015 03:27, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore
101 - 200 of 467 matches
Mail list logo
