On Mon, Feb 11, 2013 at 8:21 PM, H. Peter Anvin wrote:
> On 02/11/2013 07:33 PM, Linus Torvalds wrote:
>> On Mon, Feb 11, 2013 at 5:37 PM, tip-bot for H. Peter Anvin
>> wrote:
>>>
>>> However, we can declare a bitfield using sizeof(), which is legal
>>> because sizeof() is a constant expression.
On Tue, Feb 12, 2013 at 9:14 AM, H. Peter Anvin wrote:
> On 02/12/2013 09:00 AM, Linus Torvalds wrote:
>> On Tue, Feb 12, 2013 at 8:38 AM, H.J. Lu wrote:
>>>
>>> Can you do something similar to what we did in glibc:
>>
>> No. Because we use macros to be typ
On Tue, Feb 12, 2013 at 10:25 AM, H. Peter Anvin wrote:
> I just thought up this variant, I'm about to test it, but H.J., do you
> see any problems with it?
>
> #define itype(x) \
> __typeof__(__builtin_choose_expr(sizeof(*(x)) > sizeof(0UL), 0ULL, 0UL))
>
> I tried it out with a small test progra
Hi,
This patch:
commit 9f9c9cbb60576a1518d0bf93fb8e499cffccf377
Author: Zhenzhong Duan
Date: Thu Dec 20 15:05:14 2012 -0800
drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists
The right dmi version is in SMBIOS if it's zero in DMI region
This issue was origin
, "_DMI_", 5) || dmi_present(p + 16);
}
'q' isn't defined here. Change it to `p" also fixes the problem for me.
H.J.
---
> On 2013-02-21 02:12, H.J. Lu wrote:
>>
>> Hi,
>>
>> This patch:
>>
>> commit 9f9c9cbb60576a1518d0bf93fb8e
On Fri, Mar 15, 2013 at 2:56 PM, H. Peter Anvin wrote:
> On 03/15/2013 02:15 PM, Paul Moore wrote:
>> On Tuesday, February 26, 2013 03:58:23 PM Paul Moore wrote:
>>> On Friday, February 15, 2013 12:21:43 PM Paul Moore wrote:
Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
>
On Thu, Nov 15, 2012 at 1:14 AM, Arnd Bergmann wrote:
> On Wednesday 14 November 2012, H. Peter Anvin wrote:
>> On 11/14/2012 04:18 AM, Arnd Bergmann wrote:
>> > Since we are in the review phase for two new architectures that we
>> > should be merging into the mainline kernel, I think we need to
>
On Thu, Nov 15, 2012 at 6:36 AM, Arnd Bergmann wrote:
> On Thursday 15 November 2012, H.J. Lu wrote:
>> On Thu, Nov 15, 2012 at 1:14 AM, Arnd Bergmann wrote:
>> > On Wednesday 14 November 2012, H. Peter Anvin wrote:
>> >> On 11/14/2012 04:18 AM, Arnd Bergmann wrot
On Thu, Dec 20, 2012 at 10:21 AM, H. Peter Anvin wrote:
> On 12/20/2012 09:53 AM, Stefani Seibold wrote:
>>
>> In a 32 bit kernel a VDSO can mapped on an fix address VDSO_HIGH_BASE
>> (kernel parameter vdso32=2 or CONFIG_COMPAT_VDSO), which is 0xe000.
>> There is no available page BEFORE nor A
X32 uses the 32-bit compat layer for 32-bit kernel interface, which is
also used by ia32. But long long is 4-byte aligned for ia32 and 8-byte
aligned for x32. When the long long field in a system call struct has
different offsets between ia32 and x32 due to alignment padding, like
struct snd_ctl_
The integer64 field in struct snd_ctl_elem_value has different offsets,
depending the alignment of long long. This patch replaces long long
with the newly introduced __compat_aligned_s64 so that x32 and ia32
can use the same compat system call for struct snd_ctl_elem_value.
--
H.J.
0002-Use-__
The bug report is at
http://bugzilla.kernel.org/show_bug.cgi?id=2082
Problem Description: When switching to another machine with a KVM
switch and back, the mouse is out of control, with X.Org. To recover,
I have to unplug the mouse cable and plug it back.
Steps to reproduce: Have a wheel mouse
On Tue, Oct 30, 2007 at 12:53:17PM -0400, Dmitry Torokhov wrote:
> Hi,
>
> On 10/30/07, H.J. Lu <[EMAIL PROTECTED]> wrote:
> > The bug report is at
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=2082
> >
> > Problem Description: When switching to a
On Mon, Nov 13, 2017 at 12:10 PM, Andi Kleen wrote:
>> Put another way: the CONFIG_DEBUG_INFO_SPLIT option is useless. Yes,
>> it saves time and disk space, but does so at the expense of making all
>> the debug information unavailable to basic tools.
>
> You're right. It works for line information
On Fri, Jul 20, 2018 at 2:35 PM, Andy Lutomirski wrote:
>
>> On Jul 16, 2018, at 6:05 AM, H.J. Lu wrote:
>>
>>> On Fri, Jul 13, 2018 at 7:08 PM, Andy Lutomirski
>>> wrote:
>>> I'm not at all convinced that this is the problem, but the series here
On Wed, Jul 11, 2018 at 8:13 AM, Dave Hansen wrote:
> On 07/11/2018 07:56 AM, H.J. Lu wrote:
>> On Mon, Jul 9, 2018 at 8:47 PM, Dave Hansen wrote:
>>> On 07/09/2018 07:14 PM, H.J. Lu wrote:
>>>>> I'd really want to see this reproduced without KASLR to m
On Wed, Jul 11, 2018 at 9:24 AM, Dave Hansen wrote:
> On 07/11/2018 08:40 AM, H.J. Lu wrote:
>> This is a quad-core machine with HT and 6 GB RAM. The workload is
>> x32 GCC build and test with "make -j8". The bug is triggered during GCC
>> test after a couple ho
On Wed, Jul 11, 2018 at 9:49 AM, Dave Hansen wrote:
> On 07/11/2018 09:29 AM, H.J. Lu wrote:
>>>> # It takes about 3 hour to bootstrap x86-64 GCC and 3 hour to run tests,
>>>> TIMEOUT=480
>>>> # Run it every hour,
>>>> 30 * * * * /export/gnu/impo
On Wed, Jul 11, 2018 at 10:43 AM, Dave Hansen wrote:
> On 07/11/2018 10:29 AM, H.J. Lu wrote:
>>> I have seen it on machines with various amounts of cores and RAMs.
>>> It triggers the fastest on 8 cores with 6GB RAM reliably.
>> Here is the first kernel message.
>
On Wed, Jul 11, 2018 at 4:14 PM, Dave Hansen wrote:
> On 07/11/2018 04:07 PM, Andy Lutomirski wrote:
>> Could the cause be an overflow of the IRQ stack? I’ve been meaning
>> to put guard pages on all the special stacks for a while. Let me see
>> if I can do that in the next couple days.
>
> But w
On Thu, Jul 12, 2018 at 7:44 AM, H.J. Lu wrote:
> On Wed, Jul 11, 2018 at 4:14 PM, Dave Hansen wrote:
>> On 07/11/2018 04:07 PM, Andy Lutomirski wrote:
>>> Could the cause be an overflow of the IRQ stack? I’ve been meaning
>>> to put guard pages on all the special sta
On Sun, Jan 21, 2018 at 4:04 AM, David Woodhouse wrote:
>
>> On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote:
>>> From: Tim Chen
>>>
>>> Flush indirect branches when switching into a process that marked
>>> itself non dumpable. This protects high value processes like gpg
>>> bet
. Pass -z max-page-size=0x20 to linker to force
2MB page size regardless of the default page size used by linker.
Tested with Linux kernel 4.15.6 on x86-64.
Signed-off-by: H.J. Lu
--
H.J.
From c5c27b82d2e19add5372a6b2eaa00119e896d9ff Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: F
Since x86-64 kernel must be aligned to 2MB, refuse to boot kernel if
alignment of LOAD segment isn't multiple of 2MB.
Signed-off-by: H.J. Lu
--
H.J.
From 25015cf0252d1a4a0c532f391a314e343a5022dd Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Tue, 27 Feb 2018 11:41:35 -0800
vDSO code runs in userspace. Don't compile it with retpoline.
Signed-off-by: H.J. Lu
--
H.J.
From 711926409e42862de08633ec057892195fdce4e0 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Fri, 16 Mar 2018 14:58:29 -0700
Subject: [PATCH] x86: Don't build vDSO wit
On 3 x86-64 machines, kernel 4.17.4 locked up under heavy load. 2 of them don't
have any kernel messages. One has
Jul 05 14:33:32 gnu-hsw-1.sc.intel.com kernel: general protection
fault: [#1] SMP PTI
Jul 05 14:33:32 gnu-hsw-1.sc.intel.com kernel: Modules linked in:
rpcsec_gss_krb5 nfsv4 dns_
On Mon, Jul 9, 2018 at 7:54 AM, Dave Hansen wrote:
> On 07/09/2018 06:19 AM, Lu, Hongjiu wrote:
>> On 3 x86-64 machines, kernel 4.17.4 locked up under heavy load. 2 of
> them don't have any kernel messages. One has
>
> Hi H.J.,
>
> It'd be really handy if you could pastebin things like this, or
On Mon, Jul 9, 2018 at 5:44 PM, Dave Hansen wrote:
> ... cc'ing a few folks who I know have been looking at this code
> lately. The full oops is below if any of you want to take a look.
>
> OK, well, annotating the disassembly a bit:
>
>> (gdb) disass free_pages_and_swap_cache
>> Dump of assembl
On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
>
> Hi all-
>
> I'm seriously considering sending a patch to remove x32 support from
> upstream Linux. Here are some problems with it:
>
> 1. It's not entirely clear that it has users. As far as I know, it's
> supported on Gentoo and Debian,
On Sun, Dec 30, 2018 at 6:07 PM H.J. Lu wrote:
>
> On 4.19 branch,
>
> commit 82c8dbb376b9fa9b831c157cbb15664cb4a343e3
> Author: Thomas Gleixner
> Date: Mon Dec 17 13:31:05 2018 +0100
>
> posix-timers: Fix division by zero bug
>
> commit 0e334db6bb
On 4.19 branch,
commit 82c8dbb376b9fa9b831c157cbb15664cb4a343e3
Author: Thomas Gleixner
Date: Mon Dec 17 13:31:05 2018 +0100
posix-timers: Fix division by zero bug
commit 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 upstream.
The signal delivery path of posix-timers can try to rearm
Update compat_sys_preadv64v2 and compat_sys_pwritev64v2 to handle the
offset argument == -1, which should use and update the the current file
offset.
--
H.J.
From 934a68be8a092dba9558bdf8025239934efb5d7e Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Wed, 3 Oct 2018 08:07:18 -07
On Fri, Jul 13, 2018 at 7:08 PM, Andy Lutomirski wrote:
> I'm not at all convinced that this is the problem, but the series here
> will give a better diagnostic if the issue really is an IRQ stack
> overflow:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/guard_pages
On Thu, Apr 23, 2015 at 5:29 AM, Borislav Petkov wrote:
> On Thu, Apr 23, 2015 at 01:00:26PM +0200, Rasmus Villemoes wrote:
>> > or you want attribution or ...?
>>
>> That would be nice.
>
> I fail to see for what - I see H.J. Lu's patch from Dec. 2014 and you
> repeating the same patch months lat
2001
From: "H.J. Lu"
Date: Wed, 17 Dec 2014 18:05:29 -0800
Subject: [PATCH] Use -mskip-rax-setup if supported
GCC 5 added a compiler option, -mskip-rax-setup, for x86-64. It skips
setting up the RAX register when SSE is disabled and there are no
variable arguments passed in vector re
e892b19f5100427b8c89a74186b90675141ceaab Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Sat, 12 Nov 2011 11:03:38 -0800
Subject: [PATCH] Gracely handle GPE dispatch failure
When GPE dispatch fails due to missing handler, kernel issues
ACPI Error: No handler for Region
ACPI Err
On Thu, Apr 9, 2015 at 10:53 AM, Peter Hurley wrote:
> On 04/09/2015 01:43 PM, H.J. Lu wrote:
>> On Thu, Apr 9, 2015 at 7:54 AM, Peter Hurley
>> wrote:
>>> A read() from a pty master may mistakenly indicate EOF (errno == -EIO)
>>> after the pty slave has close
SED, which ensures the TTY_OTHER_DONE state will be
>set if the last input worker is already finished (or just about to
>exit).
>
> Remove tty_flush_to_ldisc(); no in-tree callers.
>
> Fixes: 52bce7f8d4fc ("pty, n_tty: Simplify input processing on final close")
>
On Thu, Feb 28, 2019 at 3:27 AM David Woodhouse wrote:
>
> On Thu, 2019-02-28 at 03:12 -0800, tip-bot for Daniel Borkmann wrote:
> > Commit-ID: ce02ef06fcf7a399a6276adb83f37373d10cbbe1
> > Gitweb:
> > https://git.kernel.org/tip/ce02ef06fcf7a399a6276adb83f37373d10cbbe1
> > Author: Daniel
On Thu, Feb 28, 2019 at 8:18 AM Daniel Borkmann wrote:
>
> On 02/28/2019 01:53 PM, H.J. Lu wrote:
> > On Thu, Feb 28, 2019 at 3:27 AM David Woodhouse wrote:
> >> On Thu, 2019-02-28 at 03:12 -0800, tip-bot for Daniel Borkmann wrote:
> >>> Commit-ID: ce02ef0
On Thu, Feb 28, 2019 at 9:58 AM Daniel Borkmann wrote:
>
> On 02/28/2019 05:25 PM, H.J. Lu wrote:
> > On Thu, Feb 28, 2019 at 8:18 AM Daniel Borkmann
> > wrote:
> >> On 02/28/2019 01:53 PM, H.J. Lu wrote:
> >>> On Thu, Feb 28, 2019 at 3:27 AM David Woodh
On Wed, Aug 12, 2020 at 4:42 AM Jessica Yu via Binutils
wrote:
>
> +++ pet...@infradead.org [12/08/20 12:40 +0200]:
> >On Wed, Aug 12, 2020 at 10:56:56AM +0200, Ard Biesheuvel wrote:
> >> The module .lds has BYTE(0) in the section contents to prevent the
> >> linker from pruning them entirely. The
TION is enabled.
Signed-off-by: H.J. Lu
---
arch/x86/entry/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile
index 08bf95dbc911..83c98dae74a6 100644
--- a/arch/x86/entry/Makefile
+++ b/arch/x86/entry/Makefile
@
On Mon, Mar 29, 2021 at 2:38 AM Richard Biener wrote:
>
> On Mon, 29 Mar 2021, Jiri Slaby wrote:
>
> > Any ideas on this?
> >
> > On 11. 01. 21, 7:31, Jiri Slaby wrote:
> > > Hi,
> > >
> > > this e-mails is a follow-up of my report at:
> > > https://bugzilla.suse.com/show_bug.cgi?id=1180681
> > >
On Mon, Mar 29, 2021 at 6:06 AM Richard Biener wrote:
>
> On Mon, 29 Mar 2021, H.J. Lu wrote:
>
> > On Mon, Mar 29, 2021 at 2:38 AM Richard Biener wrote:
> > >
> > > On Mon, 29 Mar 2021, Jiri Slaby wrote:
> > >
> > > > Any ideas on this?
On Fri, Mar 26, 2021 at 1:35 PM Florian Weimer wrote:
>
> All this needs to work transparently without user intervention. We
> cannot require firmware upgrades to fix the incorrect RTM reporting
> issue (the bug I referenced). I think we can require software updates
> which tell glibc when to u
On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov
wrote:
>
> Provide prctl() interface to enabled LAM for user addresses. Depending
> how many tag bits requested it may result in enabling LAM_U57 or
> LAM_U48.
I prefer the alternate kernel interface based on CET arch_prctl interface which
is impl
On Tue, Jan 21, 2014 at 9:10 AM, Catalin Marinas
wrote:
> On Fri, Dec 27, 2013 at 05:25:10PM +0000, H.J. Lu wrote:
>> Both x32 and x86-64 use the same struct semid64_ds for system calls.
>> But x32 long is 32-bit. This patch replaces unsigned long with
>> __kernel_ulong_t in
On Tue, Dec 10, 2013 at 2:47 PM, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 2:36 PM, Alan Modra wrote:
>> On Mon, Dec 09, 2013 at 07:10:23PM -0800, H.J. Lu wrote:
>>> Linker sets e_type in ELF header to ET_DYN for -pie -Ttext-segment=0xXXX.
>>> When I added -Ttext-seg
X32 statfs system call is the same as x86-64 statfs system call, which
uses 64-bit integer for __statfs_word. This patch defines __statfs_word
as __kernel_long_t instead of long.
--
H.J.
From f4b600158d9365fc2aad11e144699e7ffaefaf3b Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: M
Both x32 and x86-64 use the same stat system call interface. But x32
long is 32-bit. This patch changes x86 uapi to use
__kernel_long_t/__kernel_ulong_t in x86-64 stat.
--
H.J.
From ae73439297cc4a2cf4b4f580d5e83fabcfa2a316 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Mon, 16 D
On Mon, Jan 20, 2014 at 9:50 AM, Christoph Hellwig wrote:
> On Mon, Jan 20, 2014 at 09:46:41AM -0800, H. Peter Anvin wrote:
>> This comment by Christoph was literally the only feedback on this
>> patchset. The definition of __kernel_[u]long_t is "the size of 'long'
>> for the native kernel for th
On Mon, Jan 20, 2014 at 9:51 AM, H.J. Lu wrote:
> On Mon, Jan 20, 2014 at 9:50 AM, Christoph Hellwig wrote:
>> On Mon, Jan 20, 2014 at 09:46:41AM -0800, H. Peter Anvin wrote:
>>> This comment by Christoph was literally the only feedback on this
>>> patchset. The defin
On Tue, Jan 21, 2014 at 4:04 AM, Catalin Marinas
wrote:
> On Mon, Jan 20, 2014 at 05:46:41PM +, H. Peter Anvin wrote:
>> On 12/28/2013 08:33 AM, Christoph Hellwig wrote:
>> > On Fri, Dec 27, 2013 at 02:14:16PM -0800, H.J. Lu wrote:
>> >> X32 uses the same kerne
On Sat, Feb 15, 2014 at 9:44 AM, Andi Kleen wrote:
> On Sat, Feb 15, 2014 at 02:38:14PM +0100, Markus Trippelsdorf wrote:
>> On 2014.02.14 at 22:21 +0100, Andi Kleen wrote:
>> > This is the updated LTO patchkit for 3.14-rc2. LTO allows
>> > the compiler to do global optimization over the whole ke
eee1f1f4f60eb1f1139ac311e787fac50accde30 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Fri, 6 Dec 2013 12:44:41 -0800
Subject: [PATCH] binfmt_elf: fix PIE load with randomization disabled
Normally, a PIE executable has zero virtual address on the first PT_LOAD
segment and kernel will
On Mon, Dec 9, 2013 at 12:57 PM, Jiri Kosina wrote:
> On Mon, 9 Dec 2013, H.J. Lu wrote:
>
>> Normally, a PIE executable has zero virtual address on the first PT_LOAD
>> segment and kernel will load such executable at random address when
>> randomization is enabled. If r
On Mon, Dec 9, 2013 at 1:39 PM, H. Peter Anvin wrote:
> On 12/09/2013 01:03 PM, H.J. Lu wrote:
>>
>> No, please don't do that. Normally, PIE has zero load address and kernel
>> can load it anywhere. There are multiple reasons why PIE has non-zero
>> load add
On Mon, Dec 9, 2013 at 1:13 PM, Jiri Kosina wrote:
> On Mon, 9 Dec 2013, H.J. Lu wrote:
>
>> >> Normally, a PIE executable has zero virtual address on the first PT_LOAD
>> >> segment and kernel will load such executable at random address when
>> >> rand
On Mon, Dec 9, 2013 at 1:49 PM, H. Peter Anvin wrote:
>>
>>> PT_LOAD being non-zero causing randomization to be turned off seems like
>>> quite unexpected behavior to me, with a great potential to cause a lot of
>>> confusion.
>>
>> There should be no difference between dynamic executable and PIE
On Mon, Dec 9, 2013 at 1:53 PM, H. Peter Anvin wrote:
> On 12/09/2013 01:52 PM, H.J. Lu wrote:
>>>
>>> Why is that? It would seem to be a big difference between a relocatable
>>> binary (PIE) and one with a load address fixed at link time.
>>>
>>
&
On Mon, Dec 9, 2013 at 2:01 PM, H. Peter Anvin wrote:
> On 12/09/2013 01:59 PM, H.J. Lu wrote:
>>
>> A Linux/x86-64 user came to me at the end of 2008. He needed
>> to load an executable above 4GB. I added -Ttext-segment option
>> to linker:
>>
>> htt
On Mon, Dec 9, 2013 at 3:35 PM, H. Peter Anvin wrote:
> On 12/09/2013 01:44 PM, H.J. Lu wrote:
>> On Mon, Dec 9, 2013 at 1:39 PM, H. Peter Anvin wrote:
>>> On 12/09/2013 01:03 PM, H.J. Lu wrote:
>>>>
>>>> No, please don't do that. Normally, PIE ha
On Mon, Dec 9, 2013 at 4:37 PM, H. Peter Anvin wrote:
> On 12/09/2013 03:53 PM, H.J. Lu wrote:
>>>>
>>>> x86-64 small model is limited to 4GB in size. You can't build
>>>> a dynamic executable in small model larger than 4GB.
>>>>
>>&
My original post was rejected by LKML. Resend.
On Mon, Dec 9, 2013 at 4:41 PM, H.J. Lu wrote:
> On Mon, Dec 9, 2013 at 4:37 PM, H. Peter Anvin wrote:
>> On 12/09/2013 03:53 PM, H.J. Lu wrote:
>>>>>
>>>>> x86-64 small model is limited to 4GB in size. You
On Mon, Dec 9, 2013 at 8:57 PM, H. Peter Anvin wrote:
> Where do the _32 and _32S relocations come from? Are we mixing multiple
> things inside -pie?
They come from crt1.o and crtbegin.o. -pie uses Scrt1.o and crtbeginS.o.
> "H.J. Lu" wrote:
>>On Mon, Dec 9, 2013 a
On Tue, Dec 10, 2013 at 11:08 AM, H. Peter Anvin wrote:
> On 12/10/2013 04:20 AM, H.J. Lu wrote:
>> On Mon, Dec 9, 2013 at 8:57 PM, H. Peter Anvin wrote:
>>> Where do the _32 and _32S relocations come from? Are we mixing multiple
>>> things inside -pie?
>
On Tue, Dec 10, 2013 at 2:36 PM, Alan Modra wrote:
> On Mon, Dec 09, 2013 at 07:10:23PM -0800, H.J. Lu wrote:
>> Linker sets e_type in ELF header to ET_DYN for -pie -Ttext-segment=0xXXX.
>> When I added -Ttext-segment=0xXXX, one goal was to load
>> small model executable abov
On Wed, Dec 11, 2013 at 5:36 AM, Jiri Kosina wrote:
> On Mon, 9 Dec 2013, H.J. Lu wrote:
>
>> >> so that he could load his program compiled as PIE above 4GB.
>> >> If kernel is changed not to honor it, his program won't work any more.
>> >> In n
On Wed, Dec 11, 2013 at 9:49 AM, H. Peter Anvin wrote:
> On 12/11/2013 05:41 AM, H.J. Lu wrote:
>>
>> When -Ttext-segment=XXX is used, the program is expected to
>> load at XXX, regardless -pie is used or not.
>>
>
> "Expected to" by whom? I
On Wed, Dec 11, 2013 at 11:43 AM, H. Peter Anvin wrote:
> On 12/11/2013 10:21 AM, H.J. Lu wrote:
>> On Wed, Dec 11, 2013 at 9:49 AM, H. Peter Anvin wrote:
>>> On 12/11/2013 05:41 AM, H.J. Lu wrote:
>>>>
>>>> When -Ttext-segment=XXX is used, the program i
X32 adjtimex system call is the same as x86-64 adjtimex system call,
which uses 64-bit integer for long in struct timex. But x32 long is
32 bit. This patch replaces long in struct timex with __kernel_long_t.
Signed-off-by: H.J. Lu
---
include/uapi/linux/timex.h | 34
Both x32 and x86-64 use the same struct rusage and struct rlimit for
system calls. But x32 log is 32-bit. This patch change uapi
to use __kernel_long_t in struct rusage and
__kernel_ulong_t in and struct rlimit.
Signed-off-by: H.J. Lu
---
include/uapi/linux/resource.h | 32
X32 IPC system call is the same as x86-64 IPC system call, which uses
64-bit integer for unsigned long in struct ipc64_perm. But x32 long is
32 bit. This patch replaces unsigned long in uapi struct ipc64_perm with
__kernel_ulong_t.
Signed-off-by: H.J. Lu
---
include/uapi/asm-generic/ipcbuf.h
X32 msgsnd/msgrcv system calls are the same as x86-64 msgsnd/msgrcv system
calls, which use 64-bit integer for long in struct msgbuf . But x32 long
is 32 bit. This patch replaces long in struct msgbuf with __kernel_long_t.
Signed-off-by: H.J. Lu
---
include/uapi/linux/msg.h | 4 ++--
1 file
Both x32 and x86-64 use the same struct msqid64_ds for system calls.
But x32 long is 32-bit. This patch replaces unsigned long with
__kernel_ulong_t in struct msqid64_ds.
Signed-off-by: H.J. Lu
---
include/uapi/asm-generic/msgbuf.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions
Both x32 and x86-64 use the same struct semid64_ds for system calls.
But x32 long is 32-bit. This patch replaces unsigned long with
__kernel_ulong_t in x86 struct semid64_ds.
Signed-off-by: H.J. Lu
---
arch/x86/include/uapi/asm/sembuf.h | 10 +-
1 file changed, 5 insertions(+), 5
Both x32 and x86-64 use the same struct shmid64_ds/shminfo64/shm_info for
system calls. But x32 long is 32-bit. This patch replaces unsigned long
with __kernel_ulong_t in struct shmid64_ds/shminfo64/shm_info.
Signed-off-by: H.J. Lu
---
include/uapi/asm-generic/shmbuf.h | 24
Both x32 and x86-64 use the same struct mq_attr for system calls. But
x32 long is 32-bit. This patch replaces long with __kernel_long_t in
struct mq_attr.
Signed-off-by: H.J. Lu
---
include/uapi/linux/mqueue.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a
. The difference is
x32 can use 4-byte aligned long long for system calls so that it
can share the same 32-bit compat system call with ia32.
Signed-off-by: H.J. Lu
---
arch/x86/include/asm/types.h| 6 ++
arch/x86/include/uapi/asm/types.h | 35
The integer64 field in struct snd_ctl_elem_value has different offsets,
depending the alignment of long long. This patch replaces long long
with the newly introduced __compat_aligned_s64 so that x32 and ia32
can use the same compat system call for struct snd_ctl_elem_value.
Signed-off-by: H.J
On Wed, Dec 25, 2013 at 09:15:51AM -0800, H.J. Lu wrote:
> X32 uses the 32-bit compat layer for 32-bit kernel interface, which is
> also used by ia32. But long long is 4-byte aligned for ia32 and 8-byte
> aligned for x32. When the long long field in a system call struct has
> diffe
On Thu, Dec 26, 2013 at 2:03 AM, Christoph Hellwig wrote:
> On Wed, Dec 25, 2013 at 06:54:47AM -0800, H.J. Lu wrote:
>> Both x32 and x86-64 use the same struct rusage and struct rlimit for
>> system calls. But x32 log is 32-bit. This patch change uapi
>> to use __kernel_lo
On Thu, Dec 26, 2013 at 5:52 AM, H.J. Lu wrote:
> On Thu, Dec 26, 2013 at 2:03 AM, Christoph Hellwig wrote:
>> On Wed, Dec 25, 2013 at 06:54:47AM -0800, H.J. Lu wrote:
>>> Both x32 and x86-64 use the same struct rusage and struct rlimit for
>>> system calls. But x32
On Tue, Dec 24, 2013 at 04:24:58PM -0800, H.J. Lu wrote:
> X32 adjtimex system call is the same as x86-64 adjtimex system call,
> which uses 64-bit integer for long in struct timex. But x32 long is
> 32 bit. This patch replaces long in struct timex with __kernel_long_t.
>
Here is
On Wed, Dec 25, 2013 at 06:54:47AM -0800, H.J. Lu wrote:
> Both x32 and x86-64 use the same struct rusage and struct rlimit for
> system calls. But x32 log is 32-bit. This patch change uapi
> to use __kernel_long_t in struct rusage and
> __kernel_ulong_t in and struct rlimit.
On Thu, Dec 26, 2013 at 07:35:09AM -0800, H.J. Lu wrote:
> On Tue, Dec 24, 2013 at 04:24:58PM -0800, H.J. Lu wrote:
> > X32 adjtimex system call is the same as x86-64 adjtimex system call,
> > which uses 64-bit integer for long in struct timex. But x32 long is
> > 32 bit. Thi
On Wed, Dec 25, 2013 at 07:45:41AM -0800, H.J. Lu wrote:
> X32 IPC system call is the same as x86-64 IPC system call, which uses
> 64-bit integer for unsigned long in struct ipc64_perm. But x32 long is
> 32 bit. This patch replaces unsigned long in uapi struct ipc64_perm with
> __ke
On Wed, Dec 25, 2013 at 07:58:50AM -0800, H.J. Lu wrote:
> X32 msgsnd/msgrcv system calls are the same as x86-64 msgsnd/msgrcv system
> calls, which use 64-bit integer for long in struct msgbuf . But x32 long
> is 32 bit. This patch replaces long in struct msgbuf with __kernel_long_t.
&g
On Wed, Dec 25, 2013 at 08:08:07AM -0800, H.J. Lu wrote:
> Both x32 and x86-64 use the same struct msqid64_ds for system calls.
> But x32 long is 32-bit. This patch replaces unsigned long with
> __kernel_ulong_t in struct msqid64_ds.
>
Here is the updated patch which uses __kernel_
On Wed, Dec 25, 2013 at 08:53:59AM -0800, H.J. Lu wrote:
> Both x32 and x86-64 use the same struct shmid64_ds/shminfo64/shm_info for
> system calls. But x32 long is 32-bit. This patch replaces unsigned long
> with __kernel_ulong_t in struct shmid64_ds/shminfo64/shm_info.
>
Here is
On Wed, Dec 25, 2013 at 08:58:34AM -0800, H.J. Lu wrote:
> Both x32 and x86-64 use the same struct mq_attr for system calls. But
> x32 long is 32-bit. This patch replaces long with __kernel_long_t in
> struct mq_attr.
>
Here is the updated patch which uses __kernel_lo
On Thu, Dec 26, 2013 at 9:53 AM, H. Peter Anvin wrote:
> On 12/26/2013 07:54 AM, H.J. Lu wrote:
>> On Wed, Dec 25, 2013 at 08:58:34AM -0800, H.J. Lu wrote:
>>> Both x32 and x86-64 use the same struct mq_attr for system calls. But
>>> x32 long is 32-bit. Th
On Thu, Dec 26, 2013 at 9:58 AM, H. Peter Anvin wrote:
> On 12/26/2013 05:52 AM, H.J. Lu wrote:
>>
>>> c) why you suddenly need these changes now and not when the x32 ABI
>>> support was submitted and hopefully heavily tested
>>
>> Kernel headers
On Thu, Dec 26, 2013 at 10:03 AM, H. Peter Anvin wrote:
> On 12/26/2013 09:59 AM, H.J. Lu wrote:
>>
>>> but it would seem to give the wrong types when __BITS_PER_LONG in
>>> userspace is 32.
>>>
>>
>> For x32, __BITS_PER_LONG is 64, not 32. If __
r all ABIs other than x32. I am submitting 8 patches to replace
long or unsigned long with __kernel_[u]long_t so that those struct types
can be used with x32 system calls.
H.J. Lu (8):
Use __kernel_long_t in struct timex
Use __kernel_long_t/__kernel_ulong_t in
Use __kernel_ulong_t in u
X32 msgsnd/msgrcv system calls are the same as x86-64 msgsnd/msgrcv system
calls, which use 64-bit integer for long in struct msgbuf . But x32 long
is 32 bit. This patch replaces long in struct msgbuf with __kernel_long_t
if __BITS_PER_LONG == 64.
Signed-off-by: H.J. Lu
---
include/uapi/linux
X32 adjtimex system call is the same as x86-64 adjtimex system call,
which uses 64-bit integer for long in struct timex. But x32 long is
32 bit. This patch replaces long in struct timex with __kernel_long_t
if __BITS_PER_LONG == 64.
Signed-off-by: H.J. Lu
---
include/uapi/linux/timex.h | 46
Both x32 and x86-64 use the same struct shmid64_ds/shminfo64/shm_info for
system calls. But x32 long is 32-bit. This patch replaces unsigned long
with __kernel_ulong_t in struct shmid64_ds/shminfo64/shm_info if
__BITS_PER_LONG == 64.
Signed-off-by: H.J. Lu
---
include/uapi/asm-generic/shmbuf.h
Both x32 and x86-64 use the same struct msqid64_ds for system calls.
But x32 long is 32-bit. This patch replaces unsigned long with
__kernel_ulong_t in struct msqid64_ds if __BITS_PER_LONG == 64.
Signed-off-by: H.J. Lu
---
include/uapi/asm-generic/msgbuf.h | 19 ++-
1 file
1 - 100 of 216 matches
Mail list logo
