mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefani Seibold <stefani@seibold.net>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <ak@linux.intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	John Stultz <john.stultz@linaro.org>,
	Pavel Emelyanov <xemul@parallels.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	andriy.shevchenko@linux.intel.com,
	Martin.Runge@rohde-schwarz.com, Andreas.Brief@rohde-schwarz.com
Subject: Re: [PATCH v12 9/9] Add 32 bit VDSO time support for 64 bit kernel
Date: Thu, 06 Feb 2014 13:10:00 +0100	[thread overview]
Message-ID: <1391688600.29423.15.camel@wall-e.seibold.net> (raw)
In-Reply-To: <CALCETrUx7iSquojTuYzoVZ_Pbi8NW7Wvs-CXSh3GEjMd-diRKQ@mail.gmail.com>

Am Mittwoch, den 05.02.2014, 14:01 -0800 schrieb Andy Lutomirski:
> On Wed, Feb 5, 2014 at 12:20 AM,  <stefani@seibold.net> wrote:
> > From: Stefani Seibold <stefani@seibold.net>
> >
> > This patch add the VDSO time support for the IA32 Emulation Layer.
> >
> > Due the nature of the kernel headers and the LP64 compiler where the
> > size of a long and a pointer differs against a 32 bit compiler, there
> > is some type hacking necessary.
> >
> > The vsyscall_gtod_data struture must be a little bit rearranged, to
> > serve 32- and 64-bit code access:
> >
> > - The seqcount_t was replaced by an unsigned, this makes the
> >   vsyscall_gtod_data intedepend of kernel configuration and internal functions.
> > - The structure is now packed, so it can accessed from 32- und 64- bit
> >   code at the same time.
> > - The inner struct clock was removed, to make packing of the while
> >   struct easier.
> >
> > The "unsigned seq" would be handled by functions derivated from seqcount_t.
> >
> > Signed-off-by: Stefani Seibold <stefani@seibold.net>
> > ---
> >  arch/x86/include/asm/vgtod.h          |  20 +++---
> >  arch/x86/kernel/vsyscall_gtod.c       |  26 +++++--
> >  arch/x86/vdso/vclock_gettime.c        | 129 ++++++++++++++++++++++++----------
> >  arch/x86/vdso/vdso32/vclock_gettime.c |  11 +++
> >  include/uapi/linux/time.h             |   2 +-
> >  5 files changed, 132 insertions(+), 56 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
> > index 46e24d3..2567b02 100644
> > --- a/arch/x86/include/asm/vgtod.h
> > +++ b/arch/x86/include/asm/vgtod.h
> > @@ -4,16 +4,18 @@
> >  #include <asm/vsyscall.h>
> >  #include <linux/clocksource.h>
> >
> > -struct vsyscall_gtod_data {
> > -       seqcount_t      seq;
> > +/*
> > + * vsyscall_gtod_data will be accessed by 32 and 64 bit code at the same time
> > + * so the structure must be packed
> > + */
> > +struct __attribute__((packed)) vsyscall_gtod_data {
> > +       unsigned seq;
> 
> Is that actually true?  At least in the part you're changing,
> everything looks like it's aligned correctly.
> 

Yes, i know. But for convenient this is less error prone when modifying
the structure. I can kick it out if you insist.
 
> It's almost certainly having some kind of BUILD_BUG_ON that will catch
> the case where this structure's size changes.  I suspect that some
> kind of asm-offsets magic can be used for this.
> 

This kind af ASM magic wan't work, because the code will be compiled
with -m32 for a 32 bit VDSO but will access a structure generated with a
64 bit compiler.

> >
> > -       struct { /* extract of a clocksource struct */
> > -               int vclock_mode;
> > -               cycle_t cycle_last;
> > -               cycle_t mask;
> > -               u32     mult;
> > -               u32     shift;
> > -       } clock;
> > +       int vclock_mode;
> > +       cycle_t cycle_last;
> > +       cycle_t mask;
> > +       u32     mult;
> > +       u32     shift;
> >
> >         /* open coded 'struct timespec' */
> >         time_t          wall_time_sec;
> > diff --git a/arch/x86/kernel/vsyscall_gtod.c b/arch/x86/kernel/vsyscall_gtod.c
> > index 91862a4..ca48248 100644
> > --- a/arch/x86/kernel/vsyscall_gtod.c
> > +++ b/arch/x86/kernel/vsyscall_gtod.c
> > @@ -16,6 +16,18 @@
> >
> >  DEFINE_VVAR(struct vsyscall_gtod_data, vsyscall_gtod_data);
> >
> > +static inline void gtod_write_begin(unsigned *s)
> > +{
> > +       ++*s;
> > +       smp_wmb();
> > +}
> > +
> > +static inline void gtod_write_end(unsigned *s)
> > +{
> > +       smp_wmb();
> > +       ++*s;
> > +}
> > +
> 
> Someone else should probably comment on the style for this.  Maybe
> this should live in a header somewhere.  IMO if it's called
> gtod_write_begin, it should take a pointer to gtod as a parameter.
> 

Fixed in the next version.

> 
> > +struct api_timeval {
> > +       long    tv_sec;         /* seconds */
> > +       long    tv_usec;        /* microseconds */
> > +};
> > +
> > +struct api_timespec {
> > +       long    tv_sec;         /* seconds */
> > +       long    tv_nsec;        /* nanoseconds */
> > +};
> 
> Did you address my question about why there are two versions of this?
> Shouldn't it just match the userspace headers regardless of what the
> host kernel is?
> 

Again, -m32 compilation. The timeval and timespec are __kernel_long_t,
which is defined as "long long" in a case of 32 bit VDSO for 64 bit
kernel.

The vsyscall_gtod_data use the kernel defined timeval and timespec, so
for 32 bit a conversation is needed.

The only way to prevent this kind of hack is to replace the struct
timespec and time_t members of vsyscall_gtod_data by a compiler independ
definition.

In this case it would be also necessary to have an own copy of
timespec_add_ns() function for the VDSO.

> You have *still* not responded to my objection to the unconditional fixmaps.
> 

I have responded this objection on monday. If i enable the sysctl
interface i need this mapping too.

- Stefani



      reply	other threads:[~2014-02-06 12:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-05  8:19 [PATCH v12 0/9] Add 32 bit VDSO time function support stefani
2014-02-05  8:19 ` [PATCH v12 1/9] Make vsyscall_gtod_data handling x86 generic stefani
2014-02-05  8:19 ` [PATCH v12 2/9] Add new func _install_special_mapping() to mmap.c stefani
2014-02-05  8:19 ` [PATCH v12 3/9] revamp vclock_gettime.c stefani
2014-02-05  8:19 ` [PATCH v12 4/9] vclock_gettime.c __vdso_clock_gettime cleanup stefani
2014-02-05  8:20 ` [PATCH v12 5/9] replace VVAR(vsyscall_gtod_data) by gtod macro stefani
2014-02-05  8:20 ` [PATCH v12 6/9] cleanup __vdso_gettimeofday stefani
2014-02-05  8:20 ` [PATCH v12 7/9] introduce VVAR marco for vdso32 stefani
2014-02-05  8:20 ` [PATCH v12 8/9] Add 32 bit VDSO time support for 32 bit kernel stefani
2014-02-05  8:20 ` [PATCH v12 9/9] Add 32 bit VDSO time support for 64 " stefani
2014-02-05 22:01   ` Andy Lutomirski
2014-02-06 12:10     ` Stefani Seibold [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1391688600.29423.15.camel@wall-e.seibold.net \
    --to=stefani@seibold.net \
    --cc=Andreas.Brief@rohde-schwarz.com \
    --cc=Martin.Runge@rohde-schwarz.com \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=gorcunov@openvz.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®