On Wed, Jan 21, 2015, at 19:04, Borislav Petkov wrote:
> On Wed, Jan 21, 2015 at 05:20:09PM +0100, Alexander van Heukelum wrote:
> > On Wed, Jan 21, 2015, at 14:40, Denys Vlasenko wrote:
> > > On Sun, Jan 18, 2015 at 12:45 PM, Alexander van Heukelum
> > > wrote:
> &
On Wed, Jan 21, 2015, at 14:44, Denys Vlasenko wrote:
> On Sun, Jan 18, 2015 at 12:45 PM, Alexander van Heukelum
> wrote:
> > KERNEL_STACK_OFFSET is the offset from the top of the kernel stack
> > page to the value of the kernel_stack percpu variable. This patch
> > change
On Wed, Jan 21, 2015, at 14:40, Denys Vlasenko wrote:
> On Sun, Jan 18, 2015 at 12:45 PM, Alexander van Heukelum
> wrote:
> > The macro THREAD_INFO(reg,offset) is used in assembly to compute the
> > offset between the user ptregs and the thread_info struct. Change
> > th
On Wed, Jan 21, 2015, at 14:26, Denys Vlasenko wrote:
> On Sun, Jan 18, 2015 at 4:47 PM, Alexander van Heukelum
> wrote:
> > On Sun, Jan 18, 2015, at 13:05, Borislav Petkov wrote:
> >> Hi,
> >>
> >> btw, you might wanna sync with Denys who's doin
On Sun, Jan 18, 2015, at 17:38, Andy Lutomirski wrote:
> On Sun, Jan 18, 2015 at 3:45 AM, Alexander van Heukelum
> wrote:
> > Create an IRET-compatible top of stack at syscall entry and use this
> > information to return to user mode in the sysret path. This removes
&g
On Sun, Jan 18, 2015, at 13:05, Borislav Petkov wrote:
> Hi,
>
> btw, you might wanna sync with Denys who's doing cleanups in that area too:
>
> https://lkml.kernel.org/r/1421272101-16847-1-git-send-email-dvlas...@redhat.com
>
> and touching some of the stuff you're changing too.
Thanks. FWIW,
The macro THREAD_INFO(reg,offset) is used in assembly to compute the
offset between the user ptregs and the thread_info struct. Change
the macro and all its uses so that offset is given as the current
top of stack in the pt_regs frame. The generated code is identical.
Signed-off-by: Alexander van
multiple of 4 bytes, the minimal stack
alignment.
Signed-off-by: Alexander van Heukelum
---
arch/x86/include/asm/processor.h | 32 +++-
arch/x86/include/asm/thread_info.h | 10 ++
arch/x86/kernel/entry_32.S | 5 +++--
3 files changed, 16 insertions(
Create an IRET-compatible top of stack at syscall entry and use this
information to return to user mode in the sysret path. This removes
the need for the FIXUP_TOP_OF_STACK and RESTORE_TOP_OF_STACK macros.
Signed-off-by: Alexander van Heukelum
---
arch/x86/kernel/entry_64.S | 75
the automatic stack alignment
of interrupts, traps, and exceptions on x86_64.
Also change task_pt_regs to be independant of the thread's current
sp0 setting, like i386, and use it to initialize thread.sp0 in
copy_thread.
Signed-off-by: Alexander van Heukelum
---
arch/x86/ia32/ia32en
22f2aa4a0361707a5cfb1de9d45260b39965dead
(x86/entry-devel in your tree) and this kernel is now running on my
laptop.
Greetings,
Alexander
Alexander van Heukelum (4):
x86_64: cleanup THREAD_INFO(reg,offset) macro
x86_64: embrace KERNEL_STACK_OFFSET
i386: clean up KERNEL_STACK_OFFSET
x86_64, entry: Create
Create an IRET-compatible top of stack at syscall entry and use this
information to return to user mode in the sysret path. This removes
the need for the FIXUP_TOP_OF_STACK and RESTORE_TOP_OF_STACK macros.
Signed-off-by: Alexander van Heukelum
---
arch/x86/kernel/entry_64.S | 77
The syscall and sysenter code use KERNEL_STACK_OFFSET to set the
initial stack pointer a bit below the top of the kernel stack page.
Stop doing that.
Signed-off-by: Alexander van Heukelum
---
arch/x86/ia32/ia32entry.S | 4 ++--
arch/x86/include/asm/thread_info.h | 6 ++
arch/x86
on top of 22f2aa4a0361707a5cfb1de9d45260b39965dead
(x86/entry-devel in your tree) and this kernel is now running happily
on my laptop. I didn't try any benchmarking, though.
Greetings,
Alexander
Alexander van Heukelum (3):
x86_64: remove KERNEL_STACK_OFFSET from THREAD_INFO macro
x86_64: don't use KERNEL_STACK_OF
In the macro THREAD_INFO(reg,offset), the offset is relative to
KERNEL_STACK_OFFSET. Change the macro and all its uses so that
offset is given as the current top of stack in the pt_regs frame.
The generated code is identical.
Signed-off-by: Alexander van Heukelum
---
arch/x86/ia32/ia32entry.S
On Sun, Apr 13, 2014, at 1:31, H. Peter Anvin wrote:
> >>> d. Trampoline in user space
> >>>
> >>> A return to the vdso with values set up in registers r8-r15 would enable
> >>> a trampoline in user space. Unfortunately there is no way
> >>> to do a far JMP entirely with register state so this wou
Hi,
> This is a writeup I did to a select audience before this was public:
I'ld like to add an option d.2. for your consideration. Can you think of a
fundamental problem with it?
Greetings,
Alexander
> > Some workarounds I have considered:
> >
> > a. Using paging in a similar way to the 32
t that told
> me that a change to dump_stack_32 I made may be wrong if current can
> be NULL (it can't), as there was a check for it by assigning task to
> current, and then checking if task is NULL.
>
> Reported-by: Dan Carpenter
> Cc: Jesper Juhl
> Cc: Alexander van Heukel
My Acer 8510TZ stops displaying anything when X starts with Linus' current
tree. I bisected it down to commit ee1452d74584.
This patch reverts commit ee1452d74584.
After the revert, everything works as before.
Signed-off-by: Alexander van Heukelum
---
drivers/gpu/drm/i915/intel_disp
Hi all,
On my Acer 8510TZ, the backlight now turns off completely as soon as X
starts. I bisected the problem to ee1452d74584 "drm/i915: assume all GM45
Acer laptops use inverted backlight PWM", which says:
There is plenty of evidence suggesting all of the GM45 based Acer
laptops (includi
On Fri, Jun 7, 2013, at 8:01, Alexandre Courbot wrote:
> A framebuffer of this format is set up by SHIELD's bootloader. This
> allows us to use it as a framebuffer console.
>
> Signed-off-by: Alexandre Courbot
> Acked-by: Olof Johansson
> ---
> Changes from v1:
> - Added description to motivate
On Fri, Apr 12, 2013, at 22:15, Hans de Bruin wrote:
> On 03/27/2013 10:18 PM, Alexander van Heukelum wrote:
> > On Wed, Mar 27, 2013, at 20:46, Al Viro wrote:
> >> On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote:
> >>> Hi Al,
> >>>
On Wed, Mar 27, 2013, at 20:46, Al Viro wrote:
> On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote:
> > Hi Al,
> >
> > Hans de Bruin found a regression due to one of your changes. I asked him to
> > test a fix and he reported back that it worke
17 00:00:00 2001
From: Alexander van Heukelum
Date: Tue, 26 Mar 2013 21:57:43 +0100
Subject: [PATCH] x86, vm86: fix VM86 syscalls: use asmlinkage calling convention
Commit 49cb25e9290 x86: 'get rid of pt_regs argument in vm86/vm86old'
got rid of the pt_regs stub for sys_vm86old and sys
Hi Hans,
Could you check if the attached patch solves your problem?
Greetings,
Alexander van Heukelum
On Sun, Mar 24, 2013, at 22:19, Hans de Bruin wrote:
> commit 49cb25e9290 x86: 'get rid of pt_regs argument in vm86/vm86old'
> somehow breaks the colors when I play '
On Mon, 25 Feb 2008 10:13:17 -0800, "H. Peter Anvin" <[EMAIL PROTECTED]>
said:
> Alexander van Heukelum wrote:
> >
> > arch/x86/kernel/head64.c | 45
> > +++--
> > 1 files changed, 27 insertions(+), 18 deletio
: Alexander van Heukelum <[EMAIL PROTECTED]>
--
I think this patch is against -x86.git#testing :-/.
Greetings,
Alexander
arch/x86/kernel/head64.c | 45 +++--
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/he
On Sun, 24 Feb 2008 18:18:16 -0800, "H. Peter Anvin" <[EMAIL PROTECTED]>
said:
> Alexander van Heukelum wrote:
> > early res: 3 [9f000-9] EBDA
> >
> > Is it really necessary to force the allocation to a page boundary?
>
> It is, but that roundin
On Sun, 24 Feb 2008 20:41:21 +0100, "Ingo Molnar" <[EMAIL PROTECTED]> said:
>
> * Alexander van Heukelum <[EMAIL PROTECTED]> wrote:
>
> > Hi Andi,
> >
> > My eyes fell on the following table in the boot messages:
> >
> > ea
into the area normally
reserved for the VGA adaptor. It seems that you wanted to force
the allocation to cover whole pages, like:
early res: 3 [9f000-9] EBDA
This is what this patch implements.
Is it really necessary to force the allocation to a page boundary?
Signed-off-by: Alexander van
check in modpost. We are no longer dependent on the actual
> configuration of for example HOTPLUG.
>
> I think that explains it.
I should have looked at that commit first. Indeed, it does explain
why it is better to keep the sections separate. Thanks.
--
Alexander van Heukelum
y. Same for MEMORY_HOTPLUG/meminit and HOTPLUG_CPU/cpuinit.
On the condition that someone with knowledge in this area confirms
that this approach is right and not for some reason undesirable:
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
include/asm-generic/vmlinux.lds.h | 98 +
avoided.
Compile-tested on:
silly minimal config
defconfig x86_32
defconfig x86_64
defconfig x86_64 -HIBERNATION +MEMORY_HOTPLUG
Comments?
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
diff --git a/mm/internal.h b/mm/internal.h
index 953f941..5b46b32 100644
--- a/mm/internal.h
++
ing into another one, however. My guess is
that you did not see the new warning due to inlining, but I
compiled with CONFIG_CC_OPTIMIZE_FOR_SIZE=y.
Greetings,
Alexander
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - And now for something completely differentÂ…
it is guarded by
ACPI_HOTPLUG_CPU (which depends on HOTPLUG_CPU).
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
CC: Sam Ravnborg <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/topology.c
index 78cbb65..e6757aa 100644
--- a/arch/x86/kernel/topo
le-tested i386-defconfig.
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
Oh, and the compile-problem still exists in git-99f1c97. The git-tree is
changing faster than I can test the patch and write an e-mail :-/.
diff --git a/drivers/base/core.c b/drivers/base/core.c
index edf3bbe..
t doesn't. Of course if one wants to be warned in such cases
(initialisation
of a character array of specified length using a string constant) one
could
tell the compiler that the 0 at the end should really be there:
struct {char c[4];} s2 = {"abcd" "\0"};
Writing it lik
bootsector stub. It also moves
some code from the .header section (a data section) to .inittext.
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
---
> I'd prefer .bstext or .bs_text and .bsdata/.bs_data; possibly .bsecttext
> and .bsectdata. The term "boot sector" f
bootsector stub. It also moves
some code from the .header section (a data section) to .inittext.
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
---
Hi,
I hope the new section names are ok? Alternatives would be
.bstext/.bsdata or .floppytext/.floppydata.
Greetings,
Ale
On Thu, May 10, 2007 at 03:48:08PM -0700, H. Peter Anvin wrote:
> > It doesn't probe the hardware in dangerous ways. (Search for mode_scan
> > in video.S) It works by trying to set a mode via the normal
> > AH=0/AL=mode/int 0x10 method for all possible values of mode. It then
> > checks if the bios
On Thu, May 10, 2007 at 11:08:10AM -0700, H. Peter Anvin wrote:
> As far as I could tell, "scan" simply caused the nonstandard video
> driver scan modules (unsafe probes) to be invoked. Since those modules
> are no longer present, there appeared to be no need for them. The VGA
> and VESA probes a
t easier to start thinking of a new kernel image format without
breaking bootloaders that use a bzImage in the intended way.
Good luck,
Alexander
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - A fast, anti-spam email service.
-
To unsubscribe from this lis
On Wed, May 09, 2007 at 09:51:36AM -0700, H. Peter Anvin wrote:
> Alexander van Heukelum wrote:
> >
> > Hi!
> >
> > I'm making coffee now. I just don't see what I missed? Maybe you were
> > led astray by the new PARAM_VESA_PAD I added?
> >
>
On Wed, May 09, 2007 at 08:04:07AM +0800, Antonino A. Daplas wrote:
> On Tue, 2007-05-08 at 20:32 +0200, Alexander van Heukelum wrote:
> > diff --git a/arch/i386/boot/bootsect.S b/arch/i386/boot/bootsect.S
> > diff --git a/arch/i386/boot/video.S b/arch/i386/boot/video.S
> > i
On Tue, May 08, 2007 at 11:45:47AM -0700, H. Peter Anvin wrote:
> Alexander van Heukelum wrote:
> >
> > Oh! A padding hole in a struct! That could be a problem. If the freeze
> > is after decompression, could you test if this makes it work again?
> >
>
On Tue, May 08, 2007 at 03:28:17AM -0700, Andrew Morton wrote:
> On Sat, 5 May 2007 12:44:52 +0200 Alexander van Heukelum <[EMAIL PROTECTED]>
> wrote:
> > --- a/arch/i386/boot/bootsect.S
> > +++ b/arch/i386/boot/bootsect.S
> > @@ -44,7 +44,7 @@ #endif
> > _
intention was a 16:16-bit far jump.
This patch changes only x86_64.
Greetings,
Alexander
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
---
diff --git a/arch/x86_64/boot/bootsect.S b/arch/x86_64/boot/bootsect.S
index 011b7a4..ae9df0d 100644
--- a/arch/x86_64/boot/bootsect.S
intention was a 16:16-bit far jump.
This patch changes only i386.
Greetings,
Alexander
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/boot/bootsect.S b/arch/i386/boot/bootsect.S
index 011b7a4..ae9df0d 100644
--- a/arch/i386/boot/bootsect.S
+++
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 the FAQ at http://www.tux.org/lkml/
>
>
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastma
act
exactly the size of the compressed kernel image.
I have no idea what went wrong, but it went wrong in the build process
of the bzImage.
Hope this helps,
Alexander
> --
> Jean Delvare
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>
50 matches
Mail list logo
