which shared same CPU core.
> >
>
> Hmm, it seems you just make the sort slower, and nothing more changes.
> Am I right ?
Well, it has to make the sort slower, but it'll also avoid hogging the
CPU (on a non-preemptible kernel), avoiding a potential soft lockup
warning and allowing other tasks to run.
--
Vojtech Pavlik
VP SUSE Labs
in a
time window after that.
> Let me gain some experience with the patch. I don't think hardware
> does as heavy debouncing as you describe.
Microswitches vibrate significantly when clicked. Without hardware
debouncing, you'd have many clicks instead of one even on a new mouse.
--
Vojtech Pavlik
en updates from the hardware, a
real doubleclick can look absolutely the same as what you observe as a
bounce.
As such, it couldn't be enabled by default.
If you really want to go this way, a userspace solution is the better choice.
--
Vojtech Pavlik
/
> { USB_DEVICE(0x061c, 0xc084) }, /* ACT LABS Force RS */
> + { USB_DEVICE(0x06a3, 0xff04) }, /* Saitek R440 Force Wheel */
> { USB_DEVICE(0x06f8, 0x0001) }, /* Guillemot Race Leader Force
> Feedback */
> { USB_DEVICE(0x06f8, 0x0003) }, /* Guillemot Jet Leader Force
> Feedback */
> { USB_DEVICE(0x06f8, 0x0004) }, /* Guillemot Force Feedback
> Racing Wheel */
> --
> 2.19.1.450.ga4b8ab536
>
--
Vojtech Pavlik
Director SUSE Labs
/
> { USB_DEVICE(0x061c, 0xc084) }, /* ACT LABS Force RS */
> + { USB_DEVICE(0x06a3, 0xff04) }, /* Saitek R440 Force Wheel */
> { USB_DEVICE(0x06f8, 0x0001) }, /* Guillemot Race Leader Force
> Feedback */
> { USB_DEVICE(0x06f8, 0x0003) }, /* Guillemot Jet Leader Force
> Feedback */
> { USB_DEVICE(0x06f8, 0x0004) }, /* Guillemot Force Feedback
> Racing Wheel */
> --
> 2.19.1.450.ga4b8ab536
>
--
Vojtech Pavlik
Director SUSE Labs
this way, but nevertheless, the
address isn't valid anymore, so removing it makes good sense.
--
Vojtech Pavlik
Director SUSE Labs
this way, but nevertheless, the
address isn't valid anymore, so removing it makes good sense.
--
Vojtech Pavlik
Director SUSE Labs
o I can have caching _and_ compatibility with
> grub2 etc (and avoid 400GB move):
The common way to do that is to move the beginning of the partition,
assuming your ext4 lives in a partition.
I don't see how overlapping the ext4 and the bcache backing device
starts would give you what you want, because bcache assumes the
backing device data starts with an offset.
--
Vojtech Pavlik
o I can have caching _and_ compatibility with
> grub2 etc (and avoid 400GB move):
The common way to do that is to move the beginning of the partition,
assuming your ext4 lives in a partition.
I don't see how overlapping the ext4 and the bcache backing device
starts would give you what you want, because bcache assumes the
backing device data starts with an offset.
--
Vojtech Pavlik
er against
each kernel code address verifying the output and bail if there is a bug
in the toolchain that affects it.
--
Vojtech Pavlik
Director SuSE Labs
er against
each kernel code address verifying the output and bail if there is a bug
in the toolchain that affects it.
--
Vojtech Pavlik
Director SuSE Labs
struct gameport_driver *drv)
>
> gf2k_trigger_seq(gameport, gf2k_seq_reset);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> gf2k_trigger_seq(gameport, gf2k_seq_digital);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> if (gf2k_read_packet(gameport, GF2K_LENGTH, data) < 12) {
> err = -ENODEV;
> --
> 2.6.2
>
--
Vojtech Pavlik
gameport_driver *drv)
>
> gf2k_trigger_seq(gameport, gf2k_seq_reset);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> gf2k_trigger_seq(gameport, gf2k_seq_digital);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> if (gf2k_read_packet(gameport, GF2K_LENGTH, data) < 12) {
> err = -ENODEV;
> --
> 2.6.2
>
--
Vojtech Pavlik
X_TIME, ANALOG_MAX_TIME + 100);
> + t = gameport_time(gameport, ANALOG_MAX_TIME);
> gameport_trigger(gameport);
> while ((gameport_read(port->gameport) & port->mask) && (u < t))
> u++;
> --
> 2.6.2
>
--
Vojtech Pavlik
+ 100);
> + t = gameport_time(gameport, ANALOG_MAX_TIME);
> gameport_trigger(gameport);
> while ((gameport_read(port->gameport) & port->mask) && (u < t))
> u++;
> --
> 2.6.2
>
--
Vojtech Pavlik
= -ENODEV;
> goto fail2;
> }
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> j = sw_read_packet(gameport, idbuf, SW_LENGTH, i); /*
> Retry reading ID */
> dbg("Init 2c: ID Length %d.", j);
> }
> @@ -655,7 +655,7 @@ static int sw_connect(struct gameport *gameport, struct
> gameport_driver *drv)
>
> do {
> k--;
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> i = sw_read_packet(gameport, buf, SW_LENGTH, 0);/* Read
> data packet */
> dbg("Init 3: Mode %d. Length %d. Last %d. Tries %d.", m, i, l,
> k);
>
> --
> 2.6.2
>
--
Vojtech Pavlik
goto fail2;
> }
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> j = sw_read_packet(gameport, idbuf, SW_LENGTH, i); /*
> Retry reading ID */
> dbg("Init 2c: ID Length %d.", j);
> }
> @@ -655,7 +655,7 @@ static int sw_connect(struct gameport *gameport, struct
> gameport_driver *drv)
>
> do {
> k--;
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> i = sw_read_packet(gameport, buf, SW_LENGTH, 0);/* Read
> data packet */
> dbg("Init 3: Mode %d. Length %d. Last %d. Tries %d.", m, i, l,
> k);
>
> --
> 2.6.2
>
--
Vojtech Pavlik
On Mon, Apr 04, 2016 at 01:33:07PM -0500, Josh Poimboeuf wrote:
> On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> > On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> >
> > > Hm, can you explain why it should be copied from the parent?
&
On Mon, Apr 04, 2016 at 01:33:07PM -0500, Josh Poimboeuf wrote:
> On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> > On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> >
> > > Hm, can you explain why it should be copied from the parent?
&
?
How could a newly forked task start in the old universe if its parent
has already been migrated? Any context it inherits will already be from
the new universe.
--
Vojtech Pavlik
Director SuSE Labs
?
How could a newly forked task start in the old universe if its parent
has already been migrated? Any context it inherits will already be from
the new universe.
--
Vojtech Pavlik
Director SuSE Labs
>
> LIVE PATCHING
> M: Josh Poimboeuf <jpoim...@redhat.com>
> -M: Seth Jennings <sjenn...@redhat.com>
> +M: Jessica Yu <j...@redhat.com>
> M: Jiri Kosina <ji...@kernel.org>
> -M: Vojtech Pavlik <vojt...@suse.com>
> +M: Miroslav
> M: Josh Poimboeuf
> -M: Seth Jennings
> +M: Jessica Yu
> M: Jiri Kosina
> -M: Vojtech Pavlik
> +M: Miroslav Benes
> +R: Petr Mladek
> S: Maintained
> F: kernel/livepatch/
> F: include/linux/livepatch.h
> --
> 2.4.3
Acked-by: Vojtech Pavlik
--
Vojtech Pavlik
Director SuSE Labs
Fix writeback_thread never finishing writing back all dirty data in bcache when
partial_stripes_expensive is set, and spinning, consuming 100% of CPU instead.
Signed-off-by: Vojtech Pavlik
---
This is a fix for the current upstream bcache, not the devel branch.
If partial_stripes_expensive
Fix writeback_thread never finishing writing back all dirty data in bcache when
partial_stripes_expensive is set, and spinning, consuming 100% of CPU instead.
Signed-off-by: Vojtech Pavlik <vojt...@suse.com>
---
This is a fix for the current upstream bcache, not the devel
Each callable function must never leave its own bounds (i.e. with a
> >jump to outside the function) except when returning.
>
> Won't that break with sibling/tail calls? GCC can generate those, and
> the ia32_ptregs_common label is an example of such a thing.
It only validates
returning.
Won't that break with sibling/tail calls? GCC can generate those, and
the ia32_ptregs_common label is an example of such a thing.
It only validates hand-written assembly, so how it could?
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe
ly would
> they be?
A windows translation layer is fairly easy, people porting software from
Windows to Linux told me numerous times that adapting isn't hard. I also
believe that at least one of the BSD's has a compatible implementation
these days based on the fact that I was asked to allow copying th
translation layer is fairly easy, people porting software from
Windows to Linux told me numerous times that adapting isn't hard. I also
believe that at least one of the BSD's has a compatible implementation
these days based on the fact that I was asked to allow copying the
headers in the past.
--
Vojtech
n be realistic.
> Granted, with live kernel upgrades it's much more complex
> to get the 'simple' case into an even rudimentarily working
> fashion (full userspace state has to be enumerated, saved
> and restored), but once we are there, it's a whole new
> category of goodness and it
here for some
> reason the initialization sequence takes longer time and it
> makes sense to share hardware discovery information between
> two versions of the driver. I'm not convinced such a
> mechanism is necessary in the general case.
--
Vojtech Pavlik
Director SUSE Labs
--
To
give up. On the other hand, I
definitely wouldn't argue against having modes of operation where the
latency is higher and the tool is more powerful.
> I.e. don't make it a single-issue project.
There is no need to worry about that.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from th
that.
--
Vojtech Pavlik
Director SUSE Labs
--
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/
patching usecases on day 1 already ...
Feel free to start working on it. I'll stick with live patching.
--
Vojtech Pavlik
Director SUSE Labs
--
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
discovery information between
two versions of the driver. I'm not convinced such a
mechanism is necessary in the general case.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
kGraft has tools to automate the generation of patches,
these are generally not required to create a patch.
--
Vojtech Pavlik
Director SUSE Labs
--
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://
to create a patch.
--
Vojtech Pavlik
Director SUSE Labs
--
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/
n a disaster scenario. Not
necessarily for a regular update scenario.
The value of live patching is in near zero disruption.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
scenario.
The value of live patching is in near zero disruption.
--
Vojtech Pavlik
Director SUSE Labs
--
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
mes at the highest cost in terms of impact on running
tasks. It's so high (the interruption may be seconds or more) that it
was deemed not worth implementing.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
implementing.
--
Vojtech Pavlik
Director SUSE Labs
--
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/
On Thu, Feb 19, 2015 at 11:32:55AM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 19, 2015 at 06:19:29PM +0100, Vojtech Pavlik wrote:
> > On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> > > On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> >
klp_switch_task_universe(task);
The s390x arch used to have a TIF_SYSCALL, which was doing exactly that (well,
negated). I think it would work well, but it isn't entirely for free: two
instructions per syscall and an extra TIF bit, which are (near) exhausted on
some archs.
--
Vojtech
On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> > On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
> >
> > > > No, these tasks will _never_ make syscalls. So you need to g
;
> > It is, see kthread_park().
>
> When the kthread returns from kthread_parkme(), it'll still be running
> the old thread_fn code, regardless of whether we flipped the task's
> patch state.
We could instrument kthread_parkme() to be able to return to a different
function, but
On Thu, Feb 19, 2015 at 10:52:51AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote:
> > For live patching it doesn't matter whether code is running, sleeping or
> > frozen.
> >
> > What matters is whether there is sta
On Thu, Feb 19, 2015 at 11:32:55AM -0600, Josh Poimboeuf wrote:
On Thu, Feb 19, 2015 at 06:19:29PM +0100, Vojtech Pavlik wrote:
On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
On Thu, Feb 19, 2015 at 10:24
On Thu, Feb 19, 2015 at 10:52:51AM +0100, Peter Zijlstra wrote:
On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote:
For live patching it doesn't matter whether code is running, sleeping or
frozen.
What matters is whether there is state before patching that may not be
valid
function, but it'd be a bit crazy indeed.
--
Vojtech Pavlik
Director SUSE Labs
--
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
On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
No, these tasks will _never_ make syscalls. So you need to guarantee
they don't accidentally
);
The s390x arch used to have a TIF_SYSCALL, which was doing exactly that (well,
negated). I think it would work well, but it isn't entirely for free: two
instructions per syscall and an extra TIF bit, which are (near) exhausted on
some archs.
--
Vojtech Pavlik
Director SuSE Labs
--
To unsubscribe from
he freezer itself, though. And isn't
obvious for author of new kernel threads either.
The ideal solution would be to convert the majority of kernel threads to
workqueues, because then there is a defined entry/exit point over which
state isn't transferred. That is a lot of work, though, and has other
dr
/exit point over which
state isn't transferred. That is a lot of work, though, and has other
drawbacks, particularly in the realtime space.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
e equal, others can comment
Since any loaded kernel module can do virtually anything on a machine,
there can only be one level of trust. As such, all trusted keys are
equally trusted.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
.
--
Vojtech Pavlik
Director SUSE Labs
--
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/
whether one
is enough, or whether an engine that can do more than one is required.
The consistency models of kpatch and kGraft aren't directly compatible.
I think we're on a good way towards a single model, but we'll see when
it's implemented within the live patching framework just posted.
--
V
the patch changes, then it cannot be
applied.
If the changes are small and localized, don't depend on the order in
which individual functions are replaced, when both new and old code can
run in parallel on different CPUs or in sequence in a single thread
safely, then it can be applied.
--
Vojtech
individual functions are replaced, when both new and old code can
run in parallel on different CPUs or in sequence in a single thread
safely, then it can be applied.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
framework just posted.
--
Vojtech Pavlik
Director SUSE Labs
--
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
nking about, too. But I'm also thinking, "this will
be complex, is it really needed"?
> Anyway, I'd like to support for this effort from kernel side.
> At least I have to solve ftrace regs conflict by IPMODIFY flag and
> a headache kretprobe failure case by sharing per-threa
kretprobe failure case by sharing per-thread retstack
with ftrace-callgraph.
While I don't know enough about the IPMODIFY flag, I wholeheartedly
support sharing the return stacks between kprobes and ftrace graph
caller.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line
e counters
reach zero.
This handles the frequent sleeper case, it doesn't need annotated kernel
thread main loops, it will not need the user to wake up every process in
the system unless it sleeps in a patched function.
And it can handle all the patches that kpatch and kGraft can (it n
, which causes the calling function to be considered
different, or just add it to the set of functions considered manually.
I'd prefer latter one :) or just gives hints of watching targets.
Me too.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe
e to be handled possibly case by case.
Also, kernel threads are problematic for kGraft (as you may have seen in
earlier kGraft upstream submissions) as they never leave the kernel.
--
Vojtech Pavlik
Director SUSE Labs
--
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/
en all of the threads are outside of the patched set at the
> > same time. Depending on how often the functions are used and how large
> > the set is, reaching that moment will get harder.
>
> Yeah, I think this is the biggest drawback of SWITCH_KERNEL. More
> likely to fail (o
the perfect moment.
--
Vojtech Pavlik
Director SUSE Labs
--
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/
or SIGSTOP/SIGCONT. It's one of the disadvantages
of kGraft that sleeper threads have to be handled possibly case by case.
Also, kernel threads are problematic for kGraft (as you may have seen in
earlier kGraft upstream submissions) as they never leave the kernel.
--
Vojtech Pavlik
Director SUSE
On Fri, Nov 07, 2014 at 09:45:53PM -0600, Josh Poimboeuf wrote:
> On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
> > On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
> >
> > > > LEAVE_FUNCTION
> > > > LEAVE_P
On Fri, Nov 07, 2014 at 09:45:53PM -0600, Josh Poimboeuf wrote:
On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
LEAVE_FUNCTION
LEAVE_PATCHED_SET
LEAVE_KERNEL
NEL for the 10% of complex patches. This because
(LEAVE_PATCHED_SET) SWITCH_THREAD finishes much quicker. But I'm biased
there. ;)
It seems more and more to me that we will actually want the more
powerful engine coping with the various options.
--
Vojtech Pavlik
Director SUSE Labs
--
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/
o what the consistency model should look like.
PPS.: I haven't included any handling of changed data structures in
this, that's another set of properties.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
> > On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> >
> > > On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrot
On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think
the consistency model should look like.
PPS.: I haven't included any handling of changed data structures in
this, that's another set of properties.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
a SWITCH_KERNEL for the 10% of complex patches. This because
(LEAVE_PATCHED_SET) SWITCH_THREAD finishes much quicker. But I'm biased
there. ;)
It seems more and more to me that we will actually want the more
powerful engine coping with the various options.
--
Vojtech Pavlik
Director SUSE Labs
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> > I don't think this specific example was generated.
> >
> > I also don't think including the whole kpatch automation into the kernel
a viable development model for it. (Same would apply for kGraft
automation.)
So I believe including one or more human produced examples makes most sense.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
d symbols if any are
referenced.
So no objection to the idea. We'll have to look more into the code to
comment on the implementation of the dynrela stuff.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
more into the code to
comment on the implementation of the dynrela stuff.
--
Vojtech Pavlik
Director SUSE Labs
--
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
would apply for kGraft
automation.)
So I believe including one or more human produced examples makes most sense.
--
Vojtech Pavlik
Director SUSE Labs
--
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
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this specific example was generated.
I also don't think including the whole kpatch automation into the kernel
tree is a viable development
consistency when patching, so TIF_KGR and the lazy migration will not
exist, and neither will we be stopping the kernel or checking stacks.
This will make applying patches bigger than a single functions tricky,
but it's a good initial goal.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubs
stacks.
This will make applying patches bigger than a single functions tricky,
but it's a good initial goal.
--
Vojtech Pavlik
Director SUSE Labs
--
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
Hello Heiko,
I can confirm that kGraft works well on top of current mainline with
this patch added.
Another reason for a performance impact when kGraft is enabled is that
kGraft still adds two instructions to the syscall path on s390x, as
there is no space left for a kgraft TIF in the first
Hello Heiko,
I can confirm that kGraft works well on top of current mainline with
this patch added.
Another reason for a performance impact when kGraft is enabled is that
kGraft still adds two instructions to the syscall path on s390x, as
there is no space left for a kgraft TIF in the first
en when the speed of the i/o operations
changes.
What is important is that the GET_TIME() macro is fast (0.1 usec or
less), precise (sub-microsecond resolution) and reliable. Digital
protocols also rely on udelay() and mdelay() waiting precisely for the
amount of time specified.
--
Vojtech Pav
), precise (sub-microsecond resolution) and reliable. Digital
protocols also rely on udelay() and mdelay() waiting precisely for the
amount of time specified.
--
Vojtech Pavlik
Director SuSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
ws.htm
> >
>
> They have better chance of being supported ;) I had a couple a few years back
> and they did work for me.
They do work for analog joysticks if you don't want any extended
functionality. I have a couple in said box.
--
Vojtech Pavlik
Director SuSE Labs
--
To unsubscr
if you don't want any extended
functionality. I have a couple in said box.
--
Vojtech Pavlik
Director SuSE Labs
--
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
of return address by changing the PSW (instruction
pointer) member od struct pt_regs.
Signed-off-by: Vojtech Pavlik
Reviewed-by: Jiri Kosina
Cc: Steven Rostedt
---
arch/s390/Kconfig |1
arch/s390/include/asm/ftrace.h |4 ++
arch/s390/include/asm/lowcore.h | 12
of return address by changing the PSW (instruction
pointer) member od struct pt_regs.
Signed-off-by: Vojtech Pavlik vojt...@suse.cz
Reviewed-by: Jiri Kosina jkos...@suse.cz
Cc: Steven Rostedt rost...@goodmis.org
---
arch/s390/Kconfig |1
arch/s390/include/asm/ftrace.h |4
> enabled. What other hot paths do you refer to?
As Jiří says, I don't see any hot path where kGraft would add
instructions: Kernel exit and entry are handled outside the hot path
in the _TIF_WORK_SYSCALL_ENTRY and _TIF_ALLWORK_MASK handlers. [patch 15/21]
It adds instructions into the main loops of
are handled outside the hot path
in the _TIF_WORK_SYSCALL_ENTRY and _TIF_ALLWORK_MASK handlers. [patch 15/21]
It adds instructions into the main loops of kernel threads, but those
can hardly be called hot paths as they mostly sleep for long times.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe
stack
* Second NMI handler ends
* First NMI handler ends and goes into an infinite IRET loop, always
returning to the beginning of itself
But you do have all the ingredients.
And I don't see any other way out than not calling IRET for MCEs.
--
Vojtech Pavlik
Director S
, always
returning to the beginning of itself
But you do have all the ingredients.
And I don't see any other way out than not calling IRET for MCEs.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
similar thing may happen with kgraft. If old function and
> new function share a non-auto variable and they modify it different way,
> the result will be unexpected by the mutual interference.
By non-auto I assume you mean globally accessible variable or data
structures.
Yes, with kGraft the new functi
and their semantics are free to change,
though, and kGraft guarantees consistency there.
--
Vojtech Pavlik
SUSE Labs
--
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
nd try_to_freeze() and kgr_task_safe() nicely
into one place and at the same time put enough constraint on what the
thread function can do to prevent it from breaking the assumptions of
each of these calls.
--
Vojtech Pavlik
SUSE Labs
--
To unsubscribe from this list: send the line &
put enough constraint on what the
thread function can do to prevent it from breaking the assumptions of
each of these calls.
--
Vojtech Pavlik
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
dler start and the check), a SMI-triggered
nested NMI has happened.
Then we should be able to at least report it before dying.
If it doesn't ever happen: Great, this wasn't a real concern. If it
does, we can pester BIOS vendors.
--
Vojtech Pavlik
Director SuSE Labs
--
To unsubscribe from this
1 - 100 of 1085 matches
Mail list logo
