Cool Thanks for the fix.
Am Montag, den 01.04.2013, 05:04 -0700 schrieb Anatol Pomozov:
> Hi
>
>
> On Wed, Oct 3, 2012 at 1:51 AM, Stefani Seibold
> wrote:
> Hi,
>
> i am faced with a strange kernel crash while removing a
> loo
Hi,
i am faced with a strange kernel crash while removing a loopback device
with losetup, during a software update of my embedded device, which was
introduced between 3.0 and 3.4. All other used kernels 2.6.39, 2.6.35,
2.6.33, 2.6.29, 2.6.27 and 2.6.20 works well.
BUG: unable to handle kernel NUL
const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> - if (0) { \
> - typeof(__tmp->ptr) __dummy __attribute__ ((unused)) = NULL; \
> - __buf = __dummy; \
> - } \
> + ty
don't need do the type check. Remove it.
>
> LINK: https://lkml.org/lkml/2012/10/25/386
> LINK: https://lkml.org/lkml/2012/10/25/584
>
> Cc: Andrew Morton
> Cc: Wei Yang
> Cc: Stefani Seibold
> Cc: Fengguang Wu
> Cc: Stephen Rothwell
> Signed-off-by: Yuanhan
Am Freitag, den 26.10.2012, 06:36 +0800 schrieb Richard Yang:
> >
> >And holy cow that code is hard to read :( Why was kfifo_in()
> >implemented as a macro, anyway? AFAICT all its args have a known type,
> >so we could have used a proper C interface, which would have fixed all
> >this nicely.
>
Am Freitag, den 26.10.2012, 14:11 +0800 schrieb Yuanhan Liu:
> On Fri, Oct 26, 2012 at 07:38:31AM +0200, Stefani Seibold wrote:
> > Am Freitag, den 26.10.2012, 09:46 +0800 schrieb Yuanhan Liu:
> > > From: Yuanhan Liu
> > >
> > > Firstly, this kind of type c
Am Freitag, den 26.10.2012, 15:17 +0800 schrieb Yuanhan Liu:
> On Fri, Oct 26, 2012 at 08:51:06AM +0200, Stefani Seibold wrote:
> > Am Freitag, den 26.10.2012, 14:11 +0800 schrieb Yuanhan Liu:
> > > On Fri, Oct 26, 2012 at 07:38:31AM +0200, Stefani Seibold wrote:
> > > &
.
> Thanks,
> Yuanhan Liu
> -
>
> Cc: Stefani Seibold
> Cc: Andrew Morton
> Signed-off-by: Yuanhan Liu
> ---
> kernel/kfifo.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/kfifo.c b/kernel/kfifo.c
> index 59dc
Am Freitag, den 26.10.2012, 20:33 +0800 schrieb Yuanhan Liu:
> On Fri, Oct 26, 2012 at 11:30:27AM +0200, Stefani Seibold wrote:
> > Am Freitag, den 26.10.2012, 15:56 +0800 schrieb Yuanhan Liu:
> > > Say, if we want to allocate a filo with size of 6 bytes, it would be safer
&
Am Freitag, den 26.10.2012, 21:04 +0800 schrieb Yuanhan Liu:
> On Fri, Oct 26, 2012 at 11:26:31AM +0200, Stefani Seibold wrote:
> > Am Freitag, den 26.10.2012, 15:17 +0800 schrieb Yuanhan Liu:
> > > On Fri, Oct 26, 2012 at 08:51:06AM +0200, Stefani Seibold wrote:
> > > &
Am Dienstag, den 30.10.2012, 23:52 -0700 schrieb Andrew Morton:
> On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold
> wrote:
>
> > > Yes, and I guess the same to give them a 64-element one.
> > >
> > > >
> > > > If there's abso
Am Mittwoch, den 31.10.2012, 14:49 +0800 schrieb Yuanhan Liu:
> On Wed, Oct 31, 2012 at 07:30:33AM +0100, Stefani Seibold wrote:
> > Am Mittwoch, den 31.10.2012, 13:59 +0800 schrieb Yuanhan Liu:
> > > On Mon, Oct 29, 2012 at 01:59:35PM -0700, Andrew Morton wrote:
> > >
Am Mittwoch, den 31.10.2012, 13:59 +0800 schrieb Yuanhan Liu:
> On Mon, Oct 29, 2012 at 01:59:35PM -0700, Andrew Morton wrote:
> > On Fri, 26 Oct 2012 15:56:57 +0800
> > Yuanhan Liu wrote:
> >
> > > Say, if we want to allocate a filo with size of 6 bytes, it would be safer
> > > to allocate 8 byt
Hi,
i have tried to kexec a 32 bit kernel on a Freescale P2020 dual core CPU
(e500v2, revison 5.1 - pvr 8021 1051), but Kexec will hang after the
"Bye!".
The host and the kexec kernel are the same, based on the current kernel
version 3.10.
I have tried it with kexec-tools 2.0.4.git released 30 J
Am Mittwoch, den 10.07.2013, 16:48 +0800 schrieb tiejun.chen:
> On 07/10/2013 04:39 PM, Stefani Seibold wrote:
> > Hi,
> >
> > i have tried to kexec a 32 bit kernel on a Freescale P2020 dual core CPU
> > (e500v2, revison 5.1 - pvr 8021 1051), but Kexec will hang after
This was introduce by me to suppress a compiler warning, so don't remove
it.
Am Mittwoch, den 17.10.2012, 16:05 +0200 schrieb Jiri Kosina:
> On Wed, 17 Oct 2012, Richard Yang wrote:
>
> > >> This patch just remove this code.
> > >> ---
> > >> include/linux/kfifo.h |4
> > >> 1 files ch
Am Donnerstag, den 18.10.2012, 09:59 +0800 schrieb Richard Yang:
> On Wed, Oct 17, 2012 at 09:51:49PM +0200, Stefani Seibold wrote:
> >This was introduce by me to suppress a compiler warning, so don't remove
> >it.
> Which warning? I compile by removing this, but not find
Am Freitag, den 19.10.2012, 00:37 +0200 schrieb richard -rw- weinberger:
> On Thu, Oct 18, 2012 at 3:59 PM, Wei Yang wrote:
> > In kfifo_in marco, one piece of code is arounded by if(0). This code in
> > introduced by Stefani Seibold to suppress a compiler
> > warning. This
Am Dienstag, den 11.12.2012, 11:37 -0800 schrieb Andy Lutomirski:
> On Tue, Dec 11, 2012 at 8:11 AM, wrote:
> > From: Stefani Seibold
> >
> > This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> > and vdso_time() support to the VDSO for x86
Am Dienstag, den 11.12.2012, 11:27 -0800 schrieb John Stultz:
> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
> > From: Stefani Seibold
> >
> > This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> > and vdso_time() support to the
Am Dienstag, den 11.12.2012, 13:18 -0800 schrieb Andy Lutomirski:
> On Tue, Dec 11, 2012 at 12:54 PM, Stefani Seibold wrote:
> > Am Dienstag, den 11.12.2012, 11:27 -0800 schrieb John Stultz:
> >> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
> >> > From: Stefa
Am Freitag, den 09.11.2012, 10:32 +0800 schrieb Yuanhan Liu:
> On Thu, Nov 08, 2012 at 01:37:15PM +0100, Stefani Seibold wrote:
> > Am Donnerstag, den 08.11.2012, 20:24 +0800 schrieb Yuanhan Liu:
> Yes, it is. I will try log API then.
>
> Stefani, I found an issue while rew
Am Donnerstag, den 08.11.2012, 20:24 +0800 schrieb Yuanhan Liu:
> On Tue, Oct 30, 2012 at 11:52:10PM -0700, Andrew Morton wrote:
> > On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold
> > wrote:
> >
> > > > Yes, and I guess the s
Am Dienstag, den 18.12.2012, 08:17 -0800 schrieb H. Peter Anvin:
> On 12/18/2012 01:40 AM, stef...@seibold.net wrote:
> > From: Stefani Seibold
> >
> > This patch adds support for 32 bit VDSO.
> >
> > For 32 bit programs running on a 32 bit kernel, the same me
Am Dienstag, den 18.12.2012, 10:44 -0800 schrieb H. Peter Anvin:
> On 12/18/2012 08:52 AM, Stefani Seibold wrote:
> >
> > Pardon, i never disregarded nor i have agreed that this is going to be a
> > part of the VDSO. I currently have also no idea how to do this and i see
>
Am Dienstag, den 18.12.2012, 12:37 -0800 schrieb Andy Lutomirski:
> On Tue, Dec 18, 2012 at 12:32 PM, Stefani Seibold wrote:
> > Am Dienstag, den 18.12.2012, 10:44 -0800 schrieb H. Peter Anvin:
> >> On 12/18/2012 08:52 AM, Stefani Seibold wrote:
> >> >
> >&
on. Again:
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 AFTER the page, so it is not
possible to have VVAR or HPET as a part of that list
> Stefani Se
I have cross checked this use case. This was tested, but i doesn't work
any more. So i need a little bit time to fix it. The macro for this are
a little bit tricky, but i think there is a way to solve this issue.
For the next two weeks i am heavy busy in a final project stage, so
please be patient
This patch add a missing usb device id for the GDMBoost V1.x device
The patch is against 3.9-rc5
Signed-off-by: Stefani Seibold
---
ftdi_sio.c |1 +
ftdi_sio_ids.h |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
Am Mittwoch, den 12.12.2012, 15:34 -0800 schrieb H. Peter Anvin:
> On 12/12/2012 12:19 PM, stef...@seibold.net wrote:
> > diff --git a/arch/x86/vdso/vdso32/vclock_gettime.c
> > b/arch/x86/vdso/vdso32/vclock_gettime.c
> > new file mode 100644
> > index 000..c9a1909
> > --- /dev/null
> > +++ b/a
Am Mittwoch, den 12.12.2012, 22:14 -0800 schrieb H. Peter Anvin:
> This is too late for 3.8 anyway, so there is time to make it work correctly
> before tge 3.9 merge window anyway. After this merge window is over I may
> pull tjis into a testing branch, but compat support is a precondition.
>
>
Am Mittwoch, den 12.12.2012, 22:47 -0800 schrieb H. Peter Anvin:
> Should be a simple matter of sharing pages. Look perhaps at the x32 vdso for
> a hint.
>
> >
> >Any idea or clean solution how i can map the 64 bit vgtod into the 32
> >bit address space? Thats the only problem i see.
> >
No,
Am Freitag, den 14.12.2012, 14:46 -0800 schrieb H. Peter Anvin:
> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> > On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> >> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
> >>> Wouldn't the vdso get mapped already and could be mremap()'d. If we
type of the fifo can be
converted to the passed type of the destination.
So a big NAK!
> v2: remove ptr and const_ptr, which were used for type checking.
>
> LINK: https://lkml.org/lkml/2012/10/25/386
> LINK: https://lkml.org/lkml/2012/10/25/584
>
> Cc: Stefani Seibold
>
Am Mittwoch, den 09.01.2013, 10:35 +0800 schrieb Yuanhan Liu:
> On Tue, Jan 08, 2013 at 10:51:04PM +0100, Stefani Seibold wrote:
> > Am Dienstag, den 08.01.2013, 22:57 +0800 schrieb Yuanhan Liu:
> > > Firstly, this kind of type check doesn't work. It does something sim
31 18:27:57 2000
+++ linux.noprintk/CREDITS Fri Jan 26 10:51:19 2001
@@ -2395,6 +2395,14 @@
S: Oldenburg
S: Germany
+N: Stefani Seibold
+E: [EMAIL PROTECTED]
+D: Possibility to disable all kernel messages by overload printk with a
+D: dummy macro (saves a lot of disk- and ramspace for embedded
7 2000
+++ linux.noprintk/CREDITS Fri Jan 26 10:51:19 2001
@@ -2395,6 +2395,14 @@
S: Oldenburg
S: Germany
+N: Stefani Seibold
+E: [EMAIL PROTECTED]
+D: Possibility to disable all kernel messages by overload printk with a
+D: dummy macro (saves a lot of disk- and ramspace for embedded systems
... I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard
> god...
> Stefani Seibold wrote:
> > this kernel patch allows to disable all printk messages, by overloading
> > the printk function with a dummy printk macro.
> >
> > This patch is use
+2395,14 @@
S: Oldenburg
S: Germany
+N: Stefani Seibold
+E: [EMAIL PROTECTED]
+D: Possibility to disable all kernel messages by overload printk with a
+D: dummy macro (saves a lot of disk- and ramspace for embedded systems
+D: and rescue disks)
+S: Munich
+S: Germany
+
N: Darren Senn
E: [EMAIL
appear in
the output.
The inline function is the best choice, because it it full compatible to old
old printk. No side effects are expeted.
Thanks also for the link. I had a look on it and i think i will add a extrac
option to disable also the panic messages.
Greetings,
Stefani
> Stef
EDITS Fri Jan 26 10:51:19 2001
@@ -2395,6 +2395,14 @@
S: Oldenburg
S: Germany
+N: Stefani Seibold
+E: [EMAIL PROTECTED]
+D: Possibility to disable all kernel messages by overload printk with a
+D: dummy macro (saves a lot of disk- and ramspace for embedded systems
+D: and rescue disks)
+S: M
Am Montag, 29. Januar 2001 18:40 schrieb James Simmons:
> > You are right... this patch make no sense on a computer system with human
> > interactions. But think on tiny hidden computers, like in a dishwasher or
> > a traffic light. This computer are standalone, if it crash, then it will
> > be re
6 10:51:19 2001
@@ -2395,6 +2395,14 @@
S: Oldenburg
S: Germany
+N: Stefani Seibold
+E: [EMAIL PROTECTED]
+D: Possibility to disable all kernel messages by overload printk with a
+D: dummy macro (saves a lot of disk- and ramspace for embedded systems
+D: and rescue disks)
+S: Munich
+S: Germany
+
2001
@@ -2396,6 +2396,14 @@
S: Oldenburg
S: Germany
+N: Stefani Seibold
+E: [EMAIL PROTECTED]
+D: Option to disable all kernel messages by overload printk with a
+D: dummy macro (saves a lot of disk- and ramspace for embedded systems
+D: and rescue disks).
+S: Munich
+S: Germany
+
N: Darren Senn
@ -2396,6 +2396,14 @@
S: Oldenburg
S: Germany
+N: Stefani Seibold
+E: [EMAIL PROTECTED]
+D: Option to disable all kernel messages by overload printk with a
+D: dummy macro (saves a lot of disk- and ramspace for deeply embedded
+D: systems and maybe for rescue disks).
+S: Munich
+S: Germany
+
N
4PM +0100, Stefani Seibold wrote:
> > Hi folks,
> >
> > sorry about the previous patch, it was my test code, which will not
> > work
>
> You should also notify the IRDA maintainer as listed in the MAINTAINERS
> file: [EMAIL PROTECTED]
>
> Linus and Alan wil
Hi,
the question is how can i get all pte's from a vmalloc'ed memory. Due to
the zeroed mapping pointer i dont see how to do this?
Am Dienstag, den 30.10.2007, 10:56 +0100 schrieb Peter Zijlstra:
> On Mon, 2007-10-29 at 21:22 -0400, Jaya Kumar wrote:
> > On 10/29/07, Peter Zijlstra <[EMAIL PROTE
Hi,
i have a problem with vmalloc() and vm_ops.page_mkwrite().
ReadOnly access works, but on a write access the VM will
endless invoke the vm_ops.page_mkwrite() handler.
I tracked down the problem to the
struct page.mapping pointer,
which is NULL.
The problem original occurs with the fb
Hi,
i still wait for ACK's for the 32 bit VDSO time function support. Whats
the next step? Is there a way to apply it to the linux-git or linux-next
in near future?
- Stefani
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.k
Am Dienstag, den 11.03.2014, 10:09 -0700 schrieb Linus Torvalds:
> On Tue, Mar 11, 2014 at 9:50 AM, Andy Lutomirski wrote:
> > Looking forward, would it be reasonable to have an extensible set of
> > flags that live in the ELF interpreter's headers somewhere
>
> No. Not reasonable. The whole "32-
This patch enables 32 bit vDSO which are larger than a page. Currently
two pages are reserved, this should be enough for future improvements.
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/fixmap.h | 4 +++-
arch/x86/vdso/vdso32-setup.c | 29 +++--
2 files
This patch bring some improvments to the vDSO 32 bit:
- undef some kernel configs which increase the code size of the VDSO
- remove vsyscall and prevent wrong conditional VVAR_PAGE mapping
- handle VDSO larger than a page
The patch set is agains tip 7ed5ee279499a02bf35c77f0a91d657c24f6474e
--
To
In case of a 32 bit vDSO build the CONFIG_OPTIMIZE_INLINING and
CONFIG_X86_PPRO_FENCE options will increase the size of the generated
vDSO not to fit in a page.
A #undef of this config options will solve this.
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vdso32/vclock_gettime.c | 6
vsyscall_32.c has not much code in it and the only function map_vsyscall()
was invoked prior to vdso_setup() which results in wrong conditional
mapping of VVAR_PAGE.
Moving the whole fixmap initialization into map_compat_vdso() will
solve this calling dependences.
Signed-off-by: Stefani Seibold
Am Mittwoch, den 12.03.2014, 20:48 -0700 schrieb H. Peter Anvin:
> On 03/12/2014 04:11 PM, stef...@seibold.net wrote:
> >
> > I will do this when your patch is pulled into tip. For now we have the
> > choice, but i preferer our solution removing the compat vdso.
> >
>
> Sorry, that didn't parse
Am Donnerstag, den 13.03.2014, 15:08 -0700 schrieb H. Peter Anvin:
> On 03/13/2014 01:11 AM, Stefani Seibold wrote:
> > Am Mittwoch, den 12.03.2014, 20:48 -0700 schrieb H. Peter Anvin:
> >> On 03/12/2014 04:11 PM, stef...@seibold.net wrote:
> >>>
> >>> I w
Hi,
i want ask if there is a change to bring the patch back to tip?
As requested the glibc patch is now available at
http://seibold.net/glibc.patch
Any idea how to bring this patch into glibc? Is the process similar to
the kernel?
- Stefani
--
To unsubscribe from this list: send the line "un
Am Montag, den 03.03.2014, 23:20 -0800 schrieb H. Peter Anvin:
> Pretty much... contact the glibc maintainers. However, with glibc being a
> GNU project you will have to sign a copyright transfer.
>
> On March 3, 2014 11:02:08 PM PST, Stefani Seibold wrote:
> >Hi,
> >
Hi,
again i want ask if there is a change to bring the patch back to tip
and/or linux next?
I also need a review of [Patch v22 10/12] x86: Add 32 bit VDSO time
support for 64 bit kernel.
Some more tests and acked-by would be also fine :-)
Till the 32 bit VDSO time functions are not in the vanil
Am Donnerstag, den 27.02.2014, 16:18 -0800 schrieb Andy Lutomirski:
> rdtsc_barrier() needs this.
>
Thanks for doing this.
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/include/asm/vdso.h | 2 ++
> arch/x86/vdso/vdso32-setup.c | 25 +
> arch/x86/vdso/vma.c
Am Mittwoch, den 26.02.2014, 16:55 -0800 schrieb Andy Lutomirski:
> Um. This code doesn't work. I'll send a patch. I can't speak
> towards how well it compiles in different configurations.
>
> I can't speak towards how well it compiles in different
> configurations. Also, vdso_fallback_gettime
Am Donnerstag, den 27.02.2014, 16:18 -0800 schrieb Andy Lutomirski:
> There's no reason for the vDSO to use a special function call ABI. Use
> the platform defaults.
>
The only reason was performance. What is good for the kernel should be
also good for the VDSO. Now all functions inside the VDSO
ins the clock code should review the changes in:
>
> commit 0fc8a237cbe98a06962f5ea37d24fc2369e23c74
> Author: Stefani Seibold
> Date: Wed Feb 19 10:09:10 2014 +0100
>
> x86, vdso: Add 32-bit VDSO time support for the 64-bit kernel
>
> very
Am Freitag, den 28.02.2014, 12:19 -0800 schrieb Andy Lutomirski:
> On Fri, Feb 28, 2014 at 7:06 AM, H. Peter Anvin wrote:
> > How many internal function calls are there? It seems we should try to avoid
> > those as much as possible by suitable inlining.
>
> There are no non-static calls at all,
Am Freitag, den 28.02.2014, 12:15 -0800 schrieb Andy Lutomirski:
> On Thu, Feb 27, 2014 at 11:33 PM, Stefani Seibold wrote:
> > Am Donnerstag, den 27.02.2014, 16:18 -0800 schrieb Andy Lutomirski:
> >> I'd still like someone else to confirm that the 32-bit vDSO is wor
Am Donnerstag, den 27.02.2014, 16:18 -0800 schrieb Andy Lutomirski:
> rdtsc_barrier() needs this.
>
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/include/asm/vdso.h | 2 ++
> arch/x86/vdso/vdso32-setup.c | 25 +
> arch/x86/vdso/vma.c | 9 ++---
> 3 fil
Am Samstag, den 01.03.2014, 14:56 -0800 schrieb H. Peter Anvin:
> On 02/28/2014 06:00 PM, Andy Lutomirski wrote:
> >
> > This leads to a potentially interesting question: is rdtsc_barrier()
> > actually necessary on UP? IIRC the point is that, if an
> > rdtsc_barrier(); rdtsc in one thread is "be
There a currently more than 30 users of the gtod macro, so replace the
last VVAR(vsyscall_gtod_data) by gtod macro.
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vclock_gettime.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch
rdtsc_barrier() needs this.
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vdso.h | 2 ++
arch/x86/vdso/Makefile | 3 ++-
arch/x86/vdso/vdso32-setup.c | 25 +
arch/x86/vdso/vma.c | 13 ++---
4 files changed, 27 insertions(+), 16
bit address space. This will be done
with io_remap_pfn_range() and remap_pfn_range, which requieres a vm_area_struct.
Signed-off-by: Stefani Seibold
---
include/linux/mm.h | 3 +++
mm/mmap.c | 20
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/include
This patch do a little cleanup for the __vdso_gettimeofday() function.
It kick out an unneeded ret local variable and makes the code faster if
only the timezone is needed.
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vclock_gettime.c | 7 ++-
1 file changed, 2 insertions(+), 5
This patch is a small code cleanup for the __vdso_clock_gettime() function.
It removes the unneeded return values from do_monotonic_coarse() and
do_realtime_coarse() and add a fallback label for doing the kernel
gettimeofday() system call.
Signed-off-by: Stefani Seibold
---
arch/x86/vdso
This intermediate patch revamps the vclock_gettime.c by moving some functions
around. It is only for spliting purpose, to make whole the 32 bit vdso timer
patch easier to review.
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vclock_gettime.c | 85 +-
1
This patch move the vsyscall_gtod_data handling out of vsyscall_64.c
into an additonal file vsyscall_gtod.c to make the functionality
available for x86 32 bit kernel.
It also adds a new vsyscall_32.c which setup the VVAR page.
Signed-off-by: Stefani Seibold
---
arch/x86/Kconfig
This patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() to the 32 bit VDSO.
The reason to do this was to get a fast reliable time stamp. Many developers
uses TSC to get a fast time stamp, without knowing the pitfalls. VDSO
time functions a fast and a reliable way, be
This patch revamp the vvar.h for introduce the VVAR macro for vdso32.
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vvar.h | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
index 0a534ea
This patch add the time support for 32 bit a VDSO to a 32 bit kernel.
For 32 bit programs running on a 32 bit kernel, the same mechanism is
used as for 64 bit programs running on a 64 bit kernel.
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vdso.h | 3 ++
arch/x86/include
exposed to userspace.
Signed-off-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/kernel/vmlinux.lds.S | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 1d4897b..49edf2d 100644
--- a/arch/x86/kernel/vmlinux.lds.S
32- and 64-bit access
- The inner struct clock was removed to pack the whole struct.
The "unsigned seq" would be handled by functions derivated from seqcount_t.
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vgtod.h | 71 +--
arch/x86/include/
This patch move the vsyscall_gtod_data handling out of vsyscall_64.c
into an additonal file vsyscall_gtod.c to make the functionality
available for x86 32 bit kernel.
It also adds a new vsyscall_32.c which setup the VVAR page.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
This patch revamp the vvar.h for introduce the VVAR macro for vdso32.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vvar.h | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include
From: Andy Lutomirski
rdtsc_barrier() needs this.
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vdso.h | 2 ++
arch/x86/vdso/Makefile | 3 ++-
arch/x86/vdso/vdso32-setup.c | 25 +
arch/x86/vdso/vma.c | 13 ++---
4 files changed, 27
This patch add the time support for 32 bit a VDSO to a 32 bit kernel.
For 32 bit programs running on a 32 bit kernel, the same mechanism is
used as for 64 bit programs running on a 64 bit kernel.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vdso.h
There a currently more than 30 users of the gtod macro, so replace the
last VVAR(vsyscall_gtod_data) by gtod macro.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vclock_gettime.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86
This patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() to the 32 bit VDSO.
The reason to do this was to get a fast reliable time stamp. Many developers
uses TSC to get a fast time stamp, without knowing the pitfalls. VDSO
time functions a fast and a reliable way, be
This intermediate patch revamps the vclock_gettime.c by moving some functions
around. It is only for spliting purpose, to make whole the 32 bit vdso timer
patch easier to review.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vclock_gettime.c | 85
This patch do a little cleanup for the __vdso_gettimeofday() function.
It kick out an unneeded ret local variable and makes the code faster if
only the timezone is needed.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vclock_gettime.c | 7 ++-
1 file
bit address space. This will be done
with io_remap_pfn_range() and remap_pfn_range, which requieres a vm_area_struct.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
include/linux/mm.h | 3 +++
mm/mmap.c | 20
2 files changed, 19 insertions(+), 4
This patch is a small code cleanup for the __vdso_clock_gettime() function.
It removes the unneeded return values from do_monotonic_coarse() and
do_realtime_coarse() and add a fallback label for doing the kernel
gettimeofday() system call.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani
32- and 64-bit access
- The inner struct clock was removed to pack the whole struct.
The "unsigned seq" would be handled by functions derivated from seqcount_t.
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vgtod.h | 71 +--
arch/x86/include/
of memory that is exposed to userspace.
Signed-off-by: Stefani Seibold
---
arch/x86/kernel/vmlinux.lds.S | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 1d4897b..49edf2d 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++
bit address space. This will be done
with io_remap_pfn_range() and remap_pfn_range, which requieres a vm_area_struct.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
include/linux/mm.h | 3 +++
mm/mmap.c | 20
2 files changed, 19 insertions(+), 4
There a currently more than 30 users of the gtod macro, so replace the
last VVAR(vsyscall_gtod_data) by gtod macro.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vclock_gettime.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86
This patch revamps the vvar.h for introduce the VVAR macro for vdso32.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vvar.h | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include
This patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() to the x86 32 bit VDSO.
The reason to do this was to get a fast reliable time stamp. Many developers
uses TSC to get a fast time stamp, without knowing the pitfalls. VDSO
time functions a fast and a reliable way
This patch do a little cleanup for the __vdso_gettimeofday() function.
It kicks out an unneeded ret local variable and makes the code faster
if only the timezone is needed (an admittedly rare case.)
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vclock_gettime.c
From: Andy Lutomirski
We need the alternatives mechanism for rdtsc_barrier() to work.
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vdso.h | 2 ++
arch/x86/vdso/Makefile | 3 ++-
arch/x86/vdso/vdso32-setup.c | 23 ---
arch/x86/vdso/vma.c | 13
This patch add the time support for 32 bit a VDSO to a 32 bit kernel.
For 32 bit programs running on a 32 bit kernel, the same mechanism is
used as for 64 bit programs running on a 64 bit kernel.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/include/asm/vdso.h
This patch is a small code cleanup for the __vdso_clock_gettime() function.
It removes the unneeded return values from do_monotonic_coarse() and
do_realtime_coarse() and add a fallback label for doing the kernel
gettimeofday() system call.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani
This intermediate patch revamps the vclock_gettime.c by moving some functions
around. It is only for spliting purpose, to make whole the 32 bit vdso timer
patch easier to review.
Reviewed-by: Andy Lutomirski
Signed-off-by: Stefani Seibold
---
arch/x86/vdso/vclock_gettime.c | 85
1 - 100 of 263 matches
Mail list logo
