On Wed, 2012-08-08 at 12:56 -0400, Nicolas Pitre wrote:
> On Wed, 8 Aug 2012, Russell King - ARM Linux wrote:
> > Done correctly, it shouldn't be a problem, but I wouldn't say that
> > arch/arm/kernel/kprobes-test*.c is done correctly. It's seen quite
> > a number of patching attempts since it
On Wed, 2012-08-08 at 12:56 -0400, Nicolas Pitre wrote:
On Wed, 8 Aug 2012, Russell King - ARM Linux wrote:
Done correctly, it shouldn't be a problem, but I wouldn't say that
arch/arm/kernel/kprobes-test*.c is done correctly. It's seen quite
a number of patching attempts since it was
On Wed, 8 Aug 2012, Russell King - ARM Linux wrote:
> On Wed, Aug 08, 2012 at 09:55:12AM -0400, Nicolas Pitre wrote:
> > On Wed, 8 Aug 2012, Cyril Chemparathy wrote:
> > > Neat macro magic. Are you thinking that we build this in as a self test
> > > in
> > > the code?
> >
> > For such things,
On Wed, Aug 08, 2012 at 09:55:12AM -0400, Nicolas Pitre wrote:
> On Wed, 8 Aug 2012, Cyril Chemparathy wrote:
> > Neat macro magic. Are you thinking that we build this in as a self test in
> > the code?
>
> For such things, this is never a bad idea to have some test alongside
> with the main
On Wed, 8 Aug 2012, Cyril Chemparathy wrote:
> On 08/08/12 01:56, Nicolas Pitre wrote:
> > On Tue, 7 Aug 2012, Cyril Chemparathy wrote:
> [...]
> > > u32 arm_check[] = {
> > > 0xe2810041, 0xe2810082, 0xe2810f41, 0xe2810f82, 0xe2810e41,
> > > 0xe2810e82, 0xe2810d41, 0xe2810d82, 0xe2810c41,
On 08/08/12 01:56, Nicolas Pitre wrote:
On Tue, 7 Aug 2012, Cyril Chemparathy wrote:
[...]
u32 arm_check[] = {
0xe2810041, 0xe2810082, 0xe2810f41, 0xe2810f82, 0xe2810e41,
0xe2810e82, 0xe2810d41, 0xe2810d82, 0xe2810c41, 0xe2810c82,
0xe2810b41, 0xe2810b82, 0xe2810a41,
On 08/08/12 01:56, Nicolas Pitre wrote:
On Tue, 7 Aug 2012, Cyril Chemparathy wrote:
[...]
u32 arm_check[] = {
0xe2810041, 0xe2810082, 0xe2810f41, 0xe2810f82, 0xe2810e41,
0xe2810e82, 0xe2810d41, 0xe2810d82, 0xe2810c41, 0xe2810c82,
0xe2810b41, 0xe2810b82, 0xe2810a41,
On Wed, 8 Aug 2012, Cyril Chemparathy wrote:
On 08/08/12 01:56, Nicolas Pitre wrote:
On Tue, 7 Aug 2012, Cyril Chemparathy wrote:
[...]
u32 arm_check[] = {
0xe2810041, 0xe2810082, 0xe2810f41, 0xe2810f82, 0xe2810e41,
0xe2810e82, 0xe2810d41, 0xe2810d82, 0xe2810c41, 0xe2810c82,
On Wed, Aug 08, 2012 at 09:55:12AM -0400, Nicolas Pitre wrote:
On Wed, 8 Aug 2012, Cyril Chemparathy wrote:
Neat macro magic. Are you thinking that we build this in as a self test in
the code?
For such things, this is never a bad idea to have some test alongside
with the main code,
On Wed, 8 Aug 2012, Russell King - ARM Linux wrote:
On Wed, Aug 08, 2012 at 09:55:12AM -0400, Nicolas Pitre wrote:
On Wed, 8 Aug 2012, Cyril Chemparathy wrote:
Neat macro magic. Are you thinking that we build this in as a self test
in
the code?
For such things, this is never a
On Tue, 7 Aug 2012, Cyril Chemparathy wrote:
> Hi Nicolas,
>
> On 8/4/2012 1:38 AM, Nicolas Pitre wrote:
> [...]
> > > extern unsigned __patch_table_begin, __patch_table_end;
> >
> > You could use "exttern void __patch_table_begin" so those symbols don't
> > get any type that could be misused
Hi Nicolas,
On 8/4/2012 1:38 AM, Nicolas Pitre wrote:
[...]
extern unsigned __patch_table_begin, __patch_table_end;
You could use "exttern void __patch_table_begin" so those symbols don't
get any type that could be misused by mistake, while you still can take
their addresses.
Looks like
Hi Nicolas,
On 8/4/2012 1:38 AM, Nicolas Pitre wrote:
[...]
extern unsigned __patch_table_begin, __patch_table_end;
You could use exttern void __patch_table_begin so those symbols don't
get any type that could be misused by mistake, while you still can take
their addresses.
Looks like
On Tue, 7 Aug 2012, Cyril Chemparathy wrote:
Hi Nicolas,
On 8/4/2012 1:38 AM, Nicolas Pitre wrote:
[...]
extern unsigned __patch_table_begin, __patch_table_end;
You could use exttern void __patch_table_begin so those symbols don't
get any type that could be misused by mistake,
On Mon, 6 Aug 2012, Russell King - ARM Linux wrote:
> On Mon, Aug 06, 2012 at 09:19:10AM -0400, Cyril Chemparathy wrote:
> > With a flush_cache_all(), we could avoid having to operate a cacheline
> > at a time, but that clobbers way more than necessary.
>
> You can't do that, because
On 8/6/2012 9:26 AM, Russell King - ARM Linux wrote:
On Mon, Aug 06, 2012 at 09:19:10AM -0400, Cyril Chemparathy wrote:
With a flush_cache_all(), we could avoid having to operate a cacheline
at a time, but that clobbers way more than necessary.
You can't do that, because flush_cache_all() on
On Mon, Aug 06, 2012 at 09:19:10AM -0400, Cyril Chemparathy wrote:
> With a flush_cache_all(), we could avoid having to operate a cacheline
> at a time, but that clobbers way more than necessary.
You can't do that, because flush_cache_all() on some CPUs requires the
proper MMU mappings to be in
On 8/6/2012 7:12 AM, Russell King - ARM Linux wrote:
On Tue, Jul 31, 2012 at 07:04:37PM -0400, Cyril Chemparathy wrote:
+static void __init init_patch_kernel(void)
+{
+ const void *start = &__patch_table_begin;
+ const void *end = &__patch_table_end;
+
+
On Tue, Jul 31, 2012 at 07:04:37PM -0400, Cyril Chemparathy wrote:
> +static void __init init_patch_kernel(void)
> +{
> + const void *start = &__patch_table_begin;
> + const void *end = &__patch_table_end;
> +
> + BUG_ON(patch_kernel(start, end - start));
> +
On Tue, Jul 31, 2012 at 07:04:37PM -0400, Cyril Chemparathy wrote:
+static void __init init_patch_kernel(void)
+{
+ const void *start = __patch_table_begin;
+ const void *end = __patch_table_end;
+
+ BUG_ON(patch_kernel(start, end - start));
+
On 8/6/2012 7:12 AM, Russell King - ARM Linux wrote:
On Tue, Jul 31, 2012 at 07:04:37PM -0400, Cyril Chemparathy wrote:
+static void __init init_patch_kernel(void)
+{
+ const void *start = __patch_table_begin;
+ const void *end = __patch_table_end;
+
+
On Mon, Aug 06, 2012 at 09:19:10AM -0400, Cyril Chemparathy wrote:
With a flush_cache_all(), we could avoid having to operate a cacheline
at a time, but that clobbers way more than necessary.
You can't do that, because flush_cache_all() on some CPUs requires the
proper MMU mappings to be in
On 8/6/2012 9:26 AM, Russell King - ARM Linux wrote:
On Mon, Aug 06, 2012 at 09:19:10AM -0400, Cyril Chemparathy wrote:
With a flush_cache_all(), we could avoid having to operate a cacheline
at a time, but that clobbers way more than necessary.
You can't do that, because flush_cache_all() on
On Mon, 6 Aug 2012, Russell King - ARM Linux wrote:
On Mon, Aug 06, 2012 at 09:19:10AM -0400, Cyril Chemparathy wrote:
With a flush_cache_all(), we could avoid having to operate a cacheline
at a time, but that clobbers way more than necessary.
You can't do that, because
Hi Nicolas,
On 8/4/2012 1:38 AM, Nicolas Pitre wrote:
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
The original phys_to_virt/virt_to_phys patching implementation relied on early
patching prior to MMU initialization. On PAE systems running out of >4G
address space, this would have entailed
Hi Nicolas,
On 8/4/2012 1:38 AM, Nicolas Pitre wrote:
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
The original phys_to_virt/virt_to_phys patching implementation relied on early
patching prior to MMU initialization. On PAE systems running out of 4G
address space, this would have entailed an
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
> The original phys_to_virt/virt_to_phys patching implementation relied on early
> patching prior to MMU initialization. On PAE systems running out of >4G
> address space, this would have entailed an additional round of patching after
> switching
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
The original phys_to_virt/virt_to_phys patching implementation relied on early
patching prior to MMU initialization. On PAE systems running out of 4G
address space, this would have entailed an additional round of patching after
switching over to
The original phys_to_virt/virt_to_phys patching implementation relied on early
patching prior to MMU initialization. On PAE systems running out of >4G
address space, this would have entailed an additional round of patching after
switching over to the high address space.
The approach implemented
The original phys_to_virt/virt_to_phys patching implementation relied on early
patching prior to MMU initialization. On PAE systems running out of 4G
address space, this would have entailed an additional round of patching after
switching over to the high address space.
The approach implemented
30 matches
Mail list logo
